ELSEVIER

0951-8320(95)00113-1

Reliability Engineeringand System Safety 51 (1996)159-167

1996ElsevierScienceLimited
Printed in NorthernIreland.All rightsreserved
0951-8320/96/$15.00

Practical experiences with a data collection

project: the O R E D A project
H e l g e A . S a n d t o r v a, P e r H o k s t a d a & D a v i d W . T h o m p s o n b
aSINTEF Safety and Reliability, 7034 Trondheirn, Norway
bBP International Ltd., Research and Engineering Centre, Sunbury, England

Experience data on the reliability of equipment has become vital to many

types of engineering and maintenance analyses. The consequences of incorrect
design or poor maintenance may adversely affect: safety, the environment or
cost in most categories of process industries, and, in particular, offshore
exploration and production industries. The OREDA project is a data
collection programme for the offshore industry which has been operating since
the early 80's. A high level of knowledge has been gained from this
programme on: specification of data, data collection methods and the
utilization of data. Some of the results and the knowledge gained from this
project are presented in this paper.

1 INTRODUCTION

20REDA

Since the start of oil exploration in Norway great

attention has been paid to safety and reliability.
Various analyses are used to estimate the risk of
hazards, pollution, vital damage to equipment or
production unavailability. These methods are used to
analyze the interaction between equipment, systems
and people; to assess the risk of unwanted events.
For events where safety or the environment are
jeopardized, it is important to obtain knowledge about
the consequence of the event and with what
probability this event is estimated to occur. Then one
may establish a criticality measure for this event and
judge that criticality in relation to the defined
acceptance criteria, or in order to compare different
concepts/designs. In this area many analysis methods
exist ( H A Z O P , Fault tree, F M E A etc.).
For events where the consequences are primarily of
an economic nature (downtime, repair), it is also
important to be able to estimate the probability of an
equipment failure. One is then able to estimate the
expected availability of the selected concept, and
hence obtain a better basis for planning maintenance.
Historical data on failure frequency and the nature
of failure are vital in the performance of the analyses
and assessments. As in many other industries, the
offshore industry has embarked on a joint venture to
collect, exchange and utilize operating experience for
relevant equipment. The most significant effort in this
area is in the OREDA-projects. 3

The O R E D A (Offshore REliability DAta) project

was launched in the early 80's as an initiative from the
Norwegian Petroleum Directorate. After several
pre-projects with engagement both in Norway and the
UK, a main project was initiated ( O R E D A phase 1).
The main objective was to collect reliability data for
safety important equipment. Many of the offshore
companies claimed that such data were company
sensitive, and did not want the authorities to be
involved. Hence, O R E D A was started as a club
project with participation from 8 major oil companies
operating offshore in Norway, U K and Italy. This
organization has been maintained throughout the
O R E D A projects.
At the beginning the primary objective of O R E D A
was to collect reliability data for improved input to
safety and reliability studies. Phase 1 of O R E D A
covered a wide range of equipment, and focused on
failure rate, failure modes and criticality. The results
from this phase were published in a Handbook, more
than 1000 copies of which have been sold worldwide. 1
The project continued in Phase II (1985-88). The
concept was changed to collect data on fewer
equipment classes, but to collect in more depth on
inventory and failure data. Data from different
platforms were input directly to portable PCs and then
merged into one c o m m o n database. The participating
oil companies used these data for internal analyses, or
analyses undertaken by consultants on their behalf. A
159

HISTORY

H. A. Sandtorv, P. Hokstad, D. W. Thompson

160

generic dataset from Phase II was published in a

revised version of the Handbook.
The third O R E D A phase (1990-92) was a
continuation and further development of phase II.
Some additional equipment classes were included, and
great emphasis was placed on quality assurance gain
from Phase II. In parallel, several projects on: data
analysis, automated data collection and standardization were completed.
In 1994 a fourth phase was initiated which is
planned to last two years. In this phase the data
collection will be automated when possible and
worthwhile. The data collection will increasingly be
undertaken by the participating companies, and the
range of equipment classes will be extended.
A summary of the different phases is given in Table
1. Table 2 shows on which equipment the data has
been collected in the three past phases, and the
number of inventories and failures collected altogether in the three phases. The number of failures
include all categories of failures, i.e., critical, degraded
and incipient.

3 ORGANIZATION

Each project phase has been managed by a Steering

Committee with representatives from all the participating oil companies. A main contractor has been
selected to act on their behalf with the day-to-day
project management activities. S I N T E F has been the
main contractor since 1990.
The choice of equipment on which the data was to
be collected was selected by the oil companies.

Contractors undertook the data collection work for

platforms situated in the North Sea and Adriatic;
mainly working on shore but occasionally offshore
visits were required. A spin-off effect from this
organization, which has gradually developed through
the years, is the improved cooperation climate
between different countries, business cultures and
individuals.

4 T H E O B J E C T I V E S A N D B E N E F I T S OF
RELIABILITY DATA COLLECTION
4.1 Application

At the outset, O R E D A data was primarily needed for

risk and availability studies in the early concept and
engineering phases of an offshore development. In
recent years there has been an increasing interest in
data for use in maintenance optimization. This
involves new user categories (e.g., operating and
maintenance departments). Each application requires
different data types and level of detail. Table 3 shows
some typical application areas for use of the O R E D A
data.
4.2 Benefits

OREDA
data has been used mostly in the
design/engineering phases (see Table 3) for which the
data originally were intended. Experience indicates

Table 1. O R E D A project phases

Phase

Years

#Part.

Contents
Data

'81'84

Wide variety of equipment

Compiled data only

II

'85'88

Production equipment only

(7 equipment classes)
Individual equipment history
stored
in database

III

'90'92

10

As phase II, extended with 5 new

equipment classes
More emphasis on quality
information on planned
maintenance included

Products
Software

Other

Book
(Open)

IV

'94'96

10

Data collection more automated

Data collected by Participants
More focus on maintenance data
Cooperation with manufacturers

Specialized
Software

Data base
1. All data:
Participants
only.
2. Curtailed
version
(Students)

Generalized
Software

Guidelines on:
--data collection
--data analysis
--application

Seminars
Conversion to
Windows and
object model
ling

Promotion material
Vendor cooperation
ISO standard
Revised Guideline
Misc. being planned
('94)

Practical experiences with a data collection project: the OREDA project

161

Table 2. Data collected in the various O R E D A phases

Equipment classes

Data collected in phases:

I

II

1981-84

1985-88

Gas Turbines
Compressors
Electric Generators
Pumps
Vessels
Heat exchangers
Valves
Fire and Gas detection
Process sensors/control
Drilling equipment
El. power systems
Subsea systems
Misc. safety systems
Misc. utility systems
TOTAL

~/
~/
,/
,/
,/
~/
,/
~/
~/
,/

~/

~/

154

5245

~/

~/

~/

112
125
852
742
764
2202
9511
4227
880
1321
77
1703
1035
23 705

4762

v/
,/
,/
~/

~/
~/
,/
,/
,/
~/
,/
~/

,/
,/

that the data is inadequate for detailed maintenance

analysis. In phase IV data will be collected to
overcome these limitations.
Figure 1 shows one example where the data has
been used in a design optimization analysis. Many
other examples where there have been significant cost
savings, notably on design studies, have been
reported.
The cost savings indicated in Fig. 1 cannot solely be
attributed to the use of the O R E D A data. However,
O R E D A data was a crucial input to the analyses. A
higher level of confidence by management that the
chosen solution was the optimal one is therefore
achieved. Moreover, regulatory authorities have been
convinced, by the use of O R E D A data, of the
credibility of alternative nonstandard design solutions
which otherwise may have been rejected.

No. of data
#Equipment #Failures
1990-92
Units
III

2111

5159
1180
505
1918
5363
2078
1106
455
85
737
2147
32 851

In 1994 D N V Technica, assisted by SINTEF,

carried out a survey among the participating
companies on the use of reliability data. The survey
was based on a questionnaire. 22 responses were
received.
Some of the conclusions were:
1. Unavailability of data for reliability studies is a
problem (82%)
2. Data bases are their main sources for reliability
data (77%)
3. 10-30% of the time is spent establishing data
dossiers in reliability studies (71%)
4. Standardization, large populations, high quality
data, easy access and analysis of data were
ranked as the most important O R E D A benefits.
In addition to the collected reliability data, the

Table 3. Typical areas of application for reliability data

Discipline
Design/Engineering

Maintenance/Operations

Example Applications
Availability studies:
Availability estimates (e.g. system performance simulation)
Design optimization (e.g. evaluate need for redundancy)
Equipment selection (e.g. select most reliable make/model)
Risk analysis:
Estimate probabilities of critical events
Estimate survival time for safety-critical items
Maintenance planning and optimization (e.g. Reliability Centered
Maintenance):
Decide on maintenance approach, and optimize maintenance
intervals
Analyze reliability characteristics (e.g. lifetime distribution, failure
mechanisms)
Reveals weak designs that need modification or redesign
Feedback of data to manufacturers and engineering designers
Operations:
Demonstrate how operating conditions affect performance of
equipment

H. A. Sandtorv, P. Hokstad, D. W. Thompson

162

Solution:

One ~ s s

train selected with redundanciesat specified partof the process

Fig. 1. Example of application of reliability data.

O R E D A projects have also created some spin-off

activities such as:
1. Development of standards and guidelines for
collection and analysis of reliability data. The
O R E D A concept is used as the basis for a
current work on developing an ISO-standard on
the collection of oil industry reliability data (ISO
TC67/WG4)
2. Development of specific software for collection
and analysis of data
3. Increased knowledge as to the need for, and
requirements to reliability data
4. A high level of knowledge on data collection
process, e.g., specification, procedures, training,
cost-effective methods, has been attained
5. Useful cross-fertilization of knowledge and
efforts between
different companies
and
countries.

50REDA

DATABASE

DESCRIPTION

5.1 Organization of data

An O R E D A database for a given equipment category

consists of three related database files: an Inventory
part, a Failure part and a Maintenance part.
The Inventory part contains a description of each
Equipment Unit (e.g., a pump) for which data are
collected. This description contains technical data
(e.g., capacity, size) as well as some operating and
environmental data (e.g., operating mode, vibrations).
The inventory description is stored in one Inventory
record in the database.
The Failure part contains all failure events being
experienced for one Equipment Unit during the
period of surveillance; one failure record for each
failure event. The failure events are always related to
one Inventory record by a software-maintained
cross-reference numbering system.
The Maintenance part contains information about

the actual preventive and corrective maintenance

being carried out (e.g., maintenance action, manhours). Preventive maintenance is always related to
the Inventory part while corrective maintenance is
related to the failure event records. One failure may
be related to more than one corrective action. This is
relevant if the first corrective action did not cure the
problem and a second maintenance job at a later
occasion was required. The database structure, and
the relation between the different information files, is
shown in Fig. 2.

5.2 System hierarchy and boundaries

Reliability data that are collected on different systems

and different platforms must be compatible when
being merged into a common database. They must
therefore be referred to the same level and boundaries
of the equipment classes. In O R E D A each equipment
class (e.g., pump) is broken down in a three-level
hierarchy as shown in Fig. 3. For each equipment class
this hierarchy is specified. To get a consistent failure
event description, it is specified to what indenture
level each piece of information is related (e.g., failure
mode is related to the equipment unit).
As shown in Fig. 3 we use the terms Boundary
level, Sub-boundary level, etc. to describe the
indenture levels while we use the terms Equipment
unit, Subunit and Maintainable Item to describe the
hardware unit(s) on each indenture level. An
Equipment Unit is the highest level we apply in
O R E D A and will typically be a pump, a gas turbine, a
compressor, etc.
Equally important is the boundary definition which
specifies what equipment should be considered as part
of an equipment class. In O R E D A general guidance
on this is given as well as specific boundary diagrams
for each equipment class. An example of such a
boundary diagram is given in Fig. 4.

Practical experiences with a data collection project: the O R E D A project

Inventory
File:

Failure
File:

Maintenance
File:

Inventory
description

Preventive i
..... |
maintenance
~ . ~
C0rrective 1.1 ~
I
I 1 maintenance /
L~
Corrective 1.2 I |
J
maintenance
J

Failure 1

I
Failure 2

Inventory
description 2

Failure 1

Failure 'n'

CrrenVtei~:nJ

II/

Maintenance 1

Maintenance 'n'
.=

('n' inventories)

Fig. 2. Database structure.

\
Boun~ry
level

\
\

\
EQUIPMENT
UNIT
(E.g. Pump)

Sub-boundary
level

(E.g.LuC=rlcatIon
System)
\

I MAINTAINABLE
ITEMNo, 1
(E.g Lub. oil
coo~er)

I
I............ I

SUBUNITN

I T E M NO. 1

ITEMS

Maintainable
Item level

MAINTAINABLE
ITEMNO.N

I MAINTAINABLE
ITEMNO.N

I
\

Fig. 3. System hierarchy.

163

H. A. Sandtorv, P. Hokstad, D. W. Thompson

164

BUS

STARTINGSYSTEM
INCL C.B

l I

COO. . . .
SYSTEM

CONTROLAND
MONI'IORIN~

MI~.

........... J.... t .......................

Coolant

Power

Romoleinstr.

Fig. 4. Boundary diagram for electric motors.

5.3 Taxonomy
O R E D A classifies the equipment in Equipment
Classes, e.g., pumps, compressors, gas turbines, etc.
Each individual unit within an Equipment Class is
termed Equipment Unit (e.g., one pump). Each
Equipment Unit is further classified by some
characteristics as to identification of the data record,

design-, and use-characteristics (see Fig. 5). Based on

these characteristics, a multitude of data cells are
created, each with a unique address to house failure
rate data for each specifically defined piece of process
equipment and its use. The subdivision of information
in categories/fields makes it easier to search and query
the database for equipment classes with similar
characteristics.

OREDA IV Taxonomy Structure

OO,PMENTO

SS

__L

I
c...~cT~.,s~.cs

,!!

Environment ~ - -

Datarecord

O0 ,at,on

Classification

I Mainten~ccnc~ii~ l

pro~,~m

(optional)

,OE.T,F,
A.,ONfii

~ --~

.oft....... t~!i I
...,,,.,,on liiiilf

Fig. 5. Inventory data categories.

Practical experiences with a data collection project: the OREDA project

5.4 Data categories

The data is collected in a predefined format. As far as
possible the O R E D A software use a menu of
predefined codes for each data. This has the
advantage of making search and analysis of data
significantly more feasible than by free text, but one
loses some details in the information. However, an
additional free format 'remarks field' is used to add a
more complete free text description of the event. The
use of codes requires a very considerate selection of
code menu, and definition of the codes, in order to
minimize interpretation problems. A summary of the
data categories we use is given in Table 4. The main
failure event data are:
1. Failure modes, which are defined for each
equipment class.
2. Severity class, which describes the severity of the
failure for the main function of the equipment
unit and is defined in three levels, viz. Critical,
Degraded and Incipient.
3. Failure descriptor defines the observable cause.
It is a two-level parameter; upper level
describing the failure type (e.g., Material) and
lower level the more specific cause (e.g.,
corrosion).
4. Observation method describes how the failure
was detected (e.g., by casual observation).
5. Failure consequence describes the failure effect
on higher level systems (e.g., oil production).

6 ANALYSES
In the O R E D A software, which is a computer tool for
creating and using the databases, it is possible to select

one, or a few data fields, to be included in a search or

analysis by using software filters (see example in Table
5). The main types of data analyses that can be run
are:

6.1 Standard analysis

In this analysis the failure rates for the different
failure modes and criticality classes are calculated.
Such analyses can be carried out for all systems of a
certain category (e.g., all gas turbines) or on any
selected group by setting filters on the data (e.g., all
gas turbines > 5 M W driving compressors). It is
possible to toggle between the failure rate calculated
based on calendar time or operating time. Also
maintenance manhours (or active repair time) is
included in this calculation as shown in Table 5 for
some selected valves.

6.2 Frequency analysis

It is also possible to extract information for the many
combinations of data that the database contains from
the Inventory file, Failure Event and Maintenance file,
independently. By doing this one is able to perform a
frequency analysis which gives the failure rates for
each combination of the values in the selected data
fields.
As an example we may wish to have the number of
failures (or failure rates) for pumps grouped according
to driver category, and sorted on 'failure modes'. The
output from such analysis is shown in Table 5.

Table 4. Data categories

Inventory data

Failure and maintenance data

Classification:

Equipment class, design class, platform

system

Failure and maintenance data Failure data:

Misc. identification data Detection date
Failure mode Severity class Failure
descriptor Items failed Observation
method Failure consequence Maintenance
data: Misc. identification data Maintenance
category Items maintained Maintenance
action Downtime Active repair time
Restoration man hours (per category)

Installation:

Owner and installation (coded), operation

category,
equipment description, no of subunits etc.
Manufacturer name, model type]designation
Size, weight, material, design code,
instrumention etc. as relevant
Capacity, power, flow, RPM etc. as relevant
Application, operating mode, operating
time, no of demands, date installed
Location (geographic), external
environment, internal environment

Manufacturer:
Design:
Performance:
Operation:
Environment:

165

H. A. Sandtorv, P. Hokstad, D. W. Thompson

166

Table 5. Output (example) from a frequency analysis

PUMP
DRIVER

EXL 1

FTS

FWR

LOU

DIESEL
ELECTRIC
TURBINE
TOTALS

62
343
23
428

74
165
3
242

35
539
264
838

27
45
16
88

FAILURE MODES
OTH
OVH
SEL
195
864
44
1103

13
25
1
39

19
1
20

SPT

UNK

SUM

8
73
7
88

34
114
2
150

448
2187
361
2996

~EXL = External leakage, FTS = Fail to start, etc.

6.3 Lifetime distribution
D a t a can easily be exported to other software for
m o r e sophisticated analyses such as assessing lifetime
distributions (Weibull, exponential, etc.). S I N T E F has
developed several types of such programs which are
compatible with the O R E D A software.
For all calculations it is possible to export the result
into some spreadsheet software (e.g. Quatro, Excel)
to display the results in a graphic format. An example
of this is given in Fig. 6.

7 PROBLEMS EXPERIENCED
COLLECTION

IN D A T A

4. collection of historical data makes it difficult to

interpret information which is incomplete or
dubious
5. the effect of preventive maintenance on the
reliability is difficult to measure; thus it is
difficult to extract the 'naked failure rate' (i.e.,
the failure rate that would be observed if no PM
was performed). 4 In some cases preventive
maintenance has even an adverse effect on
reliability (poor workmanship, sub-standard
parts etc.)
6. it may be difficult to find personnel with proper
competence for data collection.

7.2 Data quality

7.1 General experience

Though there is a large benefit potential in collecting
and analyzing reliability data, there are m a n y pitfalls
that we have experienced in the course of these
projects.
1. collection of historical data batchwise and by
manual methods as applied in O R E D A is time
consuming and expensive. A m o r e cost-effective
and a u t o m a t e d approach is planned to be used in
the next O R E D A phase (Phase IV)
2. quality and availability of data varies significantly between the companies. In general,
data for detailed maintenance planning is less
than adequate
3. it is difficult to develop specifications for
complex equipment which are interpreted in the
same way by each data collector

In the last O R E D A phases, quality of data has been

emphasized. By this is m e a n t to achieve the m a x i m u m
quality of data from the sources available. In some
cases, where the data sources have not been adequate,
data collection has been a b a n d o n e d for this system or
platform. The major quality measures applied have
been:
1. comprehensive Guideline manual for data
collection. This Guideline is published as an
' O R E D A product' and issued in revision 6 (early
1995) 2
2. specific software package for data collection and
analysis 5
3. specific Quality Assurance system for providing
m a x i m u m quality of information at the outset

Table 6. Experienced quality problems in the data collection process

Quality checks on data Deviation reports
Subject

Deviation reports
Percent

Interpretation of the Guideline / wrong codes

Illegal codes / typographic errors

39
20

Missing non-compulsory information

Missing compulsory information
Inconsistency
Questionable information

17
10
7
7

Subject
Data availability / quality
Interpretation of Guidelines (codes, boundaries
etc.)
Missing codes / new codes
Revised data collection plan
Software errors
Others

Percent
28
26
11
4
4

Practical experiences with a data collection project: the O R E D A project

35

8 R E C O M M E N D A T I O N S FOR D A T A
COLLECTION PROJECTS

OREDA II
[] OREDA III

30

~ 25
20
e~
15
E

lO

.= 5
r,

0
COCE(36/37)

CORE(14/8)

TOT(50/45)

Fig. 6. Failure rate for compressors in phase II and III for

the taxonomy code 'Type'.

and verifying the quality during the data

collection process
4. a close communication system between the data
collectors and the project management as to
procedures, interpretation rules, deviations etc.
5. built-in consistency check in the data collection
software.
The quality control of the data was carried out at
several steps:
1. initially by the individual data collector person
by specified self-check routines
2. by the contractor doing the data collection when
one platform or system was finished
3. spot checks and statistical checks carried out by
the project management on arbitrarily selected
data during the data collection process
4. final verification by the project management on
the complete database
Two challenges have been predominant
quality assurance process:

167

1. The use (immediate and potential) of data

should be analyzed and specified before deciding
on a data collection project. Avoid a 'nice-tohave' approach.
2. A clear definition and specification as to
boundaries, data type and format is paramount
for obtaining high quality data.
3. Quality assurance of data should be emphasized
in the specification, data collection- and verification procedures.
4. Data collection shared by many companies
(industry branch) gives a significant cost-benefit
gain vs company individual efforts.
5. The provisions for an automated data transfer
and exchange should be exploited, notably for
failure and maintenance data (data in large
quantities).
6. Feed-back of useful data/analysis to the
operating department is vital for creating
required motivation.
7. A combination of coded data and free text
should be used. Use standardized terms in free
text (e.g., hypertext).
8. Start small, and design for flexibility.
ACKNOWLEDGEMENT
The present paper is written with funding from the
Growth Point Centre in Safety and Reliability at
S I N T E F and N T H (Norwegian Institute of Technology). The authors wish to thank the O R E D A Project
sponsors A G I P , BP, Elf Petroleum, Esso/Exxon,
Norsk Hydro, Phillips Petroleum, S A G A Petroleum,
Shell, Statoil and T O T A L for permission to publish
this paper.

in the

1. harmonizing interpretation rules and quality

standards between different data collectors
2. dealing with changes (plans, definitions, codes
etc.) in the course of the data collection project.
Problems in these areas have been revealed and
solved with specific control and reporting procedures
of which quality control and reporting of deviations
are the primary ones. A summary of the most
c o m m o n problems in this area is given in Table 6
(1992 only).

REFERENCES
1. OREDA-92, Offshore Reliability Data Handbook 2nd
edition, DNV Technica.
2. OREDA, Guideline for Data Collection, 6th edition,
prepared by SINTEF on behalf of OREDA, 1995.
3. Sandtorv, H. A., Experience with the collection, QA and
application of an offshore R and M database--The
OREDA project. E and P Forum seminar, London, 15
December 1993
4. Cooke, R. et al., Design of reliability databases for the
aerospace application. Report 93-110 TU, Delft, 1993.
5. Jensen, S. B. et aL, A software tool and database for
offshore systems reliability. In O M A E '93 conference,
Glasgow, 20-24 June 1993.