Model-based Approach to Automated Calculation of Key

Performance Indicators for Industrial Turbines

Gulnar Mehdi1, Davood Naderi2, Giuseppe Ceschini3, Alexey Fishkin4, Sebastian Brandt5 Stuart Watson6, and Mikhail
Roshchin7
1,4,5,7
Siemens AG, 81739, Germany
[email protected]
[email protected]
2
Siemens Industrial Turbomachinery AB, 61241, Sweden
[email protected]
3
Siemens AG, 90001, Germany
[email protected]
6
Siemens AG, LN63AD, United Kingdom
[email protected]

ABSTRACT Finally, we provide an evaluation and future developments.

In recent years, the service business of the global turbo- 1. INTRODUCTION
machinery industry has undergone important changes. Many
of these changes have been motivated by an increased In recent years, the turbo-machinery industry has provided a
demand for dedicated and systematic approaches to process wide range of products and comprehensive services to their
safety, reliability, asset integrity and the overall health of the customers. The industry has evolved in terms of increasing
system. This has strengthened the role of key performance product standardization and continues to adopted strategies
indicators (KPIs) as a means of providing guidance for the to enhance their value-added services. As part of that
system’s health state and improve risk management. In industry, Siemens AG aims to expand their service business
order to provide trustable and accurate calculations of these to mobilize the additional potential of sustainable growth.
performance indicators in an automated fashion, we argue Keeping up with the technological advances, Siemens
for a model-based solution that deals with the complexity of Corporate Technology (CT) and the turbo-machinery
diverse configurations and interdependences between portfolio is laying the foundations for next-generation smart
system components. This paper presents a solution for and efficient solutions in the energy sector. Their focus is to
calculating KPIs by a semi-automated process based on enable improved plant operations, lower maintenance costs,
post-data processing from the site and specific system increased plant lifetime, safety, reliability, asset integrity,
models. The models consist of a combination of system and mitigation of risks. In general, these objectives can be
descriptions in terms of ontologies and complex event achieved by the adoption of appropriate monitoring,
processing models. By virtue of our models, state indicator diagnosis and maintenance tools that support effective
rules for KPI calculations can be formulated at different decision-making and customer service.
levels, identifying performance gaps and indicating KPI-based approaches are among the most practical and
precisely where action should be taken by the service popular ways to describe the state and efficiency of the
engineers. With the adopted solution, we discuss the plant. Ceschini (2002) states that KPIs also provide
practical implementation and present results of our success guidance for monitoring, availability, maintenance and
story at Siemens AG for the Industrial Gas Turbines. review of the system’s health and help to derive sound
statistics directly from the operational data. Recently
Gulnar Mehdi et al. This is an open-access article distributed under the
terms of the Creative Commons Attribution 3.0 United States License, automated calculations for machine performance indices
which permits unrestricted use, distribution, and reproduction in any have been reported by Ding et al (2013) and Odgaard et al
medium, provided the original author and source are credited. (2013) which significantly focus on developing engineering
models of the machine components and drive results using

1
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

statistical methods. Whereas Márquez et al (2012) describes 3. It is important to note that the interaction and
various state-of-the-art techniques including qualitative fault dependences of components within one level as well as
tree analysis for performance monitoring of established between levels may be quite complex and hence
thermodynamic models. These reported techniques require creating the model requires greater expertise.
greater engineering expertise to build a system model, is 4. Available off-the-shelf statistical approaches as
less transparent and lacks usability. Nevertheless, the discussed by Ceschini (2002) and Márquez et al (2012)
application of KPIs for industrial turbines still has its are based entirely on manual data gathering and manual
challenges. Some of the prominent features that introduce assessment of scenarios for asset downtime. Such data
substantial complexity to the computation of KPIs are as is often contaminated by human factors and potentially
follows: by forced business incentives. Even today, service
1. Forsthoffer (2011) shows that industrial turbines may engineers still need to spend considerable time and
have many different sets of configurations and effort calculating KPIs for a single site.
topologies depending on design and applications. For Considering all the challenges described above in terms of
example, twin-shaft turbines versus single-shaft and complexity, diverse configurations, interdependences of the
applications for mechanical drive versus power plant model and data acquisition, the key idea is to simplify
generation. As an example Fig. 1 shows a sample list of the computation of KPIs in two steps. Firstly, rather than
various configurations occurring in the industry. addressing the KPIs of a plant at each level of its hierarchy
in isolation, we introduce dedicated level-oriented rules that
re-use KPIs already computed on one level for the
computation of related KPIs on another. Secondly, in order
to avoid re-phrasing KPI computation rules for each of the
numerous different turbine configurations, we introduce an
abstraction layer hiding the different configurations and
define our KPI computation rules against the abstraction
layer rather than the actual machine configurations. The
Figure 1. Samples of different designs and abstraction layer will be based on a domain ontology
applications of industrial gas turbines. describing turbines, their components and functions. The
2. In addition to the complexity of diverse plant level-based KPI computation rules mentioned above will
descriptions, there is also another dimension of the equally make use of the ontology providing the abstraction
“level” in the plant model. The plant model gives an layer but will be encoded as Complex Event Processing
overview of the main components of the plant in a (CEP) rules.
hierarchical fashion and comprises many levels. Each
level consists of number of individual components and For a given specific plant the computation of actual KPIs
supports level-specific information. Within one level, does not utilize the abstract CEP rules expressed in terms of
each component contains its physical parameters the ontology-based abstraction layer but rather depends on
relevant to computations. Fig. 2 gives an overview of a an instantiation step in which the abstract rule-base is
generic plant model at site level, plant level, system instantiated for the specific plant and its configuration. This
level and so on. instantiation step is based on mappings between the
concrete plants and the abstraction layer. The key
observation here is that maintaining these mappings for a
variety of different plants and configurations is a small task
in comparison to maintaining the entire rule base for each
plant and configuration. The paper follows with Section 2
describing the basic standards and KPI definitions used in
the model for Industrial Turbines. Section 3 presents our
case study and the proposed model-based solution
architecture Section 4 introduces the basic concepts and
application of ontology and complex event processing
technology used for KPI computations. Section 5 presents
results and serves for the evaluation and future
developments. Finally, we conclude in Section 6.

2. KEY PERFORMANCE INDICATOR STANDARDS

Figure 2. Hierarchical structure of a plant model. Performance measurement is important to the management
of industrial turbines. It identifies performance gaps

2
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

between the desired and actual state and provides

indications of the progress to meet those gaps. While KPIs
are common tools for the measurement of system
performance, the choice and definition of specific KPIs for a
given system is not trivial.
For our KPI solution framework, we have revised and
adopted definitions from the IEEE (2006) and ISO (1999)
standards. Since we will rely on historic data in our
computations, we introduce an additional parameter,
“NoData”, that deals with possible data gaps. The following
is a list of basic KPIs used in our solution.
Period Hours (PH) – Time, in hours, in the period under
consideration.
No Data Hours (NoData) – Time, in hours, where not all
required data is available, here we use the term PH* for
Period hours excluding the no data hours.
Figure 3. Overview of adopted KPI definitions
Available Hours (AH) – Time, in hours, during which the
unit was capable of providing service, whether or not it was
Using the four KPIs defined above, we can compute the
actually in-service, regardless of the capacity level that it
following factor KPIs:
can provide.
Service Hours (SH) – Time, in hours, during which the unit
Availability Factor (AF) – Probability that the unit will be
was in-service, i.e., it is electrically connected to the system
usable at a point in time based on past experience:
and performing generation function. For gas turbines, this
covers from main flame ignition through to flame
AF = [AH / (PH*)] x 100%
extinction.
Reserve Shutdown/Service Hours (RSH) – Time, in
Unavailability Factor (UF) – Probability that the unit will
hours, during which the unit was available, but not in
be unusable at a point in time based on past experience:
service (Number of hours when the gas turbine is available
but there is no demand).
UF = [UH / (PH*)] x 100%
Unavailable Hours (UH) – Time, in hours, during which
the unit was not capable of operation. The unavailable state
Reliability Factor (RF) – Probability that the unit will not
persists until the unit is made available for operation, either
be in a forced outage condition based on past experience:
by being synchronized to the system (in-service state) or by
being placed in the reserve shutdown state.
RF = [(PH* – FOH) / (PH*)] x 100%
Planned Outage Hours (POH) – Time, in hours, during
which the unit (or a major item of equipment) was originally
Service Factor (SF) - Probability that the unit will be in an
scheduled for a planned outage with a pre-determined
duration plus the extension of planned work beyond this
pre-determined duration. Note that the extension due to
either a condition discovered during a planned outage or a
startup failure would result in a forced (unplanned) outage.
Forced Outage Hours (FOH) – Time, in hours, during
which the unit was unavailable due to a component failure
or another condition that requires the unit to be removed
from service immediately or before the next planned outage.
Fig. 3 shows a hierarchical overview of these definitions
that forms the basis of the solution framework.

Figure 4. Use-case of an industrial plant model

3
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

operating condition based on the past experience: In Fig. 5 we present the overall solution architecture: a
domain ontology is used to represent turbine configurations
SF = [SH / (PH*)] x 100% and the relationships between different physical components
in the plant and their function and performance variables
Forced Outage Factor (FOF) – Probability that the unit (such as speed, main flame, active power, etc.). The
will be in a forced outage condition based on past performance parameters describe the primary behavior of
experience: the plant at different levels. We store these configurations in
a separate database (turbine configuration database) for easy
FOF = [FOH / (PH*)] x 100% access. In the next step, we model complex events and
formulate abstract state indicators rules and update rules for
Mean Time Between Failures (MTBF) – Average time each node. These rules are abstract in that they are defined
between failures initiating a forced outage based on the past w.r.t. the ontology-based vocabulary from the configuration
experience. Here, FON is the number of forced outages: database rather than data specific to any individual plant
coming from the remote monitoring service database.
MTBF = SH / FON
In order to actually compute KPIs for a specific plant
however, i.e., apply the rules, we instantiate the abstract set
For simplicity, we also use N/A for indicating the case
of CEP rules with the concrete plant information using a
where the KPI value cannot be correctly computed, e.g.,
semantic mapping mechanism. Once the instantiation is
PH == 0, PH == NoData or FON == 0.
completed, we proceed with the KPI computation
procedure.
3. A NOVEL APPROACH FOR KPI WITH APPLICATION TO
INDUSTRIAL GAS TURBINES
The proposed approach has been applied to a fleet of
Siemens industrial gas turbines located at different sites
around the globe.

3.1. Case Description

At any given site, see Fig. 4, the plant system consist of two
subsystems, namely drive train and balance of plant. Based
on the configuration, each drive train subsystem comprises
i) a driver package (for example, gas turbines or steam
turbines), ii) driven equipment (for example, a compressor
or pump), and iii) gearbox. Furthermore, within a driver
package, a turbine component may consist of a gas
generator, power turbine and auxiliary system. Each Figure 5. KPI System Architecture
functional component includes physical parameters and The computation framework uses operational sensor data as
threshold values, for example, speed, load, temperature etc. well as event streams for its state evaluation. Because of the
Each of this physical parameter needs to be configured. This large amount of data, we use a data cache for storing and
configuration is a mapping of parameters to one or several post-processing.
sensors (for example, Two-out-of-three) and a setting
threshold values. 4. ONTOLOGY
The following section describes the solution architecture. As described above, our approach to KPI computation rests
Details on the models used for our approach will be on an abstraction layer by means of which a comparatively
introduced in Sections 4 and 5. small set of abstract rules can be instantiated to match a very
large set of turbines and their various concrete
3.2. Solution Architecture configurations. At the core of this abstraction layer lies a
Modeling a plant system is a critical step for constructing domain ontology that represents basic knowledge about the
KPIs that accurately reflect the impact of actions taken to compositional structure of plants, types of its components,
manage the plant. The proposed approach uses two well- and their function.
established paradigms from AI, namely ontology and Ontologies are logic-based knowledge representation (KR)
complex event processing, to be discussed separately in the formalisms that evolved from frame-systems, see Baader
following sections. (2003). Chandrasekaran and others. (1999) characterize
ontologies as “a formal, explicit specification of a shared

4
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

conceptualization”. They usually represent the core notions  Train Ontology: This describes the internal structure of
of a domain of discourse and the relations existing among the plant i.e. its components and sub-components. For
them. A key advantage of ontologies over many other KR example: Burner is a component of a combustor in a
formalisms is their formally well-defined semantics. These Gas Turbine. In addition to this, the ontology also
enable so-called reasoners to derive implicit knowledge specifies the functional purpose of each component. For
from the explicit ontology statements, detect redundancies example: Main flame is in hot gas path. The ontology is
and inconsistencies, and discover relationships that may not expressed in OWL 2 DL.
have been clear to the author of the ontology in the first  Sensor Ontology: This ontology lists the sensor
place. Currently, the most commonly used ontology information, its measured values, sensor type and its
formalism is OWL1 and its sublanguages. location. For example: GT speed sensor measures the
Some additional characteristics of Ontology, which address shaft rotor speed of the turbine. It also accompanies the
the key challenges in the turbo-machinery domain, are as observational characteristics (such as measurement
follows as stated by Ming and Jie (2002): range etc.) and measurement characteristics (such as
measurement unit etc.) of each sensor. Sensor ontology
 Ontologies clarify the structure of knowledge and is also expressed in OWL 2 DL.
devices for an effective KR system.
In this way, we developed a comprehensive model of the
 They separate factual knowledge about the domain domain by combining the above mentioned ontologies. Fig.
from problem-solving knowledge. 7 depicts the consolidated ontology used for accessing data
based solely on the domain model and use them in the rule
 They facilitate sharing and re-using knowledge as based component as a knowledge-base.
well as interoperability of information resources
between humans and software agents.
For the purpose of computing KPIs we have developed a
domain ontology of turbines, their components and
functions. Note that multiple kinds of relationships different
from ‘is-a’ can easily be expressed in OWL. Fig. 6
illustrates a basic example with Driver and Driven
equipment as classes, Gas turbine as a subclass and SGT-
800 as an object, called ‘individual’ in OWL. Object
properties, such as ‘provides power’ in the example,
establish links between classes or individuals. The
combination of object properties and subclass relationships
now give rise to additional implicit relationships, for
example: “If SGT-800 provides power” then this implies Figure 7. Train ontology design
“Generator requires power”. A key advantage of OWL is
that all implicit knowledge is fully automatically taken into
5. COMPLEX EVENT PROCESSING
account by the reasoner. Hence, redundancies and inherent
contradictions are detected automatically, leading ultimately Complex Event Processing (CEP) is a paradigm of choice
to smaller and more easily maintainable models. for many monitoring and reactive applications. It supports
decentralized information sources by deploying tagging and
sensing technology along with integration to real-world
objects. CEP helps to build highly scalable and dynamic
systems by decoupling the provider and receiver of the
information and mediates in form of events. Temporal
relations can also be specified by using correlation rules
(often called Event Patterns) as mentioned by Robins
(2010). CEP also benefits the scalability of the system by
Figure 6. Ontology example to Turbines reducing the massive event load through stepwise
correlation of events.
4.1. Domain Ontology Design
In general, CEP is used to generate new set of complex
Our domain ontology comprises several ontology modules events by aggregation and composition. Its processing
of which the largest two are the following: promotes detection of a plant-significant situation, which
typically involves a collection of evaluation conditions and
constraints over an event set as founded by Wasserkrug, S.,
1
www.w3.org/2004/OWL Gal, A., Etzion, O., & Turchin, Y. (2008). Another

5
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

characteristic of CEP is event transformation, filtering, Figure 10 gives an overview of the states required for
enrichment, pattern recognition, routing, validation etc. computation. For outage hours (OH), we can define more
Figure 5. serves as an example of constructing new signal specifiers. For example: reserve shut down (RSH), forced
event processing rules for speed and load of turbines by outage (FOH), and planned outage (POH). For our
using sensor data and events. implementation, we do not go into the details of the outage
hours at the moment. Though the solution is flexible enough
to identify these states based on the manual entries by the
service engineers.

Figure 10. Overview of State Specifiers

Figure 8. Alarms for high speed and low load using CEP
Rules
5.2. Level Update Rules
For our solution, we have devised two set of abstract rules The level update rules are formulated to capture the state
that are encoded as CEP rules to identify the state of a plant dependencies at one level of the plant to the other. For
at different levels. The following sections briefly discuss the example, any entry of outage specifier interval on one
implementation and purpose of these rules. system level will lead to the respective “updates” of the
outage specifier intervals on the other system levels. One
5.1. State Indicator Rules concrete case would be entering a forced outage interval in
the gear box. This will lead to a forced outage interval in the
The state indicator rules define how a given state of a plant drive train, but will be treated as a reserve shutdown interval
is acquired that is useful for our computation. These states in the driver package.
are determined using physical parameters, such speed, load,
temperature etc. Every plant has its own set of threshold This indicates that as soon as an outage specifier, e.g., RSH
values and specific events from the control system to or FOH, is added to one component, we have to perform so-
indicate its performance. These features in our case study is called Level Update Rules. Figure 11 shows the update
encoded in the abstraction layer i.e. domain ontology. By mechanism for a drive train at level 1 and gas turbine and
using expert knowledge, here we formulate abstract set of generator at level 2. The rules can be:
state rules that can incorporate all configurations of turbines.
 If Drive Train is in reserve shutdown state, then
The three important state indicators are; i) State of Service
gas turbine and generator at level 2 are updated to
Hours (SH), ii) State of Outage Hours (OH), and iii) State of
reserve shutdown state as well.
Start Attempt (SA) / Start Failure (SF) / Start Success (SS).
 If Generator is in forced outage state, then driver
train at level 1 is updated to the same state whereas
the gas turbine at the same level is updated as
reserve shutdown.

Figure 9. State Indicator Rules

In Figure 9, we have a KPI state machine with State
indicator rules on edges, for example. a drive train can move
from “start-success” state to “service hours” state if the rotor
speed is greater than #value1 RPM and generator load is Figure 11. Example of level update rules (Part I)
greater than #value2 MW. Here the tags value1and value2 Figure 12. gives an another view of the above mentioned
will be replaced upon instantiation. example. This is a visualization of the state for every level

6
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

and unit as identified by state CEP rules and its updated Another visualization of results is with respect to a specific
version as specified manually by the engineer. drive train and its respective units within the hierarchy.
Most of the recent methodologies do not consider the
component and system level setup. Whereas our approach
facilitates the engineers and managers to look up for indices
at any given hierarchy and package level. Another highlight
is the use of sensor data and events together to detect the
state of the machine. Therefore, our results are more
accurate, reliable and justifiable than any other traditional
approaches.

Figure 12. Example of level update rules (Part II)

6. RESULTS
The first set of results using our KPI application provide an
availability and reliability comparisons between three
design model of gas turbine by year. These indicators play
an important role in decision making and put a real
challenge when the system model is complex and involves
large set of engineering rules. In comparison to the manual
calculations, our results are more reliable and accurate Figure 14. KPIs per drive train and its units.
because of the adoption of ontology based configurations
and reusable rule production system. Here we incorporate the high level performance indices at
the train level where we specifically visualize for the
unavailability, availability and no data states for a specific
unit. Such kind of visualization is readily available at the
dashboard for high level managers and is also helpful to
detect malfunctions of the data collectors on site.

Figure 15. KPI per unit

Similarly, using our approach and generated KPI result

database, we can provide different views based on site
region or country, customer, driver, driven unit, etc. We
claim that our approach is unique and fits best for
calculating KPIs in different fashions and provides
Figure 13. Availability and Reliability Comparison by customized visualization of results that could be integrated
turbine type and year

7
 ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2015

as a part of monitoring dashboard services. Fig. 16 shows Ding, S. X., Yin, S., Peng, K., Hao, H., & Shen, B. (2013).
another view of KPI results filtered for a service region. A novel scheme for key performance indicator
prediction and diagnosis with application to an
industrial hot strip mill. Industrial Informatics, IEEE
Transactions on, 9(4), 2239-2247.
Odgaard, P. F., Stoustrup, J., & Kinnaert, M. (2013). Fault-
tolerant control of wind turbines: A benchmark model.
Control Systems Technology, IEEE Transactions on,
21(4), 1168-1182.
Márquez, F. P. G., Tobias, A. M., Pérez, J. M. P., &
Papaelias, M. (2012). Condition monitoring of wind
turbines: Techniques and methods. Renewable Energy,
46, 169-178.
Forsthoffer, W. E. (2011). Forsthoffer's Best Practice
Handbook for Rotating Machinery. Elsevier.
Ceschini, G. F., & Carlevaro, F. (2002, January). Gas
Figure 16. KPI results based on ServiceRegion turbine maintenance policy: a statistical methodology to
prove interdependency between number of starts and
7. CONCLUSION running hours. In ASME Turbo Expo 2002: Power for
Land, Sea, and Air (pp. 1137-1142). American Society
We demonstrated a KPI systems approach using an
of Mechanical Engineers.
abstraction layer based on a domain ontology and complex
IEEE Standard Definitions for Use in Reporting Electric
event processing technology. This allows us to adopt our
Generating Unit Reliability, Availability, and
KPI computations for different turbine types, different
Productivity. IEEE Std 762™-2006. IEEE Power
control system types and incorporate additional information
Engineering Soc.
available from the external systems. We extended the
Gas turbines - Procurement - Part 9: Reliability, availability,
standard definitions from IEEE and ISO to be used for our
maintainability and safety. BS ISO 3977-9:1999.
case-study. The solution makes use of the sensor data and
British Standards.
events from the control system to identify turbine states and
Baader, F, & Calvanese, D., & McGuinness, D., &. Nardi,
perform the computations. The solution also provides
D., & Patel-Schneider, P., (2003) The Description
different visualization of the results. The presented
Logic Handbook. Cambridge University Press.
architecture is distributed, extensible and scalable. The
Chandrasekaran, B., Josephson, J. R., & Benjamins, V. R.
computations are automated and have minimum dependency
(1999). What are ontologies, and why do we need
on user-interaction. Hence, they provide reliable and
them?. IEEE Intelligent systems, 14(1), 20-26.
trustable results for decision-making. By including the
Ming, D. Z. T. S. Z., & Jie, Y. D. C. (2002). Overview of
maintenance calendar, we can also automate the
Ontology. Acta Scicentiarum Naturalum Universitis
computation for the reserve shutdown and planned outage
Pekinesis, 38(9), 728-730.
hours. Also the inclusion of events from the control system
Robins, D. (2010, February). Complex event processing.
that specify for the internal and external outage would add
In Second International Workshop on Education
value to the application. For the future, the KPI application
Technology and Computer Science. Wuhan.
can be integrated with the remote diagnostic solution
Wasserkrug, S., Gal, A., Etzion, O., & Turchin, Y. (2008,
framework to evaluate its potential.
July). Complex event processing over uncertain data.
In Proceedings of the second international conference
ACKNOWLEDGEMENT on Distributed event-based systems (pp. 253-264).
We would like to acknowledge Mr. Michal Skubacz for the ACM.
support and encouragement. Their valuable feedback Luckham, D. (2002). The power of events (Vol. 204).
sessions were important in development of rule-base and Reading: Addison-Wesley.
software system.

REFERENCES
Ceschini, G. F., & Saccardi, D. (2002). Availability centered
maintenance (ACM), an integrated approach.
In Reliability and Maintainability Symposium, 2002.
Proceedings. Annual (pp. 26-31). IEEE.