a collaborative virtual workspace for disaster...

37
PhD Thesis Proposal A Collaborative Virtual Workspace for Disaster Management of Oil & Gas Offshore Structures Enio Emanuel Ramos Russo, Petrobras/PUC-Rio Supervisors: Marcelo Gattass, PUC-Rio Terrence Fernando, University of Salford

Upload: vodieu

Post on 26-Apr-2018

216 views

Category:

Documents


0 download

TRANSCRIPT

PhD Thesis Proposal

A Collaborative Virtual Workspace for Disaster Management of

Oil & Gas Offshore Structures

Enio Emanuel Ramos Russo, Petrobras/PUC-Rio

Supervisors:Marcelo Gattass, PUC-Rio

Terrence Fernando, University of Salford

Motivation

• Serious risks involved in running offshore units, with many reported disasters:– possibility of deaths;– important environmental impacts;– strong impact on business.

• The worst disasters:– Exxon Valdez oil tanker in Alaska in 1988 with

direct cleanup costs of 4 to 8 billions of dollars; – Piper Alpha oil platform in the North Sea in

1989 with 167 people killed.

Examples from Petrobras

• Two Major Accidents:– P-36 in 2001: the largest semi-submersible

platform in the world (40 story-high, 31,000 tons costing half a billion dollars) sunk, killing 11 employees and ceasing a daily production of 84,000 barrels of oil and 1.3 million cubic meters of natural gas;

– P-34 in 2002: a FPSO (Floating Production, Storage and Offloading) unit with a daily production of 35,000 barrels and a storage capacity of 58,000 m3 of oil, weighting 62,000 tons, had a stability problem and almost sunk, immediately ceasing its operation, requiring a huge investment to be restored.

Case Study 1: P-36Drawbacks: – no updated model of the platform;– no simulation models available;– no distributed system with

geographically distributed nodes;– the distributed specialists had to

be brought together and carried into the scene because they were not able to communicate adequately, causing a delay in the process;

– there was no appropriate environment for discussing and analyzing the scenario, allowing consensus building.

Petrobras identified:- the need for updated emergency procedures;- that the actions should occur in a short period of time in order to save the unit.

Flooding of column tanks

Modeling and simulation in two days

Case Study 2: P-34Step change due to the resolutions taken after the first major accident occurred with P-36: a second paradigm for reacting to emergency situations.

Available:– an updated model of the offshore unit;– a form of distributed working that did

help the rescue team to act quickly;– a static simulator that allowed the

specialists to run different simulations.

Lacking:- an adequate environment for different

teams to communicate to each other, which still caused the necessity to bring people together into the scene with some delay in the process and avoiding perfect interaction, simulation and discussing during the whole rescue operation;

- some of the information was not directly available to the decision makers, showing the necessity to strengthen the communication among the distributed teams.

Initial inclined position

Two days of work.

Case Study 2: P-34

Configuration after the flooding of tanks 3 and 4

(7o)

FinalConfiguration

(2.5o)

Evolution of Disaster ManagementFrom the above examples, we observe the need for going a step further and developing a third paradigm for reacting to emergency scenarios.

This paradigm should provide:– a good communication media among all the

participants in this emergency scenario;– that each participant node of this distributed

environment is able to communicate to each other, to make their own simulations and to share their results with the other participants;

– that each participant should have to access whatever data they need and to be able to discuss the results and the decisions to be taken in an adequate and easily usable workspace environment.

This indicates that:- virtual co-location could be a very useful feature of

this environment;- a robust and at the same time flexible communication

system is fundamental, also allowing eventual aggregation of some mobile experts to the existing network.

Actions Taken by Petrobras to Ensure Safety

• In 2000, Petrobras created the Environment Management and Operational Security Excellence Program (PEGASO), with an investment of 1.7 billion dollars and the development of 4,000 projects in 4 years.

• As a direct result of the P-36 accident in 2001, the inquiry commission recommended the implementation of another operational excellence program (PEO) specific for offshore production units.

Recommendations for Improving Disaster Management

• In terms of people, as part of the operational excellence program, the inquiry commission recognized the following needs :– to have sharper responsibility definitions;– to avoid delegating too many functions per

person.

ICT is proposed to be used as a way of efficiently connecting these distributed teams, supporting the decision making process .

Aim

• To investigate the development of a distributed workspace environment for supporting disaster management, involving distributedtechnical teams.

real oil spot

Objectives

• The aim of the thesis will be achieved through the following objectives:

– To conduct a survey:• to identify the requirements from the

stakeholders involved in a disaster scenario;• to analyze the most important distributed

systems as well as the commercial emergencysystems available.

– To design and build a distributed workspaceenvironment for the technical team to engagein the rescue efforts.

– To evaluate the usability and functionality ofthis environment for training and operationalpurposes.

Crisis Scenario

• Distributed nature of the teams:– the high level decision team at the operational unit;– a technical support team with naval engineers,

structural engineers, risers analysts and oceanographers at the headquarters in Rio, at the Business Unit and also at the research center, for example making some simulations;

– a task force group leading the decision process:• At the Business Unit (in Rio, if the platform is located in

Campos Basin) if the platform is not heavily damaged and two or three platform operators remain inside the unit and can perform the operations required;

• In a city which is the nearest place to the accident on earth (Macaé, if the platform is located in Campos Basin) from where orientation is given to divers, who do the only possible work when the unit is heavily damaged and has security problems;

– mobile experts, who sometimes are overseas or travelling and who must also be connected.

Crisis Scenario

• Added difficulty: offshore environment with

possible strong waves’, currents’ and winds’ forces.

ReferenceCenter for Num Sim

Accident

Operations’Local Command

CrisisManagement

Task Force

Mobile

Tech Supp

Mobile

Mobile

Distributed Nature

• Distributed nature of the resources :– access to simulation programs running on super-

computers or computer clusters;

– access to various databases of CAD models and simulation models (ex.: GIEN and INFOPAE databases);

– each site can have different configurations, such as VR Centres, an intranet desktop and a laptop connected to the network;

– experts who are travelling may have to be linked via mobile technologies;

– the connection between the unit and the people on earth may vary. In the best case, the unit is one node of the network, and, in the worst case, the communication with the operators can be done only by radio or telephone.

Scope

The thesis is focused on exploring

overall requirements

to support technical

teamsdistributed in

up to 6 nodes

running simulators which have access to simulation databases.

Crisis Information Management Software (CIMS)

Bringing all these groups of people together is a complex task due to the diverse and the distributed nature of the groups.

There are already some Crisis Information Management Software (CIMS) commercially available. They support the minimum requirements of the five major management activities of an incident:

• Command;• Operations;• Planning;• Logistics;• Finance/administration.

Crisis Information Management Software (CIMS)

Crisis Information Management Software (CIMS)

These CIMS software should:

• integrate with other systems, such as mapping, other CIMS, and telephonic alert notification systems;

• integrate public health into emergency management;

• operate within a variety of network configurations;

• have features consistent with the four phases of emergency management operations: planning, mitigation, response, and recovery;

• have help desk support available on a 24-hour, 7-day-per-week basis.

Crisis Information Management Software (CIMS)

The state-of-the-art commercial systems support or have:

• incident management as well as training and planning;

• strong capability of integration with internal databases and external systems;

• a flexible architecture in terms of networks and software integration;

• the basic requirements for emergency management, each one with a special emphasis: on modeling and simulation, or on response planning, or on resource planning or on accounting;

• the capability of logging and tracking activities and resources, important not only during a real emergency case but also as an efficient tool for training purposes;

• checklists as an efficient method to address the multiple simultaneous requirements present during an emergency scenario;

• interfaces to third party Geographic Information Systems (GIS) or GIS capabilities which are organic to the software;

• standards of operations.

Crisis Information Management Software (CIMS)

Crisis Information Management Software (CIMS)

The state-of-the-art commercial systems still don’t have:

• a fully and suitable integration of simulators with high performance visualisation systems;

• adequate security and access control features.

Conclusion:

• there is the need to build a system architecture capable of supporting these distributed resources, mainly distributed simulators running on high performance visualisation systems.

Conceptual Architectural Design

In face of all these requirements, there is the need of an efficient communication media to bring people together and so the use of ICT is proposed as a way of efficiently connecting these distributed teams.

Different approaches can be used to build this architecture, namely:

• Middleware: in this category enters CORBA, which is as open standard for communication between local and remote processes, and Grid Computing, which are coordinated computational resources not subject to centralized control;

• Distributed Virtual Environments: there are several specific systems developed to support networked virtual environments, such as DIVE, MASSIVE, DIVERSE, Avango, DEVA, COVISE, CAVERNsoft and VRJuggler, as well as specific architectures developed to facilitate the interoperability and composability of the broadest range of component-based simulations, such as the High Level Architecture (HLA);

• Web collaboration tools: typically employ a thin-client/server architecture model, such as IBM Websphere.

Conceptual Architectural Design

• Approach selected: Distributed Virtual Environment.

• The particular choice of a Distributed Virtual Environment and ofthe system architecture will depend on the specific requirementsand on the type of application being considered.

• It is observed that in the recent years many groups have beenspending huge efforts in order to define standards to this area,such as HLA, W3C, IETF and WSRF, with a general standard yet tobe defined. To adopt one of these standards as a base line insteadof developing a system from the scratch is strongly recommended.

Conceptual Architectural Design

• The HLA architecture seems suitable to many aspects of acollaborative workspace for disaster management of the oil & gasarea, except for the fact that it is mainly developed to have manynodes with precise real-time update, while in the oil & gas area thereare fewer nodes but with higher visualisation demands.

Conceptual Architectural Design: HLAWhat is the High Level Architecture?

The High Level Architecture (HLA) is a standard framework thatsupports simulations composed of different simulation components.

Why is the HLA needed?

Many complex simulations involve a combination of simulations ofseveral different types of system with other aspects of the totalenvironment to be simulated. Often simulations of some of thesecomponents already exist, having been developed for a differentpurpose, and they could be used in the new simulation:

- reusability: component simulation models can be reused indifferent simulation scenarios and applications;

- interoperability: reusable component simulations can becombined with other components without the need for re-coding.

Conceptual Architectural Design: HLAExample of the development of a new military aircraft and its weaponsystems which involves a great deal of simulation for differentpurposes and involving numerous different models:

- suppose that a new weapon system is to be installed into an existing aircraft, suchas the F-16 fighter;

- it would be beneficial not to have to develop a completely new simulation fromscratch;

- ideally one could reuse an existing F-16 simulation with new simulationcomponents representing the new weapon system and simulations of scenarios inwhich the new system would be deployed;

- for all of these components of the complete simulation to function together,possibly distributed over a number of computers of different kinds, they mustconform to a standard, which guarantees interoperability.

HLA was developed to respond to the need for a standard of this kind.

Conceptual Architectural Design

• The HLA architecture standard is not restricted to be used withDistributed VR systems.

• As the demand for integration of processes, systems and databaseswithin the company continuously grows, this is one of the approachesthat should be considered while defining integration solutions.

Conceptual Architectural Design

• In terms of architecture, from the Emergency Systems databases point of view, it seems recommended to adopt a Distributed Architecture, probably replicating external data in internal servers for reliability reasons (e.g., in case of a link fail).

• From the point of view of integrating specific simulators to high performance visualisation systems, the Distributed Architecture seems to be the best choice for the future.

• Nevertheless, by the time being, there are some issues, such as accessing huge data through the current real network, confidentiality and reliability, which don’t make it possible to have a fully distributed system, with possibly some replicated data along the network. The recommendation here is to at least develop self-sustained teams in terms of data and ICT requirements.

Research Methodology

The requirements gathering will be focused through Petrobras case studies P-34 and P-36. The idea then is to investigate in details this emergency scenario, mainly identifying the roles and attributes of all the people involved in the operation, as well as the procedures being executed, which is being done by means of structured interviews.

Research Methodology

• Once the user requirement capture phase is completed, the next step is to define the technical requirements in terms of collaboration models, simulation steering, personalized and global workspaces, synchronized viewing, video-streaming, etc.

•The intended collaborative workspace will need to have several distributed nodes with personalized interfaces which will represent various user perspectives.

•After analyzing the most important distributed systems available as well as the commercial emergency systems, these technical requirements will then be used to design and implement the system and to build the prototype environment.

Research Methodology

1. To analyze the problem to identify the user requirements.

2. To do a survey to analyze the most important distributed systems as well as the commercial emergency systems available -> HLA is chosen.

3. To develop an HLA-compliant instance to fit the problems’ requirements.

4. To develop a prototype as a proof of concept of this technology, with a specific design interface for the technical group. The prototype environment is expected to have 4 visual clients and 2 simulators (SSTAB and DYNASIM).

5. To evaluate this environment with one simple case study.

Stability of Floating Systems (SSTAB)

Bending

Shear

Light weight

Dead Weight

Total Weight

Buoyancy

Sstab Longitudinal Strength - Draft 18.06 Low KGLoad (ton/m)

X coord. (m)-1079

-860

-641

-422

-203

16

235

454

673

892

1111

-7 32 71 110 149 188 227 266 305 344 383

P-18

Theta1 Theta0

lw2 lw1GZ Area

Tunnel Test

GMt

GZ Arm Theta lim

P53_ESTAB_INT.SST Displ.=279073.1 Azim.=0.00 KG=12.26 Intact FS var. Draft 18.06 Low KG

Met

ers

Incl. angle (Degrees)

-5.3

-4.2

-3.1

-2.0

-0.9

0.2

1.3

2.4

3.5

4.6

5.6

-30.0 -20.0 -10.0 0.0 10.0 20.0 30.0 40.0 50.0 60.0

P-53

Dynamic Stability (DYNASIM)

Expected Contribution

• By carefully investigating the problem and gathering information from the experts of the oil & gas E & P area through structured interviews while identifying their roles, this work will give an insight into the distributed and complex environment of an oil & gas E & P emergency scenario.

• It will also help in analyzing the whole process.

Expected Contribution• It will represent a concrete

collaboration to a real industrialapplication, meeting robustcommunication requirements as wellas defining appropriate types ofworkspaces to handle these complexsituations.

• During the development of thisapplication, it will be investigated howthe users' perceptions and capabilitiesvary under extreme conditions.

• As a collateral effect of this work, itwill also be developed a good metricsof how to evaluate these perceptionsin both the real and the immersiveenvironments.

Expected Contribution

• As a result of its main aim, this work willcontribute in how can we use ICT todevelop a new software architecture tohelp people deal with emergencyscenarios in the oil & gas area and tosupport such decision-making process.

• We will then be capable to answer if wecan really use Distributed VR to supporta real emergency scenario problem.

Expected Contribution• It will design and implement a new paradigm of a flexible

architecture which will provide efficient communicationamong the geographically distributed participants ofthis scenario, while supporting multiple users'perspectives, personalized and intuitive interfaces, real-time performance and a high degree of usability.

• Finally, it will provide evaluation results of the prototypewithin real industrial settings.

• In summary:– We will not claim a new architecture, but rather

analyze a problem that have requirements andchoose a standard architecture that supports it.

– We will then develop a prototype as a proof ofconcept of this technology to be applied to a realworld scenario.

– Finally, we will make an evaluation of this prototypewhich will be the key of the thesis.

• Expected date of Thesis Presentation:March 2006.