Integration of FTA and RCM - a case from shipping

Svein Inge Masdal, Research Engineer

Roar Bye, Senior Research Engineer

Section of Technical Operations/ Division of Machinery and Operation Tehnology

Norwegian Marine Technology Research Institute A.S, MARINTEK
E-Mail: SveinInge.Masdal@marintek.sintef.no, Roar.Bye@marintek.sintef.no

ABSTRACT
There is no common practice of structured transfer of results from risk and reliability analysis in design to operation
requirements in shipping. There is also a general lack of experience feedback from operation to design.

This paper describes a method for utilisation of results from Fault Tree Analysis, FTA, in Reliability Centered Maintenance,
RCM, to improve operational performance, in terms of increased availability and reliability and reduced maintenance costs.

The paper also presents a methodology for continuous improvement of both operation and design. Continuous improvement
necessitates sufficient relevant data, which again requires a rigid regime for data collection. In order to gather sufficient
number of data, data from additional sources may be required. A data collection from various sources will be eased by
applying standardised data formats.

Rules governing shipping have traditionally been prescriptive. In an attempt to address this issue, IMO (UN maritime body)
has arrived at an interim set of guidelines for the application of Formal Safety Assessment, FSA, in the rule-making process.
This paper describes how requirements from an FSA can be applied in FTA.

The issues raised above have been developed and implemented in the EU-founded project MOSys (Models for Operational
Reliability, Availability and Integrity Analysis of Ship Machinery Systems). Experiences from MOSys are presented in the
paper.

KEYWORDS a set of maintenance strategies assigned to vital

Ship Operation, RAM analysis, STEP, AP 226, Fault
Tree Analysis, Continuous Improvement, Formal
Safety Assessment
MOTIVATION
A study of the state of art regarding application of
Reliability, Availability and Maintainability, RAM,
revealed that in the aircraft industry, as well as in
nuclear and space industries, the employment of
RAM data is and has been a vital element in design
and in operation of equipment and systems [Ref: 1].
The study, however, revealed a complete lack of
utilisation of RAM data within the European
shipbuilding and shipping industry. The current
shipyard design practices are not based on the life-
cycle view and has no formal link to operational
experience. A life-cycle view in design must be built
upon an in-service feedback of parameters relevant
for design improvement. The application of RAM
technology to ship machinery systems feedback has
yet to be realised.
Although there has been some attempts of collection
of RAM data, the overall picture shows a lack of
consistency in terms of collection, analysis, utilisation
and employment of data.
This paper describes a method for applying RAM
data in fault tree analyses, FTA, supporting
Reliability Centred Maintenance, RCM, ending up in
equipment.
The methodology described is based on the fact that
maintenance is needed to obtain a requested
availability, and thus also directly influencing – and
influenced by – the reliability of an item.
It is generally recognised that RCM analyses often
suffer from lack of reliable and applicable failure
data. It is further assumed that applying FTA to
strengthen the criticalityI assessment part of the RCM
would increase the quality of the analysis as such and
in addition implant design knowledge in the
traditionally operation focused RCM analysis.
THE MOSys PROJECT
MOSys (Models for Operational Reliability, Integrity
and Availability Analysis of Ship Machinery Systems)
is a research project that is funded by the European
Commission under the Brite/EuRam programme. It
aims to enhance the operational efficiency and
profitability of ship plant systems through reliability,
availability and maintainability (RAM) analysis at
ship design stage and implementation of Technical
Asset Integrity Management (TAIM) technology
during the rest of the ship life cycle. In particular it
seeks to harness the power of information technology
in handling the life-cycle data which is an essential
requirement for achieving the above objectives.
I
The term “Criticality” used in RCM is synonymous
to the term “Risk” used in FTA.

1

To achieve these goals, MOSys will develop
techniques and tools for:
- RAM and maintenance cost analysis, based on
ship machinery historical data, FMEA and
criticality analysis.
- Survey, Inspection and Repair (SIR) planning,
for harmonisation of the logistic support for ship
survey, inspection and repair in support of
operational availability.
- Technical asset management with assets’ design,
functional and operational data capture and data
analysis capability in support of RAM, SIR,
maintenance cost analysis, and the life-cycle
tracking of the asset’s conditions. This is targeted
at the ship operation phase.
- The above modules will be supported by
development of a distributed SEMDR (Ship
Equipment and Machinery Data Repository) that
will be based on the ISO 10303 (STEP)
Application Protocol 226 (Ship Mechanical
Systems) [Ref: 2].
The project consortium comprises Lloyds Register
(UK), Germanischer Lloyd (D), BIBA (D),
Marenostrum (POR), Lisnave (POR), Fordesi (POR),
HDW (D) and MARINTEK (N).
Integration of FTA and RCM
In the MOSys project, FTA and RCM is integrated to
increase the quality of the criticality assessment,
which is an important part of the RCM analysis [Ref:
3].
A simplified overall dataflow in the RAM module
developed in MOSys is shown in Figure 1:
RCM FTA
Data capture
and preparation
Data
Repository
Figure 1 Simplified dataflow schematics of the
RAM module developed in MOSys
In the following, the focus is put on the dataflow
between the RCM and FTA.
RCM comprises the following main parts:
• Function/system breakdown
• Function analysis
• Criticality analysis (FMECA)
• Maintenance assignment
• Job packing
Criticality analysis
The Criticality analysis is a major part of the RCM
analysis, since the criticality of failure modes often
affects the maintenance strategy. Criticality is often
derived from the following formula:
CR = P( xi ) ×S [Ref: 4]
CR = Criticality
P(Xi) = Probability of occurrence of the failure mode
Xi for component i.
S = Severity factor (function of consequences)
In many cases the system architecture is complex, and
a single failure mode does not always lead to a system
failure (e.g. two pumps may stand in parallel, and
both pumps must stop to cause a critical situation).
A more explicit measure for criticality may therefore
be derived from the following formula:
CR = P( xi ) × P( H | xi ) × S
CR = Criticality
P(Xi) = Probability of occurrence of failure mode Xi
for component i.
P(H|Xi) = The conditional probability of the overall
hazardous condition H given failure mode Xi for
component i.
S = Severity factor
FTA may be used to model such a situation. The top
event in the fault tree should be the overall hazardous
condition, and the basic events should be the failure
modes.
Birnbaum's measure of importance of component i at
time t is defined in the following formula:
∂Q0 (t )
I B (i | t ) = for i = 1,2,..., n [Ref: 5]
∂qi (t )
Q0(t) = Probability that the top event occurs at time t
qi(t) = Probability that basic event i occurs at time t
2
An alternative definition of Birnbaum's measure is:
Birnbaum's measure of reliability importance of
component i at time t is equal to the probability that
the system is in such a state at time t that component t
is critical for the system [Ref: 5].
We can therefore say that:
P(H|xi) = IB
Practical implementation
The integration between RCM and FTA is
implemented in a software prototype, where the
prototype version of RCMToolII and CARA Fault
TreeIII are linked together. The RCM analysis is
performed in RCMTool, while fault tree definition
and fault tree calculations are performed by CARA
Fault Tree. All data for RCMTool is stored in a
database. In the same database the name of the fault
trees is defined with connections to specified
functions in the function hierarchy. RCMTool
comprises the following main parts:
-Function tree
-Equipment assignment
-Function analyses
-FMECA (Failure Mode Effect and Criticality
Analysis)
-Maintenance task assignment
Each new fault tree is connected to a function in the
function hierarchy. Figure 3 shows how the function
hierarchy appears in RCMTool. The fault tree can be
linked to any function at any level in the function
hierarchy.
There can be no exact recipe for linking fault trees to
the functional hierarchy. This excerise must be
performed on a case to case basis; it is, however,
possible to give some rules of thumb.
The fault tree methodology should mainly be used on
the most critical functions, since it is time consuming
to analyse all functions. The functions where fault
trees are used should also be complicated enough to
justify the use of fault tree analysis. The fault trees
should be linked to a level in the functional hierarchy,
which give useful results. This will probably vary in
the systems life cycle. In the design phase, one might
be interested in comparing the reliability of two
different lubrication oil systems. In such a case,
lubrication of main engines, may be an appropriate
function level. In another cases, one might be
interested in identifying the main contributors to risk
for grounding. In such a study propulsion might be a
more suitable level.

Figure 2 shows how functions, equipment, functional

failures, parts and failure modes are logically
connected in RCMTool:

Function code

Equipm. #1 Equipm. #2 Equipm. #3

Function
failure #1

Part #1

Function
failure #2

Part #2

Function
failure #3
Part #3

Failure mode #1

Failure mode #2

Failure mode #3

Figure 2: Logical description of connected

elements in RCMTool

II
RCMTool is a software product developed by
MARINTEK
III
CARA Fault Tree is a software product developed
by SINTEF

3
Figure 3: Screen picture from Function Tree part of RCMTool

Figure 4: Screen picture from CARA dialog window in RCMTool

4
Definitions of new fault trees is performed in the
screen picture shown in Figure 4. Function code
and name is automatically displayed in the first
field, and top event must be chosen from a set of
predefined top events in the following field.
The weight factor, which is assigned to each fault
tree, is a consequence measure, for comparison of
results from different fault trees. This is useful if
e.g. a failure mode is part of two different fault
trees. In one fault tree, the failure mode is a big
contributor to the probability of the top event, while
the failure mode is ranked low in the other fault
tree. In such an example the result from the fault
tree with highest weight factor should be paid most
attention.
The fault tree must be assigned to at least one of the
four categories (Safety, Environment, Production
Down Time, Maintenance Cost). The categories
found here are the same as the criticality codes used
in RCMTool. It is important to select the correct
Figure 5: Example of fault tree defined in CARA
Figure 6: Example of output from RCMTool in CARA
categories as it may be used later in the FMECA
part of RCMTool.
When all attributes have been defined, it is possible
to start constructing the fault tree. So far the new
fault tree and its attributes have been defined in the
RCMTool database, and the fault tree name is
linked to function code. Construction of the new
fault tree is done manually, meaning the user
defines appropriate gates and basic events in the
fault tree. However, some support from RCMTool
is offered. When basic events have been defined it
is necessary to supply them with data. These data
are often already entered into the RCM database
during the FMECA. This integrated software makes
it possible to retrieve data from the RCM database
to ease the FTA.
An example of a fault tree is showed in Figure 5.
5
The data presented in Figure 6 come from
RCMTool, and all equipment and assigned failure
modes that are found below selected function (in
this example function 1.1.7) will be in this list.
Basic events in the fault tree often correspond with
the identified failure modes in RCMTool, and it is
therefore possible to reuse much of the information
entered during the RCM analysis. Basic events in a
fault tree may also be human failures that seldom
are considered in an RCM analysis. Data for such
basic events must therefore be entered manually.
When data for all basic events have been defined, it
is possible to perform calculations for the fault tree
using available functions in CARA. These functions
are found in the “Analysis” menu, but the functions
will not be discussed here. Results from fault tree
calculations will be performed automatically when
the FMECA is carried out in RCMTool at a later
stage.
In the FMECA part of RCMTool, criticality
analysis is performed. The criticality is a measure of
the product of the consequence and its related
frequency, as a result of an equipment failure,
which in next turn causes a functional failure.
Figure 7: Screen picture from FMECA part of RCMTool.
From the screen picture shown in Figure 7 it is
possible to display the results from the FTA to
improve the Criticality Assessment.
Criticality is often expressed with respect to the
following four parameters:
• Safety (S)
• Environment (E)
• Production down time (P)
• Maintenance cost, incl. equipment damage (M)
Criticality is determined for each of the four
parameters, in this case the values 0,1,2 or 3 are
used, but other parameters may also be used.
Results from fault tree analysis is intended to
support the user in determining the criticality. This
can be done in cases where selected equipment and
functional failure in FMECA is also found in one or
more fault trees. When defining new fault trees
some equipment and functional failure is included
in fault trees as basic events. In such cases it is
possible to perform fault tree analysis from FMECA
without having to remember details from definition
of fault trees. The system will automatically find all
fault trees where selected equipment and functional
failures were included, and then present results from
fault tree calculations.
6

Figure 8: Example of result from fault tree
analysis for use in criticality assessment in
FMECA part of RCMTool
Figure 8 shows results from fault tree calculations.
Theoretically it is possible to rank all failure modes
with respect criticality using the following formula:
m
Crit i = ∑ P( xi ) × P( H j | xi ) ×S j
j =1
Criti = Criticality measure for failure mode i
P(xi) = Probability of occurrence of failure mode i.
P(Hj|xi) = The conditional probability of top event
j, given failure mode Xi for component i.
S = Severity factor for top event j
m = number of top events
This formula assume that all critical events are
modelled by means of FTA.
Within MOSys the following syntax is used:
m
Crit i = ∑ lambda × I B ×weight j
IV
j =1
(The term "Reliability" used in Figure 8 is the
product of Birnbaum's number and Lambda
(Lambda = 1/MTTF))
In a practical situation it may be unrealistic to use
this method to rank all failure modes automatically.
Often expert opinions from experienced operators
and designers could give extra information, which it
may be difficult to model fully by means of FTA.
Performing FTA for all critical events, may also be
too time consuming.
Within the Mosys project, the results from the FTA
are used more as decision support, to adjust the
criticality after an ordinary criticality assessment is
done based on expert judgement. The measures
IV
P(xi) is not equal to lambda, P(xi) connection to
lambda is dependant of the failure distribution used.
P(xi) is strongly increasing with increasing values of
lambda. For ranking purposes lambda may be used
instead of P(xi).
"Reliability" and "Weight" are therefore not
discussed further.
Continuous Improvement
As stated in the introduction, there is, within the
maritime industry, a strong need for a more
systematic feedback of historical data from
operation to design. In order to improve equipment
design based on experience data, a system must be
available for collection and analysis of failure data.
In addition to the continuous improvement of
design based on operational data, there is a
significant potential for improvement of
maintenance and spare part stock in operation.
Normally in shipping and most industries,
continuous improvement of maintenance is based
on deviation analysis on macro level, e.g.
Ratio Planned Maint./Corrective Maint. or
Back-log - (jobs not carried out according to plan).
Unfortunalely, corrective actions are, more the rule
than the exception, characterised as accidental,
unsystematic, time and cost intensive.
The TAIM module in MOSys includes among other
features, a solution for continuous improvement of
maintenance. The idea is to analyse extensive
amounts of historical data in order to reveal
deviations between planned and reported
maintenance.
The methods for continuous improvement analysis
of RAM data, is conceptually shown in Figure 9.
Title:
contimp.eps
Creator:
Micrografx Graphics Engine
Preview:
This EPS picture was not saved
with a preview included in it.
Comment:
This EPS picture will print to a
PostScript printer, but not to
other types of printers.
Figure 9: Continuous Improvement of RAM
data in MOSys
Data collection
RAM analysis requires high quality input data to
obtain good results. Today, the lack of high quality
RAM data is one of the main problems concerning
performance of RAM analysis within the maritime
industry. Only a few initiatives are made to ease this
situation. RAM/SHIPNET has probably been the
most successful of these initiatives [Ref: 6] [Ref: 7].
7
RAM/SHIPNET was established in the US under
the umbrella of the Ship Operations Cooperative
Program (SOCP). The project was set up as an
information network, which should support the
optimisation of reliability, safety and the operation
costs of the ship operation. Involved in this project
are a number of government organisations and
regulatory bodies as well as ship operators and
research institutes. Consisting of a distributed and
shared Reliability, Availability and Maintainability
(RAM) database, RAM/SHIPNET was designed to
collect, process, disseminate and to store marine
equipment failure informations.
Data input for this database is coming from Chief
Engineers, ship-operation managers, regulatory
agencies, equipment manufacturer and shipyards.
Software to ease the data collection has been
developed within RAM/SHIPNET, and these
software products are today used on several ships to
collect data.
The MOSys consortium soon realised the need for
RAM data, and MOSys has therefore formalised co-
operation with RAM/SHIPNET.
Standardisation
Building a ship or to manufacture ship equipment
based on operational data requires fast access to
common data in a database. In order to make this
methodology applicable obligates a standardisation
of data types for populating such a database.
Use of information technology for enhanced
engineering and cost analysis, concurrent
engineering and life cycle data handling is essential
to meet the coming requirements to reliability,
availability and technical asset management.
An essential part of the MOSys project is to apply
the existing ISO AP226 Protocol especially for
Title:
fta_eta_fsa.eps
Creator:
Micrografx Graphics Engine
Preview:
This EPS picture was not saved
with a preview included in it.
Comment:
This EPS picture will print to a
PostScript printer, but not to
other types of printers.
Figure 10 Conceptual view of FTA and ETA interface
Conclusion
design applications, and in addition extend the
AP226 to embrace operational data.
FTA - FSA
Rules governing shipping have traditionally been
prescriptive. In an attempt to address this issue,
IMO (UN maritime body) has arrived at an interim
set of guidelines for the application of Formal
Safety Assessment, FSA, in the rule-making
process.
The FSA is in principle a guideline for carrying out
risk analyses.
One of the activities in MOSys regarding FSA, was
identify information types by applying the FSA
guideline on a selected case (ship propulsion
system).
The FSA comprises five steps:
• Hazard identification
• Risk Assessment
• Evaluation of risk-control options
• Cost-benefit assessment
• Recommendations for decision-making
Prior to the FSA, the study comprised definition of
the system in terms of boundaries, secondly to
describe a general mission (manoeuvring, sailing in
restricted waters and deep seas) for the case study.
The objective of the FSA carried out was to make
recommendations for which information types that
should be established and exchanged between
parties handling ship propulsion systems.
A possible application of the FSA in the future will
be to identify top events and acceptance levels
(acceptable reliability) for the fault tree analyses.
This is illustrated in Figure 10.
8
The aircraft industry, nuclear industry and space
industry has applied RAM analyses in design and
operation great success.
MARINTEK has, through the MOSys project,
presented a methodology for integrating fault tree
analysis and RCM analyses. The intention has been
to improve the decision base upon which the
maintenance plan has been founded. We have in
addition demonstrated that a link between a
prototype RCMTool and a commercial FTA tool
(CARA) can be established and operate
satisfactory.
The integration has been based on the fact that in
accordance with the definition, maintenance is
needed to ensure availability, and is thus also
directly influencing - and influenced by - the
reliability of an item. The worse the reliability, the
more maintenance is required.
Specifications”, Svein Inge Masdal, Roar Bye & al.,
MOSys Report D2.2-1, 1998.
Ref: 4 “Reliability Centred Maintenance”,
Anderson and Neri, ELSEVIER Applied Science
1990
Ref: 5 “System Reliability Theory, Models and
Statistical Methods”, Arnljot Høyland & Marvin
Rausand, John Wiley & Sons, 1994.
Ref: 6 “Interim Report of SOCP Reliability”,
Availability, Maintainability Data Bank for Ships,
Dr. Bahadir Inozu, Nov. 1993.
Ref: 7 “Reliability Data Collection for Ship
Machinery”, Dr. Bahadir Inozu & al., Marine
Technology, April 1998.

A failure may result in downtime and it may also

result in hazardous situations and accidents. It is
thus important that safety functions and
systems/equipment with inherent risks are properly
maintained.

There is an increasing focus on continuous

improvement in terms of improved design and
operation regularity. However, the systematic
feedback of expert knowledge from design to
operation and feedback of historical experience data
from operation back to design has suffered from
lack of data and if existing, the data quality has
been poor.

The evident need for quality RAM data may only be

remedied by employing existing standards for data
reporting and interchange.

Another issue, which most probably will have an

impact on the dissemination of the application of
integration of RCM and FSA, is the introduction of
authority requirements, e.g. rule making in the
classification societies.

References
Ref: 1 “Evaluation of Existing RAM and
Maintenance Cost Analysis Concepts”, Alfred
Mechsner & al., MOSys Report D2.1-1, 1998.

Ref: 2 “AP226 STEP Standard”, 1998 ISO

TC184/SC4/WG3 N730, ISO/WD 10303-226 Ship
Mechanical Systems. Edited By Dr. Z Bazari,
March 1998.

Ref: 3 Design and Development of RAM and

Maintenance Analysis Models and Implementation