See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/275646151

New Generation Risk Based Inspection Methodology and Software for the
Process Industry

Conference Paper · January 2011

CITATION READS

1 2,861

4 authors, including:

Panos Topalis Maneesh Singh

Det Norske Veritas Høgskulen på Vestlandet
7 PUBLICATIONS   14 CITATIONS    46 PUBLICATIONS   564 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Evaluation of the Structural Integrity of Corroding Oil and Gas Pipes View project

Strength of cement-bonded briquettes View project

All content following this page was uploaded by Maneesh Singh on 30 April 2015.

The user has requested enhancement of the downloaded file.

 New Generation Risk Based Inspection Methodology and
Software for the Process Industry
Panos TOPALIS1, Geir KORNELIUSSEN2, Maneesh SINGH3, Frode WIGGEN3
1. DNV Software, Palace House, 3 Cathedral Street, London SE1 9DE, panos.topalis@dnv.com
2. DNV Software, P.O.Box 300, 1322 Høvik, Norway, geir.korneliussen@dnv.com
3. DNV,P.O.Box 408, 4002 Stavanger, Norway, maneesh.singh@dnv.com, frode.wiggen@dnv.com

ABSTRACT
Risk Based Inspection (RBI) is now a well established approach for managing inspections in the process
industry. A new RBI methodology and software is presented in this paper. The software has been built on
the new risk framework architecture, a generic platform facilitating efficient and integrated development
of software applications using risk models. The framework includes a library of risk models and the user
interface is automatically produced on the basis of editable schemas. This first version of the risk-
framework-based RBI tool has been applied in the context of offshore topside RBI but it has been designed
with the objective of being generic enough to allow risk studies of process plants.
The offshore topside methodology is based on the latest joint industry recommended practice DNV RP-
G101 and includes models for qualitative, semi-quantitative and quantitative RBI studies. The
methodology assesses damage mechanism potential, susceptibility or degradation rate, probability of
failure (PoF), consequence of failure (CoF), risk and inspection intervals and techniques.
The data are structured according to an asset hierarchy including field, installation, system, corrosion
circuit, tag, part and inspection levels and the data are inherited / defaulted seamlessly from a higher
hierarchy level to a lower level. Typically a qualitative analysis can quickly start at a high level and it can
then progressively become more detailed and more quantitative, when the data become available during
the project and if more accuracy is judged to be important because of a high risk level. The user interface
includes synchronized hierarchy tree browsing, dynamic dialogues and grid-view editing and reports with
drill-in capability. The software also includes numerous advanced features such as change tracking and
facilitated verification and quality checking.
Keywords: Risk-based Inspection, software, offshore

1. INTRODUCTION
The risk based inspection (RBI) approach is currently well established and widely used in the Oil & Gas,
Refining, Petrochemical and Chemical Industries. FIGURE 1 shows a typical inspection management
process based on equipment risk calculations. A risk assessment, including consequence of failure and
Likelihood of failure, ranks items according to risk and allows elaboration of an effective inspection
program, including inspection methods, timing and coverage. This is translated into a detailed inspection
plan, which is executed and the results are evaluated and fed back into the next cycle of risk assessment
and inspection planning.
Š‡ ‡••‡–‹ƒŽ ‡Ž‡‡–• ‘ˆ ƒ Dz“—ƒŽ‹–›dz ‹• ƒ•‡† •’‡…–‹‘ ƒƒŽ›•‹• Šƒ˜‡ „‡‡ †‘…—‡–‡† by the
American Petroleum Institute (API) in API RP 580 (2009). API RP 581 (2008) describes a specific RBI
methodology with full details: data tables, algorithms, equations, models. The API 581 methodology
focuses on RBI for the downstream sector, especially refineries. A joint industry project produced DNV
RP-G101 (2002) which describes a specific RBI methodology for the upstream offshore topside sector. The
implementation of the RBI methodologies has been facilitated by commercial software tools such as
ORBIT Onshore (Topalis, 2007), ORBIT Offshore (DNV, 2009), API RBI (Panzarella et al, 2009). The RBI
benefits are well known and they are summarized by API RP 580 (2009):

Page 695
 Inspection Philosophy
Inspection Systematics
Inspection data evaluation
Consequence of Failure
Analysis of results Safety, Production Loss

Inspection and testing Inspection Probability of Failure

Execution & Reporting Management Materials/Environment
and Strength

Risk evaluation per

Inspection Plan equipment
Inspection details,
planning, logistics Inspection Programme
Method, Timing, Coverage,
Location, Cost

FIGURE 1: Typical Risk Based Inspection Management Process

x RBI facilitates the development of optimised plans (inspection or mitigation plans) to manage
risks on an equipment level
x RBI may provide an overall reduction in risk for the facilities and equipment assessed
x RBI provides an acceptance/understanding of the current risk
x RBI may identify equipment that not requiring inspection or some other form of mitigation
o Inspection & maintenance activities can be focused and more cost effective
o This results in a significant reduction in the amount of inspection data that is collected
o RBI plans may also result in cost reductions
ǯ•  •‘ˆ–™ƒ”‡ ’ƒ…ƒ‰‡• ”„‹– •Š‘”‡ ƒ† ˆˆ•Š‘”‡ ƒ”‡ ƒ–—”‡ ’”‘†—…–•ǡ ƒ”‡ ™‹†‡Ž› —•‡† ƒ”‘—†
the world and have been updated regularly since the their first commercial release in 2000. However any
computer software benefits from re-architecturing, especially after several years of development.
Therefore a decision has been taken for a complete re-write of the RBI software and this started with the
offshore/upstream module of the RBI software, which we call Orbit 3 Offshore. This development brings a
number of benefits:
x Opportunity for merging/ integration of the offshore/upstream and onshore/downstream
functionalities
x Re-architecturing allows a much more modern and powerful user interface
x The new Risk Framework architecture allows easy maintenance/ addition of new features
x Update to the latest recommended practice. The offshore RBI module is now consistent with the
latest edition of DNV-RP-G101 (2009)
x Improved consequence model
x Includes feature to allow formal verification of data/ calculation results
x Has the possibility to easily interface with external applications e.g. Enterprise Resource Planning
(ERP) applications or Computerized Maintenance Management Systems (CMMS)
This paper presents some of the features of the Orbit 3 software. Generally, theory and models from the
previous version 2 have been re-used and tested and it is not the authorsǯ intention to document or justify
these models in this paper. DNV-RP-G101 (2009) is a public document and contains the references used in
the latest version of software.

Page 696
2. NEW SOFTWARE ARCHITECTURE
2.1 Risk Framework Architecture
Š‡ƒ’’Ž‹…ƒ–‹‘”„‹–‹•‘‡‘ˆǯ••–ƒ†ƒŽ‘‡”‹•ƒ’’Ž‹…ƒ–‹‘•ƒ•‹–…ƒ„‡•‡‡‹

FIGURE 2. Risk applications such as Phast, Neptune and Orbit use similar types of models such as
discharge, dispersion, effects, PoF and risk calculation models. Same general design principles apply to all
tools but have been implemented independently for historical reasons and typically:
x The risk applications use separate architectures from different implementation technologies:
o Different 3rd party tools
o Different code languages
x There is duplication of effort in development and support
x Investment in common components cannot be shared e.g. risk model updates
x All of the tool environment look and feel different

Phast and Safeti Neptune Orbit

GUI ± Scenario based IO Reports Reports GUI ± Equipment Based IO Reports

GUI ± Scenario based IO

Linked Model Templates ± Hard Coded Flexible Model Linkage, part of GUI Linked Model Template ± Hard Coded Lookup
DEGRADATION/ tables
DISCHARGE DISPERSION EFFECTS RISK DISCHARGE DISPERSION EFFECTS RISK DISCHARGE
PoF

Data Data Data

FIGURE 2: Old standalone risk application architecture

Phast/
Neptune Orbit Summit Solutions
Phast-Risk

BRIX Risk Explorer 2.0

(Main window, child window and control templates)
BRIX Rules? Visual representation of Risk Objects (Tools)

Risk Framework
(data & schema management, generic data editing, generic charting and
reporting support [model] calculation support, notification pipeline
Data Dictionaries (support for multiply active tools), model-view-presenter (undo/redo,
macro support), serialization to local SQL Server of larger data etc.
Database Engine/PMOD

Data Store
Flexible Model Interface

New
Models: $, User¶s
Discharge Dispersion/ Degradation Risk
Fault Tree, Models
Effects / PoF Smoke
Third party software

FIGURE 3: New Integrated Risk Model Architecture

FIGURE 3 shows the new risk model architecture. Orbit 3 is the first application in the new architecture.
The risk framework development has a number of benefits:
x One tool that meets all market needs

Page 697
 x Benefits of updates and upgrades are controlled and shared between applications
x Development is more flexible and efficient
x Enhancements and solutions are easier to build
x One common core tool is supported so learning is faster and support is less dependant on tool
specific knowledge
x Tools can communicate with each other and user applications
x Quality of tools improves as the framework is the model development environment

FIGURE 4: Orbit 3 Overview

2.2 Orbit 3 Overview

FIGURE 4 shows an overview of the ORBIT 3 user interface, which is typical of a risk framework
application interface. This shows the following elements:
x Modern Microsoft-style ribbon at the top with the home tab selected by default.
x Asset tree explorer normally located on the left had side
x Grid view, normally on the right-hand side
x Output/ messages area at the bottom
Navigation/ selection is via the assets explorer tree. Any object at any level in the tree can be selected and
opened through double-click or the right-click menu on the tree or through the grid. FIGURE 5 shows the
dynamic dialogue resulting from opening an object and allowing viewing or editing of the object .

Page 698
FIGURE 5: Dynamic dialogue for a « Part » object

2.3 Tree and Data Hierarchies

RBI Study Node

Field

Installation

System

Tag

Inspection

Part

Inspection

Thickness Measurement Location

FIGURE 6: Main Asset Hierarchy for Orbit 3 Offshore

Page 699
The Orbit 3 Offshore asset tree explorer, shown on the left hand side of FIGURE 4 is used for navigating
the main asset hierarchy as well as the additional groupings/ hierarchies. The main asset hierarchy is
shown in FIGURE 6. The following additional groupings/ secondary hierarchies are also available:
x Corrosion circuits. These are groups of equipment items with similar corrosion characteristics.
Several tags or parts can belong to a corrosion circuit
x Isolatable sections. Several tags can be grouped into one isolatable section
x Areas. An Area includes one or more isolatable sections

2.4 Dynamic Dialogue

A dynamic dialogue is one method to edit input data or display results for a given object such as
installation, system, tag or part. There are 2 types of dynamic dialogues:
1) Dynamic dialogue for object (part, tag etc) general data. FIGURE 5 shows an example of dynamic
dialogue for a given Generic Part object. This dialogue is normally started by double-clicking on the object
‘”•‡Ž‡…–‹‰Dz”‘’‡”–‹‡•dz‹–Š‡”‹‰Š–-click menu of the object.
2) Specific calculation Dynamic Dialogue. This is selected from the right-click menu of the object. It shows
input and output fields for a given calculation e.g. External Corrosion dynamic dialogue.
Colour coding is used to mark the status of the object fields:
x Green if the value is inherited by an object higher in the hierarchy. E.g. if the product service
attribute PT for the part is inherited from the parent tag, then it is marked green
x Red if a mandatory value has not been set.
x Black if the field has been set with a value that has not been defaulted from a higher level.

2.5 Grid
The grid facility is one of the most powerful features of Orbit 3. A grid is a tabular view of the attributes of
several objects at the same time. There numerous grids in ORBIT either for editing object general data
(system data, corrosion circuit general data, tag general data, part general data) or for specific calculations
(Tag PoF calculation, Part CoF Calculation etc). The grid also facilitates batch import of data from MS
š…‡Žǡ™Š‹…Š‹•ƒ˜‡”›‡ˆˆ‹…‹‡–†ƒ–ƒ‡–”›‡–Š‘†Ǥ‡šƒ’Ž‡‘ˆDzƒ‰•dz‰”‹†‹••Š‘™‘–Š‡”‹‰Š–Šƒ†
side of ORBIT in FIGURE 4.
Another interesting feature is the hierarchical grid option; displaying data from several object types. An
example of hierarchical grid could be the Tag-Part Grid, where the tag grid rows can be expanded to show
the underlying Part data,

2.6 Validation/Verification Audit Tracking

Sometimes it is a requirement that the object input data (e.g. tag or part data) or results of a calculation
should be verified by the user and there should be an audit record of the validation for quality assurance
purposes. The software achieves this through the validation fields.
FIGURE 5 shows the dynamic dialogue for an object (part: oil sphere receiver) with the validation check
box. The verifier sets the Validation checkbox after the verification and the object is time-date-stamped
and signed by the named verifier.

3. RBI WORKFLOW AND CALCULATIONS

3.1 Workflow
Orbit 3 offers the user the capability to optionally perform RBI at various levels of detail (qualitative, semi-
quantitative and fully quantitative) and for various hierarchy level objects (system, corrosion circuit, tag,
part) is one of the strengths of Orbit 3. Typically the user starts from a less detailed analysis (e.g.
qualitative) and from a higher level object (eg system) and optionally progresses to more detailed analysis
and lower level objects, if the level of risk justifies such a detailed analysis.

Page 700
 Collect relevant
data

Create
Corrosion
Circuits

Level1 RBI: Screening

At System & Circuit level
High risk
Risk
Riskanalysis
Level

Low risk
Medium risk Level II RBI: Semi-Q

Annual General
Visual Inspection.
Corrective Low risk Risk
Riskanalysis
Level
Maintenance High
Assessment per corrosion risk
circuit. Use of DNV RP G101
Inspection
planning Medium risk

Yes Acceptable risk Level III RBI: Detailed

Inspection Riskanalysis
Risk Level
interval No
Acceptable?

Based on subdividing corrosion

Yes circuits into tags & sub-tags

Confirm data Unacceptable

Inspection
execution risk

Assess findings
& update Other risk
database with No mitigating actions
findings

Need to
update
RBI?

FIGURE 7: Example of RBI workflow in ORBIT 3

An example of RBI workflow that can be achieved with the software is shown in FIGURE 7:
x A screening analysis can start at high level e.g. at system level (or corrosion circuit level) with
minimum data input. If the risk for the system is low then no further analysis is required and
general visual inspection / corrective maintenance is planned.
x If the risk is medium or high then a screening (pure qualitative) or semi-quantitative analysis (e.g
qualitative CoF combined with quantitative PoF) can be attempted at a corrosion circuit level. At
this point some more detailed data are required and corrosion circuits need to be defined.

Page 701
 x If the risk is sill high a fully qualitative analysis can be conducted at tag or part level. This is a
detailed analysis, requires data for the tags or sub-tags (parts) and can produce detailed
inspection plans with inspection intervals and techniques for each tag or part.
The software includes rules for data defaulting so that the analysis can move from the high level to the
more detailed level with minimum effort. Similarly, after a detailed analysis, aggregation rules allow
presentation of the detailed results at a higher level.

3.2 Risk and Inspection Planning Calculations

In the screening assessment, PoF and CoF categories are effectively set by user expert judgement , on the
basis of some rules and limited data, as described in DNV RP G101 (2009).
Detailed risk calculation includes the following steps:
x Allocate degradation models for each part/ tag on the basis of the item material of construction
and product service
x Calculate Consequence of Failure (CoF) for each item
x Calculate Probability of Failure (PoF) for each item
x Calculate risk and time to inspect for each item

3.2.a Degradation Model Allocation

Default degradation models are allocated according to rules described in DNV RP G101 (2009) and
depend on the material of construction, the product service and the type of defect such as internal
thinning, external thinning or Stress Corrosion Cracking (SCC). The allocation rules can be overridden by
the user in the admin toolkit.
The Orbit 3 Offshore mechanisms/ models are summarised in FIGURE 8. This FIGURE also shows that the
method to calculate PoF depends on the type of mechanism. There are 3 types of model:
x Degradation rate model, when the equipment degrades steadily with time e.g. CO2 corrosion.
x Non-rate model when failure occurs suddenly after an incubation period. In this case the PoF is
calculated directly through an empirical correlation, typically dependent on temperature.
x Manual PoF calculation, when there is no model to assess the PoF and the calculation needs to be
done manually outside the software.

3.2.b CoF Calculation

Three types of consequence effects are taken into account:
x Safety consequence, expressed in terms of potential loss of life (PLL) for personnel, which is a
standard risk measure in risk assessments. Personnel injuries can be estimated through empirical
equations but this is not considered necessary in this case.
x Economic consequence, expressed in financial terms using appropriate currency units.
x Environmental consequence. This is currently also expressed in terms in financial terms as the
cost of cleaning up the spill.
There are currently quantitative methods to estimate safety and economic consequence, involving simple
discharge, dispersion and effects models. But it is still possible to set all 3 CoF components with a
qualitative category-based approach.

Page 702
 Allocate Mechanism from
Material and Product Service

Erosion of Carbon
Quantitative Quantitative PoF Internal Thinning
Steel

Rate PoF Procedure

Water Corrosion of
Carbon Steel

CO2 Corrosion of
Carbon steel

MIC of Carbon
Steel

Water Corrosion of
stainless steel

Water Corrosion of
copper-nickel alloy

Water Corrosion of
Titanium
Non-Rate PoF Procedure
Uninsulated
External Thinning
Ext.Corrosion of
carbon steel

Insulated
External SCC
Ext.Corrosion of
carbon steel
Quantitative CoF
Insulated
Ext.Corrosion of
stainless steel

Uninsulated
Ext.Corrosion of
Quantitative Risk
stainless steel
Procedure
for Low-Manual PoF
External Corrosion
of copper-nickel or
titanium

FIGURE 8: Allocation of Degradation Mechanisms/ Models and PoF Models

3.2.c PoF/ Risk Calculation and Inspection Planning

The PoF model depends on the type of mechanism, as it was discussed previously and shown in FIGURE 8.
FIGURE 9 shows a typical example of Rate model i.e. CO2 corrosion rate is function of time. If the user sets
a maximum risk target (or maximum PoF) the program can calculate the time to inspection.
FIGURE 10 shows a non-rate model: External Stress Corrosion Cracking (SCC). PoF is calculated on the
basis of the material and the temperature.
Risk can be considered as the product of PoF and CoF
Risk = PoF x CoF (1)
Comparison of the calculated risk with acceptance criteria determine the follow-up action according to the
workflow e.g. FIGURE 7

Page 703
 PoFLimit,Type = RiskLimit,Type 316 ESCC DSS ESCC
PoF | 1.0 CoFType Release! 1.E+00

Annual Failure probability

PoFLimit,Type 1.E-01
(log scale)

Code limit
1.E-02
PoF

1.E-03
PoF < 10-5 Corrosion
Allowance 1.E-04

New Time 1.E-05

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150
Corr Hole
Allw Code Risk Temp °C
limit Limit

FIGURE 9: Degradation Rate Model e.g. CO2 Corrosion FIGURE 10: Non-Rate PoF Model (External SCC)

4. CONCLUSION
Ǯ‡™‰‡‡”ƒ–‹‘ǯ•‘ˆ–™ƒ”‡Šƒ•„‡‡”‡˜iewed in this paper. The generic risk framework architecture
is a strength of Orbit 3 as it will allow easy development and support over the lifecycle of the product.
Orbit 3 includes comprehensive qualitative and quantitative RBI functionality, based on a DNV
Recommended Practice, which has been validated through a joint industry project. Orbit 3 has a modern
and user-friendly interface with features such as the asset hierarchy tree, the tabular grid view and
dynamic dialogues. The flexible workflow, the data defaulting mechanism and the capability to conduct
analysis at various level of detail and for different types of assets make a powerful tool which is suitable
for industry inspection planners as well as experienced RBI analysts.

ACKNOWLEDGEMENT
The authors are grateful to Det Norske Veritas for funding this development work.

REFERENCES
API RP 580, 2009. Risk-Based Inspection. API Recommended Practice 580, 2nd Edition, November 2009.
API RP 581, 2008. Risk-Based Inspection Technology. API Recommended Practice 581, 2nd Edition, September 2008.
DNV RP-G101. 2002. Recommended Practice DNV-RP-G101, Risk Based Inspection Of Offshore Topsides Static
Mechanical Equipment, January 2002.
DNV RP-G101. 2009. Recommended Practice DNV-RP-G101, Risk Based Inspection Of Offshore Topsides Static
Mechanical Equipment, 2nd edition, April 2009.
DNV, 2009. Orbit Offshore 2.4.2 User Manual.
Panzarella, C.H. and Zheng R.H., 2009. Overview of API RBI Technical Basis and Future Enhancements. API RBI
Software Users Group, June 2, 2009.
Topalis, P., Alajmi G.F, Teo Y.S, Sattar A., Zafar S., 2007. Implementation Of An Integrated Risk Based Inspection (RBI)
System For An Onshore Installation. ESOPE 2007, Paris, Sept 2007.

Page 704

View publication stats