Operation of Diskos databases

BASIS FOR PREQUALIFICATION FOR SUPPLY OF SOFTWARE

AND OPERATION OF Diskos DATABASES

Norwegian Petroleum Directorate

12.02.2013
 2

CONTENTS

1 BACKGROUND ............................................................................................................. 4
1.1 General ................................................................................................................... 4
1.2 Current use of the database .................................................................................... 5
2 DISKOS ......................................................................................................................... 6
2.1 Current Diskos User Groups ................................................................................... 7
3 OBJECTIVE OF PREQUALIFICATION ......................................................................... 9
3.1 Diskos modules covered by PREQUALIFICATION ................................................. 9
4 PLAN FOR PREQUALIFICATION PROCESS ............................................................... 9
5 DESCRIPTION OF DISKOS SERVICES COVERED BY THE PREQUALIFICATION ..10
5.1 Scope of work / Description of Diskos modules to be contracted ............................10
6 EVALUATION TEAMS, PROJECT AND DISKOS STRUCTURE .................................12
7 QUALIFICATION AND SELECTION CRITERIA FOR THE PREQUALIFICATION ......12
7.1 General mandatory requirements ...........................................................................12
7.2 Solution / Domain specific criteria...........................................................................12
7.3 Ability to serve and be long term partner ................................................................12
8 TENDER INSTRUCTIONS, STRUCTURE AND DELIVERABLES ...............................13
8.1 Date for submission................................................................................................13
8.2 Response procedures ............................................................................................13
8.3 Dialogue with Diskos Management during prequalification process ........................13
8.4 Structure of response to prequalification request ....................................................14
9 COMMERCIAL REQUIREMENTS FOR SERVICES COVERED BY THE
PREQUALIFICATION ..........................................................................................................15
9.1 Contract period.......................................................................................................15
9.2 Ownership ..............................................................................................................15
9.3 Contract to be used – legal Domicile ......................................................................15
9.4 Option Clause ........................................................................................................15
9.5 Storage location .....................................................................................................15
9.6 Information Security ...............................................................................................15
9.7 Data transfer (loading/unloading) in beginning – and at end - of contract ...............16
9.8 Current Price structure ...........................................................................................16
9.8.1 Exceptions to price structure ........................................................................... 16
9.8.2 Revenue from synergies with associated (non exclusive) services .................. 16
9.8.3 Conditional Price reduction.............................................................................. 16
9.9 Ownership of data ..................................................................................................17
10 GENERAL DESCRIPTION OF CURRENT DISKOS DATABASE/SOLUTION .............17
10.1 Brief description of today’s Diskos database ..........................................................17
11 SEISMIC MODULE – CURRENT AND INTENDED FUNCTIONALITY .........................18
11.1 Currently Seismic Data types .................................................................................18
11.2 User Role description relevant for Diskos members ...............................................18
11.2.1 Data Managers usage: .................................................................................... 18
11.2.2 G&G (geoscientists) personnel at Diskos members (end users): ..................... 18
11.3 User roles related to submission of data to Diskos operator ...................................18
11.4 Dataflow for Seismic, from Acquisition to Interpretation (current example) .............19
11.5 Intended future Functionalities ...............................................................................20
11.6 Future use cases for Seismic data and database ...................................................20
11.6.1 Search and browse Seismic Data in database ................................................ 20
11.6.2 Downloading Seismic data from database....................................................... 20
11.6.3 Download post-stack data from database........................................................ 20
11.6.4 Download pre-stack data from database ......................................................... 20
11.6.5 Download field-data from database ................................................................. 20
11.6.6 Download Navigation Seismic Merge data from database ............................... 20
11.6.7 Download Velocity data from database ........................................................... 21

12.02.2013
 3

11.6.8 Provision of data to database .......................................................................... 21

11.7 Description of data types and statistics...................................................................21
11.7.1 Coordinate Reference System (CRS) Definition .............................................. 21
11.7.2 Seismic data, velocity and navigation data ...................................................... 21
11.8 QC of data ..............................................................................................................22
11.8.1 Check on navigation data files. ........................................................................ 22
11.8.2 QC in connection with upload to Diskos database. .......................................... 22
11.8.3 QC in connection with download from Diskos database. ................................. 22
12 WELL MODULE – CURRENT AND INTENDED FUNCTIONALITY .............................23
12.1 Current Well database functionality ........................................................................23
12.2 Well data usage .....................................................................................................23
12.3 Well data types.......................................................................................................23
12.4 Coordinate Reference System (CRS) Definition .....................................................24
13 PRODUCTION MODULE ..............................................................................................25
13.1 Production Data .....................................................................................................25
13.2 Production module usage .......................................................................................25
13.3 Loading procedures and quality control ..................................................................25
13.4 Data storage...........................................................................................................26
13.5 Production Data flow ..............................................................................................26
14 TRADE MODULE .........................................................................................................27
14.1 Trade Operator Usage ...........................................................................................27
14.2 Trade data-flow ......................................................................................................27
14.3 Trade module functions ..........................................................................................28
15 DISKOS FRONT- END..................................................................................................29
16 OTHER TYPES OF DATA ............................................................................................29
16.1 Cultural data ...........................................................................................................30
17 FUNCTIONAL MODULES AND UTILITIES ..................................................................31
17.1 Application Programming Interface (API) ................................................................31
17.2 Entitlements system ...............................................................................................31
17.3 End User interface; Display, Browse, Query, Select and Order ..............................32
17.4 Audit system...........................................................................................................33
18 DISKOS DATA BASE OPERATOR ..............................................................................34
18.1 Short information ....................................................................................................34
18.2 Backup and Disaster Plans ....................................................................................34
18.3 Service levels and SLA ..........................................................................................34
19 DATA - AND TRANSACTION VOLUMES ....................................................................35

12.02.2013
 4

1 BACKGROUND

1.1 General
Diskos is a formalised joint venture consisting of a majority of oil companies operating on the
Norwegian Continental Shelf (NCS). The Norwegian Petroleum Directorate, who also is a
member of Diskos, has been given the task of coordination and management of activities
within Diskos. Since 2011, also non-oil companies have been accepted as "associated
members" of Diskos. By primo 2013, 19 such associated members exist plus six Norwegian
Universities and research institutions.

The purpose of establishing Diskos in 1993 was to develop and operate a database
containing relevant data and information needed by the oil companies during exploration,
drilling and production of oil and gas on the NCS, and for the reporting of necessary data to
the Norwegian authorities required by legislation.

The Diskos database is the Norwegian National E&P Data Repository – which stores the
majority of the petrotechnical data from NCS.

Typical data stored:

 Seismic data
 Well log data
 Petroleum production data
 Cultural data (Licence areas etc)

The Diskos database is used for online loading and, storing by the Diskos operator and
retrieval of these data types by the members of the Diskos joint venture.
The amount of data currently stored is approximately 370 Terabytes.

The Diskos group wants to ensure the continued services related to storage, viewing, sharing
and trading of petrotechnical data. The current contractor agreement expires 31 December
2014. Since 1993 the operation/services has been provided by three organisations – which
managed all the relevant data types included in this request. The same software has been
used by all providers, but this is not a requirement to future provider(s).

This prequalification is opening up the possible scope of services, by requesting potential

suppliers of individual “modules” (data types managed) to express interest and to qualify as
tenderer. The Diskos group objective is to contract provider(s) of the services required to
manage all data types. Some suppliers may have existing solutions to support these
services, while other suppliers may have to develop – or partner up – to be in a position to
offer holistic services. i.e. to provide operation/services as described in this document, on
infrastructure and solutions owned or operated by themselves.

12.02.2013
 5

1.2 Current use of the database

All Diskos members use the database on a regular basis. The average amount of data being
downloaded each month is illustrated in graph below. For further information see Chapter 19.

Download requests, November 2012

12.02.2013
 6

2 DISKOS

Diskos is a group of oil and gas companies, collaborating through a formal agreement to
develop and operate shared databases and solutions for storage, access, data trading and
distribution of seismic, well and production data. The group operates through the Norwegian
Petroleum Directorate, as its legal entity.

Diskos is managed and organized in two primary user groups; Members and Non-Members –
served by a Diskos Operator. See illustration below.

12.02.2013
 7

2.1 Current Diskos User Groups

Members - Participants Participant Type Comment

Government Chairman of Management Committee and
NPD (Oljedirektoratet) Project Management. (Original Participant)
Agora Oil and Gas Oil Company
Bayerngas Norge Oil Company
BG Norge Oil Company
BP Oil Company
Bridge Energy Oil Company
Centrica Oil Company
Chevron Oil Company
Concedo Oil Company
ConocoPhillips Oil Company
Core Energy Oil Company
Dana Petroleum Norway Oil Company
Det norske oljeselskap Oil Company
DONG E&P Norge AS Oil Company
Edison International Oil Company
Emergy Exploration Oil Company
Eni Norge Oil Company
EnQuest Oil Company
EOn Ruhrgas Oil Company
Explora Petroleum Oil Company
ExxonMobil Oil Company Original Participant
Faroe Petroleum Norge Oil Company
Fortis Petroleum Norway Oil Company
GDF Suez E&P Norge Oil Company
Hess Oil Company
Idemitsu Oil Company
Lime Petroleum Norway AS Oil Company
Lotos Exploration & Production Oil Company
Lukoil Overseas North Shelf AS Oil Company
Lundin Norway AS Oil Company
Maersk Oil Norway Oil Company
Marathon Oil Oil Company
Noreco Norway AS Oil Company
Norske AEDC Oil Company
North Energy Oil Company
OMV (Norge) Oil Company
Petoro Oil Company
Petrolia Norway Oil Company
PGNiG Norway Oil Company
Premier Oil Norge Oil Company
Repsol Exploration Norge AS Oil Company
Rocksource ASA Oil Company
RWE Dea Oil Company
Shell Oil Company
Skagen44 Oil Company
Spike Exploration Oil Company
Spring Energy Norway Oil Company
Statoil Oil Company Original Participant
Suncor Energy Oil Company
Svenska Petroleum Oil Company
Talisman Energy Norge Oil Company
Total Oil Company
Tullow Norge AS Oil Company
Valiant Petroleum Norge Oil Company
VNG Norge Oil Company
Wintershall Norge Oil Company

12.02.2013
 8

Associated members

Associated Members . Non-Oil Associated Members – Universities and

Companies Government (non-profit) Research Institutions
Acona AS UiS (University of Stavanger)
Aker Geo UiB (University of Bergen)
Carmot Seismic UiO (University of Oslo)
CGGVeritas UiT (University of Tromsø)
Envision Invenio NTNU (Norwegian University of Science and
Exploration Geosciences Technology)
Exploro Geoservices NGU (Norges Geologiske Undersøkelser)
Fugro Data Solutions Ltd.
Fugro Multiclient Services AS
Globex Norway AS
Ikon Science
Multiclient Invest AS (PGS)
Robertson Geospec (Fugro-Robertson)
Schlumberger Information Services AS
Searcher Seismic
Spectrum
TGS-NOPEC
Well Design Online AS
WesternGeco Geosolutions

12.02.2013
 9

3 OBJECTIVE OF PREQUALIFICATION

The objective of this prequalification process is to allow all candidates to present themselves,
their industry and technical credentials – and preferred role as supplier for one or more of the
modules to be contracted. The submissions will be used to:
1. Qualify which candidates will receive subsequent Request for Proposal (RFP), based on
agreed criteria. Some of these are mandatory, and candidates must clearly state if these
can be adhered to, or where necessary, describe any deviations or alternative solutions.
2. Allow potential suppliers to propose alternatives/innovations to requested technical
solutions and services that may create added value to Diskos for one or more modules.
3. Allow potential suppliers to propose alternatives/innovations to commercial terms and
requirements that can add commercial/contractual value to Diskos for one or more
modules.

Diskos are not obliged to proceed with the prequalification process or the RFP. Diskos can
terminate the process for one, multiple or all the described modules.

3.1 Diskos modules covered by PREQUALIFICATION

Diskos will consider prequalification submissions for software, database and operation for
each database representing a "Diskos module". I.e.: Seismic, Well, Production and Trade. In
addition Diskos will consider submissions for a separate “Front-end module” that can provide
a user interface to the Seismic and Well modules.
Potential suppliers may submit proposal for one, multiple or all modules. Diskos may choose
to award contract to suppliers of a single module, or to suppliers offering multiple – or all -
modules.

4 PLAN FOR PREQUALIFICATION PROCESS

All prequalification submissions will be evaluated by a technical work group and a separate
commercial work group. The work groups will consider the submissions related to both
technical and commercial evaluation criteria, ref. Chapter 3.1.
Qualified suppliers will be shortlisted and invited to tender.
The preliminary timeline for the procurement process is as follows:
 12.02.2013 Issue of prequalification request
 20.03.2013 Deadline for clarification questions in the prequalification process
 27.03.2013 Submission of prequalification documents
 03.05.2013 Notification to qualified/ not qualified suppliers

 31.05.2013 Last date made available for possible supplier presentations (Chapter 7)

 17.06.2013 Issue of request for proposal (RFP)

 30.08.2013 RFP Submission deadline
 02.12.2013 Contract award

2014 is intended as a “transition year”

 01.01.2015 New Diskos Operator(s) commence services

12.02.2013
 10

Between contract award and commencement of operation a separate timeline with

milestones will be developed to ensure preparation and readiness for operation.

5 DESCRIPTION OF DISKOS SERVICES COVERED BY THE PREQUALIFICATION

5.1 Scope of work / Description of Diskos modules to be contracted

The following Diskos modules are intended to be contracted as part of the tender process. In
addition to the short description below a more comprehensive description are included in the
technical chapter later in this document.

1. Seismic Data
2. Well Data
3. Production Data. 1 (see comment in footnote)
4. Trading of data, management of rights to access data.
5. Diskos Front End. 2 (see comment in footnote)

The expectations to the Diskos modules are explained in more detail below:

1. A contract for receipt, quality control (QC), loading storage and downloading of seismic
data in compliance with the NPD reporting requirements as these are practiced by
Diskos. Seismic data includes both meta-data (including positioning and other reference
data), structured field data, pre-stack and post-stack data in standard formats, including
navigation data, e.g. SEG-D/SEG-Y formats, data files in a variety of formats e.g. ASCII
variants and documents in standard file formats (e.g. PDF, MS-Word, MS-Excel etc.).
Data must be searchable for downloading through the meta-data (survey name, data set
name, document type, GIS, date etc.). Diskos will consider the storage of certain data
types (such as seismic field data) either on disk, tape and/or a hybrid (on-line, near-line
or off-line) in compliance with the SLAs for accessibility of the specific data types.

The solution shall contain functionality to present overviews and various types of status
reports. The solution shall comprise of a “Front-end” (user interface) for the use of all
Diskos member companies for searching, viewing and download all of the data they are
entitled to, down to shot-point and document level. (Including all non-confidential data).
The system must, therefore, have stringent access controls.

2. A contract for the receipt, QC, loading, storage and downloading of well/wellbore data
according to the current NPD reporting requirements for digital well data that are
managed by Diskos. Well/wellbore data is defined as both meta-data (including
positioning and other reference data), structured data in standard formats (e.g. logs),
data files in a variety of formats (ASCII variants), and documents in standard file formats
(e.g. PDF, MS-Word, MS-Excel etc.). The data files shall be searchable to enable
downloading through the use of meta-data (well/wellbore name, document type, GIS,
date etc.)
The solution shall contain functionality to present overviews and various types of status

1
NPD may decide to move the responsibility of Production Data from Diskos to NPD. This will be decided prior to issuance of RFP as it
may result in a separate NPD tender process.
2
This module will be influenced by decisions of supplier and solutions for Seismic and Well. As a result the RFP for this module may be
issued later. E.g.: late 2013 or early 2014.

12.02.2013
 11

reports. The solution shall comprise of a “Front-end” (user interface) for the use of all
Diskos member companies for searching, viewing and download all of the data they are
entitled to including all non-confidential data down to individual data sets and document
level. The system must, therefore, have stringent access controls.

3. A contract for receipt, QC, loading storage and downloading of production data in
compliance with the NPD reporting requirements as these are practiced by Diskos.
Production data in this connection are defined as monthly figures for production and sale
of various products (oil, gas, NGL, condensate), injection and consumption of fuel gas,
diesel, etc. from wells/wellbores, field installations and land-based terminals that handle
petroleum products from the Norwegian Continental Shelf.
The solution shall contain functionality to present overviews and various types of status
reports. The solution shall comprise of a “Front-end” (user interface) for the use of all
Diskos member companies for searching, viewing and download all of the data they are
entitled to (including all non-confidential data). The system must, therefore, have
stringent access controls.

4. A contract for the development and operation of an IT solution that has the functionality to
assist Norsk olje og gass (Norwegian Oil and Gas Association) to plan and effectuate the
trading of confidential data between oil companies. The solution must have an online
connection to the other solutions (well and seismic) in order to extract real-time
information on current entitlements to comply with confidentiality requirements,
participation in production licenses or previously effectuated data trades.

5. Diskos Front-End.
This module is considered an optional module, which may be finally specified in the RFP.
Current databases are hosted by one supplier, providing one standard web-interface to
Seismic and Well databases – for search and order of data.
If the Seismic and Well databases will be developed/hosted by different vendors, there
may be a need to build, host and maintain a common front-end to the Seismic and Well
databases – to provide the same user experience of one, searchable interface. As this
module will be influenced by decisions of suppliers and technology the RFP for this
module may be issued later. E.g.: late 2013 or early 2014. This process are aimed to
qualify potential suppliers of such an interface, able to develop a front to 3’r part
databases – and handle the technical complexity of integration, hosting and provision of
view, search, select and order services.

12.02.2013
 12

6 EVALUATION TEAMS, PROJECT AND DISKOS STRUCTURE

The prequalification and the following RFP processes will be managed by Diskos
Management, providing recommendations to the Diskos Steering Group. The final decision
will be approved by the Diskos Management Committee.

The illustration below outlines the structure of the Diskos organization. All groups will be
engaged in the end-to-end prequalification and RFP process. In the current prequalification
process both technical and commercial work groups will review and asses the submissions,
prior to providing their recommendations to Diskos Management.

DISKOS Management Committee

Chaired by the NPD
(consists of all Diskos participants)

DISKOS Steering Group

Acting on behalf of Management Committee.
Chaired by NPD, with 5 representatives from Diskos Participants

DISKOS Management
Coordinating DISKOS activities
Overall management of the procurement process

DISKOS Technical Working Group DISKOS Commercial Working Group

(Technical Evaluation) (Commercial Evaluation)

7 QUALIFICATION AND SELECTION CRITERIA FOR THE PREQUALIFICATION

The following selection criteria will be used to evaluate and qualify which potential suppliers
will be shortlisted and invited to receive final tender. The qualification will be based on the
received documentation and possible clarifications. The qualified suppliers may be invited to
present their conceptual solution prior to issuance of RFP. Criteria in 7.1 are mandatory and
non-compliance will result in disqualification. Criteria in section 7.2 and 7.3 will have equal
weight.
7.1 General mandatory requirements
1. Provision of valid company certificate (Firmaattest), Tax confirmation, most recent
Annual Report. HSE declaration
2. Acceptance of contract formats and legal domicile (9.3)
7.2 Solution / Domain specific criteria
3. Industry or domain understanding. Response, references and credentials to illustrate
solid understanding of the solution area (Diskos module) the response is addressing.
4. The proposed technical and operational solutions outlined. In addition to functionality
this should also include considerations for reliability, scalability and flexibility,
including support of standards and open interfaces.
5. Credentials and references from similar services.
7.3 Ability to serve and be long term partner
6. Documented ability to mobilize and commence operation in accordance with timeline
7. Documented ability to continuously improve services / satisfy SLA requirements

12.02.2013
 13

8. The suppliers’ commitment and perceived ability to be a long term partner.

8 TENDER INSTRUCTIONS, STRUCTURE AND DELIVERABLES

The following are formal requirements for the prequalification submissions.

8.1 Date for submission

Candidates who wish to take part in the prequalification process must submit their response
no later than 27. March, 2013 at 12.00 hours - CET.

Submissions/Documents will not be opened before the prequalification deadline.

Resubmissions are allowed until deadline.

8.2 Response procedures

All documents shall be in English, signed and submitted as hardcopies and electronically, in
a sealed envelope. Containing:

Two printed copies, and one electronic version (PDF document format), on a USB flash
drive.

PricewaterhousCoopers AS
P.O.Box 8017
Kanalsletta 8
4068 Stavanger
Norway

Ref: Diskos prequalification 13/106

8.3 Dialogue with Diskos Management during prequalification process

Any questions or requests for clarifications related to the prequalification process, from
issuance of prequalification request until notification shall be directed in writing to
Diskos@no.pwc.com.

The mail should have Subject: “Question/Clarification regarding Diskos prequalification

13/106”

Answers and clarifications will be distributed to all registered prequalification respondents.

12.02.2013
 14

8.4 Structure of response to prequalification request

Response to prequalification submissions should cover the following obligatory elements:

General:
1. Cover letter, signed by contact person authorized (name and position) to represent
company.
2. Company information (Providing valid company certificate (Firmaattest),
Tax confirmation, most recent Annual Report. HSE declaration.
3. Specification of which Diskos module(s) the supplier wants to be qualified and
shortlisted for, in order to receive Request for proposal.
4. Confirmation of understanding and acceptance of the commercial requirements for
services covered by the prequalification. Including:
- Illustration of a proposed – preferred – pricing model (without prices).
- Ideas to improve or add value through new arrangements or business models.
This must be as addition to confirmation of understanding and acceptance or
commercial requirements.

Solution or Domain specific response:

5. For each Diskos module of interest the supplier wants to be qualified, confirm
understanding and acceptance of Technical Requirements. (As detailed in Chapter
10 and onwards).
6. For each Diskos module of interest the supplier want to be qualified:
a. Describe solution(s) available, customizable or to be developed. Include
information of maturity of technology, areas of innovation is welcomed.
b. Explain functionality of existing/new solutions and proposed services related to
descriptions and requirements in Technical chapters.
c. Explain flexibility to potentially take on new services
d. Explain scalability of solution, to handle significantly higher data volumes for
storage - and user traffic.
e. Explain use of open standards, technical requirements to end-user/client SW.
Also, how to avoid technical challenges with end-user SW, e.g. use of Java in
Diskos browsers which could conflict with company requirements to versions,
security etc.

Ability to serve and be long term partner:

7. Industry or solution domain experience to demonstrate knowledge within data base
and application development, and for G&G activities where relevant for Diskos
module of interest.
f. Reference. (Client, Project description, Value, Duration, Location, Contact)
g. Intended work plan and organization/staffing for providing services within timeline
illustrated in Chapter 4.
h. If partners or subcontractors are considered, explain how solutions and services
will be provided – and which legal entity will be responsible contract partner for
Diskos.

12.02.2013
 15

9 COMMERCIAL REQUIREMENTS FOR SERVICES COVERED BY THE

PREQUALIFICATION

As outlined in chapter 3, the objective of the prequalification process is to attract the best
suppliers to participate in a tender process where the scope of work will be to develop, or
provide and maintain, software and operation of Diskos databases.

The Diskos group objectives are to have a software solution with a functionality and capacity
equal to or better than the current software in use, and to maintain or improve the efficiency
of the Diskos operation. Innovation and improvement compared to existing software is
welcome – and should be emphasized.

9.1 Contract period

A successful tenderer may foresee a contract period of 5 – 6 years of operation.

9.2 Ownership
Ownership of software developed by suppliers to Diskos, at the cost of the supplier, will be
the property of the supplier. Diskos members, including the Norwegian Petroleum Directorate
will have rights of use.

The supplier shall make arrangements to ensure that Diskos have access and right of own
use (as intended by prequalification and RFP) to all necessary source code in case the
supplier is unable to deliver the contracted services, e.g. due to bankruptcy or other
unforeseen causes.

9.3 Contract to be used – legal Domicile

NPD will be contract partner, on behalf of the Diskos group, for all contract(s) awarded. The
contract will be developed by NPD, and made available in English. It will be governed by
Norwegian law. Legal domicile will be Stavanger District Court.

9.4 Option Clause

The future tender request and contract awarded may include options for Diskos to extend the
contract period on agreed terms.

9.5 Storage location

All Diskos data – for all modules - must be stored physically in Norway.

9.6 Information Security

The contractors are expected to ensure physical safety and access control for the servers,
data and infrastructure they operate as part of the contract in accordance with Norwegian Oil
and Gas “Information Security Baseline Requirements”. Ref:
http://www.norskoljeoggass.no/Documents/Retningslinjer/100-127/104%20-
%20Information%20security%20baseline%20requirements.pdf

12.02.2013
 16

9.7 Data transfer (loading/unloading) in beginning – and at end - of contract

The bidder will be expected to demonstrate their ability to support change of software and
operation of the database at the beginning and end of contract. Existing provider is similarly
obliged to support transfer to new operator(s). Time, cost and consideration of initial data
transfer to new operator will be described in further detail in later RFP.

Initial loading of data will include correct mapping of all entitlements on a given date. The
current level of “granularity” (where entitlements are assigned) must be maintained.

9.8 Current Price structure

The current price structure regulating the compensation to Diskos operator is based on a
combination of:
 Annual (independent of data use) fixed revenue, paid by the Diskos group.
 Variable (volume dependent) revenue for data input/output for different data types. This is
paid by the individual Diskos member. Variable revenue will also come from provision of
data to non-members and “Time and Material revenue from members” based on agreed
rates for services not covered in contract.

Respondents should propose a pricing model (not prices) as part of response to the
prequalification. New and innovative pricing models may be considered - as input to RFP.
The final price structure and supplier risk model will be decided and described before the
Request for Proposal documents are published.

There are some ongoing efforts that may significantly influence data volumes to be stored in
the Seismic data module. Inclusion of more field data (pre-stack) data will significantly
increase the data volumes.

9.8.1 Exceptions to price structure

The following exception to compensation will apply:
1. The Norwegian Petroleum Directorates has rights of free access and download, which will
not be chargeable by Diskos Operator(s).
2. The same applies to named Norwegian universities and governmental research
organizations, for non commercial activities (see Chapter 2).These have a right to limited
downloads.
3. The operators of Seismic and Well databases are expected to offer a free of charge public
portal (web interface) to allow graphical view of selected metadata.

9.8.2 Revenue from synergies with associated (non exclusive) services

Diskos Operators may – in addition to providing the contracted Diskos service – become an
associated member and find synergies between their role as host and manager of Diskos
data and other “non exclusive” services they may offer.

9.8.3 Conditional Price reduction

The supplier will be expected to establish and agree a Service Level Agreement which will
have consequences for the compensation for the services provided. i.e. a price reduction in
situations where service levels agreed are not met.

12.02.2013
 17

9.9 Ownership of data

The individual data stored in Diskos database(s) are normally the property of the operator
submitting it, but may also have multiple co-owners. The ownership and “user right” will be
registered as entitlement for all data. The entitlements may change (e.g. from sales, trades,
mergers and acquisitions etc.) and require database updates.

10 GENERAL DESCRIPTION OF CURRENT DISKOS DATABASE/SOLUTION

10.1 Brief description of today’s Diskos database

The main data stored in the database currently are:
 Seismic data
 Well data
 Petroleum production data
 Trade entitlement data

Well and Seismic data includes associated documents and information which are stored in
Diskos as “Archive objects”.

The Diskos database is used for online loading, storing, sharing and retrieval of these data
types by the members of the Diskos joint venture. The amount of data currently stored is
approximately 370 Terabytes in total. Estimated volume by January 2015 is approximately 6-
900 TB.

In addition the system includes cultural data, which is downloaded from NPD for the
Norwegian Continental Shelf and from IHS for North West Europe. The software is able to
manage cultural data, field and well positions, licence areas etc. Static data sets, such as
coast-lines, base-line, border lines, quadrants and blocks are stored with some basic
information attached; names, country and co-ordinates.
Dynamic data sets, such as licences, well headers, pipelines, installations, fields and
discoveries are stored with additional attribute information specified for each type.

Current system functions for all areas:

 Data selection
 Data browsing and viewing
 Data requests and - retrieval
 Data trading
 External data access
 Maintenance of security
 Maintenance of data
 Administration of system
 Generation of reports
 Select list management
 Data loading
 Data retrieval

Most data residing in Diskos database is currently stored in online disk systems, including
pre-stack and field data. The existing databases run on an Oracle Relational database.

The following chapters will outline current and intended functionality for each Diskos module.

12.02.2013
 18

11 SEISMIC MODULE – CURRENT AND INTENDED FUNCTIONALITY

The module consists of data, database (including meta data access) and front end with a
user interface.

11.1 Currently Seismic Data types

 Field & Pre-stack
 Navigation data
 Post-stack seismic data (2D, 3D, land, marine)
 Seismic survey- and geometry data
 Seismic processing velocities
 Associated reports (acquisition, observer logs, navigation, processing etc.)

The NPD constantly assesses the legislation regarding reporting of these methods and
Diskos will adopt the regulations when mandated. The Contractor should be prepared to
handle the data types requested by the NPD according to the legislation and to add new
functionality and data model extension if requested during the contract period (ref. Yellow
book, http://www.npd.no/Global/Norsk/5-Regelverk/Tematiske-
veiledninger/Geophysical_guidelines_e.pdf).

11.2 User Role description relevant for Diskos members

The users and usage of this Diskos database module will vary for each Company.

In general the users can be divided into 2 groups:

 Data Managers (super users)
 G&G personnel (geoscientists)

11.2.1 Data Managers usage:

They are normally the company representative, responsible for accessing and downloading
any data, available in Diskos database, for company use.

Assist G&G personel, to explore for available data, including company owned data, license
owned data, public data, and data with restricted or no access.

Responsible for hosting all geoscientist related data internally, make the data available and
load to interpretation software.

11.2.2 G&G (geoscientists) personnel at Diskos members (end users):

Individual geoscientist, enabled to explore/search for data in database.

Access rights handled within each company, dependent on company policy, for who should
have rights to order and download data. Can have the same privelegies as a Data Manager.

11.3 User roles related to submission of data to Diskos operator

This role is maintained by all licensees on the NCS. The role is responsible for data delivery
of acquired data, to the operator of Diskos database, according to authority requirements.
Some of these requirements are stated in the “Blue book” for well data, and “Yellow book” for
seismic data.

12.02.2013
 19

This role/function, will be responsible for the quality of the data submitted.

Seismic data is considered reported to authorities when data has been correctly loaded into
the Diskos database.

It is important that integrity of all data loaded to Diskos database is maintained. No header
data or meta data must be lost due to missing ability to represent data in Diskos database
operator(s) proprietary data formats.

11.4 Dataflow for Seismic, from Acquisition to Interpretation (current example)

Contractor

Nav Seis
SEGY tapes
QC

Field data, Navigation

SEGD tapes data

Processed
ge
er

SEGY
eis Y

Navigation QC QC and loading

v S S EG
M
Na

DISKOS
PetroBank

Poststack,
Bin gathers QC Company
CDP gathers Project DB
Field Data
Near-line On-line
Offline

New reporting requirements from NPD expands the pre 2012 requirements by including
Seismic Field data and pre-stack data, hence Diskos database may be involved in the
lifecycle of almost all traditional seismic data on NCS.

New from 2012 is a unique NPD index number for each survey, which is also planned to be
implemented as metadata at dataset level.
Field Data is original recorded data from the acquisition phase in a SEG-D format and are
normally delivered on high capacity tapes.

Positions of shot and receivers (Navigation data) are written into trace headers and output as
SEG-Y files. This dataset is called Navigation Seismic Merge. The SEG-D dataset and shot
receiver navigation data are sent for long term storage. (Please note that this is a mandatory
reporting requirement). The navigation seismic merge (Nav-seis merge) dataset is sent to a
seismic processing contractor.

Final products from the processing contractor are normally transferred directly to Diskos
database. These data are post-stack data and pre-stack data in the form of bin gathers for
3D data and CDP gathers for 2D data.

When processing contractor has finalized the processing project they shall after en agreed
period return navigation seismic merge data to database company data store.

12.02.2013
 20

11.5 Intended future Functionalities

The functionalities should match or exceed today’s solution. It may include new geophysical
data types resulting from new techniques and technologies.

The Tenderer is asked to elaborate about their suggested solutions.

11.6 Future use cases for Seismic data and database

DM and G&G personnel have a number of use cases and requirements when using
database which should be performed in the most practical and efficient manners.

General usage:
 Search and browse Seismic data
 Download post-stack data
 Download pre-stack data
 Ship/ download field-data
 Upload post-stack data
 Upload pre-stack data
 Download Velocity data

11.6.1 Search and browse Seismic Data in database

DM and G&G personnel from companies must be able to search and browse all entitled data.
It must be easy to filter and sort data on all available metadata tags.

Diskos database operator(s) should offer web services in such a way that companies can
create data overviews available for end users through internal portals and applications.

11.6.2 Downloading Seismic data from database

When the database user is searching and browsing for data it must be easy to create and
append to select lists for making orders for downloads.

11.6.3 Download post-stack data from database

It must be possible to clip data geographically based on a polygon, to delimit data in time,
inline/cross line or CDP range and to decimate data in time, inline/cross line or CDP
increment for 2D lines.

11.6.4 Download pre-stack data from database

In addition to the possibilities to delimit and decimate on post-stack data, pre-stack workflow
it is desirable to limit and decimate on offset.

11.6.5 Download field-data from database

The need for quick turnaround in seismic processing projects means that data must be
transferred from archive to processing contractor as quickly as possible.
To help companies ordering data for merges it is essential to have a GIS view of shot points.
Generation of select lists based on polygons should be made available.

11.6.6 Download Navigation Seismic Merge data from database

As for field-data above.

12.02.2013
 21

In addition, for both field-data and Navigation Seismic Merge Data, the transfer method
chosen will be dependent of the SLA. If navigation seismic merge data are downloaded from
database it must be optional to download via network or output to media, either external
disks or high capacity tapes.

11.6.7 Download Velocity data from database

Browsing for and download of velocity (ASCII / SEG-Y) data as the case for seismic data. It
must also be a relation established between the seismic data and the velocity data generated
from the seismic data.

11.6.8 Provision of data to database

Companies may also generate data for upload that they consider to be useful for partners
and want to archive in database for sharing and for long term storage.

Same requirements for the data must apply as for data received directly from processing
contractor.

11.7 Description of data types and statistics

Please see statistics provided at the end of this document.

11.7.1 Coordinate Reference System (CRS) Definition

Buyer request the Contractor to implement the OGP/EPSG standard for handling
georeferenced coordinates in the Diskos database. This is essential when transferring data
from the Diskos database to other applications ensuring unique CRS and datum
transformation identification.

See also EPSG web pages: http://www.epsg.org or http://info.ogp.org.uk/geodesy/

11.7.2 Seismic data, velocity and navigation data

The software must be able to manage digital seismic, velocity and navigation data in
compliance with current NPD reporting requirements.

Examples of seismic data types to be handled in the Diskos database:

Data type Comments

Processed navigation data
Raw and final post stack seismic
data
Pre stack data seismic data
Field data seismic data
Source - and receiver navigation
data
Seismic velocity data
Including maintenance of a spatial database.
All the common industry-used formats must be handled.
Including 2D, 3D, 4C, 4D and other relevant processed
versions
Volume is estimated as twice the volume of post-stack
Volume is estimated to be 80 times higher than Post stack.
All the common industry-used formats should be handled.

12.02.2013
 22

11.8 QC of data
Please elaborate on the following:

11.8.1 Check on navigation data files.

Compliance with EPSG for navigation codes and parameters mentioned earlier should make
it possible to conduct an automatic test on the navigation data loaded into the database. The
latitude/longitude positions can be verified against the projected coordinates using the
geodetic information in the header.
The check can either be on sample data, or the full set. Using EPSG descriptions as a
standard for headers will allow this computational check to be implemented, using automatic
lookup and calculation.

11.8.2 QC in connection with upload to Diskos database.

- Specify how your applications complies with format requirements and requirements defined
in international/national instructions for each different data-type.
- What means will be applied to perform QC of data to be uploaded to Diskos? This includes
all data types.
- What prerequisites are made concerning formal quality of data, data internal consistency and
data accuracy? Please specify for each individual data-type.

11.8.3 QC in connection with download from Diskos database.

- What means will be applied to log unsuccessful downloads?
- Specify for each individual data-type the possibilities to carry out data transformations, and
specify the means to secure a legal transformation that also complies with international and
national instructions.
- What means will be applied to secure formal quality of data, data internal consistency and
data accuracy? Please specify for each individual data-type.

12.02.2013
 23

12 WELL MODULE – CURRENT AND INTENDED FUNCTIONALITY

The module will consist of data, database (including meta data) and front end with a user
interface.

The Tenderer is asked to elaborate about their suggested solutions.

12.1 Current Well database functionality

The Well module shall be able to manage well data as described according to the NPD
reporting requirements (NPD Blue Book). http://npd.no/Global/Norsk/5-
Regelverk/Tematiske-veiledninger/B_og_b_digital_rapportering_e.pdf

Details of all relevant file formats are in NPD document (Wells - Blue book table A1- reporting
requirements for digital well data). http://npd.no/en/Regulations/Guidelines/

 Raw data as acquired and measured

 Edited or composite data
 Interpreted or computed data
 Digital images of raw logs, completion logs and reports

High business value log curves are loaded into the Recall (TM) data base, and in
accordance with the established Energistics Practical Well Log Standard version 2 and the
NPD reporting requirements.

Please see details at http://w3.energistics.org/PWLS/pwls_20.htm - and

http://www.energistics.org/geosciences/geology-standards

12.2 Well data usage

Diskos members’ access online data using a front end software developed by Landmark.
Non-Diskos members can browse and order public data for the Norwegian Continental Shelf.

Well data are currently reported to Diskos database using a FTP drop-server. Data must be
reported according to the NPD requirement, before the Diskos database operator uploads
the data to the database and set entitlements.

12.3 Well data types

The following data types are examples of wells data loaded into Diskos database, and are
currently part of the data sets required to be reported to the NPD. Note that this list is
illustrative and that the specific NPD requirements may change.

Data types:
 Completion Reports
 Core data
 Core Photos
 Core Reports
 Drilling logs
 Drilling Reports

12.02.2013
 24

 Fluid Reports
 Geological Completion Reports
 Geological Reports
 Geological Well Logs
 Logging Reports
 MWD Logs
 Petrophysical Evaluations
 Pressure Logs
 PVT Reports
 Site Survey Reports
 Test reports
 Well Log Indexes
 Well Path Data
 Well Report Indexes
 Well bore Seismic Data
 Well bore Seismic Reports
 Wire line Logs

12.4 Coordinate Reference System (CRS) Definition

Buyer request the Contractor to implement the OGP/EPSG standard for handling
georeferenced coordinates in the Diskos database. This is essential when transferring data
from the Diskos database to other applications ensuring unique CRS and datum
transformation identification.

See also EPSG web pages: http://www.epsg.org or http://info.ogp.org.uk/geodesy/

12.02.2013
 25

13 PRODUCTION MODULE

The Tenderer is asked to elaborate about their suggested solutions to this challenge.

13.1 Production Data

The Software must be able to manage production data as described according to the NPD
reporting requirements (Guidelines for production – and sales data – reporting to NPD,
http://npd.no/Global/Norsk/5-Regelverk/Tematiske-veiledninger/Produksjonsdata_e.pdf )

The main production data types reported to the Diskos database are those required to meet
the NPD reporting requirements for monthly allocated production data:

 Production volumes per well, installation, field part and field (Gross production)
 Allocated production figures per field part/field on a monthly basis (Net production)
 Sales and storage data

Each oil company shall report data directly into the system themselves with assistance and
QC check by the database operator.
The oil companies shall also be able to modify production figures previously reported for any
period in history. The database shall be able to receive production data from fields on the
border line to UK and store split factor that varies over time.

13.2 Production module usage

Users of the data is Norwegian Petroleum Directorate (NPD), Oil Companies, Ministry of Oil
and Energy (MPE), Petroleum Tax Office, Statistic Bureau of Norway (SSB),and others
(newspapers, magazines, banks, students etc.)

Report files are sent from NPD or from each of the oil companies that have role as operator
of a producing field. The reports could also come from the operators of the Land Terminals
(ex. Kårstø) handling oil and gas produced on the Norwegian Continental Shelf.

When all the necessary files have been loaded, the NPD withdraw some key figures from the
Diskos database and loads this information into an internal database before published on the
fact pages. The simplified structure of the database is that volumes are stored for each oil
and gas field, as defined in the NPD Fact pages:
http://factpages.npd.no/factpages/Default.aspx?culture=no ), for each installation and for
each production well belonging to each field. The volumes are both gross- and net
production, injection, fuel etc. and stock (tank volumes) and sales figures.

13.3 Loading procedures and quality control

Totally 76 different oil and gas fields are reporting to the system. The system receives data in
both COPEX format (standard ASCII files) and a new XML format developed together with
The Norwegian Oil and Gas Association (MPRML) from oil companies directly, or through
Epim Reporting HUB (ERH).

At the present time only one oil field delivers data using XML , the rest use COPEX. There
will be a transition period (some years) before all operators can report using XML. For the
XML files: The vendor shall run a Microsoft .Net web service in order to validate files before
loading. This web service shall be run as a front end for quality control before loading the
XML data input. The web service was developed by the NPD in 2012, based on XML and
Schematron technology. No data with errors are to be loaded into the database.

12.02.2013
 26

13.4 Data storage

The database shall be securely accessible both for extracting and importing data in a
machine readable format by the use of any standard technology at any given time.
Entitlements shall be set on the data elements that are not public. At present time this is at
the wellbore level and gas sales per company.

The following data will be stored in the database:

 Production volumes per well, installation and field of gross production as oil, gas,
condensate and water.
 Allocated production figures per field on a monthly basis of saleable production:
 Oil, gas, condensate, gasoline, butane, ethane, isobutane, propane, LPG and NGL
 Injection per well, installation and field of gas, water and cuttings
 Fuel per installation and terminal/processing plant of gas and diesel.
 Flare per installation and terminal/processing plant of gas
 Cold vent per installation of gas and co2
 Storage data per field and terminal/sales point of
 Oil, condensate, gasoline, butane, ethane, isobutane, propane, LPG and NGL
 Sales data of gas per terminal/sales point
 Sales data per boat of:
o Oil, condensate, gasoline, butane, ethane, isobutane, propane, LPG and NGL

All cultural data, such as well, installation, field, terminals, companies and countries must be
retrieved from XML files available on the NPD FactPages. Information will be stored in units
as mass (kg, ton), volumes (Sm3, Nm3, bbl), energy (MJ, KW.h) together with densities of
the product.

13.5 Production Data flow

The workflow is best described below.

12.02.2013
 27

14 TRADE MODULE

The trading solution (software) is intended to prepare for changes in access/use rights to
data stored in Diskos databases based on work processes and agreements. Changes in
rights of use are a result of a number of possible transaction types. This may cover, but not
be limited to, monetary sale or trading of different data types without monetary compensation
(swapping of user rights). This module may be considered as a separate solution, interfacing
with other Diskos databases. This chapter outlines current functionality and some of the
discussions of new requirements. The Tenderer is asked to elaborate about their suggested
solutions.

14.1 Trade Operator Usage

Data trades are normally administrated by Geodata Trade Operator Norsk Olje og Gass
(GTO), but companies can also administer trading themselves.

The objective and main goal of trade operator is to ensure the best possible flow of data
between all oil companies on the Norwegian Continental Shelf (NCS) by centralised
administration of the data exchange process.

The trade operator assists customers by simulating possible trades using a specially
designed trading software. This is a significant contribution to efficiency in arranging trades,
purchase and sale of well and seismic data.

Information needed for a trade is found by accessing the Diskos well database, seismic
database, NPD Factpages.

14.2 Trade data-flow

The figure below gives a general description of the data-flow for a trade and what external
elements are involved.

12.02.2013
 28

14.3 Trade module functions

The trade module contains data and functionality to assist the trade operator to organize
trade, purchase and sell data packages (and single reports) with seismic and well data
information on behalf of single companies, licenses or groups of companies. All trade-related
information must be kept strictly confidential between the companies involved in a trade and
GTO. This must be kept in mind with regards to access to reports etc.

The software must include a system for trading of data with at least the functionality provided
by the current solution in Diskos, which is currently managed by GTO

The description in this section is a specification of the data types and functionalities wanted
in order to design an enhanced system to fulfil all trade requirements.

Some of the main functions of an enhanced trade module are:

 Functionality to support the trade process, by simulating scenarios for trade, purchase or
sale of data. The current version contains simulation functionality for well data. Seismic
trade should be supported by similar functionality.
 The trade operator sets or instructs the Diskos database operator(s) to set entitlements
(user rights) based on trade agreements between the different companies
 The Trade module must store information about the historical information on all trade
proposals, both the completed and the rejected ones.

A trade proposal involves at least two trade objects. Current version limits the number of
“wanted objects” to be one and “given objects” to be two or more. Each trade proposal has a
unique number, which preferably is generated automatically.

In a new solution there must be the possibility of having more than one object on both sides
of the trade.

The types of trades are defined as:

 Ordinary trade – meaning well vs. well or seismic vs. seismic

 Pre-trade; this is when a trade is done before one or more of the involved wells or seismic
are completed. They can have status as planned or on-going.
 Split-trade; this is a trade where companies within a trade group receive different trade-
objects in return.
 Purchase/selling – meaning well/seismic vs. money

A trade proposal for an object (well and/or seismic, report, etc.) involving a set of information,
is registered. The meta-data is found in the Diskos database and/or the NPD FactPages. A
Trade simulation is performed to calculate potential benefits to the trading partners, to
establish the feasibility for the trade to be accepted and when the trade can take place.
When the trade has been carried out, entitlements can be set.

The figure below illustrates the interaction between the Trade module and the Diskos
databases.

12.02.2013
 29

API
Trade module
well
Web services

GTO
seismic
organisation

15 DISKOS FRONT- END

With reference to chapter 5 in this document, the Tenderer(s) is asked to elaborate on this
module. The users and the usage of the various databases are short described in this
document.

The Buyer would like the Tenderer(s) in their elaboration to focus on elements such as
connectivity between the databases, user access, application platform, anticipated user
experience, requirements to the underlying databases and applications, and how the
Tenderer(s) foresee the operation and maintenance of such a front-end.

16 OTHER TYPES OF DATA

There are other types of data not covered by current reporting requirements, such as EM
data and the Grav-Mag data. It is expected that NPD will mandate requirements for new data
types within the new contract period.

Refer to “Yellow book” (http://www.npd.no/Global/Norsk/5-Regelverk/Tematiske-

veiledninger/Geophysical_guidelines_e.pdf).

12.02.2013
 30

16.1 Cultural data

The cultural data types in the Diskos data base mostly serve as reference data used as GIS
map layers and geographical objects to assist with data identification, cataloguing and
searching. The different cultural data types and their current sources are described briefly
below:

Data type Comments Data Source

Northern Europe ;Well header
Well NPD for Norwegian wells
information
Northern Europe; Complete license
Licence history with operators and partners for NPD for Norwegian licenses
NCS licenses.
Licence co- Northern Europe; Complete history
NPD for Norwegian licenses
ordinates for NCS licenses
Fields and
NCS NPD for Norwegian data
discovery
Pipeline Northern Europe
Block Northern Europe NPD for Norwegian data
Quadrant Northern Europe NPD for Norwegian data
Permanent
Northern Europe NPD for Norwegian data
Installations
Boarder Northern Europe NPD for Norwegian data
Coast Northern Europe NPD for Norwegian data
Base line NCS NPD for Norwegian data
Depth interval of 100m from 0 to
WD 500m and a depth interval of 500m NPD for Norwegian data
from 501 up to 4000m.

12.02.2013
 31

17 FUNCTIONAL MODULES AND UTILITIES

The functional modules are functionalities in a more general manner, not specific to a Module
as described above.

Tenderer is asked to elaborate around the functions below and suggest new innovative
functions.

17.1 Application Programming Interface (API)

Below are some examples of functionality seen as beneficial for an open application
architecture.

1. SQL – type access to database; Diskos request to be able to query the database either
directly or indirectly via a logical data model. The access right should only be read and of
course limited to the information each company is entitled to see.
2. The architecture of the API should utilize a thin client interface by using computer
resources at the Operator site as much as possible as opposed to having a Web server
etc. in the Diskos members’ office.
3. Access through a Web Services API to key data types.
4. Access through the API must honour the security
5. Access through the API must honour the entitlement setting for the data
6. The API must be well documented, this includes data/object descriptions and
specification of the interface
7. It must be possible to browse/query all data types stored in the database
8. It must be possible to query/filter on one or more of any of the attributes for a data type
9. It must be possible to create an order from the API
10. The API must honour the coordinate system conversion used in the system and convert
all coordinates to one coordinate system

17.2 Entitlements system

The entitlements system is the basis for a system of which sharing of information and data is
one of the main functions. The following requirement must be included in the entitlement
system:

1. A mechanism to allow Diskos Data Operator(s) to ensure that entitlements are set in
accordance with documented owner or user rights.

2. A notification method must be made available to notify a company’s representative when

company access to data are set or removed.

a) A notification method must be made available to notify a company’s representative

when access to his data are given or removed to/from another company or
organization. Examples:“My data” are set public
b) Company get access to “my data” from date to date – reason for access (partner,
trade, purchase)

3. A company must at any time be able to view and download a list of full entitlement
details and history for the data they own.

4. A company must at any time be able to view and download a list of full entitlement
details and history for the data and information they are entitled to.

12.02.2013
 32

17.3 End User interface; Display, Browse, Query, Select and Order
Some requirements for the End User Interface could be:

1. There must be seamless integration between the map and table view on the data, this
means a selection in the table view must also highlight the select data on the map, the
user must be able to select data on the map and then get it displayed in a table view etc.
2. It must be possible to search top – down or bottom – up in the data type hierarchy
a. Ex: Show all wells with Sonic Logs or show all logs for specific wells
3. Possibility to plot spider plot of well deviation data
4. The search system must easily be able to present a high-level summary and an item
count on all data types and items available
a. E.g.: Show me a list of data types available for selected wells
5. Access information such as “reason for access (traded, partner, owner etc.)” must be
available in table view
6. It must be possible to search for data by distance from a graphical object:
a. Ex: All data within a given diameter from a specific well or platform.
b. Ex: All wells intersecting a seismic line or with a given maximum distance from a
seismic line.
7. It must possible to do all browsing, querying and selection involving a specific data type
and archive data in one view.
a. Ex: Searching for well data involving well data module and archive module in one
operation
8. Contractor must suggest a workflow oriented user interface or workflow wizard as a tool
to guide the user through the system
9. It must be possible to colour fill a polygon with a transparent fill percentage in the map-
display. (e.g. colour-fill of 50% is transparent)
10. It must be possible to export from table view to Excel
11. Export all displayed or selected map data to Landmark Zmap ZGF shape format files
12. Export to ESRI shape files with compliance with SDE; it must be possible to load these
into SDE
13. Ability to export spatial data to ESRI shape formatted file including coordinate reference
system definition (.prj file)
14. GIS functionality; it should be possible to add or export ESRI layer file (*.lyr). These files
contains a description of:
 Data source
 Symbols
 Data filters
 Join to attribute tables
 Label definitions
15. If Spatial Data Engine is part of the solution a direct read connect to SDE from ESRI
applications and other “SDE enabled” applications must be possible

12.02.2013
 33

17.4 Audit system

An Audit system must be developed for tracking purposes to create a basis for:

1. Invoicing background:

a) Keep an audit trail of all activities in the Diskos database in order to provide the
Operator with all information needed for invoicing. Typical information will be:
 Sign-on count (number of sign-on per user)
 Data type and volumes loaded into Diskos database
 Data type and volumes exported and download
 Other system activity influencing the invoicing

2. Historical information:

b) Keep an audit trail of activities related to usage of data and to be able to track the
history of a data set. Typical information will be:
 Loading of data; Loaded by, QC’ed by, updated by
 Data updates and changes; KB changes, rig changes, well characterization type
changes (Exploration well become production well),
 Data set deleted and replaced

c) Request information; the system should provide functionality to easily find old
requests, view details and re-send request. Also information about previous
downloads for a selected data set should be shown.

d) The audit system should maintain a trail of all entitlements changes and should as a
minimum contain:
 Date and time of entitlement setting
 User id of the person performing the setting
 Other necessary change details

e) The entitlement system and the trade module should be closely linked when it comes
to audit trails, tracking and history of trades, e.g. an entitlement setting triggered by a
trade should reflect the trade-id set in the trade module.

12.02.2013
 34

18 DISKOS DATA BASE OPERATOR

Please elaborate about the operation below.

Based upon the module description(s) in this document and the Tenderer’s experience, the
Tenderer is encouraged to propose innovative solutions for the selected module.

18.1 Short information

The Diskos database Operator can receive data from acquisition contractor, processing
contractor, a 3rd. party QC company (if any) and from the data owner e.g. oil company.

The method used for transferring data might be digital media of some sort or network. The
Diskos database Operator is loading the data into the database after performed a quality
control (QC).

Entitlements are set by the Diskos database operator and data made available to the users
for browsing and data ordering/ downloading.

The Diskos database operator will be responsible to host and maintain Helpdesk
functionality.

18.2 Backup and Disaster Plans

The Diskos database operator shall maintain a secure and updated copy of all data sets
stored in the database to ensure that data is not lost as a result of technical or other
unforeseen situations.

The Diskos database operator must be prepared to establish a disaster recovery plan for the
successful reconfiguration and repopulation of systems in the event of a major disaster to the
operations. E.g. a failover solution – or equivalent concepts to ensure availability of services
in accordance with agreed Service Levels Agreement (SLA).

18.3 Service levels and SLA

There will be developed a set of Service Levels for the services to be provided within each
module. The Tenderer is asked to suggest the SLA for their services and how they will be
measured, including the time factor. Service levels like (but not limited to):
 Data base availability
 Helpdesk availability
 Loading of data
 Retrieval of data
 Response to potential bug fixing or application adjustments

12.02.2013
 35

19 DATA - AND TRANSACTION VOLUMES

Monthly Statistics

As of the end of December 2012 Disk usage for Diskos amounted to 364 TB
Monthly increase of 8.8 TB, compared to last month’s increase of 28 TB

12.02.2013
 36

Download statistics per November 2012

Number of logins though existing Frontend

12.02.2013
 37

Status Operation Well Data

As per November 2012

12.02.2013