DEP SPECIFICATION

SMARTPLANT INSTRUMENTATION (SPI) –

PROJECT EXECUTION

DEP 32.31.00.35-Gen.

February 2013
ECCN EAR99

DESIGN AND ENGINEERING PRACTICE

© 2013 Shell Group of companies

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, published or transmitted, in any form or by any means, without the prior
written permission of the copyright owner or Shell Global Solutions International BV.

This document contains information that is classified as EAR99 and, as a consequence, can neither be exported nor re-exported to any country which is under an
embargo of the U.S. government pursuant to Part 746 of the Export Administration Regulations (15 C.F.R. Part 746) nor can be made available to any national of such
country. In addition, the information in this document cannot be exported nor re-exported to an end-user or for an end-use that is prohibited by Part 744 of the Export
Administration Regulations (15 C.F.R. Part 744).
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 2

PREFACE

DEP (Design and Engineering Practice) publications reflect the views, at the time of publication, of Shell Global Solutions
International B.V. (Shell GSI) and, in some cases, of other Shell Companies.
These views are based on the experience acquired during involvement with the design, construction, operation and
maintenance of processing units and facilities. Where deemed appropriate DEPs are based on, or reference international,
regional, national and industry standards.
The objective is to set the standard for good design and engineering practice to be applied by Shell companies in oil and
gas production, oil refining, gas handling, gasification, chemical processing, or any other such facility, and thereby to help
achieve maximum technical and economic benefit from standardization.
The information set forth in these publications is provided to Shell companies for their consideration and decision to
implement. This is of particular importance where DEPs may not cover every requirement or diversity of condition at each
locality. The system of DEPs is expected to be sufficiently flexible to allow individual Operating Units to adapt the
information set forth in DEPs to their own environment and requirements.
When Contractors or Manufacturers/Suppliers use DEPs, they shall be solely responsible for such use, including the
quality of their work and the attainment of the required design and engineering standards. In particular, for those
requirements not specifically covered, the Principal will typically expect them to follow those design and engineering
practices that will achieve at least the same level of integrity as reflected in the DEPs. If in doubt, the Contractor or
Manufacturer/Supplier shall, without detracting from his own responsibility, consult the Principal.
The right to obtain and to use DEPs is restricted, and is typically granted by Shell GSI (and in some cases by other Shell
Companies) under a Service Agreement or a License Agreement. This right is granted primarily to Shell companies and
other companies receiving technical advice and services from Shell GSI or another Shell Company. Consequently, three
categories of users of DEPs can be distinguished:
1) Operating Units having a Service Agreement with Shell GSI or another Shell Company. The use of DEPs by these
Operating Units is subject in all respects to the terms and conditions of the relevant Service Agreement.
2) Other parties who are authorised to use DEPs subject to appropriate contractual arrangements (whether as part of
a Service Agreement or otherwise).
3) Contractors/subcontractors and Manufacturers/Suppliers under a contract with users referred to under 1) or 2)
which requires that tenders for projects, materials supplied or - generally - work performed on behalf of the said
users comply with the relevant standards.
Subject to any particular terms and conditions as may be set forth in specific agreements with users, Shell GSI disclaims
any liability of whatsoever nature for any damage (including injury or death) suffered by any company or person
whomsoever as a result of or in connection with the use, application or implementation of any DEP, combination of DEPs
or any part thereof, even if it is wholly or partly caused by negligence on the part of Shell GSI or other Shell Company. The
benefit of this disclaimer shall inure in all respects to Shell GSI and/or any Shell Company, or companies affiliated to these
companies, that may issue DEPs or advise or require the use of DEPs.
Without prejudice to any specific terms in respect of confidentiality under relevant contractual arrangements, DEPs shall
not, without the prior written consent of Shell GSI, be disclosed by users to any company or person whomsoever and the
DEPs shall be used exclusively for the purpose for which they have been provided to the user. They shall be returned after
use, including any copies which shall only be made by users with the express prior written consent of Shell GSI. The
copyright of DEPs vests in Shell Group of companies. Users shall arrange for DEPs to be held in safe custody and Shell
GSI may at any time require information satisfactory to them in order to ascertain how users implement this requirement.
All administrative queries should be directed to the DEP Administrator in Shell GSI.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 3

TABLE OF CONTENTS
1. INTRODUCTION ........................................................................................................ 5
1.1 SCOPE........................................................................................................................ 5
1.2 DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS ......... 5
1.3 DEFINITIONS ............................................................................................................. 5
1.4 CROSS-REFERENCES ............................................................................................. 6
1.5 SUMMARY OF MAIN CHANGES ............................................................................... 7
1.6 COMMENTS ON THIS DEP ....................................................................................... 7
2. SPI PROJECT EXECUTION OVERVIEW .................................................................. 8
2.1 EXECUTION PATH .................................................................................................... 8
3. EXECUTION STEP 1 – VERSION AND SCRIPTING ................................................ 9
3.1 DATABASE PLATFORM ............................................................................................ 9
3.2 SPI VERSIONS/SERVICE PACKS/HOTFIXES ......................................................... 9
4. EXECUTION STEP 2 – BASELINE LOAD .............................................................. 10
4.1 DATABASE SELECTION ......................................................................................... 10
4.2 SPI GLOBAL TEMPLATE – ISA AND ISO VERSIONS ........................................... 10
4.3 GLOBAL TEMPLATE REGULATED CONTENTS.................................................... 11
4.4 UNREGULATED GLOBAL TEMPLATE CONTENTS .............................................. 12
4.5 SPI GLOBAL TEMPLATE MOC ............................................................................... 12
4.6 FEEDBACK TO THE SPI GLOBAL TEMPLATE ...................................................... 12
5. EXECUTION STEP 3 – DESIGN REQUIREMENTS AND PHILOSOPHY .............. 13
5.1 REVIEW OF STANDARDS FOR APPLICABILITY................................................... 13
5.2 HOSTING PLAN AND HOSTING SELECTION........................................................ 14
5.3 POPULATE LOOKUP TABLES ................................................................................ 15
5.4 PROJECT DELIVERABLE REQUIREMENTS ......................................................... 15
5.5 DEFINE MINIMUM DATA REQUIREMENTS ........................................................... 16
5.6 DESIGN PHILOSOPHIES ........................................................................................ 19
5.7 DEFINE USER ACCESS RIGHTS ........................................................................... 21
6. EXECUTION STEP 4 – PROJECT CONFIGURATION ........................................... 22
6.1 HIERARCHY STRUCTURE...................................................................................... 22
6.2 PLANT BREAKDOWN STRUCTURE (PBS) ............................................................ 22
6.3 NAMING CONVENTIONS ........................................................................................ 22
6.4 UNITS OF MEASURE (UOM) – IMPERIAL OR SI ................................................... 23
6.5 USER DEFINED FIELDS AND TABLES .................................................................. 23
6.6 INSTRUMENT TYPES AND PROFILES MODIFICATIONS .................................... 23
7. EXECUTION STEP 5 – PROJECT IMPLEMENTATION ......................................... 24
7.1 SPI PROJECT DELIVERABLES EXECUTION ........................................................ 24
7.2 TECHNICAL ASSURANCE ...................................................................................... 24
8. EXECUTION STEP 6 – HANDOVER ....................................................................... 25
8.1 OVERVIEW ............................................................................................................... 25
8.2 DATA AUDIT ............................................................................................................. 25
8.3 STANDARD INSTRUMENT INDEX BROWSER VIEWS ......................................... 25
8.4 MAPPING OF EXTERNAL DOCUMENTS ............................................................... 26
8.5 CLEANUP OF USER ACCOUNTS ........................................................................... 26
8.6 SECURITY GROUPS ............................................................................................... 26
8.7 DELIVERED FORMAT OF THE SPI DATABASE .................................................... 26
8.8 ENSURING HEALTH OF THE SPI DATABASE ...................................................... 26
8.9 SPI DATABASE DELIVERY ..................................................................................... 26
8.10 FOLLOW-UP ............................................................................................................. 26
9. REFERENCES ......................................................................................................... 27
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 4

APPENDICES
APPENDIX A SPI ORGANIZATION AND STRUCTURE ...................................................... 28
APPENDIX B SPI ENGINEERING AND DESIGN ROLES AND RESPONSIBILITIES ........ 30
APPENDIX C INFORMATION SECURITY ............................................................................ 31
APPENDIX D EXPORT CONTROLS ..................................................................................... 31
APPENDIX E APPLICATIONS USED BY THE CONTRACTOR .......................................... 32
APPENDIX F INFORMATION FROM SUB-CONTRACTORS .............................................. 32
APPENDIX G INFORMATION REVIEW AND APPROVAL BY THE PRINCIPAL ............... 32
APPENDIX H SPI PROJECT SPECIFICATION (EXAMPLE FRAMEWORK) ...................... 32
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 5

1. INTRODUCTION

1.1 SCOPE
This new DEP specifies requirements and gives recommendations for the execution plan,
implementation, and configuration of a SmartPlant Instrumentation (SPI) project. It is
applicable for new projects of all sizes, as SPI assists in production of the majority of
instrumentation deliverables.
Quality SPI project execution is especially significant, given that the resulting database is
highly valuable for the maintenance of a facility for its entire operational lifespan.

1.2 DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS

Unless otherwise authorised by Shell GSI, the distribution of this DEP is confined to Shell
companies and, where necessary, to Contractors and Manufacturers/Suppliers nominated
by them. Any authorised access to DEPs does not for that reason constitute an
authorisation to any documents, data or information to which the DEPs may refer.
This DEP is intended for use in facilities related to oil and gas production, gas handling, oil
refining, chemical processing, and gasification. This DEP may also be applied in other
similar facilities.
When DEPs are applied, a Management of Change (MOC) process shall be implemented;
this is of particular importance when existing facilities are to be modified.
If national and/or local regulations exist in which some of the requirements could be more
stringent than in this DEP, the Contractor shall determine by careful scrutiny which of the
requirements are the more stringent and which combination of requirements will be
acceptable with regards to the safety, environmental, economic and legal aspects. In all
cases, the Contractor shall inform the Principal of any deviation from the requirements of
this DEP which is considered to be necessary in order to comply with national and/or local
regulations. The Principal may then negotiate with the Authorities concerned, the objective
being to obtain agreement to follow this DEP as closely as possible.

1.3 DEFINITIONS
1.3.1 General definitions
The Contractor is the party that carries out all or part of the design, engineering,
procurement, construction, commissioning or management of a project or operation of a
facility. The Principal may undertake all or part of the duties of the Contractor.
The Manufacturer/Supplier is the party that manufactures or supplies equipment and
services to perform the duties specified by the Contractor.
The Principal is the party that initiates the project and ultimately pays for it. The Principal
may also include an agent or consultant authorised to act for, and on behalf of, the
Principal.
The word shall indicates a requirement.
The word should indicates a recommendation.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 6

1.3.2 Specific definitions

Term Definition
Shell SPI Global Template that consists of two core databases (based on ISA and ISO
Template standards), essential in the development of regional SPI projects
databases. These contain standardized Shell elements such as
instrument types, specification sheets, I/O card libraries, etc.
seed database SPI database ready for implementation and approved by the Principal
for regional requirements.
instrument type Letter code established to describe an instrument’s function.

1.3.3 Abbreviations

Term Definition
CMMS computerized maintenance management system
EIS engineering information specification
EPC engineering, procurement and construction (contractor)
ERU Enhanced Report Utility (interchangeable with ESI)
ESL Enhanced Smart Loop (interchangeable with ERU)
G-SIST Global SPI Implementation & Support Team
ISA Instrument Society of America
ISO International Organization for Standardization
MAC main automation contractor
OU operating unit
PAU plant – area – unit
PBS plant breakdown structure
PSR powersoft report file extension
PAS process automation system (consisting of BPCS, SIS, FGS etc)
PEFS process engineering flow scheme
RTA Regional Technical Authority
SoW scope of work
SPEL SmartPlant Electrical
SPF SmartPlant Foundation
SPI SmartPlant Instrumentation
SPPID SmartPlant P&ID
TBD to be determined
UOM units of measure
UDF user defined field(s)
UDT user defined table(s)

1.4 CROSS-REFERENCES
Where cross-references to other parts of this DEP are made, the referenced section
number is shown in brackets ( ). Other documents referenced by this DEP are listed in (9).
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 7

1.5 SUMMARY OF MAIN CHANGES

This is a new DEP.

1.6 COMMENTS ON THIS DEP

Comments on this DEP may be submitted to the Administrator using one of the following
options:

Shell DEPs Online Enter the Shell DEPs Online system at

https://www.shelldeps.com
(Users with access to
Shell DEPs Online) Select a DEP and then go to the details screen for
that DEP.
Click on the “Give feedback” link, fill in the online
form and submit.

DEP Feedback System Enter comments directly in the DEP Feedback

(Users with access to System which is accessible from the Technical
Shell Wide Web) Standards Portal http://sww.shell.com/standards.
Select “Submit DEP Feedback”, fill in the online form
and submit.

DEP Standard Form Use DEP Standard Form 00.00.05.80-Gen. to record

(Other users) feedback and email the form to the Administrator at
standards@shell.com.

Feedback that has been registered in the DEP Feedback System by using one of the above
options will be reviewed by the DEP Custodian for potential improvements to the DEP.
 ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 8

2. SPI PROJECT EXECUTION OVERVIEW

2.1 EXECUTION PATH

The following diagram illustrates the recommended SPI project execution path, organized
into six execution steps:

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version Baseline Design Project Project Handover
and Load Requirements & Configuration Implementation
Scripting Philosophy

Sections (3) through (8) provide requirements and guidelines for each execution step. The
requirements/guidelines are general in nature and are therefore applicable for many
situations across the Principal’s regions.
The Principal’s regions are expected to take this execution path and mature it per local
project learnings.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 9

3. EXECUTION STEP 1 – VERSION AND SCRIPTING

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version Baseline Design Requirements Project Project Handover
and Load and Philosophy Configuration Implementation
Scripting

Step 1 – Version and Scripting defines application and database requirements for SPI. This
can be done at the Principal or Contractor locations.

3.1 DATABASE PLATFORM

All handover databases shall be formatted for, and compliant with, the Principal’s particular
Oracle infrastructure requirements. Any transformation requirements at handover based on
platform changes are the responsibility of the Contractor.
In situations where an SPI database is hosted outside of Shell infrastructure (e.g., a
contractor office), the host shall house the project database on a dedicated SPI
server/instance containing only the Principal’s projects and/or the Principal’s data.

3.2 SPI VERSIONS/SERVICE PACKS/HOTFIXES

Whether housed at the Principal location or the Contractor office, all new project databases
shall be created in the latest version standardized by the Principal.
The current version, service pack, hotfix number and scripting guidelines are available via
the Shell SPI Wiki Site. See section “GID Scripts and Request Site”. Selected version,
service pack and hotfix shall be listed in the specific project’s SPI project specification; see
(5).
Contractors shall coordinate with the Principal’s Regional SPI Administrators to ensure their
versioning is set correctly per the Principal’s standards.
Contractors shall not upgrade or hotfix their systems without approval of the Principal’s
Regional SPI Administrators. Contractors may assume the database will remain on a
singular version for a significant amount of time, if not the entire life span of the project.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 10

4. EXECUTION STEP 2 – BASELINE LOAD

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version Baseline Design Requirements Project Project Handover
and Load and Philosophy Configuration Implementation
Scripting

Once the SPI database platform and application are in place, the project moves to Step 2 –
Baseline Load. In this step, a template database is selected and loaded into the
server/instance for the purpose of project implementation.

4.1 DATABASE SELECTION

A template database is required in the creation of new SPI projects. The expectation is that
greenfield projects will use the SPI Global Template database.
Where a mature, regionally modified SPI database exists (sourced from the global
template), it may be used to facilitate the baseline load. But in all cases, the Principal shall
confirm which source database will be used for the project baseline load. The following
figure visually defines the process:

SPI Global Template

SPI Global Template
(Baseline Load) (I
(Baseline Load)

Version and Design Requirements

Scripting and Philosophies

Mature Regional SPI

database
(Baseline Load)

4.2 SPI GLOBAL TEMPLATE – ISA AND ISO VERSIONS

The SPI Global Template is comprised of two core SPI databases provided by the
Principal, in ISA and ISO configurations.
Each SPI template database contains four key categories of standardized information.
These are:
a. Instrument types and profiles
b. Specifications forms
c. Control system I/O card libraries
d. User defined fields and tables (UDFs and UDTs)
Sections (4.3.1 – 4.4.4) provide specific information concerning the global template
contents:
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 11

4.3 GLOBAL TEMPLATE REGULATED CONTENTS

4.3.1 Profiled instrument types
SPI Instrument types are standardized across the Principal’s regions, and regulated per
SAP EIS class definition. Instrument type listings vary somewhat between the ISA and ISO
versions of the template. The following references define instrument type coding. Consult
your project’s SPI project specification; see (5) for additional project specific information
regarding instrument type coding:
a. EIS class definition and conformance
b. SPI instrument types and the sap equivalent code (ISA)
c. Global template instrument type detail report (ISA)
d. Recommended instrument types legend sheet (ISA)
e. SPI instrument types and the SAP equivalent code (ISO)
f. Global template instrument type detail report (ISO)
g. Recommended instrument types legend sheet (ISO)
4.3.2 Specification forms
Specification forms delivered with the SPI Global Template are standardized for use across
the Principal’s regions. Any required modifications to the form library for a particular project
shall be approved by the RTA and Regional SPI Administrators.
Other specification form libraries exist within Shell (such as GAME), however these are not
provided with the template databases. The use of other libraries by project teams is not
covered under the guidelines of this DEP.
Refer to your project’s SPI project specification for additional information.
4.3.3 Control system I/O card libraries
The SPI Global Template, both ISA and ISO versions, contain I/O card libraries for four
control system Manufacturers for use on the Principal’s projects. Additional libraries may be
added in the future. Manufacturer/Supplier libraries currently available are:
a. Emerson
b. Honeywell
c. Foxboro
d. Yokogawa
4.3.4 User defined fields and user defined tables
Certain user defined fields (UDFs) and user defined tables (UDTs) are reserved for the
Principal’s global, regional, and Contractor usage. EPC UDF/UDT definitions required
during the project shall be approved by the Principal prior to use. All EPC UDF/UDT
contents shall be reviewed at the completion of the project before the database is accepted
by the Principal.
Any UDF and UDT data that does not meet the Principal’s global and regional requirements
may require modification by the Contractor(s) prior to final delivery.
Refer to the SPE DEP Informative for a listing of global reserved user defined fields.
Please refer to your project’s SPI project specification for additional information.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 12

4.4 UNREGULATED GLOBAL TEMPLATE CONTENTS

The following additional lookup tables and miscellaneous items are provided with the SPI
Global Template databases:
a. Reference junction boxes
b. Reference marshalling racks
c. Reference device panels
d. Reference cables
e. Reference DCS panels
f. Wiring connection types
g. Instrument locations
h. Instrument statuses
i. Loop types
j. Loop functions
k. Equipment types
l. Line types
m. Standard Powersoft reports
n. Standard browser views
o. Standard process unit codes
p. Enhanced report symbol library
The above items contain data that may be of use with regional projects, but are provided as
examples only. Their use is not regulated by the Principal, and the Regional SPI
Administrators may modify them as required:

4.5 SPI GLOBAL TEMPLATE MOC

As regions and Contractors mature/maintain their own regional database, advancements
will continue with future releases of the SPI Global Template. Each succeeding release of
the template will be documented by the SPI global team with the Management Of Change
(MOC) process

4.6 FEEDBACK TO THE SPI GLOBAL TEMPLATE

The SPI Global Template benefits greatly from regional learnings. Findings and
commentary may be sent to the G-SIST team for consideration/inclusion into future
releases. Please send comments to an SPI Design Center listed below:
• New Orleans for ISA template issues
Edward Merchan (edward.merchan@shell.com)
Dan Williams (dan.williams@shell.com)
• Aberdeen for ISO template issues
Martin Swaine (martin.swaine@shell.com)
Tony Beamish (tony.beamish@shell.com)
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 13

5. EXECUTION STEP 3 – DESIGN REQUIREMENTS AND PHILOSOPHY

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version Baseline Design Requirements Project Project Handover
and Load and Philosophy Configuration Implementation
Scripting

Step 3 – Design Requirements and Philosophy details the authoring of an SPI project
specification, which covers configuration and implementation (to be carried out in Step 4
and Step 5). All major decisions regarding the governance of the project SPI database shall
be determined and described in the SPI project specification prior to the completion of the
FEED phase.

5.1 REVIEW OF STANDARDS FOR APPLICABILITY

Instrumentation group leadership shall review standard database objects for applicability.
They shall document all required changes and additions to the standard objects in the SPI
project specification.
5.1.1 Instrument types and profiles
Prior to the development of the instrument legend sheets for P&ID diagrams, instrument
type codes shall be identified and approved by the Principal. To aid in this process,
standard instrument types are provided with the SPI Global Template database.
Instrument type profiles shall be also indentified and approved by the Principal. The
standard instrument types provided with the SPI Global Template come preloaded with
profiled information.
5.1.2 Instrument specification forms
Specification forms are standardized across the Principal’s regions. These forms shall be
used as the basis for all new greenfield projects. The forms shall be reviewed according to
project requirements. Regional and/or global SPI administrators may be contacted for
additional specification form needs, however the standard specification forms library shall
be applied to projects. Any deviations shall be approved by the Principal.
For brownfield projects, the Principal shall indicate if the specification sheets available
within the Global Template shall be used, or if the existing site specification sheets are to
be used.
5.1.3 Control system I/O card libraries
A control systems library, based on project control systems requirements, shall be identified
and produced,. Libraries for Emerson, Foxboro, Honeywell and Yokogawa systems are
delivered with the SPI Global Template. Once identified, all unnecessary control system
libraries shall be removed from the SPI reference data, prior to detail design (to avoid
confusion).
5.1.4 User defined fields and user defined tables
Multiple contractors share the same fields in SPI, and the capacity for using them in
different manners is significant. UDFs and UDTs shall be carefully managed to avoid data
problems at handover in the receiving facility. Please note the following:
a. Reserved global UDFs and UDTs shall be observed by regions and their Contractors.
b. The Principal shall approve all UDT and UDF usage for the project. A register of
globally and locally reserved UDFs and UDTs shall be maintained, and the
information communicated to all Contractors.
c. Contractors shall submit all UDF and UDT requirements to the Regional SPI
Administrators for approval.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 14

5.2 HOSTING PLAN AND HOSTING SELECTION

A strategic plan for hosting and host selection shall be developed and listed in the SPI
project specification.
5.2.1 Database modes
SPI may be configured in one of two modes (1) Engineering Project or (2) Owner Operator.
Engineering Project, is a standalone database, generally intended for one engineering team
to access. Owner Operator, is designed for simultaneous, multiple contractor access.
Critical Note: NEVER assume that separate standalone SPI databases (Engineering
Project type) can be sent to multiple EPC Contractors, with the idea that they will be
merged together in the end. This is a highly costly endeavour that:
a. will require outside consulting
b. will only achieve partial integration
c. can hurt the uptake and reputation of the data in the facility
d. can significantly decrease the overall value of the investment
This shall NOT occur for any project without written approval from the Principal and
Regional SPI Administrators.
5.2.2 Selecting an SPI host
A skilled, vetted party shall be selected to host the SPI database. This is a critical step in
any successful implementation strategy for SPI.
5.2.3 SPI host management
The requirements to manage an SPI database with multiple connected parties are
significant. The following items detail major expectations from a vetted SPI host:
a. SPI databases require back-office maintenance, knowledge of IT systems, and a
carefully documented approach.
b. Hosting administrators require considerable knowledge of engineering and design
work processes.
c. The SPI host serves as a liaison, being sensitive to contractual issues, personalities,
and conflicts of interest.
5.2.4 Project seed development
Because of the SPI host’s key role in managing multiple contractors, development of the
project seed database is also placed in the host’s scope. Accordingly, the SPI host shall
author the project specification and configure the SPI database, with approvals from the
Principal and Regional SPI Administrators.
5.2.5 EPC self check
The selected SPI host company shall institute an EPC self check policy. EPC Contractors
shall regularly check themselves for adherence to project standards, completeness, and
consistency. Criteria for the self check shall be defined by the Principal’s RTA.
Application tools required for self check shall be defined and/or provided by the SPI host
with guidance of the Principal’s Regional SPI Administrators.
EPC quality reports (based on self checking) shall be issued to the Principal for review at
regular intervals. The frequency and schedule of these reports shall be determined by the
RTA and Regional SPI Administrators.
5.2.6 SPI host auditing
The selected SPI host shall also institute an auditing policy from a host perspective. The
host shall review project data across all participating EPC Contractors at regular intervals.
The review shall be for adherence to the Principal’s standards, completeness, and
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 15

consistency. Additionally the SPI host shall supervise on issues of IT security and database
health.
The application tools required for auditing shall be defined by the Principal’s Regional SPI
Administrators. The SPI host shall regularly provide audit reports to the Principal at an
interval agreed upon by the RTA and Regional SPI Administrators.
5.2.7 SPI host handover
The SPI hosting company shall execute all procedures defined in Execution Step 6
“Handover”, in association with database delivery to the facility.
5.2.8 SPI hosting support and impacts
The hosting procedures listed in (5.2.x) carry through the entire lifecycle of an SPI project.
The hosting company should be considered an active, constantly involved member of a
successful project team.

5.3 POPULATE LOOKUP TABLES

Drop-down lists in SPI typically link to separate tables of information. These provide a
method of standardizing data entry within key fields. The RTA, Regional SPI Administrators
and Contractors shall review the standard values in these tables and populate them with
additional values as required. The Principal shall oversee the management of these tables.
Their contents shall be listed in the SPI project specification.
5.3.1 Index lookup tables
The following index lookup tables shall be reviewed and populated according to project
need:
a. Status
b. Location
c. Equipment
d. P&ID drawing
e. Line number
f. Manufacturer
g. Model
h. Measured variables
i. Loop type
j. Loop function
k. Certification
5.3.2 Wiring lookup tables
The Principal’s Regional SPI Administrators shall determine the extent to which wiring
module supporting tables will be utilized per local practices. A policy shall be specified in
the SPI project specification.

5.4 PROJECT DELIVERABLE REQUIREMENTS

The SPI project specification shall specify the expected SPI deliverables and their formats
for the project. On typical projects, contractors shall provide the following SPI reports to the
Principal’s facility:
a. Calibration report
b. Equipment specification datasheets
c. Wiring diagrams
d. Cross-wiring
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 16

e. Loop diagrams
f. Control system’s I/O report
g. Controls system’s control panel report
h. Control system’s I/O module loading report
i. Foundation fieldbus segment maps
Note: Loop diagrams shall be provided for all foundation fieldbus loops, regardless of their representation on
supplied fieldbus segment mapping diagrams.

Additionally, custom instrument index reports are provided with the SPI Global Template.
The instrument index module shall be populated adequately to allow for the proper
generation of these reports. Field requirements shall be determined by the Regional SPI
Administrators and appropriate OU staff.
Refer to the project’s SPI project specification for additional information.
a. Instrument summary report
b. Procurement summary report
c. Construction summary report
d. Run and maintain summary report
e. Master design trip summary report

5.5 DEFINE MINIMUM DATA REQUIREMENTS

The following SPI modules shall be utilized at a minimum (for typical projects):
a. Browser
b. Index
c. Process data
d. Specifications
e. Document binder
f. Wiring
g. Loops
The RTA and SPI administrators shall determine minimum required fields for each SPI
module listed below in (5.5.1 to 5.5.7). Field requirements may evolve as project phases
progress from FEED, through to construction. Therefore updated requirements listings
should be produced for each phase (as necessary). All field requirements shall be
documented in the SPI project specification.
Note: Field requirements shall be provided to sub-contractors as conditions of the contract.

The Principal’s SPI administrators shall meet with facility operations staff regarding
minimum data requirements for Run and Maintain. These requirements shall be specified in
the SPI project specification.
The Contractors shall conform to all contractual agreements regarding data requirements,
and seek approval from the Principal’s RTA in the case of deviations.
5.5.1 Instrument index notes
At a minimum, all instruments requiring specification sheets or wiring shall be entered into
the Instrument Index.
The addition of software tags in the index shall be determined on a project-by-project basis.
See (5.6.3) for more information.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 17

The Principal’s regions and their Contractors shall conform to reserved UDF and UDT
requirements set by the Principal’s global community. Additional user fields and tables shall
be controlled and implemented by the Regional SPI Administrators.
The instrument index contains three sets of range fields. The following figure guides their
usage:

Inst_range_min This field group represents the manufactured

inst_range_max physical range of an instrument.
inst_range_uom_max
inst_range_uflg_max

calib_range_min This field group represents the calibrated range for

calib_range_max an instrument in its current application.
calib_range_uom_max
calib_range_uflg_max

dcs_range_min
This field group represents an instrument’s
reported range in the associated control system.
dcs_range_max
dcs_range_uom

The following fields shall NOT be used, to avoid confusion. These are redundant in the SPI
software and users are typically unaware of a potential problem:
• inst_range_uom_min
• inst_range_uflg_min
• calib_range_uom_min
• calib_range_uflg_min
5.5.2 Specification sheet notes
The specification module shall be used to create and modify instrument specification sheets
for the purpose of procuring, maintaining and archiving instrument equipment information.
The Principal’s specification sheet library has been developed to meet both engineering
and facility maintenance requirements.
In specific situations with the approval of the Principal, Manufacturer/Supplier specification
sheets may be attached in the database in their native format in lieu of SPI specifications.
Normally however, SPI specification sheets shall be the central location for all specification
data. External Manufacturer/Supplier data shall be re-entered into SPI via manual or
automated means (with administration assistance).
All specification revisions shall be archived in SPI. Revision title, signatures, etc., shall be in
accordance with the project revision philosophy. To alleviate known issues with internal
document archives in SPI, all archived specifications shall be configured to save to an
external folder structure. The location and path of external archives shall be documented in
the SPI project specification.
5.5.3 Process data notes
The RTA and SPI administrators shall determine the minimum process data fields required
for specifying instrumentation, with particular focus to those required for sizing calculations.
The RTA shall also define default units of measure settings for the devices.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 18

Process data may be entered at the piping line or instrument level. The RTA and SPI
administrators shall define the default method by which process data is entered for the
project.
Process data revisions shall be entered in the customary revision mechanism included in
the SPI process data module. Revision title, signatures, etc. shall be in accordance with the
project revision philosophy. Regional SPI administrators shall define configuration of the
document archive for process data reports.
5.5.4 Calculation fields notes
The Principal’s regions and Contractors shall use appropriate Manufacturer/Supplier sizing
software where applicable. SPI sizing calculations shall not be used.
Upon receipt of certified Manufacturer/Supplier sizing information, results shall be entered
in the proper SPI reserved fields.
Whenever possible, Manufacturer/Supplier calculation sheets shall be attached to their
respective tag numbers in the SPI index, under ‘Associated Documents’.
5.5.5 Wiring module notes
The RTA and the Regional SPI Administrators shall determine the minimum field
requirements for specifying wiring devices in SPI.
In general, only connection and routing related information such as panel name, strip name,
terminal number, cable name, wire tag, wire colour, polarity, etc., are critical to the wiring
effort.
Wiring report revisions shall be entered in the customary revision mechanism included in
the SPI wiring module. Revision title, signatures, etc. shall be in accordance with the project
revision philosophy. The SPI administrators shall define the configuration of the document
archive for wiring reports.
5.5.6 Loops module notes
The Enhanced Smart Loop (ESL) application shall be utilized on projects for all applicable
loop diagrams. Manual AutoCAD drawings shall be used only to generate loop diagrams
too cumbersome for ESL to comfortably perform.
Typically the Principal incorporates only basic macros covering wiring entities – panels,
strips, terminals, cables, wires etc. into ESL loop diagrams. The RTA and SPI
administrators shall determine the minimum field requirements for specifying loop diagrams
in SPI.
The RTA shall determine reference drawing requirements for ESL loop diagrams.
A custom title block should be developed to match the format of existing facility wiring
drawings. The Regional SPI Administrator shall oversee and modify the ESL symbol library
and title blocks according to local requirements as necessary.
Loop diagram revisions shall be entered in the customary revision mechanism included in
the SPI Loops module. Revision title, signatures, etc shall be in accordance with the project
revision philosophy. The SPI administrators shall define configuration of the document
archive for loop diagrams.
5.5.7 Hook-Ups module notes
The SPI Hook-Ups module shall not be used on Principal’s projects.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 19

5.6 DESIGN PHILOSOPHIES

The following sections list recommended design philosophies useful in SPI project
execution.
5.6.1 Loop typicals philosophy
Regionally, a catalogue of loop typicals should be developed for reference in building of the
instrument index. This allows for consistent creation of loops and instruments, per regional
P&ID symbology. It should be listed in the SPI project specification.
Please refer to your project’s SPI project specification for additional information.
5.6.2 Service description philosophy
A service description philosophy shall be developed for the region by the RTA and the
Regional SPI Administrators. This document shall be included in the SPI project
specification.
The maximum character width of the service description field in SPI is 52 characters.
Descriptions are ported to control system databases, which typically have a much shorter
field requirement. The RTA and the Regional SPI Administrators shall determine the
maximum length of SPI service descriptions for the project.
Service descriptions should be very consistent in content, word order, capitalization,
abbreviations, etc.
Care should be taken to avoid duplicated information. For example, placing equipment tags
or process variables in the service description is redundant. These items already reside in
reserved SPI fields elsewhere.
A project abbreviations list for SPI should be maintained and assertively used by the
engineering team to conserve space.
All data should be entered lower case where possible to allow for additional character
space on printed reports.
5.6.3 Software tag philosophy
By default, the Principal defines SPI as a field instrumentation database. Therefore,
software tags are typically not entered, however exceptions do exist.
Ultimately, key technical staff for each project shall determine whether to include software
tags, such as indications, controls, soft alarms, operator selects, and calculation blocks.
To avoid confusion, a properly planned, documented software tag philosophy shall be
included within the SPI project specification.
5.6.4 Equipment specification philosophy
The RTA and Regional SPI Administrators shall define specification sheet philosophies,
and list them in the SPI project specification.
The Contractor shall produce instrument specifications using specification forms provided
by the Regional SPI Administrator (sourced from the Global Template).
All specification sheet drawing numbers should match the respective Instrument tag
number + ‘-SP’. Example: 10-FT-100-SP (the SPI default naming convention).
To allow the ability to view, audit, and revise instruments on an individual basis, multi-Item
instrument specifications are not provided with the SPI Global Template. Multi-item
specifications shall not be developed or utilized on Shell projects unless given specific
written consent by the Principal.
5.6.5 Intergraph External Editor philosophy
The Intergraph External Editor (IEE) is a freeware application offered by Intergraph for
editing specification sheets. It is provided primarily so that instrument manufacturers, skid
Suppliers, etc. who do not own or have access to the project SPI database, may access
SPI specifications.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 20

Where EFA-specific electronic transfers are not available with key vendors, the IEE
application is the recommended method for transferring external specification sheet
information to and from SPI.
5.6.6 Document binder philosophy
The RTA shall define whether document binders are to be utilized for a given project, and
list it in the SPI project specification. The following are key issues for consideration if
binders are used:
a. Document binder naming (e.g., purchase order number, requisition number, etc) and
alignment with other procurement principles
b. Usage for all revisions vs. purchase level revisions only
c. General notes page philosophy vs. Notes area on individual specification sheets
d. Instrument grouping philosophy (e.g., by device type, by skid, by
Manufacturer/Supplier, etc.)
5.6.7 Wiring philosophy
All SPI projects incorporating wiring should be based on a documented wiring philosophy.
It shall be described by the RTA and Regional SPI Administrators in the SPI project
specification.
A key element to this philosophy is a philosophy block diagram. This denotes major pieces
of wiring equipment, terminal strip configurations, and wiring and cable specifications. It is a
road map for wiring personnel to do their work, and is paramount to a proper wiring effort.
Refer to your project’s SPI project specification for additional information.
5.6.8 SPI wiring reports philosophy
Two wiring report types are provided within the SPI application:
a. Standard or ‘canned’ wiring reports offer much value, as they require no modifications
beyond the user performing wiring connections. This option however, provides no
means of customization.
b. Enhanced wiring reports are significantly more flexible in presentation. Additional
fields and graphical entities may be added beyond the standard setup. Arrangements
and locations of terminal and wires are movable, and title blocks can be highly
customized.
The development and implementation of enhanced reports on a project shall be evaluated
by the RTA and Regional SPI Administrators prior to the wiring effort. Decisions regarding
wiring reports shall be listed in the SPI project specification.
Go-by report template files for title block (*.sma), and for wiring diagram layouts (*.sym) are
provided as part of the SPI Global template release. Refer to your project’s SPI Project
Specification for additional information.
5.6.9 Redlining philosophy
Lines, symbols, and graphics which are added to an ESL after generation, are considered
redline items. These are not attached in the sense that they are anchored to any particular
object (panel, strip, terminal, cable, wire etc).
This feature is used to add special items like junction box outlines and revision clouds. In
an effort to standardize how ESL is used on projects, redlining should only be used at the
discretion of the RTA and SPI administrators. A policy shall be defined in the SPI project
specification to outline specifically which types of items will be added to ESL diagrams via
redlining.
5.6.10 Enhanced layout management philosophy
Layouts control arrangement and other custom settings within Enhanced SmartLoops and
Enhanced Wiring Reports. The Regional SPI Administrators shall define and provide layout
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 21

requirements for the project. No modifications should be made to the default layouts without
consent by the facility’s RTA. A top-down approach to managing these layouts is essential
for efficient and consistent wiring production. The following points should be considered:
a. Ensure that the title block file (*.sym) and the underlying layout file (*.sma) are
properly configured to meet project needs. These basic components will be used
repeatedly and thus should be as mature as possible before production begins, to
avoid future rework.
b. Develop a primary layout for each major grouping, based on logical divisions (e.g.,
panel type, I/O type, loop type, etc.).
c. During early production phases, when saving custom changes to layouts, first choose
to save at the ‘Layout Level’. This allows the user to manage large groups of
documents as one entity, thereby reducing man-hours.
d. As generated diagrams begin to mature individually, both in content and arrangement,
their layouts should be managed individually. At this point, users should save custom
layout changes to the ‘Drawing Level’. Contact the Regional SPI Administrators for
further assistance in this matter.

5.7 DEFINE USER ACCESS RIGHTS

An effective security policy shall be instigated to constrain user actions to standard work
processes and to properly secure the database. The following sections provide basic
requirements and recommendations for a foundational SPI security scheme.
5.7.1 Security options
The ‘Security Options’ dialog box is located in the administration module, under ‘System
administrator’.

The Principal’s IT policy requires a ‘Unique password’. Check this box as a minimum. This
option forbids multiple users from assigning the same password to their accounts. The
remaining available options are to be configured by the Regional SPI Administrators
according to local needs.
5.7.2 Standard access rights groups (roles)
The group names - Administrator, Design, Process, Mechanical, Instrumentation and View
Only are suggested roles to reside in your SPI database for project execution. Additional
roles such as ‘Electrician’ or ‘Technician’ may be added by the Regional SPI Administrators
according to local requirements.
5.7.3 Itemized access rights matrices
Access rights matrices are provided for standard groups (roles) contained in the SPI global
template. The RTA and Regional SPI Administrators should review and modify these rights
according to local requirements. Please refer to your project’s SPI project specification for
additional information.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 22

6. EXECUTION STEP 4 – PROJECT CONFIGURATION

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version & Baseline Design Requirements & Project Project Handover
Scripting Load Philosophy Configuration Implementation

Step 4 – Project Configuration details the configuration the project SPI database (domain),
per the SPI Project Specification.

6.1 HIERARCHY STRUCTURE

SPI databases possess a configurable hierarchy in which to organize project
instrumentation. Proper design of the database hierarchy is critical to the efficient use of
SPI in projects, facility operation and maintenance.
The SPI Host shall determine and configure the database hierarchy structure. This will be
based per the SPI project specification, learnings and decisions typically made during the
Select phase.
6.1.1 Plant/Area/Unit
The common levels of SPI hierarchy are Plant, Area and Unit (P-A-U). The levels are
defined as follows:
• Domain = The region name (or development)
• Plant = The region name (or development) + individual facility name
• Area = Highest level geographical division (examples: Topsides / Hull)
• Unit = Process unit number Code + Brief Description (examples: 21- Gas Lift,
28 – Oil Metering, etc.)

6.2 PLANT BREAKDOWN STRUCTURE (PBS)

The term Plant Breakdown Structure is synonymous to the P-A-U hierarchy. This term is
used when SPI is part of an integrated environment with an engineering data warehouse
such as SmartPlant Foundation (SPF).

6.3 NAMING CONVENTIONS

Sections (6.3.1) through (6.3.5) define tagging convention requirements for the Principal’s
SPI projects.
6.3.1 Instrument tagging
SPI tag naming conventions for instruments shall be configured by the SPI Host per project
specific requirements as listed in the SPI project specification.
Instrument tags shall:
a. Have unique names within the process unit and if possible unique names within the
area or even at the overall domain level.
b. Be associated to loops. A loop can contain as little as one tag or as many as required
by the process function.
c. Match all of the hardwired I/O shown on the P&IDs/PEFSs.
The following tagging conventions are customarily defined on typical SPI projects at a
minimum. Additional types may also be required:
a. Conventional instrument tags
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 23

b. FFB instrument tags

c. Hart instrument tags
d. Soft instrument tags
6.3.2 Loop tagging
The loop naming convention shall be configured by the SPI Host per project specific
requirements as listed in the SPI project specification.
Refer to your project’s SPI project specification for additional information.
6.3.3 Control system tagging
Careful consideration should be taken regarding control system tag naming. Issues of
prefixes, suffixes, delimeters, etc shall be detailed in the SPI project specification.
SPI administrators shall coordinate a nominally sized, test case data transfer with control
system Manufacturers/Suppliers, prior to the initial building of the instrument index. This is
to ensure that in-production transfers will succeed similarly during Execution Step 5 –
Project Execution.
6.3.4 Device panel tagging
The device panel naming convention shall follow that of its associated instrument tag,
unless detailed otherwise specifically in the SPI project specification.
The option to ‘Remove trailing spaces in each segment’ shall be checked.
6.3.5 Device cable tagging
The device cable naming convention shall follow that of its associated instrument tag,
unless detailed otherwise specifically in the SPI project specification.
The option to ‘Remove trailing spaces in each segment’ shall be checked.

6.4 UNITS OF MEASURE (UOM) – IMPERIAL OR SI

The SPI Host shall select the appropriate Global Template database (ISA or ISO version)
as the basis for their project, thereby receiving a base Imperial or SI units configuration.

6.5 USER DEFINED FIELDS AND TABLES

UDFs and UDTs, not reserved globally, may be allocated for specific project or regional
requirements. All fields and tables which are regionally assigned shall be documented and
maintained by the SPI Host in the SPI project specification.
EPCs may use non-reserved UDFs for capturing temporary project data. However, all
contractor temporary UDF/UDT data, not approved by the SPI Host is subject to review and
will likely be purged from the database at project handover.
User defined fields and tables within the global specification sheets are registered in the
global template. They are to be used strictly as designed, unless approved by the
Principal’s RTA.

6.6 INSTRUMENT TYPES AND PROFILES MODIFICATIONS

Per section (5.1.1), a review of instrument types and profiles (provided from the template
database) should have taken place. Per this review, any additions or modifications to the
instrument types or profiles shall be performed to the project database.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 24

7. EXECUTION STEP 5 – PROJECT IMPLEMENTATION

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version Baseline Design Requirements Project Project Handover
and Load and Philosophy Configuration Implementation
Scripting

The actual production of engineering and design deliverables within SPI takes place in
Step 5 – Project Implementation. The activities in Step 5 are defined below.

7.1 SPI PROJECT DELIVERABLES EXECUTION

The Contractor shall ensure that hardcopy and electronic renditions of the same document
are identical at time of handover to the Principal.
The Contractor shall provide the following deliverable reports. For detailed instructions
regarding these project deliverables, see (5) (Execution Step 3 – Design Requirements and
Philosophy):
a. Calibration report
b. Equipment specification data sheets
c. Wiring diagrams
d. Cross-wiring
e. Loop diagrams
f. Control system’s I/O report
g. Controls system’s control panel report
h. Control system’s I/O module loading report
i. Foundation fieldbus segment mapping
Note: Loop diagrams shall be provided for all foundation fieldbus loops, regardless of their representation on
supplied fieldbus segment mapping diagrams.

Additionally, the instrument index shall be populated to allow for generation of the following
custom PSR reports, based on OU and project requirements:
a. Instrument summary report
b. Procurement summary report
c. Construction summary report
d. Run and maintain summary report
e. Master design trip summary report

7.2 TECHNICAL ASSURANCE

<< FUTURE SECTION to be added 2013 per SPI workshop, June 05-06, 2012. >>
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 25

8. EXECUTION STEP 6 – HANDOVER

STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6

Version Baseline Design Requirements Project Project Handover
and Load and Philosophy Configuration Implementation
Scripting

Step 6 – Handover details the delivery of Contractor SPI databases and associated data to
the appropriate Principal operating facility. Even if the Principal provides engineering
services and has ownership of the SPI database during project execution, these
recommendations still apply.

8.1 OVERVIEW
Handover requirements shall be met in order that all delivered SPI databases contain
consistent levels of information and have a similar configuration across multiple projects.
If one or more tasks cannot be satisfied, a detailed list of exceptions with justifications shall
be submitted to the operating facility’s technical authority for approval.
The RTA shall define the timing and process for information handover in a Project SPI
Handover SoW.
All information handed over by the Contractor, whether intermediate or final, shall be
included in a formal transmittal. Prior to submitting the formal transmittal, the Contractor
shall ensure:
a. The information is numbered correctly and signed off to the appropriate authority.
b. The correct template(s) have been used.
c. The information is structured in accordance with any project specific agreements.
d. The information is classified using the correct reference data.
e. All electronic files have been virus checked.

8.2 DATA AUDIT

The SPI administration team (whether Shell or a selected SPI Host contractor) shall audit
the project database prior to handover. They shall review for adherence to Principal’s
standards, completeness, and consistency. This is especially critical in cases where multiple
EPCs access the same database.
Findings shall be delivered to responsible engineering teams in the form of auditing reports,
with expectation that corrections will be made in a reasonable amount of time.
The tools, reports and criteria used by the administrators to review shall be determined by
the Principal and the Regional SPI Administrators.

8.3 STANDARD INSTRUMENT INDEX BROWSER VIEWS

Standard index browsers shall be created and configured to reflect data in the format of the
printed deliverables. The following standard views are required from the Contractor:
a. Instrument summary by tag
b. Instrument summary by loop
c. Control system I/O list
These three basic views should contain all fields from the index appearing on their
corresponding PSR report deliverables. The fields should be arranged in a similar order
and the view sorted in the same manner as the report.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 26

Additional browser views may be created to further delineate the facility by unit or some
other criteria as required.

8.4 MAPPING OF EXTERNAL DOCUMENTS

Electronic external documents, attached to the SPI instrument index such as cutsheets,
calculations, Manufacturer/Supplier information, schematics, quotes, digital pictures, etc.,
shall be supplied to the operating facility along with the SPI database. Instructions for
refreshing the link path of external documents to the database shall be provided by the
Contractor SPI administrators.

8.5 CLEANUP OF USER ACCOUNTS

The Contractor SPI administrators shall remove all user accounts (non-administrative) that
have no relevance after the completion of project execution. The receiving facility’s SPI
administrators should configure additional user accounts as required.

8.6 SECURITY GROUPS

The responsible SPI database team shall provide the following basic security groups within
the delivered facility database:
a. Admin
b. Engineering
c. Design
The SPI database team should configure additional security groups as necessary. Once
groups are configured, a detailed analysis of access rights for each group should follow.

8.7 DELIVERED FORMAT OF THE SPI DATABASE

The SPI database shall be extracted to Watcom/Sybase format for delivery.

8.8 ENSURING HEALTH OF THE SPI DATABASE

Prior to extraction of the SPI database to Watcom format, the responsible SPI database
team shall perform utilities to ensure database health. We recommend:
a. Run CheckDB. Review results and resolve discrepancies.
b. Clear locked records.
c. Rebuild procedures and triggers.
d. Use a commercial/in-house review application. Review results and resolve
discrepancies.

8.9 SPI DATABASE DELIVERY

When all above steps are complete, the database and supplemental materials may be
delivered. Delivery should follow standard transmittal procedures implemented in the
Principal’s region and local plant facility.
The database, linked documents and transfer instructions are to be issued to the operating
facility via CD-R or DVD with a formal transmittal document. While the materials may
initially be transferred via FTP or some other electronic means, they shall be followed up
with physical delivery of hard media and written transmittal.

8.10 FOLLOW-UP
Upon receipt of the SPI database transmittal, the operating facility may require assistance
from the responsible SPI database team in setup.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 27

9. REFERENCES
In this DEP, reference is made to the following publications:
NOTES: 1. Unless specifically designated by date, the latest edition of each publication shall be used,
together with any amendments/supplements/revisions thereto.
2. The DEPs and most referenced external standards are available to Shell staff on the SWW (Shell
Wide Web) at http://sww.shell.com/standards/.

SHELL STANDARDS
DEP feedback form DEP 00.00.05.80-Gen.
PEFS & UEFS legend sheet, EP GLOBAL TEMPLATE EP-GLOBAL-001

INTERNATIONAL STANDARDS
Information technology - Security techniques - Code of practice for ISO 17799
information security management
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 28

APPENDIX A SPI ORGANIZATION AND STRUCTURE

A.1 INTRODUCTION
The following organizational roles are key in the management of SPI projects:
A.1.1 Regional Technical Authority
The RTA is traditionally represented by the Principal. This person shall coordinate with the
Regional SPI Administrators to establish specific guidelines, technical standards and
policies for the region.
A.1.2 Regional SPI Administrator
The Regional SPI Administrators are typically Shell staff who oversee the complete
implementation of SPI for a facility or group of related facilities in a Shell region. They:
a. Coordinate and follow guidelines set by the RTA.
b. Coordinate with the SPI Host administrator, EPC SPI administrators, and EPC
Contractors to ensure data integrity across entire projects.
c. Serve as Facility SPI Administrators where none are available.
d. Participate in global SPI activities.
A.1.3 SPI Host Administrator
SPI Host Administrators oversee SPI implementation for the Principal where multiple
Contractors access a centrally hosted database. They:
a. Provide security for all EPC personnel accessing the SPI database.
b. Coordinate data claims and merges for all partners.
c. Install auditing policies to ensure the resulting data follows the Principal and project
specifications.
d. Provide database access to key Principal personnel for review purposes.
e. Ensure overall health of the database.
f. Coordinate final database handover to the Principal.
A.1.4 EPC SPI Administrator
The EPC SPI Administrator:
a. Oversees administration and operation of an individual EPCs users, group definitions
and their related access privileges.
b. Implements Principal’s guidelines & standards. Submits deviations to SPI Host
Administrator or Regional SPI Administrators for approval.
A.1.5 Facility SPI Administrator
The Facility SPI Administrator:
a. Manages and audits SPI databases in operating facilities.
b. Provides access, security and support to plant SPI personnel.
c. Coordinates with the Regional SPI Administrators as required.
A.1.6 EPC Contractor
The EPC Contractor generates the bulk of the project deliverables using SPI
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 29

A.1.7 Global SPI Implementation and Support Team (G-SIST)

G-SIST is an arena of Global SPI Administrators and participating Regional SPI
Administrators who:
a. Are custodians and distributors of the Global Template databases.
b. Meet regularly with PACO and SPI stakeholders on issues of standardization.
c. Are application owners of SPI.
d. Are custodians of key SPI documentation.
A.1.8 SPI Support Structure
<< FUTURE SECTION to be added December 2012 >>
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 30

APPENDIX B SPI ENGINEERING AND DESIGN ROLES AND RESPONSIBILITIES

B.1 INTRODUCTION
A key component to driving SPI project execution is to properly assign roles and
responsibilities. The following roles and responsibilities are guidelines only, but provide an
excellent starting point for dividing up SPI tasks:
B.1.1 Project Lead
The Project Lead manages all phases of the project including the initial SPI kickoff meeting
with the SPI Administrators and the project instrument engineers and designers.
B.1.2 SPI System Administrator *
The SPI System Administrator role focuses primarily on back-office operations. They
communicate requirements and issues to IT staff, and serve as liaisons between
engineering and IT.
B.1.3 SPI Domain Administrator *
The SPI Domain Administrator is a senior instrumentation professional with relevant
experience using INtools / SPI, and an affinity for IT technology. SPI Domain Administrators
configure and support SPI databases at the project level, but may also be regular users of
SPI on projects. The SPI Domain Administrator assesses and escalates problems to the
System Administrators. They serve a first-line support within the project workgroup.
* Depending on the site’s workload, the system and domain administrator functions (B.1.2
and B.1.3) may be performed by the same personnel.
B.1.4 SPI Database Custodian
The SPI Database Custodian:
a. Provides interface between engineering disciplines
b. Supports engineers with data input
c. Maintains SPI data quality
d. Ensures SPI data completeness
B.1.5 Project Instrumentation Engineer
The Project Instrumentation Engineer:
a. Coordinates an SPI kickoff meeting
b. Reviews/identifies new requirements for reference cables
c. Reviews/identifies new requirements for reference device panels
d. Reviews/identifies new requirements for instrument types and profiles
e. Produces system architecture – BPCS, IPS, F&G – Project standard documents
f. Produces Index module
g. Performs I/O loading
h. Produces panel list
i. Produces cable schedule
j. Produces instrument summary
k. Produces specification sheets
l. Produces document binder
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 31

B.1.6 SPI Design/Drafting

SPI Design/Drafting:
a. Builds panel structure (racks, slots and I/O cards)
b. Builds junction box and marshalling panel structure
c. Produces reference panels
d. Produces wiring module
e. Produces SPI design deliverables
B.1.7 Programmable System Engineer
The Programmable System Engineer:
a. Provides I/O data to MAC
b. Produces logic control blocks
c. Provides interface with the MAC

APPENDIX C INFORMATION SECURITY

The Contractor shall ensure compliance with the Principal’s Information Security
requirements and ensure processes and procedures are in place to safeguard business
continuity and minimize business damage. Particular focus should be placed on ensuring:
a. Confidentiality, protecting sensitive information from unauthorised disclosure.
b. Integrity, safeguarding the accuracy and completeness of information.
c. Availability, ensuring the project information is available to users as required.
The Contractor should be guided by ISO 17799.

APPENDIX D EXPORT CONTROLS

The Contractor shall ensure all deliverables are classified and assigned an appropriate
Export Control Classification Number (ECCN), and that the classification is clearly
displayed on all deliverables.
a. Principal’s regional staff shall provide the classifications to be used.
b. The Contractor shall ensure awareness and compliance with Export Controls at all
times.
ECCN EAR99 DEP 32.31.00.35-Gen.
February 2013
Page 32

APPENDIX E APPLICATIONS USED BY THE CONTRACTOR

Where the Principal’s region mandates the use of the SPI application and a global template
based seed file, the Contractor shall subscribe to the standards of design and overall spirit
therein wherever possible. The Contractor shall obtain the written approval from the
Principal’s region before making changes to the application or seed file.
If intelligent drawings or other smart reports are used by the Contractor, external files shall
be delivered to the Principal’s region, including all configuration, reference files and libraries
such that a fully operable application can be reassembled elsewhere. The structure of the
library and data files shall be approved by the Principal’s region prior to creation.

APPENDIX F INFORMATION FROM SUB-CONTRACTORS

The Contractor shall ensure all information originated by its sub-contractors and
Manufacturer/Suppliers comply with the Principal’s regional requirements.
The Contractor shall be responsible for any additional effort or costs associated with
ensuring the information supplied by the sub-contractors complies with the Principal’s
regional requirements.

APPENDIX G INFORMATION REVIEW AND APPROVAL BY THE PRINCIPAL

The Contractor shall be accountable for information quality. Information quality shall be
managed at source by the Contractor and shall not rely on the Principal’s regional review to
highlight issues.
The Contractor shall employ an internal information review process that ensures the
appropriate technical authorities review and comment on all new or revised information.
The Principal’s region shall reject any information issued by the Contractor that has not
been duly signed as checked and approved by the Contractor.
The Principal’s regional staff shall also review and approve some deliverables to ensure
compliance with their technical approval requirements. Acceptance of information by the
Principal’s regional staff does not relieve the Contractor of responsibility for design
accuracy or for compliance with applicable codes, standards or contractual requirements.

APPENDIX H SPI PROJECT SPECIFICATION (EXAMPLE FRAMEWORK)

<< FUTURE SECTION to be added 2013 >>