Technical Data Management Procedure

0000RP-C-G0-G000-DM-PRO-0002

Rev B02 (08 Aug 2017)

REV DESCRIPTION ORIG REVIEW APPROVAL DATE CLIENT DATE

APPROVAL

A01 Issued for Review 12/02/14 N/A

S Sanna M Williams Kent Alger

B01 Issued for Use 24/02/14 N/A

S Sanna M Williams Kent Alger
Digitally signed by Graham

Matthew Digitally signed by Matthew Oakley

DN: cn=Matthew Oakley, o=ROO
Graham Jones
DN: cn=Graham Jones,
o=ROO, ou=ROO Projects, joe.mcauley@se1.bp.com
B02 Revised for Use Projects, ou=IM Manager,
08/08/17 N/A
Jones
email=Graham.Jones@roob
2017.08.26 16:40:39
Oakley
email=matthew.oakley@roobasra.c
om, c=US asra.com, c=US
Date: 2017.08.08 12:42:53 +03'00' Date: 2017.08.08 12:05:40
+03'00' +03'00'
M Oakley G Jones N.White

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure
REVISION DESCRIPTION SHEET

Rev. Para. Reason for Revision

B02 Updates to the entire document.
Document updated to reflect working practices
Diagrams updated.

Hold No. Para. Description of Hold

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

CONTENTS

1 INTRODUCTION ................................................................................................................ 4

2 SCOPE OF DOCUMENT ................................................................................................... 5

2.1 Definitions ........................................................................................................................... 6

2.2 Abbreviations ...................................................................................................................... 7

2.3 Reference Documents ........................................................................................................ 8

3 CENTRAL INFORMATION STORE (CIS) .......................................................................... 9

3.1 CIS Overview ...................................................................................................................... 9

3.2 Central Tag Database ......................................................................................................... 9

3.3 Security ............................................................................................................................... 9

4 PROJECT DATA MANAGEMENT.................................................................................... 10

4.1 Tag Allocation and Registration ........................................................................................ 10

4.2 Tag Data Requirement Definition ..................................................................................... 12

4.3 Tag Data Submission ....................................................................................................... 12

4.4 Data Submission Validation .............................................................................................. 14

4.5 Data Maturity & Delivery ................................................................................................... 16

4.5.1 Data Maturity ........................................................................................................ 16

4.5.2 Data Delivery........................................................................................................ 16

4.6 HANDOVER/CLOSE OUT ................................................................................................ 17

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 3 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

1 INTRODUCTION
The TECHNICAL DATA MANAGEMENT PROCEDURE describes the processes that shall be followed for
the issue, review/comment and approval of all tag numbers and associated tag data in
accordance with the Information Handover Specification produced by COMPANY and the
various CONTRACTORS and/or it’s SUPPLIER(s) on the Rumaila Project.

The COMPANY’s Central Information System (CIS) is to be used for all viewing and reporting
on all tags and associated tag data produced during the execution of work.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 4 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

2 SCOPE OF DOCUMENT
There are several sources of project data that shall be managed by Rumaila.

The primary source of data is produced by CONTRACTORS for the design and construction of
facilities on the Rumaila, and is related to the Contractual Requirements for each Contract.

The secondary source of data is produced and issued by SUPPLIERS. This information is
related to the design, supply and installation of packaged equipment across the Installation and
Facilities of Rumaila.

The tertiary source of data is produced and issued by COMPANY. This information is related to
on-going development of the information sets once design and construction have been
completed.

This procedure establishes the mechanism for sharing the data between
COMPANY/CONTRACTOR and SUPPLIERS across the project. The key considerations being:

• Provide a central point from which users can obtain reliable Tag Data information.
• Enable the project to execute work scope against approved Data deliverables to
ensure that safety, quality, cost and schedule is not compromised.
• Demonstrate design integrity.
• Keep a full and concise procedure for audit purposes.
• How CONTRACTORS and/or SUPPLIERS will interface with COMPANY CIS.
• The importance of tag data delivery schedule for both CONTRACTOR and
SUPPLIER.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 5 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

2.1 Definitions

Definitions

COMPANY BP Iraq NV.

CONTRACTOR The party, which carries out all or part of the design, engineering, procurement, construction,
commissioning services. The COMPANY may undertake all or part of the duties of the
CONTRACTOR.
SUPPLIER Shall mean third party SUPPLIER delivering Equipment and/or Materials to a CONTRACTOR.
Where the Purchaser has contracted/delegated a total design responsibility (e.g. electrical design) to
a company, then that company shall be regarded as a SUB-CONTRACTOR, not a SUPPLIER.
WORK Shall mean all and any of the works, services and materials required to be provided by the
CONTRACTOR.
SHALL The word shall is used to indicate that a provision is mandatory.
SHOULD The word should is used to indicate that a provision is not mandatory, but recommended as good
practice.

As-Built CONTRACTOR shall certify that the final Information reflects the as-built status of the facilities as at
take-over by Operations. This includes all changes made during on-site installation and hook-up and
reported changes from commissioning. 3D CAD models, 2D CAD files, viewing files and engineering
databases shall all be updated to reflect a consistent as-built status.
SUPPLIERS shall certify that the their final Information is updated to reflect true As-Constructed
status at handover to CONTRACTOR.
CIS (Central Information COMPANY term for its systems managing the Tag’s / Tagged information, Documentation and
Store) relations (Tag-Doc and Tag-Tag). The term CIS replaces the term EDMS (Electronic Document
Management System).
The CIS can be relied on for the retrieval of all current project Tag and Document deliverables.
Deliverable Documents and Data that are produced by the project and its CONTRACTORS/SUPPLIERS. Shall
form part of the final project information handover.
Documents / Drawings Referred to in this procedure shall include all project documentation deliverables.
Tag Tag = Functional Location
All functional components subject to certification, inspection or maintenance during operations shall
be allocated a unique plant tag number in accordance with the Engineering Numbering System
(ENS). This shall apply to all parts including functional components in supplier packages.
The Tag number identifies the service/location in the plant, and not a specific equipment item. The
Tag number will not change when you change the equipment, as long as the equipment does not
change function.
Tag Data Attributes stored against a unique tag number that can be used for database population and
updates, reporting, searching and management of tag registers.
A Tag will have associated both Functional and Physical data attributes.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 6 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

2.2 Abbreviations

Abbreviations
CAD Computer Assisted Drawing
CDL Central Document Library
CIS Central Information Store
CTDB Central Tag Database
ENS Engineering Numbering Specification
IM Information Management / Manager
KPI Key Performance Indicator
MTR Master Tag Register
OEM Original Equipment Manufacturer
P&ID Process & Instrument Diagram
PDM Rumaila Project Data Manager
PIM Rumaila Project Information Manager
PSCM Procurement & Supply Chain Management
ROO Rumaila Operating Organisation (Basra)
RUI Rumaila Unique Identifier
TBC To Be Confirmed
UoM Unit of Measure
WBS Work Breakdown Structure

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 7 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

2.3 Reference Documents

Document Number Title / Description

0000RP-C-GO-G000-DM-STG-0001 PROJECT INFORMATION MANAGEMENT STRATEGY

PROJECT INFORMATION MANAGEMENT (PIM)
0000RP-C-GO-G000-DM-PLN-0001
IMPLEMENTATION PLAN
0000RP-C-GO-G000-DM-PRO-0001 DOCUMENT MANAGEMENT PROCEDURE

0000RP-C-GO-G000-DM-PRO-0002 TECHNICAL DATA MANAGEMENT PROCEDURE

DOCUMENT MANAGEMENT PROCEDURE FOR

0000RP-C-GO-G000-DM-PRO-0003
CONTRACTORS

0000RP-C-GO-G000-DM-PRO-0004 MATURITY MANAGEMENT PROCEDURE

0000RP-C-GO-G000-DM-PRO-0005 DOCUMENT MANAGEMENT PROCEDURE FOR SUPPLIERS

0000RP-C-GO-G000-DM-SPC-0001 ENGINEERING NUMBERING SPECIFICATION

0000RP-C-GO-G000-DM-SPC-0002 TECHNICAL DOCUMENT NUMBERING SPECIFICATION

0000RP-C-GO-G000-DM-SPC-0003 INFORMATION HANDOVER SPECIFICATION

0000RP-C-GO-G000-DM-SPC-0004 GENERAL GEOSPATIAL INFORMATION SPECIFICATION

0000RP-C-GO-G000-DM-SPC-0005 SPECIFICATION 2D CAD

0000RP-C-GO-G000-DM-SPC-0006 3D CAD SPECIFICATION

0000RP-C-GO-G000-DM-SPC-0007 SUPPLIER DOCUMENT NUMBERING SYSTEM

0000RP-C-GO-G000-DM-SPC-0009 IHS - TECHNICAL DATA REQUIREMENT SPECIFICATION

0000RP-C-G0-G000-IM-TPL-0011 TAG REQUEST TEMPLATE

0000RP-C-G0-G000-IM-TPL-0012 DATA COLLECTION TOOL CHECK SHEET

0000RP-C-G0-G000-IM-TPL-0013 DATA COLLECTION TOOL TEMPLATE

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 8 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

3 CENTRAL INFORMATION STORE (CIS)

3.1 CIS Overview

The CIS provides one central point of reference for controlled project information, including but
not limited to technical documentation and drawings, master tag register, engineering technical
tag data, and Cross-References. The CIS provides a mechanism through which information is
transmitted and shared. It shall ensure that technical project information is available to all
project locations and time zones, whilst being held in a secure, central information store.

3.2 Central Tag Database

One element of the CIS is the Central Tag Database (CTDB).

The CTDB provides:

• A Tag Allocation module for self-service request for unique tag numbers in
accordance with ENGINEERING NUMBERING SPECIFICATION .
• Ensure a full, concise and controlled set of tags and associated technical data
based on IHS - TECHNICAL DATA REQUIREMENT SPECIFICATION is available and can be relied
upon.
• The ability to create cross project engineering data registers.
• The ability to create and store tag to document and tag to tag associations (e.g. from
and to associations).
• A coding system derived from the project Work Breakdown Structure (WBS).
• Visibility to Project Management of tag and data completeness status directly related
to execution of the WORK.
• Design integrity and a full audit trail.
• Interfaces to other projects departments/information sharing.

The CTDB will NOT hold any Model or Geospatial data. Please refer to 3D CAD SPECIFICATION and
for Model/Geospatial related data.
GENERAL GEOSPATIAL INFORMATION SPECIFICATION

3.3 Security
COMPANY CIS security system manages logons, passwords, access to individual CIS
modules and permissions to create and modify records. Security is controlled by the CIS
Specialist and is described in the CIS System Administration Procedure referenced above.
Permissions shall be used to control access to relevant tags. Assignment of security/system
permissions shall be the responsibility of the Data Manager.

Access to the CTDB will require formal sign off by the line manager and final approval shall be
the Project Information Manager.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 9 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

4 PROJECT DAT A MAN AGEMENT

4.1 Tag Allocation and Registration

All items requiring a unique tag number in accordance with the criteria stated in ENGINEERING
NUMBERING SPECIFICATION shall be defined as a “tagged item”.

CONTRACTORS shall use create and upload a Tag Request to the CTDB, (using the Tag
request template 0000RP-C-G0-G000-IM-TPL-0011) to allocate all project tag numbers. To
ensure alignment with ENGINEERING NUMBERING SPECIFICATION and uniqueness across the project

A request shall be submitted for a tag number to the CTDB. Tags can be requested individually
or in blocks. Multiple blocks may be requested at the same time. I.e. 10 Valve tags and 5 Pump
tags may be submitted in a single request. See Figure 1 for work flow diagram of the request
process.

Once the request has been processed, the Tag Numbers will be registered against the
requesting CONTRACTOR.

Once a tag has been utilised in the design and appears on a deliverable it shall be considered
as ACTIVE. If the tag number is no longer required it shall be updated to VOID status. Tags
once created shall never be “deleted” i.e. permanently removed from the database.

CONTRACTOR shall register and manage all tags for their SUPPLIER and SUB-
CONTRACTOR scopes of work in the same manner.

Tags that are not in the CTDB but appear on documents are deemed uncontrolled
i.e.“unissued”. These shall be submitted for allocation using the established Tag Allocation
processes.

The CONTRACTOR shall void any project tag numbers registered within their scope of work
that are no longer required.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 10 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

Figure 1 - Tag Request Work flow

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 11 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

4.2 Tag Data Requirement Definition

The data attributes that are required to be populated for each tagged item are defined in the IHS
- TECHNICAL DATA REQUIREMENT SPECIFICATION. This includes but is not limited to:

• Functional Data Attributes (Functional definition of a requirement. I.e. a process

function operating parameters).
• Physical Data Attributes (Physical characteristics of the object selected to fulfil the
functional requirement. I.e. the procured item).
• Tag to Document Cross References
• Tag to Tag Cross References
• Flag Indications (Y/N)
• Contractor shall be responsible for providing all data, and shall ensure that the
requirements for any physical data collection from their SUPPLIERS are covered in
any supplier instructions.

4.3 Tag Data Submission

Data shall be delivered to the project using the Data Collection Tool Template 0000RP-C-G0-
G000-IM-TPL-0013

The Data for each Physical to Functional Class mapping is detailed in 0000RP-C-G0-G000-IM-
TPL-0012

These deliverables shall be submitted via the Central Document Library (CDL) in native file
format. Any files received which are not in the format of the project templates, will be rejected.

Once CONTRACTOR has uploaded the Data Collection Tool, the data contained shall be
imported into the CTDB.

This process includes validation according to the rules defined within IHS - TECHNICAL DATA
REQUIREMENT SPECIFICATION. All feedback on the format of the data received will be included in
review comments. Validation checks shall be carried out as specified in Section 4.4. Any
feedback on the technical content of the deliverable shall remain the responsibility of the
relevant engineering disciplines

CONTRACTOR shall be responsible for the management of tag data and for the associated
review, validation and approval of SUPPLIER and SUBCONTRACTORS’ data prior to
submission to the CIS.

CONTRACTOR shall manage the delivery of SUBCONTRACTOR’S information to ensure

timely availability and delivery to meet all engineering progress milestones, commissioning and
subsequent Project Information Handover to COMPANY of as-built engineering data.

Data Completeness shall be measured based on the full set of attribute requirements defined in
IHS - TECHNICAL DATA REQUIREMENT SPECIFICATION.

It is the CONTRACTOR’S responsibility to ensure that the appropriate data submission

template is completed for each tagged item in the CONTRACTOR, SUBCONTRACTOR or
SUPPLIER scope of work. See Figure 2 - Tag Data Submission Process for full data
submission workflow.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 12 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
 Technical Data Management Procedure
Figure 2 - Tag Data Submission Process

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 13 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
 Technical Data Management Procedure

4.4 Data Submission Validation

The CTDB shall be programmed with predefined validation rules such that when the
CONTRACTOR and SUPPLIER data submission templates are submitted the following
validation checks are run and each data submission is auto-commented and a mark-up file
produced to reflect these validation checks

The validation checks are summarized as follows:

1. Has the Engineering Register been provided on the correct template

2. Are the Tag Numbers already registered in the CTDB
3. Is the Tag Number registered to the contractor submitting the engineering register
4. Are all tags on a register operational
5. Is the Functional Class assigned to the tag compliant with the tag to class mapping
shown in ENGINEERING NUMBERING SPECIFICATION .
6. Is the Functional Class assigned to the tag allowed to be submitted on the
engineering register? (e.g. cable tag will not be valid on a Line List register)
7. Are expected attributes completed?
8. Are non-expected attributes completed?
9. Do attribute values comply with the pre-defined validation rules shown in Table 1 -
Example validation rules below

Table 1 - Example validation rules

Validation Rule Validation Rule Definition

1 Alpha Shall be letters only

2 Alphanumeric Combination of letters and numbers

3 Code exists in Central Information Store Shall be valid code in pick list defined in Central Information Store
Status Code exists in Central Information Store
4 Shall be R, O or V
(R, O or V)
Document type code exists in Central
5 Information Store as defined in COMPANY Shall be valid code as defined in Document Numbering Procedure
Document Management Procedure
Tag Code exists in Central Information Store as
6 defined in COMPANY Engineering Tag Shall be valid code as defined in Engineering Numbering Specification
Numbering Specification
7 Date (YYYY-MM-DD) Shall be date in YYYY-MM-DD i.e. 2010-10-25
Document Number exists in Central Information
8 Document number shall be registered in Central Information Store
Store
Shall be numbers (0 – 9) only
No commas allowed
9 Numeric
Decimal number shall be indicated with “.” i.e. 10.7 NOT 10,7
Use of fractions is not allowed i.e. 0.75 NOT 3/4
Tag must exist in tag register & assigned to Tag number shall be previously registered by CONTRACTOR in
10
CONTRACTOR Central Information Store
Shall be UoM as defined in the Technical Data Requirement
11 UoM
Specification
12 Y or N Shall be either Y or N

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 14 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

Each tagged item on the data submission shall be auto-commented, and a mark-up file
produced to reflect these validation checks.

The mark-up file shall be indicated as follows:

• Red - Value is not valid as per predefined validation rules. CONTRACTOR to update
before next data submission.
• Amber - COMPANY discipline to review and comment, and CONTRACTOR to update
before next data submission if applicable.
• Green - Value is valid as per predefined validation rules. COMPANY discipline to review
and comment, and CONTRACTOR to update before next data submission if applicable.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 15 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure
4.5 Data Maturity & Deliver y

4.5.1 Data Maturit y

COMPANY has defined a data requirement per tagged item named as “Tag Maturity Level”.

The purpose of this data requirement is such that the CONTRACTOR declares the state of
maturity per tagged item. This aids Engineering, Commissioning, Completions and Operations
to understand how mature the tagged item is, and whether the tagged item is i.e. ready to be
commissioned, whether maintenance routines have been developed & applied, etc. It also
assists the phased handover of the project tag data to COMPANY.

It is the CONTRACTOR’S responsibility to accurately maintain and set the “Tag Maturity Level”
for each allocated and registered project tag number by uploading the Data Collection Tool as
latest information is available.

4.5.2 Data Deli ver y

As document submissions are received into the CTDB, COONTRACTOR shall measure the
completeness of the delivery of the Functional, Physical and Commissioning / Completions /
Operations data requirements.

CONTRACTOR shall advise COMPANY of completeness with regular reporting updates.

Each tagged item must reach 100% data completeness, and tag maturity level 160. Handover
to be deemed delivered to COMPANY.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 16 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company
Technical Data Management Procedure

4.6 HANDOVER/CLOSE OUT

During the Execute phase, the CTDB shall be the point from which data is extracted for
Commissioning and for data handover to Operations.

Prior to handover to Operations, the CTDB should be sufficiently populated so that all the tag
registers (Line List, Master Equipment List, Cable Schedule, Instrument Index, etc.) shall be
obtained directly from this central location.

CONTRACTOR shall produce a close out plan detailing the methodology that will be applied to
handing over final project data and project close out to demonstrate compliance to the
Information Handover Specification.

Once the “Tag Maturity Level” (as defined in Section 4.5.1) has reached maturity level 160
“Handover” and the associated data is 100% complete, the tagged item and associated data
shall be classified as complete and delivered to COMPANY by the CONTRACTOR.

Reports shall be made available to Operations to confirm acceptance of the tagged item and
associated data.

0000RP-C-G0-G000-DM-PRO-0002 Rev B02 (08 Aug 2017) Page 17 of 17

This document is the property of Rumaila Field Develops Projects. It must not be stored, reproduced or disclosed to others without written authorisation from the Company