Event visualization for asset condition monitoring

Abstract

The present invention provides a system and method for asset management. Event data representing events experienced by assets distributed between different stations of a queue is maintained. The event data includes the asset position within the asset hierarchy of the queue and event parameters corresponding to the event. A graphical user interface (GUI) is generated to display a first window, the first window including a hierarchical list of assets organized according to the position of the assets within the asset hierarchy. When the GUI receives a selection of a level within the hierarchical list, events associated with the selected level can be identified. The identified event can be classified as a unique event that occurs once or as a recurring event that occurs multiple times based on the event data of the identified event. In response to receiving the selection, the GUI is updated to display a second window, the second window listing a single entry for the corresponding unique event and a single entry for the corresponding recurring event.

Description

Background Art

[0001] Many industries, such as hydrocarbon extraction, refining, and power generation, may rely heavily on the operation of assets (e.g., machinery), and in some cases, on the continued operation of such assets. In these environments, unplanned asset downtime and / or failures may have serious consequences, including costs due to lost production and / or expenses, potential injuries to workers, and so on. Given these risks, it may be common to monitor selected parameters of various assets during operation. Measurements of operating parameters can provide an indication of the condition of the corresponding asset components, as well as the condition of the asset as a whole. Thus, deviations between normal operation and asset operation can be identified and addressed to avoid asset downtime and / or failures. Consequently, asset condition monitoring can provide a variety of long-term benefits, such as lower production costs, reduced equipment downtime, improved reliability, and enhanced safety. Summary of the Invention

[0002] Condition monitoring systems can be configured to report various events that characterize deviations in asset performance from predetermined normal operating conditions. For example, setpoints can be used to define a normal operating range, and measurements of operating parameters outside this range can be flagged as events. However, it is understood that if the measured operating parameter fluctuates around the setpoint, the event log may be filled with more events than an operator needs to effectively analyze the cause of the triggering event. Furthermore, existing condition monitoring systems often present events as lists. Therefore, when duplicate events are recorded, it can be difficult to identify the unique event that caused the triggering event.

[0003] Additionally, many condition monitoring platforms do not combine events with supporting data and may require operators to navigate between different applications and / or computing devices to compare event details with supporting data. This situation increases the time required for operators to gather the information needed to diagnose event triggers, which may be undesirable in time-critical situations.

[0004] Thus, as discussed in detail below, provided herein are systems and methods for improving visualization of events recorded by a condition monitoring system.

[0005] In an embodiment, an asset management system is provided and may include a historian and an event analyzer. The historian may be configured to maintain a plurality of event data representing one or more events experienced by respective assets in a plurality of assets. The plurality of assets may be distributed across different stations in a queue, and the event data may include at least one position of the asset within an asset hierarchy of the queue and at least one event parameter corresponding to the event. The event analyzer includes one or more processors configured to receive the plurality of event data and perform operations including generating a graphical user interface (GUI) to display a first window. The first window may include a hierarchical list of the assets organized according to their positions within the asset hierarchy of the queue. The operations may also include receiving, within the GUI, a first user selection of a hierarchical level within the hierarchical list. The operations may further include identifying a plurality of events associated with the hierarchical level selected by the first user. The operations may also include classifying, based on the corresponding event data of the identified plurality of events, at least a portion of the identified plurality of events as single-occurrence unique events within the plurality of events or multiple-occurrence recurring events within the plurality of events. The operations may further include updating the GUI to display a second window in response to receiving the first user selection. The second window may include a list including a single entry for a corresponding unique event and a single entry for a corresponding recurring event in the first plurality of events.

[0006] In another embodiment, the event analyzer may be further configured to perform operations comprising: receiving, within the GUI, a second user selection of an event from the list; and updating the GUI to display at least one third window in response to receiving the second user selection. The third window may include event data corresponding to the selected event.

[0007] In another embodiment, the third window may include a first sub-window that displays a most recent occurrence of a selected event including a first portion of the at least one event parameter.

[0008] In another embodiment, the event data may further include at least one recommendation, and the third window may include a second sub-window displaying the at least one recommendation.

[0009] In another embodiment, the third window may include a third sub-window displaying all occurrences of the selected event, and each displayed occurrence may include a corresponding second portion of the at least one event parameter for each occurrence.

[0010] In another embodiment, the event data may further include measured operational data about the asset before, during, and after the selected event, and the third window may further include a fourth sub-window that includes a graph displaying at least a portion of the measured operational data.

[0011] In another embodiment, the event analyzer may be further configured to perform operations including updating the GUI to display a fourth window in response to receiving the first user selection. The fourth window may include a performance summary at a selected hierarchy level based on the event data corresponding to the first plurality of events.

[0012] In another embodiment, the asset hierarchy of a queue may include two or more of a queue level, a site level, an asset group level, or an asset level.

[0013] In another embodiment, the event analyzer can be configured to classify an event as a unique event when at least one event parameter corresponding to the event does not match another event in the plurality of events. The event analyzer can be further configured to classify an event as a duplicate event when at least one event parameter corresponding to the event matches all at least one event parameter of another event in the plurality of events.

[0014] In another embodiment, the at least one event parameter may include at least one of a measurement type, a measurement point, an event type, an event level, an event source, or an asset status.

[0015] In another embodiment, the event may be at least one of an alarm, a condition monitoring system health event, an instrument health event, or an analytical health event.

[0016] In another embodiment, a method of asset management is provided. The method may include maintaining, by one or more processors, a plurality of event data representing one or more events experienced by respective assets from a plurality of assets. The plurality of assets may be distributed across different stations in a queue, and the event data may include at least one position of the asset within an asset hierarchy of the queue and at least one event parameter corresponding to the event. The method may also include receiving, by the one or more processors, the plurality of event data. The method may also include generating, by the one or more processors, a graphical user interface (GUI) that displays a first window. The first window may include a hierarchical list of assets organized according to their positions within the asset hierarchy of the queue. The method may further include receiving, within the GUI, a first user selection of a hierarchical level within the hierarchical list. The method may further include identifying, by the one or more processors, a plurality of events associated with the first user-selected hierarchical level. The method may also include classifying, by the one or more processors, at least a portion of the identified plurality of events as a single occurrence of a unique event within the plurality of events or a multiple occurrence of a recurring event within the plurality of events based on the corresponding event data of the identified plurality of events. The method may also include updating, by the one or more processors, the GUI to display a second window in response to receiving the first user selection. The second window may include a second list including a single entry for a corresponding unique event and a single entry for a corresponding repeating event in the first plurality of events.

[0017] In another embodiment, the method may further include receiving, within the GUI, a second user selection of an event from the second list. The method may further include updating, by the one or more processors, the GUI to display at least one third window in response to receiving the second user selection, and the third window may include event data corresponding to the selected event.

[0018] In another embodiment, the third window includes a first sub-window that displays a most recent occurrence of a selected event including a first portion of the at least one event parameter.

[0019] In another embodiment, the event data may further include at least one recommendation, and the third window may include a second sub-window displaying the at least one recommendation.

[0020] In another embodiment, the third window may include a third sub-window displaying all occurrences of the selected event, and each displayed occurrence may include a corresponding second portion of the at least one event parameter for each occurrence.

[0021] In another embodiment, the event data may further include measured operational data about the asset before, during, and after the selected event, and the third window may include a fourth sub-window that includes a graph displaying at least a portion of the measured operational data.

[0022] In another embodiment, the method may further include updating, by the one or more processors, in response to receiving the first user selection, the GUI to display a fourth window. The fourth window may include a performance summary at a selected hierarchy level based on the event data corresponding to the first plurality of events.

[0023] In another embodiment, the asset hierarchy of a queue may include two or more of a queue level, a site level, an asset group level, or an asset level.

[0024] In another embodiment, when at least one event parameter corresponding to an event does not match another event in a plurality of events, the event may be classified as a unique event by one or more processors. In another embodiment, when at least one event parameter corresponding to an event matches all at least one event parameter of another event in a plurality of events, the event may be classified as a duplicate event by one or more processors.

[0025] In another embodiment, the at least one event parameter may include at least one of a measurement type, a measurement point, an event type, an event level, an event source, or an asset status.

[0026] In another embodiment, the event may be at least one of an alarm, a condition monitoring system health event, an instrument health event, and an analytical health event. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] These and other features will be more readily understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0028] Figure 1 is a schematic diagram illustrating an exemplary embodiment of an operating environment including an improved visualization system for condition monitoring of assets including an event analyzer;

[0029] Figure 2 It is shown by Figure 1 a schematic diagram of an exemplary embodiment of a graphical user interface (GUI) generated by an event analyzer of FIG. 1 , the GUI including a first window (e.g., 202) presenting a hierarchical list of assets of a queue (e.g., queue level, site level, group level, machine / component level, etc.), a second window (e.g., 204) listing unique events and aggregated recurring events occurring within a selected level within the hierarchical list, and a third window providing detailed supporting data regarding an event selected from the second window;

[0030] Figure 3A is shown after selecting a hierarchy level from the list in the first window and an event from the list in the second window Figure 2 Schematic diagram of the GUI;

[0031] Figure 3B is a schematic diagram illustrating the GUI of FIG. 3 , further comprising a graph of one or more operational parameter measurements corresponding to an event selected in the second window; and

[0032] Figure 4 is a flow chart illustrating one exemplary embodiment of a method of visualizing events for condition monitoring.

[0033] It should be noted that the drawings are not necessarily drawn to scale.The drawings are intended to depict only typical aspects of the subject matter disclosed herein, and therefore should not be considered as limiting the scope of the disclosure. DETAILED DESCRIPTION

[0034] Assets (e.g., machines, machine parts, etc.) can be monitored by one or more sensors to ensure that they are operating properly. A condition monitoring system can be used to review sensor measurements, detect when an asset is operating abnormally, and determine whether to log an event (e.g., an alarm). Operations engineers can review logged events to determine whether action should be taken in response to the event (e.g., shut down, schedule maintenance, etc.). Existing condition monitoring systems can present events as a list. However, in some cases (e.g., when an asset repeatedly switches between normal and abnormal operations), similar events may be recorded repeatedly. As a result, the event log may be filled with more events than an operator needs to effectively analyze the cause of the triggering event. In addition, it may be difficult to find the unique event that caused the triggering event.

[0035] Thus, improved systems and methods for visualizing events are provided. In one aspect, event data from multiple condition monitoring systems can be displayed. This is an improvement over existing condition monitoring systems that are designed to visualize only event data acquired at their local site. In another aspect, events can be reviewed and categorized as unique events or duplicate events. When the events are displayed for an operator to view, duplicate events can be aggregated into a single item. The ability to aggregate duplicate events can increase the efficiency with which an operator employs an event visualization system because duplicate events can be reviewed together without the need for additional searching. In another aspect, a displayed event can be selected to view additional details about the event, thereby facilitating review. In contrast, existing condition monitoring systems may lack the ability to acquire and display such detailed event data, or at least may require an operator to switch between multiple applications on a user's computing device.

[0036] This document discusses embodiments of systems and corresponding methods for visualizing events for condition monitoring. However, embodiments of the present disclosure may be used to visualize other data without limitation.

[0037] Figure 1 1 is a schematic diagram illustrating an exemplary embodiment of an operating environment 100 including one or more condition monitoring systems 102 in communication with an event visualization system 104. As shown, a plurality of condition monitoring systems 102 are provided, each of which resides at a respective site (e.g., Site 1, Site 2, ... Site N) including one or more assets 106.

[0038] Embodiments of asset 106 may include any machine or machine component that requires monitoring. In certain embodiments, asset 106 may be a machine that includes rotating parts, reciprocating parts, and / or fixed asset parts. Such parts may include, but are not limited to, gears, bearings, and shafts. Examples of machines containing such parts may include, but are not limited to, turbomachinery, turbines (e.g., hydro turbines, wind turbines), generators, and reciprocating compressors, among others.

[0039] As discussed in more detail below, assets 106 can be arranged in an asset hierarchy that includes multiple levels. The lowest level of the asset hierarchy can be asset components. The next level above the asset components can be the asset level, which covers all components of the corresponding asset. For example, for a recycle compressor asset, the asset components can include motors, gearboxes, and compressors. The next level above the asset 106 can be the asset group level. Assets 106 can be grouped according to any predetermined criteria (such as functionality or process). In one example, a hydrocracker asset group can include corresponding assets 106, such as recycle compressors, supplementary compressors, and charge pumps. The next level above the asset group can be the site level, which can include all assets associated with the site. As an example, a refinery site can include asset groups such as alkylation, atmospheric distillation, coking, fluid catalytic cracking, hydrocracking, reforming, and vacuum distillation. The final level above the site can be the queue level, which includes all assets 106 at all sites. It will be understood that the above examples are provided for illustration, and the asset hierarchy can include any number of levels as needed.

[0040] Each condition monitoring system in condition monitoring systems 102 can communicate with a corresponding sensor 110 configured to sense one or more operating parameters of a target asset in assets 106. Sensor 110 can further be configured to generate at least one sensor signal 110s representing the measured operating parameter and transmit sensor signal 110s to the corresponding condition monitoring system 102 (e.g., via field wiring). For example, sensor 110 can include a probe, a transducer, and signal conditioning circuitry (not shown). The probe can interact with asset 106 to measure the operating parameter. The transducer can convert the measured value of the operating parameter into an electrical signal (e.g., a voltage), and the signal conditioning circuitry can condition and / or amplify the electrical signal to generate sensor signal 110s (e.g., a voltage between a minimum and a maximum). Thus, in one aspect, sensor signal 110s can include direct or raw measurements made by the sensor transducer. Sensor signal 110s can be an analog signal or a digital signal.

[0041] In another aspect, the sensor signal 110s may include information other than direct measurements of operating parameters. For example, the sensor signal 110s may include metadata about one or more components (such as transducers) of the corresponding sensor 110. Examples of metadata may include, but are not limited to, one or more of a serial number, a version number, an operating temperature, and an operating health status.

[0042] The number and type of sensors 110 may be determined by the one or more operating parameters to be measured. In one aspect, the sensors 110 may take the form of one or more proximity probes for measuring vibration, position, velocity, direction of motion, and eccentricity. In another aspect, the sensors 110 may take the form of one or more accelerometers for measuring seismic vibration and acceleration. In another aspect, the sensors 110 may take the form of one or more temperature probes or pressure probes for measuring temperature and pressure, respectively. It should be understood that the types of sensors 110 and the corresponding measured operating parameters discussed above are not exhaustive, and embodiments of the sensors 110 may include any sensor or combination of sensors suitable for measuring the operating parameters of interest.

[0043] In use, the condition monitoring system 102 can be configured to analyze received sensor signals 110s and identify events related to the corresponding monitored asset 106. For example, the condition monitoring system 102 can be configured to determine a value representative of a measured value of an operating parameter. The condition monitoring system 102 can also be configured to compare the determined value with one or more corresponding predetermined set points or other conditions (e.g., alarm conditions) to determine an alarm condition (e.g., good, bad, excessive, insufficient, etc.). For example, good / bad can represent a pass / fail condition, while excessive / inadequate can represent that the measured value of one or more operating parameters is above or below a set point, respectively.

[0044] For example, when asset 106 is a rotating shaft and the measured operating parameter is radial vibration of the shaft, sensor signal 110s may include a measurement of the shaft's displacement as a function of time. Based on sensor signal 110s, condition monitoring system 102 may determine the amplitude value of the peak-to-peak displacement. If the alarm condition indicates that asset 106 is operating outside of a normal operating range, condition monitoring system 102 may record the alarm as an event.

[0045] In other embodiments, the condition monitoring system 102 can be configured to analyze operating parameters received from the plurality of sensors 110 using defined logic and / or models to extract high-level insights into asset failure conditions. These operating parameters can be measured from a single component / asset or multiple components / assets.

[0046] The condition monitoring system 102 may further be configured to perform monitoring on itself in a similar manner. Additional monitoring may be grouped into various categories and may include, but is not limited to, system health, instrument health, and analytical health.

[0047] System health can include the health of any aspect of the hardware and / or software that supports the functionality of health monitoring system 102. Health monitoring system 102 can receive data from its software / hardware and use this data in conjunction with setpoints or other programmed logic to determine whether a system health event has occurred and whether the event should be logged. Examples of system health can include, but are not limited to: configuration settings; loss of communication; driver, firmware / hardware updates; data package / loss; etc.

[0048] Instrument health can include any aspect of the operation of sensor 110 that collects sensor data. Condition monitoring system 102 can receive metadata about the operation of sensor 110 from sensor 110 and use this data in conjunction with setpoints or other programmed logic to determine whether an instrument health event has occurred and whether the event should be logged. Examples of instrument health can include, but are not limited to, instrument failure, instrument health, and instrument communication status.

[0049] Analyzing operational conditions may include logic for identifying events (e.g., alarms and additional monitoring). For example, rules / criteria defining when the condition monitoring system 102 records an event (e.g., the source of the event) may be prepared by one or more authorized parties (such as the manufacturer, owner, or operator of the condition monitoring system). The condition monitoring system 102 may receive metadata about the logic used for event recognition and utilize this data in conjunction with predetermined setpoints or other criteria defining normal and abnormal operation of the event recognition logic to determine whether an event has occurred and whether the event should be recorded. Examples of analyzing operational conditions may include, but are not limited to, the presence / absence of event recognition logic.

[0050] Generally, regardless of the event type, when an event is recorded, selected event data about the event may be recorded. Examples of event data may include, but are not limited to, the location of the affected asset within the asset hierarchy of the fleet, and at least one event parameter corresponding to the event (e.g., a measured value of an operating parameter in the case of an alarm event). Event parameters may optionally include one or more of the following parameters:

[0051] Event Name: The name of the identified event.

[0052] Asset Status: The operational status of the asset associated with the event. Examples may include, but are not limited to, Up, Running (normal operation), Down, etc.

[0053] Measurement type and measurement point: A measurement type is a measurement category used to identify an event (eg, vibration, temperature, pressure, etc.) A measurement point is a channel used to obtain the value of a measurement type (eg, sensor 110).

[0054] Event trigger: One or more set values used to identify an event.

[0055] Event type: the classification of the event (e.g., adverse, excessive, insufficient, etc.),

[0056] Event Source: One or more logical packages used to identify an event. Such logical packages may be received from various sources, including but not limited to the manufacturer, owner, and / or operator of the condition monitoring system.

[0057] Event time: The time or duration of the event (e.g., entry time, exit time, etc.)

[0058] • Event Level: A relative measure of event priority. After an event has been identified, the event level may be determined by the condition monitoring system 102 .

[0059] Event parameter measurement: An operational parameter measurement used to identify an event. When the event is transient, the operational parameter measurement may be a single operational parameter measurement. Alternatively, when the event is persistent, the operational parameter measurement may be multiple operational parameter measurements taken during at least a portion of the event (e.g., operational parameter measurements taken between the event entry time and the event exit time).

[0060] Each condition monitoring system 102 may be configured to output event data recorded for the assets 106 at its corresponding site. Figure 1 As shown, event visualization system 104 can communicate with multiple condition monitoring systems 102 and can receive event data (e.g., site 1 event data 112A, site N event data 112N, collectively referred to as event data 112) from the multiple condition monitoring systems. In an alternative embodiment, not shown, the condition monitoring system can output the event data to another computing device. The condition monitoring system can then retrieve the event data.

[0061] As shown, the event visualization system 104 includes an event analyzer 116 in communication with a historian 120 and a user computing device 122. The historian 120 can be configured to store event data 112 received from a plurality of condition monitoring systems 102. The event analyzer 116 can be configured to submit queries 114 to the historian 120 of the event data 112. Subsequently, the event analyzer 116 can generate a graphical user interface (GUI) 126 based on the received event data 112 and transmit the GUI 126 to the user computing device 122 for display. The user computing device 122 can be configured to display the GUI 126 generated by the event analyzer 116 and receive user selections within the GUI 126.

[0062] A hierarchical list of assets within the queue can be displayed within GUI 126, arranged in the levels discussed above. In response to receiving a user selection of a hierarchy level within this list, event analyzer 116 can be configured to identify a plurality of events associated with the selected hierarchy level. Event analyzer 116 can further update GUI 126 to include a second list of identified events, wherein unique events and duplicate events are each displayed in a single corresponding entry.

[0063] Event visualization system 104 can provide various benefits compared to existing techniques for event visualization. In one aspect, events from multiple condition monitoring systems 102 can be included in event data 112 and visualized. In contrast, existing condition monitoring systems can be configured to only visualize event data acquired at their local site and cannot visualize events experienced by assets at other sites.

[0064] In another aspect, event analyzer 116 can be further configured to update GUI 126 to display a list of events corresponding to assets 106 within the selected hierarchy level. This list can include both unique and duplicate events. However, in contrast to existing condition monitoring systems, duplicate events can be identified and aggregated into a single list entry. The ability to aggregate duplicate events can improve the efficiency with which operators utilize event visualization system 104, as duplicate events can be reviewed together without requiring additional searching.

[0065] In another aspect, the GUI 126 can be updated to display detailed data about events in the event list in response to operator selections. In contrast, existing condition monitoring systems may lack the ability to acquire and display such detailed event data, or at least may require the operator to switch between multiple applications. The ability to view detailed event data without cumbersome application switching can further improve the operator's efficiency in using the event visualization system 104.

[0066] In certain embodiments, an event may involve an alarm (e.g., an operating parameter outside of a normal operating range). In some cases, an alarm may indicate a problem with a monitored asset, and it may be desirable to resolve such an alarm in order to avoid asset downtime and / or damage. Accordingly, the GUI 126 may be further updated to display one or more recommended actions in conjunction with the alarm event. Advantageously, by displaying recommendations in conjunction with the alarm event, the event visualization system 104 may assist the operator in determining a course of action to resolve the alarm event and allow such alarm events to be resolved more quickly.

[0067] The following discussion provides some information on Figure 2 、 Figure 3A and Figure 3B An exemplary embodiment of a GUI 126 generated by the event analyzer 116 is shown. Figure 2 is a schematic diagram illustrating one exemplary embodiment of the GUI 126. As discussed in detail below, the GUI 126 may be configured to display one or more of the first window 200, the second window 202, the third window 204, and the fourth window 206 in any combination.

[0068] The GUI 126 may be configured to display a hierarchical list of assets 210 within the first window 200. As shown, the hierarchical list of assets 210 includes multiple levels, such as a queue level, a site level, an asset group level, an asset level, and a part level.

[0069] GUI 126 may be configured to receive a user selection (eg, user selection 124) of a hierarchical listing level for assets 210. In response to receiving this selection, event analyzer 116 may determine assets 106 and corresponding events associated with the selected hierarchical level.

[0070] As mentioned above, the highest level is the queue level. Therefore, a selection at the queue level includes all assets 106 of the queue (eg, all assets within each site) and all events of the queue.

[0071] The second highest level is the site level, and the site level may include one or more sites (e.g., Site 1, Site 2, ... Site N). Thus, a selection of a site in the site level may include assets 106 associated with the selected site and all events corresponding to the assets of the selected site.

[0072] The third highest level is the asset group level (eg, asset group 1, asset group 2, ... asset group N). Thus, a selection of an asset group in the asset group level may include assets 106 associated with the selected asset group and all events corresponding to the assets 106 of the selected asset group.

[0073] The fourth highest level is the asset level (e.g., Asset 1, Asset 2, Asset N). Therefore, the selection of an asset 106 in the asset level includes the selected asset 106 and all events corresponding to the selected asset 106. Optionally, when monitoring asset components, the selection of an asset 106 in the asset level may further include components associated with the selected asset 106 and events corresponding to the selected asset 106.

[0074] The fifth highest level is the asset part level (eg, part 1, part 2, part N). Thus, a selection of a part in the part level includes the selected part and all events corresponding to the selected part.

[0075] The event analyzer 116 can be further configured to update the GUI 126 to display a second list of events associated with the selected hierarchical level of the hierarchical list of assets 210. This second list can include a single entry for a unique event and a single entry for a corresponding recurring event. As discussed above, examples of events can include, but are not limited to, alarms, system health of a condition monitoring system, instrument health of an instrument (e.g., sensor 110) that obtains measurements of operating parameters of the corresponding monitored asset 106, and analytical health of logic used to identify events.

[0076] As discussed above, the event data corresponding to each event may include at least one event parameter. In certain embodiments, an event may be classified as a duplicate event when at least one event parameter corresponding to an event matches all at least one event parameter of another event in a plurality of events. Typically, such matching is intended to ensure that events classified as duplicate events are evaluated on the same basis and occur under nominally the same asset conditions and, therefore, can be attributed to the same root cause. In addition, such events may exhibit very little substantial variation relative to one another. Therefore, grouping these duplicate events into a single entry within the second list provides a significant improvement in effectiveness without substantially losing event information.

[0077] In certain embodiments, the at least one event parameter may include a measurement type and measurement point, an asset status, an event level, an event source, and an event type. Thus, in these cases, an event is classified as a unique event when at least one of the above-listed event parameters for an event does not match another event. Conversely, in these cases, an event may be classified as a duplicate event when at least one event parameter corresponding to the event matches all of the above-listed event parameters for another event.

[0078] It will be appreciated that these event parameters are discussed for example purposes only, and that at least one event parameter may be different, and optionally more or fewer event parameters may be included.

[0079] In another embodiment, the second window 202 may further display selected event information corresponding to each of the listed events. Figure 2 As shown, event information includes event priority, event name, hierarchy level, and event overview.

[0080] GUI 126 can be further configured to receive a second user selection of an event within the list displayed in second window 202. In response to receiving this selection, event analyzer 116 can be configured to update GUI 126 to display a third window 204 that includes at least a portion of event data 112 corresponding to the selected event. Examples of event data can include, but are not limited to, event summary 212, recommended actions 214, event occurrence list 216, and operating parameter graph 220.

[0081] Figures 3A to 3B A representative example is further shown. As shown, a queue hierarchy level is selected in first window 200, and the corresponding event is shown in second window 202. "Event Name 1" is the event further selected in the second window. An exemplary event detail summary 212 is shown in the first sub-window of third window 204. For example, the priority, event name, and position of the selected event within the asset hierarchy of the queue are further shown.

[0082] Embodiments of additional event data summarized in the event detail summary 212 can be based on the most recent occurrence of the event. Non-limiting examples of summarized event data can include, but are not limited to, event occurrence counts, asset status (up, running (normal operation), down, etc.), event trigger value (alone or in combination with the measured operating parameter value that caused the event to be triggered), event type (e.g., alarm, system health, instrument health, or analytical health), and event source. For a single selected event, the most recent occurrence will be the only occurrence within the event data corresponding to the selected event. Therefore, in these cases, the count takes a value of 1.

[0083] In some embodiments, recommended actions are displayed in the second sub-window of the third window 204. Recommended actions corresponding to the respective events may be determined by the condition monitoring system 102 and included in the event data 112. In some embodiments, recommendations may be determined by the condition monitoring system 102 and provided with the event data 112. In other embodiments, an operator may employ the event visualization system 104 to associate recommendations with specific events. In one example, a recommendation may suggest performing specific maintenance on the asset 106. In another example, a recommendation may suggest operating the asset 106 within specified operating parameters.

[0084] An exemplary list of event occurrences 216 is shown in the third subwindow of the third window 204. For a uniquely selected event, the most recent occurrence will be the only occurrence within the event data corresponding to the selected event. Thus, in these cases, only a single occurrence will be displayed. In contrast, for a recurring selected event, all occurrences within the event data corresponding to the selected recurring event may be displayed.

[0085] For each occurrence, selected event data can be displayed. Figure 3A As shown, event data can include event parameters, such as triggering events. For example, event occurrence list 216 can include event trigger values (alone or in combination with measured operational parameter values that caused the event to be triggered), event entry (start) and exit (stop) times, and optionally, operator confirmation of the selected event (e.g., via a quick action discussed in more detail below).

[0086] In certain embodiments, a fourth sub-window of third window 204 displays a graph of one or more measured operating parameters of asset 106 over time. As shown, the measured operating parameters may include one or more operating parameter measurements taken before, during, and / or after a selected event. Optionally, one or more setpoints may be overlaid on the graph. It will be appreciated that the graph may display other data in any desired format.

[0087] Event analyzer 116 may be further configured to update GUI 126 to display fourth window 206 in response to receiving a first user selection of a level of the hierarchical list of assets 210. For example, fourth window 206 may include a performance summary at the selected hierarchical level based on the portion of event data 112 corresponding to the first plurality of events.

[0088] Figures 3A to 3B A representative example of a fourth window is further shown. Continuing with the above example, a queue hierarchy level is selected within the first window 200, and a corresponding summary of assets at the queue hierarchy level is shown in the second window 202. As shown, the performance summary includes a performance index, a number of events (alone or in combination with a number of unconfirmed events), a number of failure events (e.g., events that have not been confirmed within a predetermined time), etc.

[0089] In another embodiment, the event analyzer 116 can be further configured to include a user interface object 222 corresponding to one or more quick actions within the generated GUI 126. The functionality of the user interface object 222 can be configured in various ways. In one embodiment, the quick action can relate to alarm management. Examples can include, but are not limited to, alarm acknowledgment, alarm suppression, resetting a latched alarm, etc. In another embodiment, the quick action can relate to situation management, such as situation creation or situation assignment. For example, if an operator has a situation management function that manages the status / maintenance of a particular asset 106 and identifies a new event related to a situation, the operator can use a quick action to assign the event to the situation to collect all supporting data. In another example, a new situation can be created after identifying a new event. In another embodiment, the quick action can relate to navigation within the GUI 126 (e.g., the operating parameter map 220). Advantageously, the ability to create and deploy quick actions enables a certain degree of customization of the GUI 126 and can promote a better operator experience.

[0090] It will be appreciated that the discussion of event parameters and corresponding summaries for display within the GUI 126 are presented for example purposes only, and that event parameters may differ from those shown, and optionally, more or fewer event parameters may be included.

[0091] Figure 4 4 is a flow chart illustrating an exemplary embodiment of a method 400 for improving visualization of events for condition monitoring. As shown, the method 400 includes operations 402-416, and is hereinafter referred to as Figures 1 to 3B It will be appreciated that in alternative embodiments, the method may include more or fewer operations and / or be performed in a manner similar to that described in the preceding text. Figure 4 Execute in a different order than shown.

[0092] In operation 402, a plurality of event data (e.g., event data 112) representing one or more events experienced by respective assets in plurality of assets 106 may be maintained (e.g., by event visualization system 104). In an embodiment, event data 112 may be maintained by historian 120. Plurality of assets 106 may be distributed across different stations in a fleet. In an embodiment, an event may be at least one of an alarm, a condition monitoring system health event, an instrument health event, and an analytical health event.

[0093] The event data may include at least one position of the selected asset 106 in the asset hierarchy of the queue and at least one event parameter corresponding to the event. In an embodiment, the at least one event parameter may include at least one of a measurement type, a measurement point, an event type, an event level, an event source, and an asset state. In another embodiment, the event data may include measured operational data (e.g., measured operational parameters) associated with the corresponding event. For example, the measured operational data may be one or more operational parameters measured at approximately the same time, before, and / or after the corresponding event.

[0094] In operation 404 , a plurality of event data may be received by one or more processors (eg, event analyzer 116 ).

[0095] In operation 406, the event analyzer 116 may generate a graphical user interface (GUI) 126 that displays a first window 200. The first window 200 may include a hierarchical list of assets organized according to their position within the asset hierarchy of the queue. For example, the asset hierarchy of a queue may include two or more of a queue level, a site level, an asset group level, and an asset level.

[0096] In operation 410, a first user selection of a hierarchical level within the hierarchical list may be received by event analyzer 116. For example, an operator of GUI 126 may view GUI 126 and provide the first user selection using user computing device 122. User computing device 122 may communicate with event analyzer 116 (e.g., via a network) and transmit the first user selection to event analyzer 116 upon entry.

[0097] In operation 412 , the event analyzer 116 may identify a plurality of events associated with the first user-selected hierarchy level.

[0098] In operation 414, the event analyzer 116 may classify at least a portion of the identified multiple events based on their corresponding event data. In some embodiments, all of the identified multiple events may be classified. For example, an event may be classified as a unique event that occurs once within a multiple event or as a repeated event that occurs multiple times within a multiple event.

[0099] In one embodiment, when at least one event parameter corresponding to an event does not match another event in the plurality of events, the event may be classified as a unique event by the event analyzer 116. In another embodiment, when at least one event parameter corresponding to an event matches all at least one event parameter of another event in the plurality of events, the event may be classified as a duplicate event by the one or more processors.

[0100] In operation 416, event analyzer 116 may update GUI 126 in response to receiving the first user selection to display second window 202. Second window 202 may include a second list including a single entry for a corresponding unique event and a single entry for a corresponding recurring event in the first plurality of events.

[0101] In further embodiments, a second user selection of an event from the second list may be received within GUI 126. In response to receiving the second user selection, event analyzer 116 may update GUI 126 to display at least one third window 204. Third window 204 may include event data corresponding to the selected event.

[0102] The third window 204 may be configured in various ways. In one embodiment, the third window 204 may be in the form of a first sub-window (e.g., event details overview 212) that displays the most recent occurrence of a selected event comprising a first portion of at least one event parameter.

[0103] In another embodiment, the event data may further include at least one recommendation. In this case, the third window 204 may be in the form of a second sub-window (e.g., recommended action 214) displaying at least one recommendation.

[0104] In further embodiments, the third window 204 may be in the form of a third sub-window (eg, event occurrence list 216) that displays all occurrences of the selected event and includes a corresponding second portion of the at least one event parameter for each occurrence.

[0105] In another embodiment, the third window 204 can be in the form of a fourth sub-window (e.g., an operating parameter graph 220) that includes a graph of measured operating data. The measured operating data can be before, during, and / or after a selected event.

[0106] As a non-limiting example, the exemplary technical effects of the methods, systems, and devices described herein include improved visualization of events for condition monitoring. In one aspect, unique and non-unique (e.g., repeated) events can be identified, and repeated events can be aggregated and displayed in a graphical user interface. Therefore, unnecessary display of redundant events can be avoided, facilitating review of listed events. On the other hand, the events displayed in this manner are not limited to events from a single site, but from multiple sites, up to the entire queue. This data visualization method is particularly advantageous when listing events in the entire queue because the number of listed events is significantly increased compared to the display of events from one site or a small number of sites. In another aspect, the graphical user interface can be further configured to display supporting information (e.g., all recurring events, data graphs showing operating parameters measured within a time range including the corresponding event, etc.) in the form of an overview view and various detailed views, which enables operators to quickly review events and supporting data without having to sort through a large number of interfering events.

[0107] Certain exemplary embodiments are described to provide a comprehensive understanding of the principles of structure, function, manufacture, and use of the systems, apparatus, and methods disclosed herein. One or more examples of these embodiments have been illustrated in the accompanying drawings. It will be understood by those skilled in the art that the systems, apparatus, and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments, and that the scope of the invention is limited solely by the claims. Features shown or described in conjunction with one exemplary embodiment may be combined with features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention. In addition, in this disclosure, similarly named components of an embodiment generally have similar features, and therefore, within a specific embodiment, it is not necessary to fully set forth every feature of every similarly named component.

[0108] The subject matter described herein can be implemented in analog electronic circuits, digital electronic circuits and / or computer software, firmware or hardware (including the structural devices disclosed in this specification and their structural equivalents) or a combination thereof. The subject matter described herein can be implemented as one or more computer program products, such as tangibly embodied in an information carrier (e.g., embodied in a machine-readable storage device) or embodied in a propagated signal, for use in one or more computer programs for executing or controlling the operation of a data processing device (e.g., a programmable processor, a computer or multiple computers). A computer program (also referred to as a program, software, software application or code) can be written in any form of programming language (including compiled or interpreted languages), and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that stores other programs or data, in a single file dedicated to the program under consideration, or in multiple collaborative files (e.g., files that store portions of one or more modules, subroutines or codes). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0109] The processes and logic flows described in this specification, including the method steps of the subject matter described herein, can be performed by one or more programmable processors executing one or more computer programs to perform the functions of the subject matter described herein by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit), and the apparatus of the subject matter described herein can be implemented as special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0110] By way of example, processors suitable for executing a computer program include both general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, one or more mass storage devices for storing data (e.g., magnetic, magneto-optical, or optical disks), or both. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and optical disks (e.g., CDs and DVDs). The processor and memory may be supplemented by, or incorporated into, special-purpose logic circuitry.

[0111] To provide for interaction with a user, the subject matter described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, as well as a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide for interaction with the user. For example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including sound, voice, or tactile input.

[0112] The technology described herein can be implemented using one or more modules. As used herein, the term "module" refers to computing software, firmware, hardware and / or their various combinations. However, at the very least, a module should not be interpreted as software that is not implemented on hardware, firmware or recorded on a non-transient processor-readable storage medium (that is, the module itself is not software). In fact, a "module" will be interpreted as always including at least some physical non-transient hardware, such as a part of a processor or a computer. Two different modules can share the same physical hardware (for example, two different modules can use the same processor and network interface). Modules described herein can be combined, integrated, separated and / or copied to support various applications. In addition, instead of the function performed at a specific module or in addition to the function performed at a specific module, the function described herein as being performed at a specific module can be performed at one or more other modules and / or by one or more other devices. In addition, modules can be implemented locally or remotely across multiple devices and / or other components relative to each other. In addition, a module can be moved from one device and added to another device, and / or can be included in two devices.

[0113] The subject matter described herein can be implemented in a computing system that includes back-end components (e.g., a data server), middleware components (e.g., an application server), or front-end components (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end components, middleware components, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), such as the Internet.

[0114] As used herein throughout the specification and claims, approximating language may be used to modify any quantitative representation that may vary without resulting in a change in the basic function to which it is related. Thus, a value modified by one or more terms such as "about," "approximately," and "substantially" should not be limited to the precise value specified. In at least some cases, approximate language may correspond to the precision of the instrument used to measure the value. Here and throughout the specification and claims, range limitations may be combined and / or interchanged, and unless context or language indicates otherwise, such ranges are identified and include all subranges contained therein.

[0115] Based on the above embodiments, those skilled in the art will appreciate other features and advantages of the present invention. Therefore, except as indicated by the appended claims, this application is not limited by the contents specifically shown and described. All publications and references cited herein are expressly incorporated by reference in their entirety.

Claims

1. An asset management system, comprising: a historian configured to maintain a plurality of event data characterizing one or more events experienced by respective assets of a plurality of assets, wherein the plurality of assets are distributed among different stations of a queue, and wherein the event data includes at least one position of the asset within an asset hierarchy of the queue and at least one event parameter corresponding to the event; and An event analyzer comprising one or more processors configured to receive the plurality of event data and perform operations comprising: generating a graphical user interface (GUI) displaying a first window, wherein the first window includes a hierarchical list of the assets organized according to their positions within the asset hierarchy of the queue; receiving within the GUI a first user selection of a hierarchical level within the hierarchical list; identifying a plurality of events associated with the hierarchical level selected by the first user; classifying at least a portion of the identified plurality of events as a single occurrence of a unique event within the plurality of events or a multiple occurrence of a repeated event within the plurality of events based on corresponding event data of the identified plurality of events; The GUI is updated in response to receiving the first user selection to display a second window, wherein the second window includes a list including a single entry for a corresponding unique event and a single entry for a corresponding recurring event in the first plurality of events.

2. The asset management system according to claim 1, further comprising: performing an operation by the event analyzer, the operation comprising: receiving within the GUI a second user selection of an event from a second list; as well as The GUI is updated in response to receiving the second user selection to display at least one third window, wherein the third window includes event data corresponding to the selected event.

3. The asset management system of claim 2, wherein the third window comprises a first sub-window that displays a most recent occurrence of the selected event including a first portion of the at least one event parameter.

4. The asset management system of claim 2, wherein the event data further includes at least one recommendation, and wherein the third window includes a second sub-window displaying the at least one recommendation.

5. The asset management system of claim 2, wherein the third window includes a third sub-window displaying all occurrences of the selected event, and each displayed occurrence includes a corresponding second portion of the at least one event parameter for each occurrence.

6. An asset management system according to claim 2, wherein the event data also includes measured operational data about the asset before, during and after the selected event, and wherein the third window includes a fourth sub-window, the fourth sub-window including a graph displaying at least a portion of the measured operational data.

7. An asset management system according to claim 1, wherein the asset management system also includes an operation performed by the event analyzer, the operation including updating the GUI to display a fourth window in response to receiving the first user selection, wherein the fourth window includes a performance overview at a selected hierarchical level based on the event data corresponding to the first plurality of events.

8. The asset management system of claim 1, wherein the asset hierarchy of the queue comprises two or more of a queue level, a site level, an asset group level, or an asset level.

9. An asset management system according to claim 1, wherein when the at least one event parameter corresponding to the event does not match another event among the multiple events, the event is classified as a unique event, and wherein when the at least one event parameter corresponding to the event matches all of the at least one event parameter of another event among the multiple events, the event is classified as a duplicate event.

10. The asset management system of claim 9, wherein the at least one event parameter comprises at least one of a measurement type, a measurement point, an event type, an event level, an event source, or an asset status.

11. The asset management system of claim 1 , wherein the event is at least one of an alarm, a condition monitoring system health event, an instrument health event, and an analytical health event.

12. A method of asset management, comprising: maintaining, by one or more processors, a plurality of event data representing one or more events experienced by respective assets of a plurality of assets, wherein the plurality of assets are distributed among different stations of a queue, and wherein the event data includes at least one position of the asset within an asset hierarchy of the queue and at least one event parameter corresponding to the event; as well as receiving, by one or more processors, the plurality of event data; generating, by the one or more processors, a graphical user interface (GUI) that displays a first window, wherein the first window includes a hierarchical list of the assets organized according to their positions within the asset hierarchy of the queue; receiving within the GUI a first user selection of a hierarchical level within the hierarchical list; identifying, by the one or more processors, a plurality of events associated with the hierarchical level selected by the first user; classifying, by the one or more processors, at least a portion of the identified plurality of events as a single occurrence of a unique event within the plurality of events or a multiple occurrence of a repeating event within the plurality of events based on corresponding event data of the identified plurality of events; as well as The GUI is updated, by the one or more processors, in response to receiving the first user selection to display a second window, wherein the second window includes a list comprising a single entry for a corresponding unique event and a single entry for a corresponding recurring event in the first plurality of events.

13. The method according to claim 12, further comprising: receiving within the GUI a second user selection of an event from a second list; as well as The GUI is updated, by the one or more processors, in response to receiving the second user selection to display at least one third window, wherein the third window includes event data corresponding to the selected event.

14. The method of claim 13, wherein the third window comprises a first sub-window that displays a most recent occurrence of the selected event including a first portion of the at least one event parameter.

15. The method of claim 13, wherein the event data further includes at least one recommendation, and wherein the third window includes a second sub-window displaying the at least one recommendation.

16. The method of claim 13, wherein the third window comprises a third sub-window displaying all occurrences of the selected event, and each displayed occurrence comprises a respective second portion of the at least one event parameter for each occurrence.

17. A method according to claim 13, wherein the event data also includes measured operational data about the asset before, during and after the selected event, and wherein the third window includes a fourth sub-window, the fourth sub-window including a graph displaying at least a portion of the measured operational data.

18. The method of claim 12, further comprising updating, by the one or more processors, the GUI to display a fourth window in response to receiving the first user selection, wherein the fourth window comprises a performance overview at a selected hierarchical level based on the event data corresponding to the first plurality of events.

19. The method of claim 12, wherein the asset hierarchy of the queue comprises two or more of a queue level, a site level, an asset group level, or an asset level.

20. A method according to claim 12, wherein when the at least one event parameter corresponding to the event does not match another event in the multiple events, the event is classified as a unique event by the one or more processors, and wherein when the at least one event parameter corresponding to the event matches all of the at least one event parameter of another event in the multiple events, the event is classified as a duplicate event by the one or more processors.

21. The method of claim 20, wherein the at least one event parameter comprises at least one of a measurement type, a measurement point, an event type, an event level, an event source, or an asset status.

22. The method of claim 12, wherein the event is at least one of an alarm, a condition monitoring system health event, an instrument health event, and an analytical health event.

Images