migration to ids datanet · migration to ids datanet a guide on how the migration to ids datanet...

Migration to IDS DataNet

A guide on how the migration to IDS DataNet improves a business

1


2

Table of Contents

Table of Contents.......................................................................................................................................... 2

List of Figures ................................................................................................................................................ 5

Executive Summary....................................................................................................................................... 6

About IDS ...................................................................................................................................................... 6

Business Concepts..................................................................................................................................... 7

Functional Applications......................................................................................................................... 7

Minimising Manual Data Entry ............................................................................................................. 8

Business Support Around The Clock ..................................................................................................... 8

Commercial Considerations .......................................................................................................................... 8

Technical Considerations .............................................................................................................................. 9

Desktop Installation versus Web‐based Application ................................................................................ 9

Desktop Installation .............................................................................................................................. 9

Advantages for Desktop Installation................................................................................................. 9

Disadvantages for Desktop Installation ............................................................................................ 9

Web‐based Application.......................................................................................................................10

Advantages for Web‐based Application .........................................................................................10

Disadvantages for Web‐based Application.....................................................................................10

Hosting ....................................................................................................................................................11

IDS Hosted – Recommended ..............................................................................................................11

Client Hosted.......................................................................................................................................11

Connected versus Disconnected (Centralised versus Decentralised) Operations..................................12

Connected (Centralised) .....................................................................................................................12

Disconnected (Decentralised).............................................................................................................12

Network Configurations..........................................................................................................................12

DataNet hosted by IDS with Black Boxes............................................................................................12

DataNet Hosted by IDS Without Black Boxes .....................................................................................13

DataNet Hosted by Client With BlackBoxes........................................................................................14

DataNet Hosted by Client Without BlackBoxes ..................................................................................15

DataNet2 Database .................................................................................................................................16

Data Bridges ............................................................................................................................................16


3

DEPOT Configuration ..........................................................................................................................17

Import/Export Data.............................................................................................................................18

Import .............................................................................................................................................18

Export..............................................................................................................................................19

Software & Hardware Requirements......................................................................................................19

Client ...................................................................................................................................................19

Software..........................................................................................................................................19

Hardware ........................................................................................................................................19

Server ..................................................................................................................................................20

Software..........................................................................................................................................20

Hardware ........................................................................................................................................20

DBMS ..................................................................................................................................................20

Networking requirements................................................................................................................... 20

Impact Considerations ................................................................................................................................21

Customisations........................................................................................................................................21

Reporting Uses ........................................................................................................................................21

Retained Knowledge ...........................................................................................................................21

Post Well Analysis ...............................................................................................................................21

Compliance and Administration .........................................................................................................21

Migration.................................................................................................................................................21

Timeline ..............................................................................................................................................21

Larger Scale Timeline ......................................................................................................................22

Smaller Scale Timeline ....................................................................................................................22

Loss of Productivity.............................................................................................................................22

Data Outcome (Legacy)....................................................................................................................... 23

Security ...............................................................................................................................................23

System.............................................................................................................................................23

Users ...............................................................................................................................................23

Resilience to Failure............................................................................................................................23

Client Failure Packages ...................................................................................................................24

Data Backup ....................................................................................................................................24

Network Resilience .........................................................................................................................24


4

Deployment ........................................................................................................................................25

Post Installation ..................................................................................................................................25

Case Studies ................................................................................................................................................25

Preparation .............................................................................................................................................26

Database Conversion ..............................................................................................................................27

Feature Comparison................................................................................................................................29

Module Customisation............................................................................................................................31

Report Customisation .............................................................................................................................33

Rollout.....................................................................................................................................................35

Glossary.......................................................................................................................................................37


5

List of Figures

Figure 1: DataNet Hosted by IDS with Black Boxes.....................................................................................13

Figure 2: DataNet Hosted by IDS Without BlackBoxes ...............................................................................14

Figure 3: DataNet Hosted by Client With BlackBoxes.................................................................................15

Figure 4: DataNet Hosted by Client Without BlackBoxes ...........................................................................16

Figure 5: DEPOT Configuration ...................................................................................................................18

Figure 6: Conversion Process ......................................................................................................................26

Figure 7: Preparation ..................................................................................................................................27

Figure 8: Database Conversion ...................................................................................................................28

Figure 9: Feature Conversion......................................................................................................................30

Figure 10: Module Customisation...............................................................................................................32

Figure 11: Report Customisation ................................................................................................................34

Figure 12: Rollout........................................................................................................................................36


6

Executive Summary

This document explains the advantages and processes for migrating to the IDS DataNet 2 (D2) application. Here are a few advantages for using the IDS suite applications:

Minimises manual data entry – our applications reduce the need for end‐user manual data entry while maximising the knowledge that must be captured.

Uses web services – our applications replicate on the web using web services what our competitors offer as a local install. This structure works in both an internet environment and an intranet environment (with a local database).

Client specified customisations – our applications interface and reports adjust according to the needs of our clients.

Converts and merges multiple databases – our applications converts multiple databases into a single database.

Minimal hardware investment – our applications run using web services and only require nominal server hardware.

No licensing fees – our applications require no individualised licenses because each uses web logins.

Improves workflow – our applications allow users to save time in all phases or report creation and publication.

Centralises data storage – our applications store data in a central location that IDS backs up regularly and recovers when necessary.

Imports and Exports data – our applications import and export data in several formats.

Utilises data bridges – our applications use data bridges to work with other repositories, such as WITSML, DEPOT, SQL Views, etc.

Today’s technology allows more competition between software providers and service providers. For example, there are standards such as size, connections, etc. that allow the use of downhole tools from different manufacturers. This same standards concept makes it possible to use software from different service providers for upstream reporting and data management.

About IDS

Solely owned by our founding directors, company began operations in 1995 in Adelaide, Australia.

In February 1996, IDS commenced a contract for the 'Drilling Data Package' with our first major client. Still a client to this day, our first client uses our products on every one of their Australian and international drilling campaigns; which amounts to over 3,500 onshore and offshore wells over the last twelve years. Also, we have serviced over 100 clients globally. We retain 95% of our original clients;


7

although, not all are operational. Our particular expertise resides in converging data from widely dispersed assets into a single, global database.

In December 2006, a complete system rewrite commenced making full use of Web 2.0‐compliant technologies and WITSML feeds to capture and deliver data while minimising manual data entry. IDS integrated all the experience and feedback obtained over the previous decade, enabling ‘DataNet2’ to transform upstream reporting and data management.

Covering the full lifecycle of the well and backed up with world class 24/7 support, DataNet2 divides into three broad categories of service that share a common database:

Exploration and Production (DrillNet, GeoNet, ProNet, CostNet and SafeNet);

Supply Chain Management (StockNet, TrackNet and CostNet) and;

Data Visualisation and Knowledge Management (VisNet)

Most significantly, DataNet2 now shares data with all WITSML compliant service companies and operators. In turn, this means that we can build much of the DDR and DGR directly from WITSML sources – an industry first and a very valuable time saver at the rig site.

With the eight (8) distinct product lines built on a 'Rich Internet Application' platform, run each of the DataNet2 applications on a standalone basis or as part of a fully integrated suite of reporting services. We deliver the entire package reliably and securely across the web to any web‐enabled device, anywhere, anytime.

Business Concepts IDS focuses its business concepts on three (3) scopes:

Functional Applications

Minimising Manual Data Entry

Business Support Around the Clock

Functional Applications

Our Research and Development teams cater to different oilfield lifecycles. The lifecycle generally follows this flow:

Conceptual – Products used for planning , such as CostNet

Site Preparation – Products used for preparing , such as SiteNet, CostNet, and SafeNet

Development – Products used for growth and improvement, such DrillNet, GeoNet, CostNet and SafeNet

Completion – Products used for conclusion, such as ProNet and SafeNet

Production – Products used for the downstream production cycle (not applicable at this time)

Abandonment – Products used for finishing a well, standard‐setting strategies, such as SiteNet


8

Minimising Manual Data Entry

One of the biggest challenges facing the providers of reporting services is to reduce the requirement for end‐user manual data entry while maximising the knowledge that must be captured. By focusing its efforts on collaborative data entry, sourcing data from WITSML repositories and a simple, fast‐loading user interface, IDS keeps the time required to build a report to the absolute minimum.

Business Support Around The Clock

IDS prides itself on being a service provider, not a software house. We supply only one level of service – a superior service standard. Working around the clock, our Client Support team strives to provide continuous excellence in the delivery of service and product support. The team is available 24 hours a day, 365 days a year with various communication methods, such as email, mobile, Skype and desktop sharing. The team even provides Site visits, when necessary.

We currently have two support teams

Help Desk ‐ whose members perform the following functions:

Acts as an interface between the clients and the support architecture

Helps users in general issues, such as answering usability questions including "how do I..." and "where do I..."

Handles basic administrative tasks for the users, such as adding new users

Documents support issues from phones and e‐mail, along with addressing and tracking escalated issues as the move through the support system

Technical Support ‐ whose members perform the following functions:

Acts as a junior team under the programming team

Works on UI customisation, such as screens and reports

Performs basic programming tasks

Maintains a training team which can be deployed to do on‐site training

Handles deployment for new sites

Conducts patch management and roll‐ups

Our Helpdesk and Technical support team members all communicate in English. IDS employees perform all support and consulting work.

Commercial Considerations

IDS supplies individualised budgetary proposals for detailed cost analysis. We utilise a usage based model with no charges for consulting.


9

Technical Considerations

The technical considerations involved in using DataNet2 require the addressing of several aspects. IDS software replicates – on the web using ‘web2’ web services – what our competitors offer as a local install.

Desktop Installation versus Webbased Application There are several advantages to using a web‐based application as opposed to a desktop installed application.

Desktop Installation

Desktop installations are the traditional method for distributing applications. This method allows for the following advantages and disadvantages.

Advantages for Desktop Installation

The advantages for using a desktop installation are familiar. Most clients and individuals use desktop installed applications every day. Here are a couple of additional advantages for using desktop installations:

Responsiveness

Dispersed installations on multiple systems, such as notebooks

Disadvantages for Desktop Installation

The disadvantages for using a desktop installation are also familiar. Most clients and individuals recognise that if the computer crashes, the applications and data are lost unless backed up previously. Here are additional disadvantages for using desktop installations:

Requires the local installation of the software

Requires licensing management

Requires copyright protection, such as dongles, dedicated security keys, etc.

Implementation on a large scale distributed system is difficult

Synchronising changes is complicated

High risk

Change of notebooks or stolen notebook means total loss of asset

Troubleshooting is difficult

Shared/common library level conflicts

Higher cost of ownership (due to license management, additional notebook purchases, etc.)

Security


10

Loss of notebook means loss of data and application license

User management – Specifying the user roles and user access to specific modules of the application when using a centralised database.

Webbased Application

Web‐based applications are the new method of distribution. This method allows for the following advantages and disadvantages.

Advantages for Webbased Application

The advantages for using a web‐based application are familiar, but unrecognised. Most clients and individuals use web‐based applications every day but do not realise it. For example, they use internet browsers to search the internet. Most individuals use (or at least or familiar with using) a web‐ based email client when checking email offsite. Here are a few additional advantages for using web‐based applications:

Allows for use anywhere (with Internet connectivity)

Connect either directly through the web or through a controlled access environment such as a Virtual Private Network (VPN).

Easily Distributed

No proprietary installation of software on the local computer

Controlled centralised storage

Backup and business recovery performed by focused specialist (not general IT staff with multi‐tier support contracts)

Near real‐time data manipulation to reduce synchronisation issues

Lower cost of ownership

Disadvantages for Webbased Application

The disadvantages for using a web‐based application are also familiar. Most individuals realise that without internet connection the web‐based applications are not functional. Here are a couple of additional disadvantages for using web‐based applications:

Requires an IP connection to the server –Deploys in both an internet environment and an intranet environment.

Internet environment – uses the internet browser for secured https:// access to the IDS applications. Many use the availability of worldwide and widespread internet hotspots.

Intranet environment – uses the internet browser http:// access without the necessity of an actual internet connection.

Requires security including the following:

User management – Specifying the user roles and user access to specific modules of the application.


11

Password management – Each user requires a password that they may be compelled to change after a specified number of days or months.

Hosting Hosting of IDS DataNet2 services requires external or internal hosting. Here are the characteristics of both.

IDS Hosted – Recommended

IDS recommends allowing the hosting of the IDS DataNet2 in our data centres. Here are several reasons for using the IDS hosted mode of operation:

Response to Issues – The speed that IDS responds to a request or an issue increases when using the IDS hosted mode. This gives us the ability to underwrite the reliability of the service by proposing a very high quality Service Level Agreement (SLA) in terms of turn‐around time.

24 hour call centre ‐ We provide hands‐on support throughout the day. Typically, the product is mainly used during non‐standard office hours and most owners/operators do not have a 24 hour IT help‐desk capable of providing systems level support.

Maintaining Quality Backup Quality – We maintain a near line, near site and off‐site backup train running constantly in the background.

Ability to assist the user directly – We use our help desk to review the same application and data together with the user.

Customisable security – We offer more security from an Internet based password protected secure access to an IP controlled VPN only access.

Client Hosted

In a client hosted environment, IDS is not responsible for the daily operations of the server and daily tuning of the service. We encourage the stakeholders to allow us a fundamental access to our application to ensure an adequate SLA can be carried out for our services.

In a client hosted solution, the client chooses the hosting system. This includes the hardware and operating system that will run our application. IDS provides a recommended hosting system specification; however, ultimately the decision will be based on IDS' minimum requirement and the client's operating specification. For example, if the client has a policy that only Oracle and Windows Server 2003 can be used in their environment, IDS' application will be tuned to run on this chosen database and operating system.

System support responsiveness from IDS greatly depends on the level of access the client's IT department provides us. Patch management and change control will be provided from the perspective of client's IT department. This can cause extra time for the client’s IT department to understand the request which has been communicated directly between the users and IDS. Such delays will be expected and communicated to the users prior to start of operations.


12

Connected versus Disconnected (Centralised versus Decentralised) Operations IDS recommends using a connected (or centralised) mode of operation when possible. However, we realise that most rigs work in frontier zones that are possibly technologically restricted.

Connected (Centralised)

The main advantage of using a connected mode of operations lies in the simplicity of the configuration and logistics. Basing customisations and migrations on a standard speeds up the migration process and allows for less time for implementation.

Disconnected (Decentralised)

IDS provides a ‘blackbox’ (in reality, an IDS network appliance resembling a ruggedised laptop) to the wellsite to run the DataNet2 software locally. This equipment acts as a local rig side server. This means users on the rig do not have to rely on the consistency of satellite connectivity to perform their daily duties. The blackbox communicates with the main server when connectivity is available to synchronise the data "between rig and town". Exports can be submitted at any time to the web via file transfer (typically ~30k file size), no matter the line quality. In this scenario, be aware of the responsibility for the movement of leased assets from IDS to the remote rigs and vice versa.

Network Configurations The following diagrams the different network configurations available when using the DataNet2 services.

DataNet hosted by IDS with Black Boxes

This configuration recommended by IDS uses the internet and includes the following:

Client Rig Network – IDS VPN tunnel from IDS BlackBox to IDS VPN network. Client computers & laptop accessing IDS DataNet server URL

IDS VPN Network

Client Town Office Network – Client computers & laptops accessing IDS DataNet URL and/or Rig’s BlackBox URL


Figure 1: DataNet Hosted by IDS with Black Boxes

DataNet Hosted by IDS Without Black Boxes

This configuration also recommended by IDS uses the internet and includes the following:

Client Rig Network – Client laptops accessing IDS Datanet server URL

IDS VPN Network

Client Town Office Network – Client computers & laptop accessing IDS Datanet server URL

13


Figure 2: DataNet Hosted by IDS Without BlackBoxes

DataNet Hosted by Client With BlackBoxes

This configuration uses the internet and includes the following:

Client Rig Network – IDS VPN tunnel from IDS BlackBox to IDS VPN network. Client laptops accessing rig’s blackbox local URL

IDS VPN Network

Client Town Office Network – IDS VPN tunnel from Client Datanet server to IDS VPN network. Client computers & laptops accessing Client DataNet site URL and/or Rig’s BlackBox URL

14


Figure 3: DataNet Hosted by Client With BlackBoxes

DataNet Hosted by Client Without BlackBoxes

This configuration uses the internet and includes the following:

Client Rig Network – Client laptops accessing Client DataNet server URL

IDS VPN Network

Client Town Office Network – IDS VPN tunnel from Client DataNet server to IDS VPN network. Client computers & laptop accessing Client DataNet server URL

15


Figure 4: DataNet Hosted by Client Without BlackBoxes

DataNet2 Database IDS DataNet is database agnostic and non‐specific. The IDS products favour no particular brand of RDBMS. The majority of installations out in the field uses MySQL due to its simplicity to manage. However, we have witnessed clients implementing the system to their internal RDBMS and MSSQL. We tested the technology stack with Oracle, MSSQL, MySQL, SyBASE, Informix etc.

Data Bridges Our data bridges work with other repositories, WITSML, DEPOT, SQL Views, etc. On the providing side (export), we perform field‐to‐field mapping. Using this method means that internal changes do not affect the final result. On the receiving side (import), we use the correct client supplied format.

The Field to field mapping strategy is the following: <field name="abc" ids="idsFieldAbc" />

Data Exchange Point of Transfer (DEPOT) bridges any third‐party standard format and IDS internal format by using an interface in between. DEPOT transforms any third party standard into IDS and vice versa.

16


17

DEPOT maintains a public interface that uses HTTP Post as the transport layer. We believe most solution providers should be able to support this approach as this is the most fundamental implementation of a Web Service. As long as both parties (IDS and third party) maintain a mutual agreement on the standard format of data transfer, the field mapping can be done very quickly. The core engine caters to different types of scenarios and handlings. Figuring out the third party structure and fitting its structure into the DataNet2 structure is the final step of the bridging process.

Our core engine named DataNet2 (D2) works with the DEPOT to allow data bridges. Every application that we develop uses this core engine, including the daily drilling report software. Therefore, all applications work with the DEPOT.

Here are a few drilling standards:

WITSML (http://www.witsml.org/witsml/Default.asp)

NPD (http://www.ptil.no/forms/drilling‐reporting‐ddrs‐to‐the‐authorities‐article5177‐415.html),

CAODC.ETS (http://www.caodc.ca/ETS/)

ISO15926

Custom formats for a specific use.

DEPOT Configuration

The following diagram shows the DEPOT configuration and its relationship to DataNet2.

http://www.witsml.org/witsml/Default.asp

http://www.ptil.no/forms/drilling-reporting-ddrs-to-the-authorities-article5177-415.html

http://www.caodc.ca/ETS/


Figure 5: DEPOT Configuration

Import/Export Data

After receiving the well data, manipulation and analysis of the data by the client is critical. Importing and exporting data allows the client to use the collected data in different manners.

Import

Import data using one of the three (3) methods listed below:

CSV – Import data into a number of screens in DrillNet. This allows data to be directly copied from a spreadsheet package, such as MS Excel, and pasted into an import window.

WITSML – DataNet2 uses WITSML to import and export data.

XML – DataNet2 imports and exports data for days or complete wells. Import data from other applications if the export type is in an XML format and the XSD (schema) is available.

18


19

In some instances additional development may be required to import XML formatted data. For example, if historical data is formatted in an XML format and no XSD (schema) is available, then additional development is required for these records to be imported into DataNet2. This type of additional development may be chargeable to the client.

Export

Export data from DataNet2 in our own custom XML format. Clients can manipulate this data spanning from a single day to an entire well.

DataNet2 publishes web services and allows access to data using W3C standard web services. This allows interfacing with other application; this extension facility provides a good entry point for integrating application. Specific communication between the applications would require an analysis of the requirements from the client and additional time to develop the application code. We recommend that any extension point be primarily developed with or by IDS.

Software & Hardware Requirements The software and hardware requirements for the IDS applications are fairly standard and do not require any specialised applications. Below are listed a few items that allow the IDS applications to run at optimum performance on both the client and server sides.

Client

The client systems require fairly standard and easy to acquire software and hardware components. The following discusses a few of the necessary items.

Software

Here are the client software system requirements:

Windows XP SP3 with Internet Explorer 7 or higher Note: IDS recommends using the approved corporate browser. However, IDS applications also work with popular browsers, such Google Chrome 3.0 and Mozilla Firefox 3.5.

Adobe Reader 9 browser plug‐in

Adobe Flash 10 plug‐in

Hardware

Here are the client hardware requirements:

1.6Ghz class processor

1GB RAM

60GB Hard Drive Space


20

Server

The server systems require a mix of commercial and open sourced software. The hardware requirements are fairly standard and easy to acquire software. The following discusses a few of the necessary items.

Software

Here are the server system requirements:

Java 1.5 minimum (http://www.java.com/en/)

Tomcat 5.5 minimum (http://tomcat.apache.org/)

Spring Framework2.07 (http://www.springsource.com/products/enterprise)

Hibernate 3.2 (https://www.hibernate.org/)

Lucene 2.3.2 (http://lucene.apache.org/java/docs/)

Hardware

Here are the server hardware requirements:

3Ghz Xeon class processor

4GB RAM

RAID 5+180GB drive array (80GB Free space)

Proxy access enabled

DBMS

Application is database non‐specific. Will work with:

MySQL

MSSQL

Oracle

SyBase

Informix

other RDBMS with JDBC connectors

Networking requirements

IP connectivity

Port 80 or 443 (SSL) access

http://www.java.com/en/

http://tomcat.apache.org/

http://www.springsource.com/products/enterprise

https://www.hibernate.org/

http://lucene.apache.org/java/docs/


21

Impact Considerations

Customisations IDS prides itself on the ability to customise its reporting package to fit in with a company’s current layout and setup. All changes requested by a client are first applied to a Staging site to ensure it does not adversely affect the system and once approved, settings are added to allow these features to be switched on/off.

Reporting Uses IDS creates a useful reporting system that has several advantages.

Retained Knowledge

A reporting system captures all the current operational knowledge on a day‐to‐day basis, stores it in a relational database and keeps it current and available for all users. It is a well established fact that more than 90% of upstream data is no longer available to the end users within 3 to 6 months of it being generated. Only IDS offers a guarantee of seven years on‐line access (100% availability) from date of last entry of data.

Post Well Analysis

Using coded activity information and built‐in analysis and visualisation tools, lost time and inefficient practices can be both identified and evaluated. Moreover, multiwell analysis enables the user to identify best practices and apply them at the planning stage of the next well.

Compliance and Administration

Government and partner reporting requirements can be handled directly from the reporting system via secure portals.

Migration The migration process involves building a relationship between IDS and the client. The client is an integral part of the migration by verifying that all required components are as specified.

Timeline

The exact timeline required to properly implement the IDS system depends on many factors. Here are a few of the factors impacting the timeline:

Size of the operation – The number of people involved in the operation and the amount of data necessary to convert for use with the IDS applications.

Breadth of operations – The scope of the company’s operations, including the different worldwide operation centres.

Variance between business units – The differences between the way different business units use the current systems.


22

Level of customisation desired – The amount of changes to the IDS application to meet client criteria.

Scope of products to be implemented – The number of IDS applications to be put into service.

Availability of client side resources – The number of client personnel available to work with IDS on the migration process.

Larger Scale Timeline

When working with a global company with business units across multiple continents, we schedule about two months worth of preparation time. We follow this with six months of an incremental site‐by‐site rollout. However, this may vary given the level of operations at the time of the scheduled rollout. We consider the following when scheduling timelines:

Rig schedules

Programs of individual business units

Important dates

Even with this typical timeline, we work with the client to drastically shorten this span given the right environment and requirements.

Smaller Scale Timeline

When working with a regional company with business units across one area, we schedule about one ‐ two weeks worth of preparation time. We follow this with a site rollout. Ideally, we can have IDS applications up and running in less than one month given the level of operations and required customisations at the time of the scheduled rollout.

Loss of Productivity

With a properly scheduled implementation process, and the correct number of resources applied on both sides, there is typically little disruption to the actual drilling operations. It is essential that resources are made available to IDS to assist with the necessary customisation and quality checking of the site prior to rollout.

Converting legacy data from an old system to the IDS system does take a period of time (usually up to 6 weeks). During this period, it is possible that all data is not available in one system; however, ongoing operations are never affected. Upon completion of the legacy data conversion, not only will current data entered into the IDS system be available for analysis and mining, but also all legacy data will be available in the IDS system.

Typically, there is no loss of productivity during the migration to our system. All work is performed by the IDS team behind the scenes. The client typically starts using our system and we migrate the data after start of use. The only impact to the client is that the data will not be available to the new system for approximately 6 weeks. It takes this amount of time to transfer the data across to the new database; however, all current operations will continue unaffected.


23

Data Outcome (Legacy)

IDS transfers the legacy data to the new database using a legacy data conversion script. The length of time for the database is based on the condition of the legacy data and the ability of the client to perform quality control on the data.

Security

There are two sections of security. Each section uses a strict security protocol.

System

IDS software has a global contract with NTT of Japan and co‐locates its servers in secure NTT data centres at key locations around the world. We maintain dedicated racks in Singapore NTT, Australia NTT and Navigata Canada to host our servers.

In the Data Centres, our servers run the 32‐bit Linux OS Centos 4.7 release. Our local network hosting site (network within the rack/cage) keeps two (2) gateway servers installed with a host based firewall (iptables) and a reverse proxy (apache). These protect our data from unauthorised intrusions. It also grants connection access to the internet for our servers on various local networks.

The Data Centres use the monitoring system named Zabbix (http://www.zabbix.com), an enterprise‐class open source distributed monitoring solution for checking on server availability, server usage, server services and performance monitoring. The Data Centres also use the monitoring system named Multi Router Traffic Grapher ‐ MRTG (http://oss.oetiker.ch/mrtg) for monitoring Internet links.

Users

At the individual user level, DataNet2 has a sophisticated access control model. A user can be assigned to a group with very specific rights, in fact, right down to a single screen or a report.

Here are a few of the user related security criteria available for use on any site:

Password expiration

Login tracking – with weekly reporting on all accounts that accessed the system

Account locking after a specified number of failed attempts

Restricted user accounts

Blocking (or only allowing) certain IP addresses/ranges

Secured Hypertext Transfer Protocol Secure (HTTPS) use

Resilience to Failure

We employ a technology mixture of system frameworks and hardware to resist system failures. The Virtualisation technology allows physical servers to be converted into files. This means there is no longer a need for the physical hardware server because the server is now a file. This file is run by a "host" which then builds a virtual machine within a machine. So, this allows multiple machines to be run within a single machine.

http://www.zabbix.com/

http://oss.oetiker.ch/mrtg


24

Because the server is contained in a file, it can be stored in a common file server (common storage). We operate two VM host (two bodies) running separate VM files. If one VM host stops working, the VM files which were running on the dead VM Host can be moved to the live VM host. The files are "initiated" or "booted" and the virtual machine is revived.

Here is a list of the technology in use:

VMWare High Availability package (system framework)

Redundant servers (VM Hosts) (hardware)

Fault resilient common storage (RAID 5+1) (hardware)

Client Failure Packages

We offer two types of packages for resilience to failure. The packages are High Availability and Fault Tolerance. The Fault Tolerance is the client premium package option.

In High Availability, in the event of a server failure, we boot up the redundant server and the application restarts at the last saved data point. The only data loss is data in‐transit, such as forms users have not committed to saving.

In Fault Tolerance, in the event of a server failure, the redundant server takes over immediately. In most cases, the user does not realise that the server went down.

Data Backup

We backup the data several ways to maintain a high‐level of availability to our clients. Data backup occurs on multiple levels:

RAID 5+1, we have an array of 8 high capacity drives with 6 active, one parity and one "hot spare" to ensure that the data is resilient to hard disk failures

Application data is further backed up to a near line store

Once a day the near line store is sent back to our central back‐up centre

Network Resilience

We work with our clients in all aspects to maintain network connectivity. Here are the multiple points for Internet connectivity:

1. User's local network

2. User's WAN (satellite link, VPN etc)

3. User's Internet Service Provider

4. ISP peer network (including physical damage of connectivity)

5. IDS Hosting site upstream ISP

6. IDS Hosting site ISP

7. IDS Hosting site network (network within the room of our hosting site)


25

8. IDS hosting site local network (network within the rack/cage)

We work with the client to help troubleshoot items 1‐ 3.

We use our hosting sites service level agreements (SLAs) to work on items #5 – 7. Our hosting company maintains resilient links with different physical upstream providers.

We use remote hands facilities to mitigate item #8. For resilience, we utitlise multiple network switches that are available to switch over manually, when necessary.

Deployment

The number of customisations and operations are the only variances that would affect this process.

IDS town hosted sites require no deployment effort on behalf of the client, as IDS hosts the software for the client and all that is required to access the software is a internet connection and web browser. For offshore installations, IDS provides a rig server aka ‘Blackbox’ with the software preinstalled. This is small enough to be hand carried and would only require network configuration and can also be handled by IDS before deployment. IDS works with the client's IT department to set this up prior to deployment of the Black box; therefore, no IDS personnel is required to visit the rig to implement this solution.

IDS builds a site which is customised with the client’s requirements. As mentioned above, the exact timing for this process is dependent on a number of factors, but experience has shown that the first operations can be brought across to the IDS system within two (2) months. An IDS Business Development Management (BDM) meets with the client to start the process of scheduling the rollout and will be better positioned to provide a time estimate after that.

IDS fully tests the site before handing it over for review. Our personnel works with the client to provide assistance with the rollout as well as ongoing support and upgrades. This ensures that the system grows with the organisation, and we continue to assist with the client’s reporting needs.

Post Installation

Post installation the system goes a technical review to cover such things as technical impact, sustainability, usability, etc. Here are few possible post installation occurrences:

Data Migration – IDS receives archived data from competitor systems (in the event of an acquisition of a new well or company) and maps the data field‐to‐field to work with DataNet2.

Specific programming needs – Specifications from the client outline the necessary programming to add client specific features.

System Training – IDS technical support team provides on and off site training for the IDS applications.

Case Studies

In a recent migration installation, IDS converted a world wide client from the Peloton system to the IDS DataNet2. We were able to convert a multi‐region worldwide database to our system. We worked with


the client to determine database conversion, reports customisations, feature comparisons and module customisations.

Migration involves approximately six segments for a successful completion.

Preparation

Database Conversion

Feature Comparison

Module Customisation

Report Customisation

Rollout

Figure 6: Conversion Process

Within each section, multiple steps require the attention of the client and IDS project team.

Preparation During the preparation, the Business Development Manager (BDM) works with the client to prepare for the migration. This step in the process allows the client and IDS to come to an appropriate timeline in the migration. Both sides are able to negotiate on how best to handle the migration. Typically, the following steps are performed:

1. BDM checks with Client for Best Timeline.

2. BDM receives implementation schedule.

3. Project Team evaluates available resources.

4. BDM informs client of proposed conversion schedule.

5. BDM receives client go ahead.

26


BDM checks with Client for Best Timeline

Project Team evaluates available resources

BDM informs client of

proposed schedule

Receive Client Go Ahead

BDM receives implementation

schedule

Figure 7: Preparation

Database Conversion During the database conversion, IDS and the client work together to verify that the proper field‐to‐field mapping occurs. This step in the process allows the client and IDS to verify that proper data mapping occurs as needed. This also gives the IDS and the client a chance to quality check the process. Typically, the following steps are performed:

1. BDM receives 3rd Party Database – Business Development Manager receives the database from the client that will be converted for use with the IDS applications.

2. Project Team evaluates – Project team evaluates the supplied database to allocate the necessary resources.

3. Support Team implements – Support team modifies the current database and tries to mirror the client database specifications.

4. IDS QC – IDS teams verifies the database conversions are complete and the mapped changes work correctly.

27


5. Client QC – Client team verifies the database conversions are complete and the mapped changes work correctly. Note: IDS checks that the data received is the same as the data in the IDS fields. However, IDS does not check the quality and accuracy of the data.

BDM receives 3rd Party Database

Write Conversion

Macro

Run Conversion

Macro

IDS QC

Is the Database Conversion

Correct?

Yes

Client QC

No

Is the Database Conversion

Correct?

Yes

No

Yes

Receive Signoff

Figure 8: Database Conversion

28


29

Feature Comparison During the feature conversion, IDS and the client work together to verify that the necessary features are customised or developed as specified by the client. This step in the process allows the client and IDS to designate necessary features and eliminate extraneous features to create a more useful and streamlined application. This also gives the IDS and the client a chance to quality check the process. Typically, the following steps are performed:

1. BDM receives Featured Comparisons – Business Development Manager receives the feature comparison report specifications from the client.

2. Project Team evaluates – Project team evaluates the supplied feature comparison report to determine the level of complexity involved.

a. Simple complexity goes straight to next step.

b. Low risk complexity goes to System Analyst evaluation.

1. System analyst writes specifications and goes to next step.

c. High complexity goes to System Analyst evaluation.

1. System analyst writes specifications.

2. Development team implements features change.

3. System analyst reviews changes to specifications and goes to next step.

3. Support Team implements – Support team modifies the current features and tries to mirror the client feature comparisons specifications.

4. IDS QC – IDS teams verifies the feature comparisons are complete and the feature changes work correctly.

5. Client QC – IDS teams verifies the feature comparisons are complete and the feature changes work correctly.


Figure 9: Feature Conversion

30


31

Module Customisation During the module customisation, IDS and the client work together to verify that the necessary modules are customised or developed as specified by the client. This step in the process allows the client and IDS to designate necessary module customisations and eliminate extraneous fields to create a more useful and streamlined application. This also gives the IDS and the client a chance to quality check the process. Typically, the following steps are performed:

1. BDM receives Module Customisations – Business Development Manager receives the identified module customisations from the client.

2. Project Team evaluates – Project team evaluates the supplied module customisations and determines whether this is a module customisation or a feature conversion.

a. Module customisation goes straight to next step.

b. Feature customisation goes to the Feature conversion flow chart.

3. Support Team implements – Support team modifies the current module customisation and tries to mirror the client module customisation specifications.

4. IDS QC – IDS teams verifies the module customisations are complete and the module changes work correctly.

5. Client QC – IDS teams verifies the module customisations are complete and the module changes work correctly.


Figure 10: Module Customisation

32


33

Report Customisation During the report customisation, IDS and the client work together to verify that the necessary reports attributes are customised as specified by the client. This step in the process allows the client and IDS to designate necessary report customisations and eliminate extraneous attributes to create a more useful and streamlined report. This also gives the IDS and the client a chance to quality check the process. Typically, the following steps are performed:

1. BDM received Report Template – Business Development Manager receives the client report specification in a report template format.

2. Project Team evaluates – Project team evaluates the supplied report template to allocate the necessary resources.

3. Support Team implements – Support team modifies the report template to mirror the client specifications.

4. IDS QC – IDS teams verifies the requested modifications are complete and the changes work correctly.

5. Client QC – Client team verifies the requested modifications are complete and the changes work correctly.


BDM receives Report

Template from Client

Project Team evaluates

Report Template

Support Team

implements Report

Template

IDS QC

Is the Report Template Correct?

Yes

Client QC

No

Is the Report Template Correct?

Yes

No

Yes

Receive Signoff

Figure 11: Report Customisation

34


35

Rollout During the rollout, the Business Development Manager and the client perform the following steps:

IDS and the client work together to rollout the finished customised applications and converted database. This step in the process allows the client and IDS to fully test the system using the client infrastructure. This also gives the IDS and the client a chance to quality check the entire application in working mode. Typically, the following steps are performed:

1. System Leaves Staging Site – The fully tested site leaves the staging area to the client site.

2. System Wide Acceptance Testing – System testing performs in the client native environment.

3. Non‐critical Well Data Testing – System testing performs on real archived well data. This test works over a client specified timeframe.

4. Simultaneous Live Operation Testing – System use on one well while simultaneously using another system to compare results.

5. Pilot Testing on one Rig Operation – System use on one rig to verify proper operations.

6. Rollout & Implementation – Rollout the system to client for implementation on all of its wells & rigs at its discretion.


Figure 12: Rollout

36


37

Glossary

VM A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. (http://en.wikipedia.org/wiki/Virtual_machine)

OS An operating system (OS) is the software that manages the hardware and software of a computer system.

DEPOT Data Exchange Point of Transfer (DEPOT) bridges any third‐party standard format and IDS internal format by using an interface in between.

RDBMS A relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model. (http://en.wikipedia.org/wiki/Relational_database_management_system)

IP The Internet Protocol (IP) is a protocol used for communicating data across a packet‐switched internetwork using the Internet Protocol Suite, also referred to as TCP/IP. (http://en.wikipedia.org/wiki/Internet_Protocol)

D2 The second generation of the IDS world leading ‘DataNet’ web‐delivered reporting and analysis services system. (http://www.idsdatanet.com/)

SLA A service level agreement (SLA) is a part of a service contract where the level of service is formally defined. (http://en.wikipedia.org/wiki/Service_level_agreement)

BDM The Business Development Manager (BDM) works one‐on‐one with the client to ensure a timely and successive migration.

http://en.wikipedia.org/wiki/Virtual_machine

http://en.wikipedia.org/wiki/Relational_database_management_system

http://en.wikipedia.org/wiki/Relational_database_management_system

http://en.wikipedia.org/wiki/Internet_Protocol

http://www.idsdatanet.com/

http://en.wikipedia.org/wiki/Service_level_agreement