Beruflich Dokumente
Kultur Dokumente
Condition-Based
Maintenance
(CBM) Using Real-time Data
A practical guide to getting more value from real-time data by
supporting effective asset management strategies
Condition Monitoring
Condition-Based Maintenance
Decision Support
Enterprise Integration
Business Intelligence
Page | 1
eBook
Contents
1
Introduction ......................................................................................................................................... 4
Overview .............................................................................................................................................. 5
2.1
2.1.1
Definition .............................................................................................................................. 6
2.1.2
Objectives ............................................................................................................................. 7
2.1.3
4.1
Getting Started............................................................................................................................ 13
4.2
4.3
4.4
CBM Configuration..................................................................................................................... 16
4.5
4.6
4.7
4.8
6.2
6.3
PI Analytics (or similar) invoking services of the CMMS for integration (push)..................... 34
7.2
7.3
7.4
7.5
P a g e |2
Transformers .............................................................................................................................. 38
8.1.1
8.1.2
8.1.2.1
8.1.2.2
8.1.3
8.1.3.1
8.1.3.2
8.1.4
8.1.5
8.2
10
Pumps ......................................................................................................................................... 43
8.2.1
8.2.2
8.2.3
8.2.4
8.3
Compressors .............................................................................................................................. 46
8.3.1
8.3.2
8.3.3
8.3.4
8.4
8.4.1
8.4.2
8.4.3
8.4.4
9.2
9.3
References ......................................................................................................................................... 54
10.1
10.2
10.3
10.4
10.5
Introduction
Today, innovative asset and infrastructure management teams are looking for ways to use data to
balance trade-offs between asset cost, performance and risk. Especially for enterprise endeavours,
the challenge is to acquire, integrate and analyze data from an ever increasing range of operational
sources without creating customized solutions. This guidebook provides recommendations for rapidly
implementing condition-based maintenance (CBM) solutions with popular CMMS 1 applications and
how to support them with high fidelity asset data. It also defines and builds on the principles of CBM
to show additional business value propositions related to CBM solutions. Finally, the guidebook will
discuss the advantages of optimizing CMMS with both real time and archived asset data using the
OSIsoft PI System. The PI System is a flexible and customizable software suite that bridges the gap
between OT and IT2 systems. Typically, our customers accelerate their ROI from various IT applications,
including CBM applications, when the PI System feeds information from time series data into them.
Five key advantages of the PI System support the implementation and execution of effective CBM
solutions. They are:
Extremely efficient, real time data management from a wide variety of operational sources in
a highly secure manner
Capturing and storing streaming data at its original fidelity, without averaging or aggregating,
using proven methods that scale to an enterprise.
Embedded data directory to organize data streams and other related process information by
asset and plant topology, giving the data functional and operational context.
Easy-to-configure, advanced analytics that convert raw data streams into meaningful events
and values.
Powerful means to surface asset health information. Information can be consumed in a wide
variety of ways by users as well as other enterprise systems.
Computerized Maintenance Management Systems (CMMS), used for work management and asset
management, similar to Enterprise Asset Management (EAM) and often part of Enterprise Resource Planning
(ERP) suites.
2
OT Operational Technology, typically the control network systems such as SCADA, DCS, PLC, etc. and IT
Informational Technology, typically enterprise business networks and systems such as ERP, eMail, Customer
Services, etc.
Page |4
Overview
Shifting from calendar-based to condition-based maintenance (CBM) regimes is a strategic goal cited
by the majority of our customers to improve asset performance, reliability and lifecycle management
of assets. CBM as a maintenance strategy crosses all major industries and asset categories (e.g.
rotating equipment, transformers, mining vehicles, fluid management, etc.) CBM differs from
calendar-based regimes in that it leverages asset data to optimize & align maintenance schedules with
actual asset condition, organizational mission and changes in environment. The CBM process starts
with monitoring specific asset parameters, continues with evaluation of that parameter in relation to
limits, trends and other asset data. The CBM process ends with integration with the work management
solution. It ties together real time data with work management systems in an evolutionary process.
The diagram below illustrates the flow of aggregated and event-based real time data that is fed into a
maintenance program of a CMMS, along with prescribed maintenance activities. This process evolves
as insights arise and system experts (asset managers, performance engineers, etc.) apply lessons
learned to the system in terms of maintenance program changes, analytic definitions, event frame
analysis, etc.
Implementing a CBM solution is a continuous improvement process, not a short-term project. CBM
can be started with limited process or asset information and does not necessarily require specialized
diagnostic or condition monitoring equipment. This guide covers the fundamentals of CBM, including
how it differs from other strategies such as reactive, model-driven, etc. (defined later). It includes
steps to get started with CBM implementation and illustrates the advantages of using real-time, high
fidelity asset data to maximize the value of a CBM implementation. The guide also covers typical
architectural configurations from the very simple to the very complex. We also introduce the PI System
and how to integrate PI System data (time series data) with enterprise CBM applications, such as
common CMMS solutions. Toward the end of the guide we provide some input toward building a
business case for CBM implementations and some lessons learned from collectively implementing
many diverse CBM solutions. Several case studies using asset examples have been included to show
benefits and value across industries.
In this guide book, we discuss the following topics:
2.1
2.1.1
Condition Monitoring
Condition Based Maintenance
CBM design
CBM monitoring and analysis
CBM extension and tools summary
Basic PI System Overview
PI System infrastructure and typical implementation overview
CBM with PI implementation options
PI System integration to external systems (EAM, CMMS, etc.)
The PI System software component family
Business Value and Reference Examples
Condition Based Maintenance (CBM) can be defined as a set of maintenance processes driven by realtime asset information to ensure maintenance is performed only when evidence of need exists.
Page |6
Objectives
The goal of a CBM implementation is to move from a calendar-based preventive maintenance program
to a condition-based preventive maintenance program.
The main objectives of CBM are to:
Reactive
Maintenance
Preventive
Maintenance
Cost Savings
Time
Now
Reactive
Maintenance
Planned
Maintenance
Preventive
Maintenance
Less Reactive
Maintenance
Less time-based
PM
Improved Planning
After CBM
2.1.3
Maintenance processes normally are, and in the case of this document are assumed to be, managed
in a work management system as pre-described maintenance tasks (preventive or planned). Work
management systems are typically called a computerized maintenance management system (CMMS)
and may be a complete and dedicated piece of software or a module of a more comprehensive
enterprise asset management (EAM) or enterprise resource planning (ERP) system.
Maintenance processes have been historically based on, calendar (time-based) schedules due to a lack
of asset-specific condition information. Calendar-based schedules are more conservative and
recommend more frequent maintenance in order to avoid running an asset to failure. Because
calendar-based schedules can generate unneeded maintenance, they can increase costs as well as
damage to assets during unnecessary repairs and decrease overall asset availability. When asset
information is integrated into CBM-enabled work systems, maintenance processes are generated by
asset-specific condition indicators that predict when an asset needs maintenance. These indicators are
Page |7
The following section provides some definitions and information on terms that often come up when
discussing CBM solutions. The definitions provided here are in the context of this document and not
exhaustive. Note that there is no standards organization to fully govern these terms; they are industry
terms.
P a g e |8
REACTIVE MAINTENANCE
This approach to maintenance is characterized by calendar-based preventive maintenance, when
applied at all, and corrective maintenance to respond to (or react to) incipient failures. This is basically
considered a "run to failure" strategy. It's appropriate for some non-critical assets and/or when
impacts and costs for this strategy are minimum. It requires a minimum of setup and oversight in terms
of manpower, specialized equipment, etc.
CONDITION-B ASED MAINTENANCE
This approach to maintenance is characterized by using the techniques described within this
document. It's generally applied to a set of critical assets and/or those assets that have significant
repair & replacement costs and/or cause significant impacts to the business process when they fail. As
described herein, specialized condition monitoring equipment may be required to monitor the
condition of assets and respond to trends or events indicating a degraded condition. Current operating
parameters, monitored using computing technology, can also be used to drive maintenance plans,
derive asset conditions, etc. as a part of a CBM strategy.
PREVENTIVE MAINTENANCE
Page |9
P a g e | 10
The "Run to Failure" portions of the graph in Figure 4 represent the risk of asset failure assuming the
test method indicates a failure is near. The response opportunity time varies based on asset, type of
test and frequency of the testing method. Quite often there is little time to respond, depending on
plant conditions, time of the notification, etc. Most commonly alarms for critical items are sent to
Operations to ensure equipment can be moved into a safe condition prior to catastrophic failure.
While these predictive techniques technically indicate a condition of the asset, they are not often used
in a CBM solution because they are not forwarded to the CMMS directly.
MODEL DRIVEN MONITORING
Model driven monitoring is both a maintenance and operations approach to reliability and improved
operations. This approach requires that an anticipated operational model exists for the asset, system,
process, etc. for a given set of ambient and input values. Operational models are based on previous
experience of a similar plant or system to understand expected behavior given current conditions. The
model will provide anticipated values for process parameters, e.g. temperatures, pressures, vibration,
etc.
During operations, the model is setup to monitor the actual values as compared to the anticipated
values. Identified deltas lead to awareness of unanticipated asset condition or operation. In typical
use, a monitored parameter is checked periodically to ensure it is within in its anticipated range. If a
number of consecutive samples (configured) all indicate that the monitored parameter is outside
anticipated range, then an alarm is latched.
P a g e | 11
This approach is rather complex, although it can be started rather small, by focusing on some critical
parameters and grow it into a model for the complete process or plant. Industry groups (e.g. EPRI),
standards organizations (e.g. IEEE) and OEM companies often offer some models for specific assets
and systems. Model driven monitoring typically uses advanced pattern recognition (APR) and it may
be referred to in this way.
RELIABILITY CENTRED MAINTENANCE (RCM)
Reliability Centred Maintenance (RCM) is a maintenance philosophy involving a number of techniques,
methods and processes that attempt to maximize reliability of components, systems, units, etc. It can
include spare parts programs, maintenance training, implementation of CBM, etc. This approach is
driven by similar pressures that lead to the need for CBM as one maintenance philosophy. The drivers
include:
P a g e | 12
Implementing CBM
4.1
Getting Started
The getting started is vital to developing a successful CBM implementation. This section contains
some practical advice on starting your CBM implementation process. Most importantly, recognize that
CBM implementations tend to be journeys rather than projects. CBM implementations will typically
start small and expand over time as process and information becomes more refined. Treating CBM
implementation as a project will often doom efforts from the start. As well, full CBM implementation
often involves a cross-disciplinary group of people. In most cases assembling and organizing and
effective team can be the main challenge to expedient CBM implementation. Internationally
recognized standards such as ISO 55001 and PAS 55 reinforce the idea that successful programs
require participation from all organizational levels so that CBM is aligned to core business missions.
Note that specialized condition monitoring equipment is not necessary to start most CBM initiatives.
This equipment does provide benefits for specific assets but is often expensive to install and may
require specialized skills to interpret data. Specialized condition monitoring equipment can also create
separate user interfaces, notification methods, integration paths to CMMS, etc. which tends to
compete with common enterprise goals to consolidate systems, interfaces and integration paths.
Carefully weigh the costs against the benefits of specialized condition monitoring equipment and, if
determined to be justifiable. It is possible to interface this equipment using the PI System to create
one user interface, one integration path to CMMS, one notification system, and one source of
condition monitoring data (PI System).
To start, identify some asset candidates for CBM; these are assets that are currently serviced through
calendar-based schedules and would benefit by converting to CBM. Some sources of information to
help identify equipment that may be best candidates include assuming that leading indicators exist for
this equipment:
Criticality to process CBM is particularly relevant when assets are critical to process.
Identifying single points of failure within a process can help select assets that would deliver
the most value if monitored with CBM.
Maintenance history can help identify assets whose mean time to repair or mean time
between failures are out of prescribed ranges.
Strong business case (ROI) when cost per failure is high for a particular assets, targeting
these assets for CBM presents a strong financial return.
After identifying asset candidates for CBM, the following resources can be used to further identify
candidates for the pilot implementation:
P a g e | 13
Failure Modes and Effects Analysis (FMEA) reports identify how a system may fail and the
effects of failure. Especially for large or critical systems, FMEA reports should contain
indicators of failure methods which may identify key points for condition monitoring. From
the FMEA, control strategies may be developed for each failure mode and may include a
preventive task, a predictive task or an operator task. These tasks are then combined and
form the basis of a maintenance plan.
Root Cause of Failure (RCF) reports - are post incident reports that show how smaller issues
and their ability to go undetected can result in a major incident. By identifying missing or nonalerted conditions and root causes of failure, potential sources for condition monitoring can
be defined. The efficiency of root cause failure analyses is greatly enhanced by easy, intuitive
access to long term archives of real time, condition and other data related to the asset. This
is a primary function of a PI System.
Subject Matter Experts (SMEs) are aware of the equipment that could be monitored for
CBM and will also help in determining how to use available information to determine asset
condition. They are also key in getting new instrumentation to help with condition
monitoring.
Maintenance Planners Depending on the type and size of the organization, maintenance
planning may be a dedicated function. These individuals are usually involved in putting
together calendar-based preventative maintenance and will likely know where vendors
recommend condition-based over calendar-based maintenance. Maintenance planners will
also be necessary to set the configuration of CMMS to support CBM.
Industry references & Vendor Manuals are a great resource (when available) to find vendor
recommendations on maintenance and where condition-based requirements are defined.
Industry references illustrate incidents from many similar plants in your industry and where
CBM needs to be applied or where its being applied well. They also help with putting
together the condition parameters and any necessary combinatorial parameters that are
necessary.
Generally speaking, technology is not usually a limiting factor when a CBM-enabled CMMS and a data
management system such as the PI System are present. In our experience, technology systems are
typically less of a challenge than overcoming the organizational issues associated with establishing a
CBM solution.
P a g e | 14
P a g e | 15
P a g e | 16
Condition
Input
Analysis
Maintenance
Planning
Work
Order
The meters current and previous values are used by the CMMS preventive maintenance program to
predict when the maintenance should be performed. To optimize CBM implementation, it is always
important to avoid these two scenarios:
Generating too many unnecessary maintenance items within CMMS can result in a reluctance
for maintenance to take seriously these orders as it overwhelms them with noise.
Systematically removing these false positives is key to broad adoption and realizing
maximum benefit by focusing attention only when it is truly needed.
Missing a necessary maintenance order based on an asset condition can be even worse. If the
asset fails and its criticality and impact to the plant or process are significant.
Its imperative to operate or otherwise test the logic of a condition monitoring process that intends
to send automated transactions to CMMS. This should be done over a period of time or history of data
to ensure that there is a confidence established when the process is automated.
A computational task (or job) will need to be scheduled within the CMMS that compares the recent
meter history to develop forecast dates for work order generation and scheduling. This is similar to
the jobs that are run for calendar based maintenance and consist of lead time for order generation.
Since for CBM the lead time is based on the progression of meter data and not days transpired, the
lead time generation calculations are more complex.
This job should be scheduled at typically once or twice the frequency of anticipated meter updates to
ensure important events are not missed. The creation of the work order is determined by parameters
defined within the maintenance plan (e.g. lead time) and considered by the preventive maintenance
program. In other words, the order may be created many days or even weeks ahead of the anticipated
need time of the maintenance to ensure that there is adequate time for planning, parts procurement,
etc. Since the maintenance planning job runs daily, sending measurement updates more than once a
day is usually unnecessary; however, there are cases where this may need to be considered.
P a g e | 17
Since meters generally run from 0 (or their previous value) to current value, there should be
consideration for resetting the start value within the CMMS for the next scheduled
maintenance once maintenance is complete.
2. When the source instrument fails and if the initial value of the replacement instrument is set
to some other value than the last value of the failed instrument, there may be a need to adjust
the value in the CMMS. An alternative is to offset the value before sending to the CMMS, which
can be done using the PI System.
3. There may be times where counter operations are incurred at the meter (or conditioning
algorithm) that should not be factored into the need to do maintenance. In these cases either
the CMMS meter readings will need to be manually adjusted or an offset value implemented
before sending to the CMMS, which can be done in the PI System.
P a g e | 18
The timing of an assessment algorithm should be such that it does not run more than once
between cycles of the CMMS maintenance process. If it did, state changes could be missed if
the condition was close to becoming a worse state. An alternative is to have the condition
algorithm monitor and account for this chatter.
2. Extreme state changes may occur for a variety of reasons and should be properly planned for
in the maintenance planning process. There may be a need to combine these meter updates
to the CMMS with an immediate notification for maintenance.
3. State changes in the condition of an asset may occur during routine maintenance of that asset
for an unrelated cause. Special precautions need to be planned for to prevent unnecessary
(and noisy) order generation when irrelevant.
P a g e | 19
With this approach, weve now integrated time-series data into enterprise IT systems bringing all
critical asset data into one comprehensive framework where more advanced applications can be
achieved. Automating the end-to-end process allows groups to refine their knowledge over time and
continuously make systematic improvement across the entire operations. Unifying systems that can
scale across functional boundaries provide common operating platform and an operational system of
record. A system that meets these challenges should have these characteristics:
P a g e | 20
The PI System delivers an open infrastructure to connect sensor-based data, operations and people.
It empowers companies across a range of industries, including oil & gas, power generation, utilities,
health sciences and mining to leverage high fidelity, real time data to support operational intelligence
and strategic business initiatives. Through hundreds of interfaces, the PI System collects data from
diverse real time systems typically contained in the OT domain. It is operated in very controlled
environments with limited access outside of operations to permit secure, reliable operation of critical
infrastructure. The PI System can make data available to defined users across the organizational levels
as well as trusted partners outside corporate walls. Real time data or analyses performed within the
PI System are accessible to enterprise systems, such as CMMS, BI, etc. to provide insight into the health
and condition of critical infrastructure assets based on. By bringing real time systems or operational
data into the IT environment, the PI System empowers all stakeholders with the data to drive
operational efficiency and strategic business initiatives.
5.1
P a g e | 21
P a g e | 22
Asset condition is
shown & analyzed
in clients
Data is
represented
and analyzed
as an asset.
Analytics &
Events are
created to reflect
condition
Time-series data is
collected and
stored PI Data
Archive
2
1
Asset data in a
variety of
systems
The figure above shows the PI System integrated with data sources and enterprise systems as applied
to condition monitoring and condition-based maintenance (CBM). The steps pictured above (and
enumerated by the black dots) show a sequential flow through the ecosystem and are explained
below:
1.
Asset data have disparate sources and exist in a variety of systems. Data are often
managed/evaluated to determine parameters that most effectively drive maintenance
health/condition and/or are used to determine maintenance activities (e.g. run time,
operations/cycles, etc.) (Figure 8 - above)
P a g e | 23
2. Data are acquired through PI interface nodes and stored in the PI Data Archive for simple retrieval
and analysis. Data streams are named as tags.
3. Assets are represented as elements within PI Asset Framework (AF) and are organized as
necessary for easy access and in support of analytics (e.g. rollups). This representation can include
static data, access to streamed data, calculations to assist in condition determination, data from
external systems (e.g. nameplate, CM/PM ratio, etc.).
P a g e | 24
=
Figure 13 - Example asset definition in PI Asset Framework (AF)
P a g e | 25
In many cases multiple sources need to be put together to define an asset framework and
populate AF. For example, the CMMS plant locations and physical equipment descriptions are
good starting points for static data, such as nameplate data and object information that is needed
to send data from the PI System to CMMS. In addition, the tag (or names of data streams) list is
needed to map tags to asset attributes. Remember, CBM is a process. Get started by mapping
some critical equipment and some critical attributes. Once assets, attributes and their data
streams are mapped in AF, payback is achieved every time somebody accesses data for CBM as
well as other activities supporting operational intelligence. .
4. Analytics & events are created to capture asset condition. They can be very simple to very complex.
For example, they can identify periods of high vibration, low pump efficiency, etc. or calculate an
aggregation of run time, material processed, etc. We can also combine a number of individual
condition factors into a health score for the asset.
P a g e | 26
5. Analysis results and events can fire notifications to either alert an individual of a condition or
update another enterprise system. For example, PI Notifications can send an email to an engineer
to indicate that a specific condition has occurred or update CMMS with a meter (operation) count.
A PI Event Frame is 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 the illustration above, an Event Frame is initiated by a trigger
P a g e | 27
P a g e | 28
The two sample reports above are just quick examples of the complex reports that are easily
created using Microsoft Excel and acquiring event data from the PI System. These reports are
numerical analysis reports that are useful for evaluating events for a specific asset and events
across many assets and asset types.
7. Finally, we can integrate asset data into CMMS and other enterprise applications in a number of
ways. Specific details are provided in the appendix. There are two basic scenarios, either push or
pull. Push sends data to people and systems using any number of delivery channels, for example
by sending emails or invoking a web service. The Pull model is enabled by PI Data Access
technologies where enterprise applications can acquire data from the PI System using any number
of technologies, including the most popular open standards methods such as OData.
P a g e | 29
In this section, well provide an overview of methods used to integrate PI System data with CMMS
applications.
P a g e | 30
6.1
In this method, the CMMS uses an internal program to access PI System data directly via one of the PI
Data Access Components and may require a client side (in this case the CMMS program) install for the
PI SDK or PI ODBC/JDBC or PI OLEDB. The CMMS may also invoke remote web services to read/write
PI System data or use our evolving PI System Access components such as the Web API or OData.
The purpose of the Data Request program is to monitor the PI System for process changes that should
be reflected in meter updates and then make those meter updates. This program could also
interrogate the state of the maintenance order and reset counters in the PI System or Event Frames
that indicate work is needed in order to initiate the next event frame.
Condition Input
Analysis
PI
Interface
SCADA,
PLC, etc.
PI Server
PI
Analytics
PI Data
Access
PM
Order
Maintenance
Plan
Configured
for CBM
CRON
Job
Data
Request
Maintenance
Planning - CMMS
The above example is a very simplistic approach and has many variants. It requires a minimum number
of PI System components and is supportable by older versions. For example, an SAP ABAP program
could control the interface between the PI System and CMMS Meter updates. This program could also
generate orders or notifications immediately if necessary.
There are cases where some PI Analytics components are required, including PI Asset-Based Analytics
or in older implementations, PI ACE.
The following table lists some pros and cons of this approach:
PI System as a real time bus, accessed via the CMMS directly (pull)
PROS
CONS
P a g e | 31
could
P a g e | 32
Condition Input
Analysis
SCADA,
PLC, etc.
PI
Interface
PI
Analytics
PI Data
Access
Maintenance
Planning - CMMS
PM
Order
PI Server
Adapter
Maintenance
Plan
Middleware
Adapter
Configured
for CBM
CRON
Job
CMMS
Core
The figure above shows a simplistic diagram of the integration of the PI System with CMMS via a
middleware component.
An example of an integration scenario initiated by an event in CMMS could include an asset change
(location, equipment and component). When this change occurs, it initiates a process that updates PI
AF to reflect the asset change. This could be new, out-of-service, retired or changed asset information.
Some examples of common middleware components include:
IBM Websphere MQ Series This is IBMs offering for enterprise integration and is a java
environment. A typical way this is used is to invoke web services or add entries to JMS
Queues, ensuring message communication.
Microsofts BizTalk This Microsoft offering operates in the MS Windows environment and is
a very popular and intuitive tool.
SAPs Process Integrator This is SAPs primary EAI broker (formerly XI) and integrates very
easily into SAP business processes although it is not limited to SAP integration (although rarely
used outside an SAP enterprise).
SAPs MII - This is not exactly an integration broker, however it is commonly used as such in
SAP Manufacturing enterprises. Manufacturing Integration and Intelligence (MII) is a part of
the SAP NetWeaver stack and specifically intended to integrate shop floor systems with SAP
and provide analytical and real time displays.
The following table lists some pros and cons of this approach:
P a g e | 33
CONS
Flexibility when the PI System needs to be Requires a PI System specific adapter that
interfaced to many other systems standards supports specific functions
based
Standards based, when middleware is used for Limited functions as this is based on specific
a number of integration scenarios
functions
6.3 PI Analytics (or similar) invoking services of the CMMS for integration (push)
In this scenario, PI Analytics (or similar) operates based on PI System events or clock schedules and
invokes the integration process with the CMMS. The integration method could vary depending on the
enterprise and technology preferences. It could be a custom program, a custom data reference or
some simple MS PowerShell scripts. Many integration (shown as a connector below) could include:
Condition Input
Analysis
SCADA,
PLC, etc.
PI
Interface
PI Server
Maintenance
Planning - CMMS
PI
Analytics
Connector
PM
Order
Maintenance
Plan
Configured
for CBM
CRON
Job
CMMS
Core
P a g e | 34
CONS
Approach suitable to minimal PI System Requires some customization of the coding for
the integration. May be as simple as invoking a
component installations
web service
Simple to implement, in most cases, depending Limited configuration information
on skill set of CMMS support
become an issue to maintain
could
Once the PI System infrastructure has enabled condition monitoring (CM) and CBM through process
information and condition indicators, there are many additional opportunities for business value.
Lifecycle Extensions
Decision Support
Engineering Desktop (System Health Indicators)
Improved Operations
Work Prioritization
More focused Capital Expenditures
Enabling more effective Business Intelligence (BI)
Improved efficiencies in Root Cause and other Failure Analysis efforts
7.1
Lifecycle Extensions
The PI System provides insights into asset history and its associated process history, such as thermal
cycling, pressure cycling, event occurrences (e.g. high vibration, shutdown, etc.). This information can
be useful in determining actual equipment life remaining. For example, IEEE provides a standard
method to calculate useful transformer life available based on asset process history and current
testing results.
P a g e | 35
7.2
Decision Support
Developing cubes for multi-dimensional analysis is a relatively simple task with todays tools and
adequate knowledge of your assets and process. Below is an example cube showing organized by
facts (gas rate, gas volume, fuel ratio, etc.) and sliced by dimensions (eq type, plant, process, etc.)
P a g e | 36
7.3
Work Prioritization
Health indicators derived from CBM solutions can also be used to prioritize work related to specific
assets, system or processes. If similar work is planned on assets serviced by similar resources, the
health of the asset or system can be employed to determine which maintenance to focus on first.
7.5
Many businesses rely on time series data as a source of business critical operations insights. The PI
System provides insights into asset information that may be combined with other process and
business focused information to enable more effective insights.
This section presents some examples of how CBM can be applied to a variety of common asset types.
For each asset type, examples are provided where one or more condition indicators are integrated
with a maintenance plan or immediate notification. Actionable output will include visualizing the
problem and data mining to determine or verify the root cause.
Types of actionable outputs may include:
P a g e | 37
Publish KPIs and operational metrics (normally via website and portals)
Email or Text Notifications
Work order to a work flow engine such as CMMS, ERP, MES etc.
Generate a detailed fault report
SOA request into an Enterprise Service Bus (ESB)
These examples are not intended as definitive CBM examples. You can find white papers for each asset
represented here with different approaches. We have listed a few customer examples and published
white papers for additional information and ideas.
8.1
8.1.1
Transformers
Transformer Asset Overview
The average age of the majority of 115,000 large transformers, in both transmission and industrial U.S.
distribution grids, is approaching the expected end of life. Many companies are now unable to obtain
transformer insurance since the devices exceed their Gompertz life cycle estimates. Copper and iron
losses, a natural part of the aging process, are continually increasing the power loss over time in these
transformers. CBM can help identify critical assets that need to be replaced before they impact
availability or safety.
Unexpected transformer failures can cause significant losses to supporting assets and facilities along
with the potential safety risk. Replacement costs for a large transformer easily run into the hundreds
of thousands of dollars, and damage to downstream equipment during transformer failure is common.
Lead time for transformers is getting longer, with some devices requiring many months for delivery.
Outages caused by the loss of a distribution transformer would have such severe impacts that many
companies maintain online backup transformers or replace working transformers long before they
reach end of life. Either of these strategies is extremely capital intensive and energy inefficient.
8.1.2
Increasingly, transformers are having more online condition monitoring instrumentation equipment
installed and used to collect data at the substation and sent back to the central office via substation
monitoring, the Energy Management System (EMS) or by other methods (e.g. dial-up, dedicated
systems). Online monitoring presents the option for onsite personnel to access the data even if there
is a loss of connectivity to the site. Regardless of the specific architecture, having consistent access to
the data remotely is essential for effective CBM implementations as most installations are geospatially
disperse and would be more costly to manage through manual inspections.
Having online monitoring information in the PI System means that it can be combined with other
information such as loads, ambient temperature, nameplate ratings, top oil tank temperatures, etc.
Combining the diagnostic oil information with these other parameters helps to ensure early detection
of issues and correlate incidents, such as overheating, with excess wear and damage. The diagram
below represents a simplified fault tree for large power transformers. There are typically a number of
P a g e | 38
P a g e | 39
Sweeping Frequency Response Analysis. This measurement is based on the delta between a
Fast Fourier Transform (FFT) analysis of the transformer input, and a corresponding FFT of the
output. Statistical Quality Control (SQC) methods are used to determine if the frequency
response of the transformer is changing in a meaningful way.
Complex Impedance Analysis. The high resolution voltage and current information provided
by the PMUs is used to compute the impedance matrix of the transformer in real-time. Again,
SQC methods are used to determine if the impedance of the transformer is changing in a
meaningful way.
Both of these analyses are good indicators of structural changes in the transformer that occur on a
very small scale. The rate and magnitude of change observed is proportional to the rate and magnitude
of transformer decay.
What is unique about this approach is that the alerting is based on rate of change away from observed
normal operating conditions, as opposed to waiting for an abnormal condition to occur. Once an
abnormal condition occurs (such as a high oil temperature) it is often too late to deal with the situation
in a proactive manner. Slope based alerts indicated a trend towards a problem, rather than that a
problem has already occurred. Operators have more advanced warning of transformer failure and can
make it easier to make plans to repair or replace the transformer.
Real time, online transformer health monitoring can be constructed using off-the-shelf OSIsoft PI
System components:
1.
2.
3.
4.
5.
6.
7.
C37.118 and Arbiter 1344 interfaces collect the required data from the Phasor Measurement
Unit meters.
The PI Server routes data to all analysis routines and visualisation clients in real-time. It also
stores both input and calculated data in the PI server archives.
The OSIsoft FFT Interface computes the fast Fourier transform of the system frequency at both
the inputs and outputs of the transformer in real-time.
The PI Analysis Engine (or custom programs using the PI AF SDK) is used to calculate the
complex impedance matrix of the transformer in real-time.
The PI-SQC system compares the computed values against statistical norms
PI ProcessBook and other methods provide real-time and historical information in graphical
formats
PI DataLink and DataLink for Excel Services allow the integration of real-time and historical
data into the Excel environment for complex analysis and presentations
P a g e | 40
8.1.3
In addition to data mining or visualizing primary data sets, conditional logic and/or business rules are
applied to prioritize and filter automated maintenance requests. Business rules for maintenance and
service requests can be very complex. They can also take into account the associated risk of non-action
and how critical the asset is to the business. They may also consider warranty status, average lead
time, number of inventory spares etc. in their rules to define actions.
Creating asset-based analytic calculations and conditional logic can be created and applied
consistently in a PI System Asset Framework (AF) Template. Complex business rules can be applied
from Asset Management or CMM applications or in an orchestration engine. For example, if a
transformer condition indicates it needs inspection within seven days of a pre-existing maintenance
appointment, the system should not create another service request.
P a g e | 41
The figure above represents some typical process and name plate values that may be configured in a
PI AF template. Analytics defined within the AF template can calculate specific asset health conditions,
such as time at emergency ratings, high temperature events, insulation degradation based on DGA
results, etc. This process can drive both specific immediate actions, such as operational or
maintenance activities as well as factor into longer term decisions for planning, capital replacement
projects, work prioritization, etc.
8.1.5
Transformer References
TVA - DobleARMS and PI System Bring Standards-Based HV Asset Management to TVA
P a g e | 42
Hydro Quebec - AMI Analytics & Power Transformer Simulation Laboratory for Proactive
Maintenance II
FinGrid - Building a Condition Monitoring System Based on PI AF
8.2 Pumps
8.2.1 Pump Asset Overview
Pumps are the second most common machine in the world; however, the potential of pump CBM as a
source of improved productivity and reduced costs is often overlooked. Because companies utilize
numerous types of pumps, creating a standard strategy to proactively perform maintenance can be
perceived as an intimidating task; however, a standardized approach leads to a variety of
improvements including:
More efficient operations (operating close to the best efficiency point (BEP) of the pump)
Prolonging asset life (through more effective usage patterns)
Improved capital expense programs (by better equipment sizing)
Lower energy costs by optimizing energy management
Maintenance improvements (by doing the right maintenance at the right time, moving from
unplanned to planned activities)
Here we discuss an approach to leveraging the PI System to create a standard, scalable monitoring
solution for an organizations centrifugal pump assets.
8.2.2
A principle challenge in creating an effective maintenance system for pump maintenance is creating a
systematic framework to link static pump properties, high fidelity operational data and operational
context. Examples of attributes, data streams and events that should be brought together so that
users can see asset information in context are:
Manufacturer
Type
Size
Horsepower
Available Net Positive Suction Head
(NPSHa)
Required Net Positive Suction Head
(NPSHr)
Static head
Friction loss
Process
EQ number
P a g e | 43
Having this information in the PI System means that pump data can be organized according to asset
attributes and topology. The PI Asset Framework (AF) creates a template for a basic pump that include
available information that applies to the majority of pumps, such as nameplate data, maintenance
data, date installed, Best Efficiency Point (BEP), criticality to the process, next maintenance date, etc.
Once templates are populated with data streams, calculations and static data values, users have access
to a single, consistent method to shape and prioritize pump maintenance. CBM implementations are
and would be more costly to manage through manual inspections.
For example, users can track the run hours of the pump or track the basic conditions related to the
operation and maintenance of the pump. When pump issues or failures occur, historical data can be
analysed to develop condition indicators and link root cause to vendor, use conditions or external
conditions. Once this first phase is complete, consider a more robust strategy of incorporating alarm
data and integrating the PI System with a CMMS system (to drive a true CBM solution). The number
of pump run hours is approaching the vendor specified limit for maintenance or calibration. For
example, operators can use PI System to define a trigger that create a work order in the local CMMS
system. When this work order is complete, a message can be returned to reset the run hours counter
on the asset.
Condition monitoring alone (CM) of pumps can lead to improvements in operation and maintenance
and is a first step to true CBM. CM may be accomplished using operational data, condition specific data
and eventually lead to information that serves as the basis for other predictive techniques such as
advanced pattern recognition (APR) that can be particularly useful in pump maintenance.
8.2.3
A key part of an effective PM solution is to develop accurate condition indicators and methods to
display actionable asset condition information. The PI System provides visualisation options that can
be reused, shared throughout the enterprise and can be easily modified as operations and data needs
evolve. Operators can use real time displays to monitor asset condition within any maintenance
strategy. Users can create standard visuals of the pump data for multiple end users using tools like PI
ProcessBook or PI Coresight.
P a g e | 44
When organizations use OSIsofts Asset Framework to structure asset data, operators, maintenance
or engineers can use asset relative displays which toggle between different pump assets associated
with the same template. Over time, users can determine how different vendors pumps perform or
how much one costs to maintain versus another. Users do not have to create custom graphics or
calculations for each pump, simplifying the creation and maintenance of the data management
system.
Maintenance and engineering personnel can drill down into archived condition monitoring data for
post-hoc analyses. Engineering can conduct root cause analyses, develop more precise indicators to
optimize CBM solutions or create information for equipment replacement evaluation. In some cases,
maintenance may need access to this information evaluate what maintenance to perform and when
to perform it.
P a g e | 45
Real time, online health monitoring for pumps can be constructed using off-the-shelf OSIsoft PI
System components:
1.
2.
3.
4.
5.
6.
8.2.4
Standard PI System interfaces collect the required data from the pump motors, bearings,
flowmeters, etc. These typically come from PLCs, DCS or SCADA interfaces.
The PI Server routes data to all analysis routines and visualisation clients in real-time. It also
stores both input and calculated data in the PI Data Archives.
PI Asset Framework organizes pump data according to asset attribute, elements and topology
to create a standardized method of assessing pump health.
The PI Asset Analysis Engine (or custom programs using the PI AF SDK) is used to calculate
condition indicator values in real-time.
The PI-SQC system compares the computed values against statistical norms.
PI ProcessBook, PI DataLink and other client tools display real-time and historical information
in visual and graphical formats
Pump References
Helping customers lower TCO with Flowserves Technology Advantage Web Portal
Condition Based Monitoring for Rotating Equipment Millennium Inorganic Chemicals
8.3 Compressors
8.3.1
Compressed air, along with gas, electricity, and water, is essential to most modern industrial and
commercial operations. It runs tools and machinery, provides power for material handling systems,
and ensures clean, breathable air in contaminated environments. It is used by operations in virtually
every industrial segment from aircraft and automobiles to dairies, fish farming, and textiles.
P a g e | 46
The following provides a basic overview of sources of data relevant to compressor health and
monitoring.
8.3.3
In this example, a report was sent to the Maintenance Department for review of the data for their
recommendation. This may happen as a function of a business process or in conjunction with other
notifications such as CMMS or CRM.
P a g e | 47
8.3.4
Compressor References
The Compressed Air ChallengeTM is a national collaborative formed to assemble state-of-theart information on compressed air system design, performance, and assessment procedures.
http://www.compressedairchallenge.org.
Heat exchangers are mechanical devices designed for the transfer of heat from one fluid matter to
another through a solid surface. The fluids themselves never mix but instead are separated by the solid
surface. Heat exchangers are widely used in petroleum refineries, chemical plants, petrochemical
plants, natural gas processing, refrigeration, power plants, air conditioning and space heating. Other
examples of heat exchangers include intercoolers, boilers, condensers, and also preheaters. You also
find heat exchangers in everyday household appliances, such as air conditioners and refrigerators. One
common example of a heat exchanger is the radiator in a car; a hot engine-cooling fluid, like antifreeze,
transfers heat to air flowing through the radiator.
P a g e | 48
8.4.2
The actual heat transfer coefficient is used to determine the overall effectiveness of a heat exchanger
over time. Real-time models can also calculate the actual tube fouling in a heat exchanger. A more
practical method uses a simple calculation comparing the input and out temperatures can provide
overall condition assessment of a heat exchanger. Sensors equipped to monitor the process
effectiveness can also be used to evaluate its overall condition.
A simple heat exchanger template can be created then be applied to more complex assets that may
contain a heat exchanger. The asset elements will also allow data roll-up calculations so that each heat
exchanger can be compared to the performance of the others identifying outliers as prospective
maintenance targets.
Real time, online health monitoring for heat exchangers can be constructed using off-the-shelf OSIsoft
PI System components:
1.
Standard PI System interfaces collect the required data from the temperature measurements
from data loggers and process control system interfaces.
2. The PI Server routes data to analysis routines and visualisation clients in real-time. It also stores
both input and calculated temperature differential data in the PI Data Archives.
3. PI Asset Framework organizes heat exchanger data according to asset attribute, elements and
topology to create a standardized method of assessing heat exchanger health in other assets.
4. PI Notifications configures the triggering event calculation for absolute temperature and rate
of temperature change and provides an email or text message. PI Notifications can have links
to the visualisation tool best suited for further investigation along with acknowledgement.
8.4.3
One effective way to make CBM information actionable is to send a notification to responsible parties
when an important event has occurred. In this example, a heat exchanger has degraded to a point
where it needs attention. In addition to sending a maintenance request to a CMMS system, the PI
System will send an email to the maintenance manager on duty along with links to visualization tools
that will be provide additional insight on it severity.
P a g e | 49
In the event the primary person or group responsible for maintenance is unable to take action, PI
Notifications can be configured to escalate the issue. Details such as the acknowledged time and
period counts of the notifications and also be used to benchmark the overall maintenance workload
and response times using an Excel spreadsheet ad-in client.
8.4.4
9.1
The basic process suggested here is fairly straightforward and consists of the following steps:
1.
P a g e | 50
Everyone is too busy These initiatives do take a fair amount of resources from a wide variety
of disciplines. They change the way work and often operations are accomplished and require
some IT and OT work (e.g. tying systems together). While its often perceived as a lack of
leadership, it seems like most people are too busy doing their day to day work to take the time
to get everyone together, all on the same page, define the goals, acquire the funding, etc. to
take this on.
2. They are approached as a Project instead of Continuous Improvement CBM is most
successful when it is implemented as an organizational change. Not that this does not require
some upfront investment (see #1 above), but organizations do not need to solve all CBM needs
in one project. Its best to start CBM implementation as a small project with the understanding
that it will continue to evolve.
P a g e | 51
STEP 1:
Strive to increase management awareness and appreciation of the operations and maintenance
program/department.
STEP 2:
Commit to begin tracking Operations and Maintenance activities.
P a g e | 52
STEP 4:
Commit to addressing at least one of these troubled systems.
Begin base-lining/tracking this system. -System operations and history. -System maintenance
and history. -System costs, time to service, downtime, resulting overtime, etc.
STEP 5:
Commit to striving for Operational Efficiency of this system.
Strive to understand how to properly operate this system. -Define and complete operator training
needs.
Strive to understand how to properly maintain this system.
-Define and complete maintenance training needs.
STEP 6:
Commit to purchasing or contracting for some form(s) of diagnostic, metering, or monitoring
equipment.
STEP 7:
Commit to trending the collected tracking and diagnostic data.
Take to time to understand the data.
Look for and develop project opportunities. -Develop appropriate cost justification metrics.
STEP 8:
Select, request funding for, and complete first Operational Efficiency project.
Start small, pick a project that will be a winner.
Carefully document all findings.
Present success in terms management will understand.
STEP 9:
P a g e | 53
10 References
This section includes OSIsoft and other industry references.
P a g e | 54
P a g e | 55
P a g e | 56