Sie sind auf Seite 1von 56

A Guidebook to Implementing

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

PI System for CBM

Contents
1

Introduction ......................................................................................................................................... 4

Overview .............................................................................................................................................. 5
2.1

An Introduction to Condition-Based Maintenance (CBM) ........................................................ 6

2.1.1

Definition .............................................................................................................................. 6

2.1.2

Objectives ............................................................................................................................. 7

2.1.3

Role of CBM in CMMS .......................................................................................................... 7

Maintenance Strategies & Types ........................................................................................................ 8

Implementing CBM ............................................................................................................................. 13

4.1

Getting Started............................................................................................................................ 13

4.2

Condition Monitoring ................................................................................................................ 14

4.3

Condition Assessment ................................................................................................................ 15

4.4

CBM Configuration..................................................................................................................... 16

4.5

Quantitative-based meters (count) ........................................................................................... 17

4.6

Qualitative-based meters (state) .............................................................................................. 18

4.7

Immediate Maintenance Order Generation ............................................................................. 19

4.8

Why is PI the right bridge from OT to IT for CBM? ................................................................... 19

An Introduction to the PI System....................................................................................................... 21


5.1

Description of PI System capabilities ......................................................................................... 21

PI System integration with ERP/EAM................................................................................................ 30


6.1

PI System as a Real Time Bus, accessed by CMMS directly ...................................................... 31

6.2

PI System as a real-time bus, using middleware for CMMS integration ................................. 32

6.3

PI Analytics (or similar) invoking services of the CMMS for integration (push)..................... 34

Some enabling opportunities ............................................................................................................ 35


7.1

Lifecycle Extensions ................................................................................................................... 35

7.2

Decision Support ........................................................................................................................ 36

7.3

Work Prioritization ..................................................................................................................... 37

7.4

More focused Capital Expenditures.......................................................................................... 37

7.5

Enabling more effective BI ........................................................................................................ 37

CBM Solution Examples ..................................................................................................................... 37

P a g e |2

PI System for CBM


8.1

Transformers .............................................................................................................................. 38

8.1.1

Transformer Asset Overview............................................................................................. 38

8.1.2

Transformer Monitoring and Analysis .............................................................................. 38

8.1.2.1

Transformer Oil and Gas Analysis.................................................................................. 39

8.1.2.2

Online Monitoring for Sweeping Frequency Response Analysis (SFRA) .................... 39

8.1.3
8.1.3.1

LTC maintenance ............................................................................................................ 41

8.1.3.2

LTC not through zero ..................................................................................................... 41

8.1.4

Transformer Actionable Output ........................................................................................ 41

8.1.5

Transformer References .................................................................................................... 42

8.2

10

Pumps ......................................................................................................................................... 43

8.2.1

Pump Asset Overview ........................................................................................................ 43

8.2.2

Pump Monitoring and Analysis ......................................................................................... 43

8.2.3

Pump Actionable Output- Visualisation ............................................................................ 44

8.2.4

Pump References ............................................................................................................... 46

8.3

Transformer Load Tap Changers (LTCs) ........................................................................... 41

Compressors .............................................................................................................................. 46

8.3.1

Compressor Asset Overview ............................................................................................. 46

8.3.2

Compressor Monitoring and Analysis ............................................................................... 47

8.3.3

Compressor Actionable Output ........................................................................................ 47

8.3.4

Compressor References .................................................................................................... 48

Improving Reliability with Caterpillar Condition Monitoring Services .................................... 48

8.4

Heat Exchangers ........................................................................................................................ 48

8.4.1

Heat Exchanger Asset Overview ....................................................................................... 48

8.4.2

Heat Exchanger Monitoring and Analysis......................................................................... 49

8.4.3

Heat Exchanger Actionable Output .................................................................................. 49

8.4.4

Heat Exchanger References .............................................................................................. 50

Guidance on CBM Implementation with the PI System ................................................................... 50


9.1

Basic CBM Implementation Practice ......................................................................................... 50

9.2

Building a business case ............................................................................................................. 51

9.3

Ten Steps to Operational Efficiency.......................................................................................... 52

References ......................................................................................................................................... 54
10.1

OSISOFT INDUSTRY REFERENCES .................................................................................................. 54


Page |3

PI System for CBM

10.2

PARTNER REFERENCES .................................................................................................................. 55

10.3

PUBLISHED BOOKS AND ARTICLES ................................................................................................. 55

10.4

List of Figures used within ......................................................................................................... 55

10.5

The team that put this book together ...................................................................................... 56

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.

CBM can be an important component of a holistic Asset Management strategy described in


internationally recognized standards such as the ISO55000 series. The content in this document
1

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

PI System for CBM


supports a framework for data-driven planning and decision-making as well as establishing criteria to
prioritize asset management decisions according to organizational needs, defined value and to
achieve a balance when faced with conflicting objectives.

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.

Figure 1 CBM is a continuous improvement process.

Some common CBM scenarios include:

Pump lubrication PM based on actual motor run-time, say 2000 hours


Analyser re-calibration PM based on actual drift exceeding 1%
Filter change PM based on measured pressure differential across the filter exceeding
allowable limits
Page |5

PI System for CBM

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. > 6
operations in < 24 hours)
Transformer servicing based on dissolve gas analysis results over time that indicates
insulation degradation.
Bearing swap out based on vibration data of motor shaft, or motor current signature
analysis.

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

An Introduction to Condition-Based Maintenance (CBM)


Definition

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

PI System for CBM


2.1.2

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:

Reduce maintenance costs (stretch maintenance cycles)


Reduce adverse impacts of maintenance activities (if it works, dont fix it)
Improve asset reliability (ensure assets are functional and capable)
Improve asset availability (minimize asset downtime)
Enable value realization from condition information (e.g. lifecycle extension, decision
support, better capital expenditures, etc.)

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

Figure 2 Cost & Maintenance Distribution before and after CBM

2.1.3

Role of CBM in CMMS

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

PI System for CBM


often supplemented by a calendar schedule as well to ensure maintenance is performed even when
the asset is little used. A familiar example to the most casual reader maybe the oil maintenance of a
vehicle, which is typically stated in terms of a condition (7,500 miles driven) or a calendar event (12
months duration) whichever comes first.
EXAMPLE: Modern vehicles can detect the condition of the lubricating oil (expressed in %) and
recommend replacement when it is losing its effectiveness.
EXAMPLE: A compressor needs maintenance after a certain number of start/stop cycles. If start/stop
cycles cannot be counted, conservative factors would be used to estimate a time interval after which
maintenance should be scheduled. The factors could be based on predictive information or vendor
recommendations to ensure maintenance would be done before exceeding the recommended
number of cycles. In contrast, CBM ensures maintenance is done only when theres a need. CBM gives
the advantage of setting maintenance cycles at longer periods than would have been done using
conservatively based on time schedules, saving money and increasing equipment availability.
Real-time asset information enables users to define asset-specific condition indicators either from raw
sensor data or though data calculations. Condition indicators derived from asset data initiate
maintenance tasks based on real time conditions and are asset-specific. Real time asset data may come
from on-line monitoring (temperatures, delta pressures, start/stop sequences, etc.), off-line diagnostic
tests (eddy current, corrosion inspection, oil analysis, etc.) or portable test equipment (thermography,
Doble electrical test set, etc.) The PI System can manage and historize, aggregate and perform analysis
on all of these data types with information from other sources. Condition indicators derived from
these analyses and calculations can be provided to the CMMS. Well cover much more on access
methods later.
The benefits of well-implemented CBM programs extend outside of protecting corporate investment
in asset portfolios. When real-time asset data provide visibility into asset condition, maintenance
schedules and costs can be planned. (Will that compressor make it until the next outage?) Common
failures or issues that occur across units or within fleets can be identified. (Why is maintenance more
expensive on a specific vendors equipment compared to other vendors?) Just by creating visibility
into asset condition indicators, data can help prevent catastrophic failures. It only takes a few big saves
to typically pay for a complete CBM implementation.

Maintenance Strategies & Types

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

PI System for CBM


Maintenance strategies describe an organization's approach to maintenance for a given group of
assets. Often these strategies are characterized as a maturity model, although it's not always
necessary to use advanced techniques on all asset types. In practice, most organizations apply a
combination of these strategies to their asset fleet, dependent on asset criticality, impact of failures
to the business, costs and other factors.

Figure 3 - Maintenance Strategies

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

PI System for CBM


Preventative maintenance (PM) is done in a proactive manner and assumes that no equipment failure
has occurred. Historically, this has been based on calendar or facility events (e.g. outages) and not on
condition. Not all assets necessarily have preventive maintenance plans. Some are determined as run
to failure (RTF). The decision to apply PM vs RTF options is often determined by a review of cost versus
value during a PM Optimization effort.
PMs are prescriptive, in other words, they are pre-defined tasks that should be performed to
accomplish the specific preventive maintenance activity. They generally follow a vendors (or OEM)
recommendation, regulatory guidance and industry experience.
PLANNED MAINTENANCE
These activities are very similar (and often used interchangeably) to preventive maintenance as
described above. They are prescriptive, follow recommendations, etc.; however they are generally
also referred to as event-based, i.e. they are called for after a specific event, such as a predictive
indicator. Preventive maintenance is included in this category.
CORRECTIVE MAINTENANCE
These activities are reactive and in response to an asset issue or failure. Except for RTF components,
these are to be minimized in most cases due to their cost and impact to operating conditions.
PREDICTIVE MAINTENANCE
Predictive maintenance uses condition monitoring and other stochastic methods to try to determine
when a failure will occur. With some predictive maintenance the idea is to predict the useful remaining
life of an asset. Overall, the idea is to perform the planned work without having to react to an incipient
failure. Predictive maintenance can operate online (e.g. vibration monitoring) or off-line, for example
during an outage. For example, its popular to do eddy current testing in steam generator tubes during
an outage to determine which tubes should last until the next outage and which ones need plugging.
The predictive maintenance model uses various techniques to produce a point on a graph to determine
remaining life of an asset. The following is an example of this curve:

P a g e | 10

PI System for CBM

Figure 4 PF Curve used in Predictive Maintenance (or Incipient Failure Detection)

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

PI System for CBM

Figure 5 an example of APR in action on a monitored process variable

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:

Figure 6 Drivers for Reliability Centred Maintenance

P a g e | 12

PI System for CBM

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

PI System for CBM

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.

4.2 Condition Monitoring


Once suitable candidates to pilot CBM have been identified, it is important to discover and refine
information that will guide CBM. Condition monitoring is the process of using asset data to monitor a
parameter (vibration, temperature etc.) in order to identify an indicator that predicts a developing
fault. It is a major component of predictive maintenance and a necessary predecessor to CBM.
Condition monitoring often involves unique and innovative ways to use data to develop accurate
indicators of asset health. Some form of condition monitoring, however basic, must be performed in
order to send updates (or transactions) to a CMMS when CBM is fully implemented.

P a g e | 14

PI System for CBM


Condition monitoring could be as simple as recording operator rounds (by shift, weekly, monthly, etc.)
or collecting hour-meter readings or quite complex. For example, one can run Fast Fourier Transforms
(FFT) on current and voltage waveforms of transformer windings and analyze harmonics to detect
issues. The results could be a state value (indication of an issue) or an analogue value. The analogue
value could be monitored separately and used in many ways, including updates to CMMS.
Often, but not always, condition monitoring involves specialized equipment that looks at a certain
aspect of an asset to understand an aspect of its condition such as vibration, acoustic monitoring,
motor current signature analysis, etc. Whether or not specialized equipment is involved, the results or
indication of the condition are only available using dashboards, displays and/or reports, as opposed to
being integrated with a related asset in CMMS. In some cases, notifications alert individuals of certain
conditions, but this is still only condition monitoring and not CBM. Condition monitoring should not be
confused with predictive maintenance (see later section) or the result of a single diagnostic test
executed by a human. For example, if someone does a thermography observation of a component
and finds an issue, maintenance issues should be addressed immediately and are not dependent on a
separate system.
Bottom line, condition monitoring is a prelude to CBM. We recommend starting with condition
monitoring alone to test the ideas, concepts, etc. behind CBM rules before integrating them with a
CMMS.
Sometimes, condition monitoring involves existing process variables and typically aggregates them to
determine an assets health, relative to other assets within and among peer groups. We refer to this
as condition assessment.

4.3 Condition Assessment


Condition assessment (CA) is the aggregation, assimilation and normalization of a series of condition
indicators (or factors) related to an asset, the result being an overall condition indicator (or asset
health indicator) in a range or state that can be compared to other assets. In the most extensive
definition of CA, the condition indicator is normalized to the point that it can be applied across peer
groups and be rolled up through an asset hierarchy, allowing system, unit, plant, fleet, etc. wide
comparisons. CA helps prioritize capital replacement/improvement dollars, system engineering time
or maintenance prioritization, etc.
Condition assessment often makes use of data other than performance data; it often includes
maintenance process data such as Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR),
asset criticality, CM/PM ratios, recent trends of damage and cause codes, etc. It may also include
nameplate and other static data such as age, manufacturer, grade, etc. These factors are often
valuable as recent values and historical trends. These data, condition indicators, come from the CMMS.
To develop a condition assessment indicator, factors have to be developed for the equipment peer
group. These factors are limited to data available, i.e. you cant use the gas content of a transformers
oil tank if its not available. If data is available for some factors and not others, there needs to be a

P a g e | 15

PI System for CBM


default or typical value when data is not available. The condition assessment (CA) is a sum of the
individual factors:
CA = F1*M1 + F2*M2 + F3*M3 + F4*M4 + F5*M5; where:
M is a number between 0 and 1 and M = 1, and
F is a number between 0 and 10.
For each of the factors, a case statement should be developed that compares the actual condition
indicator to a set of values and determines a result of a number between 0 and 10. A default or typical
value should be provided for missing data.
With this method, the result should be a number between 0 and 10. You can determine whether you
prefer 0 or 10 to be good or bad based on the evaluation of the case statement. The condition
assessment algorithm should be peer group specific and applied periodically to each asset within the
peer group and the result (CA and each factor) historized to provide the ability to associate and asset
with its CA and trend these values.
The CA value can be used with CBM by qualitative assessment. For example 0-2 creates a maintenance
order based on maintenance plan x.
These results also provide a current and historical value for the condition of the asset that is useful
in capital replacement determination, work prioritization, system health assessments, etc.

4.4 CBM Configuration


CBM configuration is primarily done within the CMMS where the maintenance processes (plans) are
configured. Calendar-based maintenance relies on time-based configurations. For CBM, we configure
maintenance processes on asset conditions. Instead of using a clock (as for time-based), we use a
meter (or measurement point) where a condition is recorded. Remember, CMMS that support CBM
use a meter that triggers pre-defined maintenance plans (even if the plan is simply to investigate the
cause of the condition). The configuration of the maintenance plan will typically include calendarbased input as well (its like changing your cars oil every 7,500 miles or 12 months, whichever comes
first).

P a g e | 16

PI System for CBM

Condition
Input

Analysis

Maintenance
Planning

Work
Order

Figure 7 Simplistic flow of condition-driven maintenance process

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.

4.5 Quantitative-based meters (count)


Meters are defined in one of two ways, either quantitative (aka usage or counter-based) or qualitative
(aka state or characteristic-based).

P a g e | 17

PI System for CBM


Quantitative-based meters represent numerical values that typically move in one direction (or count).
These values are often subcategorized into two counting types: usage and events.
Usage counting generally refers to a summing of time, material or flow. Examples may include
compressor run-hours, board feet produced or kilowatt hours (kWh) used.
Event counting refers to discrete events. Examples include breaker operations, start/stop cycles, etc.
To use a recent airline example, the compression and decompression cycles of certain 737 jets has
been limited to fixed number before a manual inspection must occur. The compression cycle event is
a typical flight for a 737 (take-off, compression, landing, decompress).
Quantitative-based meters are used most often in predictive cycles, i.e. they have the greatest impact
in determining when a maintenance order will be produced by the CMMS maintenance process job.
Special Considerations
1.

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.

4.6 Qualitative-based meters (state)


Qualitative-based meters consist of two or more discrete state values and are reset to a new value
through a meter update. The discrete values within qualitative meters generally represent the
improvement or decline in the health of an assets condition. State values generally require that
calculations are performed on primary asset data to determine the current condition of an asset. It
may be helpful to think of a qualitative-based meter as a traffic light, with green, yellow and red
colours. When calculated data indicate that there is a defined state change, a meter update is sent to
CMMS. The maintenance plan is informed to take specific action in the CMMS based on this input.
EXAMPLE: Some oil analysis systems collect a lot of detail about water and gas content of the oil and
use either industry standard or proprietary algorithms convert this information into four states. These
states indicate progressive health conditions while hiding the details of the cause of the issue. Using
these states to plan work in CMMS is a good example of a state-based meter. Based on the state of oil
health, the maintenance process may be dictated using previously define tasks.

P a g e | 18

PI System for CBM


Special Considerations
1.

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.

4.7 Immediate Maintenance Order Generation


Aside from using meters and pre-defined plans, new work orders may be generated based on
established limits, which can be set up in the PI System. This approach resembles CBM but is slightly
different than CBM as defined in this guide. In this case, established limits need to be integrated with
the CMMS to initiate an immediate maintenance order. The information provided in this order and
instructions for carrying it out are determined by a planner before assigning it to the field.
Immediate maintenance order generation is a relatively simple integration to set up (the specific
scenarios are covered later and are the same whether doing meter updates or creating orders). The
same risks apply to immediate order generation and CBM. Established limits must trigger extraneous
orders to maintenance planning only when necessary. Too many unwarranted orders can result in
desensitization to requests generated from asset data.
Sending too many orders or not sending a necessary order can also create errors while requesting a
new order. For example, a work order has been sent and is in process. If the condition comes in again,
do we send another? Not all conditions will remain set until maintenance is complete and the system
returned to service. Specific scenarios need to be worked out to ensure that a second order will not
come through until the maintenance is complete. Another condition could include when a new order
can be locked out after maintenance is complete. If the condition arises again, necessary maintenance
could missed. The technical implementation that adjusts the number of sent orders is straightforward
(similar to resetting an alarm); however, the business logic needs to be understood by all involved.

4.8 Why is PI the right bridge from OT to IT for CBM?


Many modern systems have deployed automated control and data collection systems to reduce
operating errors, mistakes and time delays that can occur with manual data entry. Deploying a
common software system between OT automation systems and business IT applications simplifies the
integration and architecture of OT and IT systems. Maintaining this layer also offers the agility to

P a g e | 19

PI System for CBM


rapidly take advantage of advances in IT applications and solutions without having to re-integrate or
rip and replace your enterprise OT architecture.
The PI System is a time-series database. The majority of process and operating data generated and
collected on critical infrastructure is, by its very nature, time series data. The PI System has myriad
interfaces to collect data from source systems and maintaining data from many streams of data for
long periods of time. This means that the PI System, as the system of record for time series data, can
be used as a single source or interface to non-time series systems, such as a CMMS. PI System Analytics
can be used to convert very high fidelity, streaming data into events, or conditions that should be
infrequently sent to CMMS as transactions. This results in a single pathway from the OT networks,
which tend to be more secure as they support critical infrastructure, to the IT network, where CMMS
and other enterprise applications exist and operate.

Figure 8 - The PI System as a Bridge from OT to IT

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:

Support for Open Standards


Scalable
Highly Secure
Highly Available
Future Proof evergreen architecture

Support for legacy automation and


future data source systems
Positioned to leverage BIG DATA and
Business
Intelligence
tools
and
techniques

P a g e | 20

An Introduction to the PI System

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

Figure 9 The PI System is a bridge from OT to IT

data into the IT environment, the PI System empowers all stakeholders with the data to drive
operational efficiency and strategic business initiatives.

5.1

Description of PI System capabilities

As an overview, the following are the major capabilities of the PI System:

P a g e | 21

PI System for CBM


Collect - an extremely large variety of interfaces collect data time series data from real time systems
and historize these streams into the PI Data Archive. PI Interfaces support buffering and redundancy
to ensure no data loss.
Historization - a unique method for storing incoming data streams minimizes resource needs (network
bandwidth, processing cycles, disk space, etc.) while maintaining the fidelity of the original instrument
or process.
Context a customizable, sophisticated asset modelling system organizes data streams (e.g. assets,
devices, systems, etc.) to reflect asset topologies and related function. Data organized by asset makes
information accessible to end users in a way that makes more sense to them. The PI Asset Framework
(AF) relates data streams and events to physical or logical assets, augmenting a users
understanding of data within a larger context.
Analytics an extremely capable means of performing complex analytics on incoming data streams in
addition to post hoc analysis on archived data. Analytics can be performed with context to data source,
relationships to other streams and other data sources (e.g. relational, external systems, etc.) to
produce meaningful information from the raw data streams. These analytics are both configurable and
programmable to ensure ease of use and extensive capability as the needs demand.
Visualisation evolving client tools provide information to a wide variety of users and address the
needs of stakeholders in a broad organization. These tools include: PI ProcessBook - graphical displays
(similar to DCS type screens), PI DataLink - numerical analysis and reporting (within MS Excel), PI Web
Parts - dashboards and mash-ups (within MS SharePoint) and PI Coresight intuitive, ad hoc
interactions within a web browser.
Accessibility providing data to a wide variety of other systems and IT platforms through industry
standard technologies such as Web Services, OData, OLEDB, JDBC, SDKs, etc. These methods help
integrate time series information (data from real time systems) with other enterprise platforms such
as ERP/EAM, reporting tools (BI), desktop productivity and custom applications.

P a g e | 22

PI System for CBM

Analytics & Events


can trigger
Notifications to
people
& systems
5

Asset condition &


health is integrated
into enterprise
reporting &
management systems
in a variety of systems

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

Figure 10 - PI System Ecosystem Overview for Condition Monitoring

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

PI System for CBM

Figure 11 Developing a Strategy for Condition Monitoring

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.

Figure 12 - Visualisation example of condition parameter

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

PI System for CBM

=
Figure 13 - Example asset definition in PI Asset Framework (AF)

Figure 14 - AF Elements as assets example hierarchy and types of data typically in AF

P a g e | 25

PI System for CBM

Figure 15 - Modeling a Power Plant in an AF Structure.

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

PI System for CBM

Figure 16 Example Calculations & Analyses using PI AF

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.

State change trigger

Process variable change trigger


Event frame

Root cause event

Figure 17 - Example flows of event frame creation

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

PI System for CBM


that could be a state change in process data. Process variable exceptions, such as a rate of change,
cross of a limit, operation over a number of times within a time period, can also initiate an Event
Frames. Asset analytics can use sophisticated calculations to define reference events based on process
data. Since 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, we may want to
see specific data for a time period before this event to determine the root cause event or conditions.
Events capture all of the following information including: the frames (or bookmarks) that define the
event, the configurable time period before the event trigger, along with the referenced element
(asset), specific attribute data and other calculations, such as duration, cost, etc. 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, we could add in cause code values when an engineer
determines the cause of the event, or we could programmatically add in data returned from an
integration with the CMMS, such as the Work Order (WO) number.
6. Within PI Clients and by making information accessible in other enterprise systems using PI Data
Access technologies, we can now surface event and other analytical data for consumption by
knowledge workers. This information is useful in not only ascertaining specific asset conditions,
but also in evaluating asset conditions over time. In this manner we can do root cause analyses
quite quickly and we can look for trends relative to asset nameplate and process data.

Figure 18 - Example Production Summary Report by Unit

P a g e | 28

PI System for CBM

Figure 19 - Example Event Frame Analytics of Vibration Data on Feed Pumps

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.

Figure 20 - Example PI Notification

P a g e | 29

PI System for CBM

PI System integration with ERP/EAM

In this section, well provide an overview of methods used to integrate PI System data with CMMS
applications.

Figure 21 - Conceptual approach to integration of real time data with CMMS

The following high-level concepts will be considered for integration:


1. PI System as a real time bus, accessed via the CMMS directly (pull)
2. PI System as a real time bus, using middleware (e.g. EAI broker) for integration scenarios with
CMMS (push/pull)
3. PI ACE, as a programming environment, invoking services of the CMMS for integration (push)
4. PI Notifications, using a delivery channel (OOTB XML or otherwise (push)
For each of the above there are variants. More than one approach may be employed for a given
customer for a variety of reasons. For example, in Scenario 2, the PI System may use a scheduled
program to write into the middleware broker (e.g. JMS queue), which would make this a push
interface.
Its important to realize that often the deciding factor in determining integration with CMMS
applications for CBM purposes comes down to organizational preferences. There are many
organizations that have standards for middleware, for integration to EAM/ERP, for preferences of
configuration over coding, etc. These preferences, skill sets, costs, etc. can factor more into the
decision than the technical approach.

P a g e | 30

PI System for CBM

6.1

PI System as a Real Time Bus, accessed by CMMS directly

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

Figure 22 - PI as a Real Time Bus accessed by CMMS directly

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

PI System for CBM


Approach suitable to minimal PI System Requires custom coding on the part of the
component installations
CMMS support group
Simple to implement, in most cases, depending Limited configuration information
on skill set of CMMS support
become an issue to maintain

could

Programming inside of CMMS allows for


Must be calendar scheduled and may
extension of features since exposure to most
experience some delay in critical notifications.
CMMS functions are available

6.2 PI System as a real-time bus, using middleware for CMMS integration


This method is similar to the above only the task of orchestrating the integration is handed off to an
Enterprise Application Integration (EAI) broker or similar middleware.
In the case of middleware, there is typically an adapter involved to communicate with each system
involved in a process. In some cases, the middleware may actually be a part of the CMMS stack (for
example, with more advanced EAM/ERP applications).
With middleware, the interaction with the PI System could be scheduled (pick up a summary of data
daily) or a CMMS event (work completed to reset notification in the PI System). In either case, the
middleware broker would access PI System data using PI Data Access.
Also, the PI System could initiate the transfer using PI ACE or PI Notifications or a simple MS
PowerShell script. Using one of these methods would support the event-driven architecture of
condition indicator changes. For example, should a condition indicator an immediate need for
maintenance, the PI System could invoke a function in the middleware to create an order in CMMS.
Functions available to the PI System are limited to those exposed via middleware. The connection to
middleware would either be programmatic (and custom, via PI ACE) or open (via web services)
depending on the middleware technology employed.

P a g e | 32

PI System for CBM

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

Figure 23 - Integrating PI with CMMS via Middleware

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

PI System for CBM

PI System as a real-time bus, accessed via the CMMS directly (pull)


PROS

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:

Invoking a web service


Updating a database using an OLEDB provider (or update a queue, e.g. JMS queue)
Invoking an update to CMMS via a middleware adapter
Programmatically invoking an update to CMMS, e.g. using an SDK or other method, for
example calling an SAP RFC.

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

Figure 24 - PI System Integration with PI Analytics

P a g e | 34

PI System for CBM


The diagram above illustrates a small part of custom code (PI Analytics) that invokes the integration
into a 3rd party system. This may be a custom data reference, MS PowerShell script or something
similar.
The following table lists some pros and cons of this approach:

PI Analytics (or similar) as an on-demand integration method (push)


PROS

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

Programming inside of CMMS allows for


extension of features since exposure to most
CMMS functions are available

Some enabling opportunities

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

PI System for CBM

7.2

Decision Support

In-depth analysis (including multi-dimensional analysis) of condition information related to specific


assets, other nameplate and classification information can inform critical decisions. The more static
nameplate and classification data may be maintained in AF (as well as your CMMS/EAM) and be
available there directly to use in business intelligence type analyses, with tools such as MS PowerPivot.
This information may also be exposed to reporting and analytical environments along with time-series
data and aggregations using PI OLEDB Enterprise. These are usually scheduled jobs to move some PI
System data into another reporting platform (e.g. MS SQLServer Reporting Services) using readily
available database tools such as MS SQLServer Integration Services (SSIS).
Using PI-OLEDB, users can produce quick, ad-hoc, aggregation of vast amounts of interesting data
(facts), based on user selected criteria (dimensions), to identify business opportunities.

Figure 25 - Quick, ad-hoc BI analysis using PI OLEDB Enterprise

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

PI System for CBM

Figure 26 - Multidimensional analysis cube example

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.4 More focused Capital Expenditures


Having historical insights into the health of assets, either specific or by asset type (e.g. manufacturer,
product code, etc.) can be used to focus capital expenditures into resources that will provide the most
return on this investment.

7.5

Enabling more effective BI

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.

CBM Solution Examples

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

PI System for CBM

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

Transformer Monitoring and Analysis

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

PI System for CBM


specific condition indicators monitored on these devices. The most common ones include load values,
temperature sensors and dissolved gas analysis (DGA) monitors.

Figure 27 - Example fault tree for large transformers

8.1.2.1 Transformer Oil and Gas Analysis


Online transformer oil analysis monitors water and gas content within the oil and can indicate a
possible degradation of winding insulation. Monitoring key parameters from the results of these tests
can show when a transformer (or its oil) is in need of maintenance or further diagnostics.
Manufacturers provide guidelines for refurbishment or replacement for transformer oil impurities.
Some transformers have gas detector or Buchholtz relay (usually on conservator models) or pressure
relays, which detect either sudden rise or high pressure levels that trip a protective breaker relay on
the transformer.
Online or offline tests can be conducted on the dielectric oil of the transformer and stored as an asset
attribute which can be used to initiate action before a breaker relay trip event.
8.1.2.2 Online Monitoring for Sweeping Frequency Response Analysis (SFRA)
Methods for offline testing transformers are well established. The Doble test and the impulse
response method developed at Powertech Labs in British Columbia have been used successfully for
several years to analyze the current state of a device; however, each of these methods requires that
the transformer be taken out of service and isolated from the surrounding circuits. This is simply not
practical for most installations. Online monitoring of gas analysis, oil levels and temperatures has been
practiced for some time now. Unfortunately the correlation between the analysis results and actual

P a g e | 39

PI System for CBM


transformers failure modes is relatively low, and the information does not predict failure far enough
in advance to plan for the consequences of device outage.
Using a relatively new, high speed, high resolution meters called phasor measurement units (PMUs)
transformer health can be calculated online in real time based on two fundamental measurements:

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

PI System for CBM


8. PI Notifications and AF provide a rich method for organizing the large volumes of data
generated into an easy to understand and manage asset based structure. Alerting and
notifications are then driven directly by this structure.

8.1.3

Transformer Load Tap Changers (LTCs)

8.1.3.1 LTC maintenance


Typical vendor recommendations for Load Tap Changer (LTC) maintenance are based on LTC
operations as opposed to strictly using time metrics. Capturing LTC counters can provide an indication
to a counter-based maintenance plan when maintenance is due for the LTC and excessive operating
can indicate circuit activity that requires additional investigation to determine its cause and remediate.
8.1.3.2 LTC not through zero
Another typical issue for LTCs occurs the LTC has not gone through neutral after a significant time
period elapses. The failure to go through neutral may indicate an imbalance in network impedance.
There may be options for addressing this situation if a condition indicators can notify appropriate
personnel to either assess why the LTC has not gone through neutral or recommend prescriptive
maintenance. For example, capacitor banks could be switched in or out, LTC adjustments can be made,
etc.
The condition to be monitored here is a defined time period where the LTC has not passed through
zero. A simple calculation can detect this condition in the PI System. When the defined time period
elapses, a maintenance trigger can be sent to CMMS.
8.1.4

Transformer Actionable Output

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

PI System for CBM

Figure 28 - Transformer Monitoring: Source Data and Process.

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.

Figure 29 - Example of a PI Event triggering an SAP PM Malfunction Report

8.1.5

Transformer References
TVA - DobleARMS and PI System Bring Standards-Based HV Asset Management to TVA

P a g e | 42

PI System for CBM

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

Pump Monitoring and Analysis

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

BEP (TDH, Efficiency, 80%, 110%)


Pump On/Off Pump run hours
Pump
start/stop
number
and
frequency
Motor temperature
Flow rates and pressures (in, out)
Screen differential pressures
Vibration Monitoring points
Bearing Temperatures
Motor current signatures
Visual inspection results
Motor power (kW)

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

Pump Actionable Output- Visualisation

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

PI System for CBM

Figure 30 Sample Condition Monitoring Display from PI ProcessBook.

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

PI System for CBM

Figure 31 MS Excel BI Condition Monitoring Report using PI DataLink.

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

Compressor Asset Overview

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

PI System for CBM


Often, plants often consider the expense of compressed air only in terms of equipment cost. Energy
costs, however, represent as much as 70% of the total expense in compressed air production.
8.3.2

Compressor Monitoring and Analysis

The following provides a basic overview of sources of data relevant to compressor health and
monitoring.

Figure 32 - Compressor Data & Maintenance Condition Monitoring

8.3.3

Compressor Actionable Output

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

PI System for CBM

Figure 33 - Example Process Overview for Compressor Asset Health

8.3.4

Compressor References

Alyeska Pipeline - Achieving Reliability-Centered Maintenance and Diagnostics with the PI


System
2012 Retrofitting Compression Equipment and Interfacing Systems for CBM

Improving Reliability with Caterpillar Condition Monitoring Services

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.

8.4 Heat Exchangers


8.4.1

Heat Exchanger Asset Overview

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

PI System for CBM


Typical degradation of heat exchangers include:

8.4.2

Wall thinning oxidizing material


Corrosion and scaling pitting and build-up of materials
Dimensional creep (warping and movement due to heat)
Tube Fouling
Heat Exchanger Monitoring and Analysis

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

Heat Exchanger Actionable Output

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

PI System for CBM

Figure 34 - PI Notification event comparison and email example.

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

Heat Exchanger References


KEPCo - Development of Real-Time Damage Monitoring System for the Optimization of
Inspection Planning of Power Boiler Tubes
Using PI to Back-Test Usage and Condition Based Maintenance Strategies to Predict
Quantifiable Benefits Prior to Deployment in Asset Management DTE 2009
PI Heat Exchanger Tutorial (registration required)

Guidance on CBM Implementation with the PI System

9.1

Basic CBM Implementation Practice

The basic process suggested here is fairly straightforward and consists of the following steps:
1.

Initiate small scale pilot


a. Build a business case / justification for pilot
b. Select candidates for initial implementation.
c. Define or specify how maintenance plans will be configured for these initial candidates.
d. Define or specify the PI System/CMMS integration scenarios to be used (could be more
than one)

P a g e | 50

PI System for CBM


e. Formulate an approach that makes use of the CBM approaches discussed earlier.
(totalizer, PEs, Alarm Tags, AF Formula References, ACE, External Application, PI
Notifications, etc.) preferably something Simple or Basic.
f. Implement Condition Monitoring with PI System do not integrate with CMMS yet
g. Monitor condition indicators in the PI System for a period of time to ensure that there
will not be excessive demand or noisy events in CMMS
h. If necessary, redress above steps to remediate
i. Connect the PI System to CMMS will likely have to sync meter or measurement point
values initially.
j. Integrate the PI System with CMMS
k. Monitor PI System indicators, events, notifications and calculations for a period of time
to ensure that there will not be accessible demand or noisy events in CMMS
2. Summarize pilot and evaluate results
3. Use these results to expand CBM deployment. At this time, bring in additional stakeholders to
help develop broad business case to expand CBM implementation.
Given what we saw above, there is little upfront cost assuming that at least some condition
information relative to planned PM activities can be used to change the PM from calendar-based PMs
to condition-based PMs. This in itself extends PM cycle resulting in immediate savings not only for the
work but for any other disruption it may have caused the unit, plant, or line. For example, the odds of
introducing problems increases by doing unnecessary maintenance. Finally, having the condition
monitors available can lead to a catch, i.e. taking action before a component functionally fails.

9.2 Building a business case


Quite often, in our experience, developing justification to pursue CBM initiatives is already well
understood by the business. If not, there are some excellent references available to discuss how CBM
can lower maintenance, lost opportunity (when assets are unavailable), collateral damage and
redundancy costs. There are typically two issues that compound movement forward, which are:
1.

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

PI System for CBM


Considering the two caveats above, we find the most success when we can work with our customers
and partners to help them identify some key and quick wins. These wins can result in significant savings
and usually suffice to develop the ROI for the initial project and change management. Theres more
on this in the steps later in this chapter. Having more details specific to your industry on where others
have identified substantial savings can help build a solid business case. It is often a good starting point
to help scope, charter, socialize and plan the initial project, based on some key assets. Just think of
some expensive, impactful, maintenance events in the last year and if CBM can reduce 20 50% of
those, it usually is justified on this alone.
When considering events for cost/benefit analysis include not only the replacement cost (parts &
labor) but the additional costs of impact to the business, risks incurred, and other impacts (e.g.
environmental, health & human safety, etc.) for a full assessment of benefit.
Refer to the CBM as a Process discussion in the definitions section earlier and to the 10 steps to
success listed below for more on this topic.

9.3 Ten Steps to Operational Efficiency


The following (including the title above) is taken from O&M Best Practices A Guide to Achieving
Operational Efficiency, Issued by the US Department Of Energy, July 2004;
http://www.pnl.gov/main/publications/external/technical_reports/PNNL-14788.pdf.

STEP 1:
Strive to increase management awareness and appreciation of the operations and maintenance
program/department.

Consider developing a maintenance mission statement and requesting/requiring management


sign-off.
Consider developing a maintenance plan and requesting/requiring management sign-off.
Begin the development of the OMETA linkages.
Develop key points of contact within other departments that can participate in the O&M
mission.

STEP 2:
Commit to begin tracking Operations and Maintenance activities.

Need to understand where O&M time is spent.


Need to understand where O&M dollars are spent.
Consider (strongly) purchasing or enhancing a Computerized Maintenance Management
System and commit to its implementation and use.

P a g e | 52

PI System for CBM


STEP 3:
Through tracking begin to identify your troubled equipment and systems.

Make a list of these systems and prioritize them.

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

PI System for CBM


Strive to highlight this success capitalize on visibility opportunities.
Consider writing an internal success story/case study.
Submit finding to trade publication or industry conference.
STEP 10:
Commit to choosing the next piece of equipment...go to Step 3.
Steps 1 and 2 are ONGOING ACTIVITIES!

10 References
This section includes OSIsoft and other industry references.

10.1 OSISOFT INDUSTRY REFERENCES


Achieving Reliability Centered Maintenance and Diagnostics with the PI System Alyeska Pipeline
Sempra Energy (SDG&E) - PI System for Enterprise Information Decision Support
PSE&G - CMMS Foundation for Smart Grid Modernization or Case study 2005
Arkema Case Study 2005
Alyeska Pipeline - Achieving Reliability-Centered Maintenance and Diagnostics with the PI System
KEPCo - Development of Real-Time Damage Monitoring System for the Optimization of Inspection
Planning of Power Boiler Tubes
Using PI to Back-Test Usage and Condition Based Maintenance Strategies to Predict Quantifiable
Benefits Prior to Deployment in Asset Management DTE 2009
2012 Retrofitting Compression Equipment and Interfacing Systems for CBM
Improving Reliability with Caterpillar Condition Monitoring Services
How PI Played a Key Role in Helping Dofasco Achieve Maximum Asset Reliability
Making the Most of Your Assets, Dow Corning

P a g e | 54

PI System for CBM

10.2 PARTNER REFERENCES


Helping customers lower TCO with Flowserves Technology Advantage Web Portal
Implementing Risk-Based Asset Management, Life-Cycle Engineering Video
The PI System, Remote Diagnostics and the Collaborative Supply Chain OSys

10.3 PUBLISHED BOOKS AND ARTICLES


Continuous Reliability Improvement article, Pride in Maintenance Website http://www.pride-inmaintenance.com/continuous-reliability-improvement
In Pursuit of the Perfect Plant, Book by Pat Kennedy, Vivek Bapat, and Paul Kurchina
Reliability engineering principles for the plant engineer, Reliable Plant Magazine
Society for Maintenance and Reliability Professionals Web site
Reliability Centered Maintenance, Plant Maintenance Magazine
Institute for Nuclear Power Operations Equipment Reliability Process Book - Inpo ap-913
IEEE Transformer CBM white papers - search for power transformer condition based maintenance for
a complete list.

10.4 List of Figures used within


Figure 1 CBM is a continuous improvement process. ................................................................................ 5
Figure 2 Cost & Maintenance Distribution before and after CBM ............................................................ 7
Figure 3 - Maintenance Strategies .............................................................................................................. 9
Figure 4 PF Curve used in Predictive Maintenance (or Incipient Failure Detection) ............................... 11
Figure 5 an example of APR in action on a monitored process variable ................................................. 12
Figure 6 Drivers for Reliability Centred Maintenance ............................................................................... 12
Figure 7 Simplistic flow of condition-driven maintenance process ......................................................... 17
Figure 8 - The PI System as a Bridge from OT to IT .................................................................................. 20
Figure 9 The PI System is a bridge from OT to IT ...................................................................................... 21
Figure 10 - PI System Ecosystem Overview for Condition Monitoring .................................................... 23
Figure 11 Developing a Strategy for Condition Monitoring................................................................... 24
Figure 12 - Visualisation example of condition parameter ....................................................................... 24
Figure 13 - Example asset definition in PI Asset Framework (AF) ........................................................... 25
Figure 14 - AF Elements as assets example hierarchy and types of data typically in AF ........................ 25
Figure 15 - Modeling a Power Plant in an AF Structure. ........................................................................... 26
Figure 16 Example Calculations & Analyses using PI AF ........................................................................ 27
Figure 17 - Example flows of event frame creation .................................................................................. 27

P a g e | 55

PI System for CBM


Figure 18 - Example Production Summary Report by Unit ...................................................................... 28
Figure 19 - Example Event Frame Analytics of Vibration Data on Feed Pumps ...................................... 29
Figure 20 - Example PI Notification ........................................................................................................... 29
Figure 21 - Conceptual approach to integration of real time data with CMMS ...................................... 30
Figure 22 - PI as a Real Time Bus accessed by CMMS directly .................................................................. 31
Figure 23 - Integrating PI with CMMS via Middleware ............................................................................. 33
Figure 24 - PI System Integration with PI Analytics.................................................................................. 34
Figure 25 - Quick, ad-hoc BI analysis using PI OLEDB Enterprise ............................................................. 36
Figure 26 - Multidimensional analysis cube example ............................................................................... 37
Figure 27 - Example fault tree for large transformers.............................................................................. 39
Figure 28 - Transformer Monitoring: Source Data and Process. ............................................................ 42
Figure 29 - Example of a PI Event triggering an SAP PM Malfunction Report ....................................... 42
Figure 30 Sample Condition Monitoring Display from PI ProcessBook. .............................................. 45
Figure 31 MS Excel BI Condition Monitoring Report using PI DataLink. .............................................. 46
Figure 32 - Compressor Data & Maintenance Condition Monitoring ...................................................... 47
Figure 33 - Example Process Overview for Compressor Asset Health .................................................... 48
Figure 34 - PI Notification event comparison and email example. .......................................................... 50

10.5 The team that put this book together


We are a team of OSIsoft professionals with industry CBM and PI System technologies experience. We
are passionate about bringing value to our customers by sharing solutions based on the PI System. We
appreciate your time and hope you have found the content valuable.
Keith Pierce Global Solutions Group
Gopal Gopalkrishnan Partner Solutions Architect
Chris Crosby Industry Principal Power Generation, Nuclear
David Thomason Industry Principal Power Generation, Conventional
Curt Hertler Partner Solutions Architect
Matt Miller Industry Principal
Zsolt Oros - Regional Account Manager
Kristin Kelly Content Strategist

P a g e | 56

Das könnte Ihnen auch gefallen