Smartplant Instrumentation (Spi) - Project Execution: Dep Specification
Smartplant Instrumentation (Spi) - Project Execution: Dep Specification
Smartplant Instrumentation (Spi) - Project Execution: Dep Specification
DEP 32.31.00.35-Gen.
February 2013
ECCN EAR99
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.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
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
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
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
Step 1 – Version and Scripting defines application and database requirements for SPI. This
can be done at the Principal or Contractor locations.
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.
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.
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.
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
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:
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
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.
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
Step 4 – Project Configuration details the configuration the project SPI database (domain),
per the SPI Project Specification.
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.
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
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.
Additional browser views may be created to further delineate the facility by unit or some
other criteria as required.
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
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
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