Assigning the Event Templates for Analysis and Root Cause Determination
The event frame template simplifies the analysis of a repeatable event with a defined start and end time. CBM events can be layered to gain insight about how the assets have operated over long periods of times by comparing them to each other over these time segments. In Figure 6.6, an event frame is initiated by a trigger that could be a state change in process data. Process variable exceptions, such as a rate of change, crossing of a limit, or run time within a given period, can also initiate an event frame. Asset analytics use sophisticated calculations to define reference events based on process data. Because an event frame is always true after a defined start point, users can capture (or reference) data before the actual trigger. For example, when a unit or piece of equipment trips, users may want to see specific data for a period before this event to determine the root cause event or conditions.
Events capture all of the following information:
- • Frames (or bookmarks) that define the event
- • Configurable time period before the event trigger
- • Referenced element (asset)
- • Specific attribute data
- • Other calculations, such as duration and cost
Event frames capture data as referenced and defined within the event frame template as well as provide placeholders for additional data to be added later. For example, users can add in cause code values when an engineer determines the cause of the event or programmatically adds data returned from the CMMS, such as the work order number.
Assigning Equipment Parameter Tables
Static characteristics about the equipment can be stored in the equipment parameter table if the real-time analytics in the real-time asset object model use them. As such, the analytics and rules for families of equipment types can be reused, simplifying the implementation and maintenance of these objects. These parameters might include the manufacturer, asset type, asset type parameter, size, nominal power, and associated data to trigger the events and notifications. This information is usually available in the CMMS environment.
Visualizing the information is easier when it is implemented using a digital plant template asset object model, which provides the attributes for each element to be queried by the visualization layer. This strategy simplifies the access and delivery of information for both real-time awareness and historical analysis. It also enables the historical data and events information to build predictive models or soft sensors from the data. Soft sensors are inferential estimators, drawing conclusions from operational data when hardware sensors are not available or when they have reliability issues. They provide an alternate way to have information when hardware sensor performance is sometimes inaccurate.
Paul provides a list of some common CBM scenarios:
- • Pump lubrication preventive maintenance (PM) based on the actual motor run time, for example 2,000 hours
- • Analyzer recalibration PM based on the measured drift exceeding 1%
- • Filter change PM based on measured pressure differential across the filter exceeding allowable limits
- • Heat-exchanger cleaning cycle PM based on calculated fouling factors
- • Circuit analysis based on significant switching operations in a small amount of time (e.g., more than six operations in less than 24 hours)
- • Transformer servicing based on dissolved gas analysis results over time that indicates insulation degradation
- • Bearing swap-out based on vibration data of the motor shaft or motor current signature analysis
CBM can be started with limited process or asset information and does not necessarily require specialized diagnostic or condition-based monitoring equipment. For example, CBM can be used to monitor the amperage of the motor attached to pump. The analysis of the amperage in real time, including its variability within a minute, can be used to detect an anomaly for further inspection.
With data to define proper data parameters, ML can be used to generate patterns, resulting in real-time alerts when abnormal conditions occur. The generated models can be incorporated in the analytics or be executed as a sub-process (Cope and Chugh 2019). Figure 6.8 represents a typical trend for a piece of equipment (asset) showing predicted behavior and the measured real-time behavior of the asset. As soon as these values start to drift, a possible fault is detected and a notification is sent to the operations and maintenance departments for further analysis, aligning with the workflow described in Chapter 4.
Advanced pattern recognition for equipment failure prevention.