QSGTL T-4144232 Systemisation Book

Flawless Start-up Initiative
Implementation Book for Systemisation

& System Engineering
A 22/05/07 DTP MV DK IFL Issued for implementation

O 07/02/07 DTP RP JG IFL Issued for implementation
Rev. Date By Chkd Appr. Status Revision reason for issue
description
Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000
Contractor Project No.: 5887 MWKL- JKP
Contractor Contract No.: PI-093 Sheet: 1 of 54 PCWBS: NA
PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

QATAR PMC Project Doc No: T-4.144.232 Rev.: A
P:\5887GTL_PMC\Technology Mgmt\Flawless Start-up\Systemisation\T-4.144.232RevA_F001.doc
TABLE OF CONTENTS
1.0 INTRODUCTION.................................................................................................................................4
2.0 PRINCIPAL OF SYSTEMISATION ....................................................................................................6
3.0 SYSTEM TEAM ..................................................................................................................................9
3.1 Roles of the System Engineer ........................................................................................................... 9

3.2 Roles of the System Engineering Coordinator................................................................................. 10
3.3 Q Coordinators................................................................................................................................. 11
3.4 Q Captains ....................................................................................................................................... 11
3.5 Asset Delivery Teams ...................................................................................................................... 12
4.0 SYSTEM DEFINITION......................................................................................................................13
4.1 System Definition Guidelines ........................................................................................................... 13

4.1.1 System size.......................................................................................................................................14
4.1.2 Process Systems ..............................................................................................................................14
4.1.3 Telecommunication Systems ............................................................................................................14
4.1.4 Instrument Systems ..........................................................................................................................15
4.1.5 Building Systems ..............................................................................................................................18
4.1.6 Civil and Structural Steel...................................................................................................................19
4.1.7 Tie-ins ...............................................................................................................................................19
4.1.8 Electrical Systems.............................................................................................................................20
4.1.9 Tightness...........................................................................................................................................22
4.1.10 Cleanliness........................................................................................................................................22
4.1.11 Novelty and complexity .....................................................................................................................23
4.1.12 Testing ..............................................................................................................................................23
4.1.13 Coinciding events..............................................................................................................................23
4.2 System numbering and identification............................................................................................... 23
4.2.1 System activity numbering ................................................................................................................25
4.3 System Definition Mark-Up Requirements....................................................................................... 26
4.4 System Activity Sheets .................................................................................................................... 28
4.5 Work Execution Flow Scheme ......................................................................................................... 28
5.0 SYSTEM FILE...................................................................................................................................29
5.1 System file index.............................................................................................................................. 29

5.1.1 General .............................................................................................................................................29
5.1.2 Pre-commissioning, Commissioning & start-up ................................................................................30
5.1.3 Quality assurance and Q areas ........................................................................................................31
5.1.4 Health, Safety & Environment...........................................................................................................32

5.1.5 Appendices .......................................................................................................................................32
6.0 SCHEDULE ......................................................................................................................................33
6.1 Schedule for system file completion ................................................................................................ 34

6.1.1 System File generation .....................................................................................................................34
6.1.2 Ready for Pre-commissioning...........................................................................................................35
6.1.3 Ready for Commissioning.................................................................................................................35
6.1.4 Ready for Start-up.............................................................................................................................36
6.1.5 Commissioning and Start-up Schedule ............................................................................................36
7.0 HANDOVER REQUIREMENTS .......................................................................................................37
7.1 Activity check list .............................................................................................................................. 38

8.0 COORDINATION & INTERFACE.....................................................................................................39
8.1 Correspondence .............................................................................................................................. 39

9.0 CHANGE MANAGEMENT ...............................................................................................................41
10.0 Q AREAS & SYSTEM BASED REVIEW .........................................................................................42
10.1 System based review....................................................................................................................... 42

10.1.1 System Q Workshops .......................................................................................................................42
10.2 Q Areas ............................................................................................................................................ 43
10.2.1 Q1 Tightness.....................................................................................................................................43
10.2.2 Q2 Cleanliness..................................................................................................................................43
10.2.3 Q3 Integrity........................................................................................................................................43
10.2.4 Q4 Operability and Maintainability ....................................................................................................44
10.2.5 Q5 Health Safety & Environment......................................................................................................44
10.2.6 Q6 Prototypes ...................................................................................................................................45
10.2.7 Q7 Complexity...................................................................................................................................45
10.2.8 Q8 Testing.........................................................................................................................................46
10.2.9 Q9 Experience ..................................................................................................................................46
10.2.10 Q10 Coinciding Events .....................................................................................................................47
10.2.11 Q11 Information ................................................................................................................................47
10.2.12 Q12 Interface ....................................................................................................................................47
11.0 NOMENCLATURE ...........................................................................................................................48
12.0 REFERENCE DOCUMENTS............................................................................................................49
13.0 APPENDIX........................................................................................................................................51

1.0 INTRODUCTION
This document formalizes the FSI Implementation Book for Systemisation and the
methods, philosophies, and procedures set out therein.
This document in conjunction with the pending PMC planning document 5887-ON-PR-PC-
010, fulfill the following requirement from T-13.377.420 (section 2.1)
All teams shall have to use the same format definition in order to allow coherent
integration afterwards of the various logics and schedules. Project management will
act as governor of this alignment process
In particular this document updates the system numbering philosophy. Where conflicts exist
between T-13.377.420 & T-4.144.232, this document (T-4.144.232) shall be governing.
FSI Flawless Start-up Initiative is a formalized program to achieve the objective of trouble
free start-up and operational performance for the total project including first cycle operation.
The Initiative consists of the implementation of processes and actions by which risks to this
objective will be identified, assessed and addressed during engineering, procurement and
site implementation, in a pro-active manner. The approach will be to value proven best
practices, apply Contractors own and Companys lessons learnt, and cooperate in the
application of flaw mitigation, risk management and the resulting improvement of normal
work processes.
This document provides supplemental information and clarifications to the requirements as
detailed in the project specification, it does not absolve the Contractor of their responsibilities
as per the project specification (Ref: Section 12).
The approach shall focus on the 6ms of efficient and flawless asset delivery per defined
system.
Machines (the assets)
Manpower (the people involved)
Means (the procedures)
Materials (the tools, spares and sub-contracts)
Methods (the management systems)
Mindset (the culture of compliance and keeping control)
Although, the main focus of the Flawless program will be Machines. The Asset Delivery
Teams (ADT) will have more of an overall focus across all the Ms (Ref: Section 3.5).
Systemisation is a key element of flawless. An operational system is a composite of piping,
vessel, power supplies, instrumentation, DCS functionality, safeguarding, pumps,
compressors and protective devices which can operate as a stand-alone entity to fulfil the
purpose for which it was designed.

The magnitude of the systemisation activity should not be under estimated, a typical process
unit may have 10 systems or more including utility services, so there could be more than
1000 systems defined over the two phase project.
Systems are in fact the building blocks of the entire design and include process systems and
non-process Systems, e.g. roads, electrical and instrumentation infrastructure, etc. From a
start-up perspective, operational systems (functions) are started up in a logical sequence,
e.g. you need to compress air first, then dry it and then distribute it. As a result systems form
logical entities that are made ready for start-up and are handed over.
An integrated multidiscipline approach throughout the project is required to ensure that a
system delivers its function (and capacity) from the moment it is called upon. This requires
Contractor to have at every phase of the project multidiscipline system teams in place, which
focus on a system.
Company will nominate for every system a system owner who will be a member of the
system team and in most cases also the ADT.
During detailed engineering (design) and procurement, the driver is the procurement train,
in which like items are grouped, regardless of their system or area, so that they can be
readily and efficiently handled in the requisitioning, bidding, ordering, manufacturing,
expediting, inspection, delivery and materials management activities.
The driving force during the initial construction phase reverts to area, which is supported with
area-based drawings. Once construction is at 60%, all further work shall be completed and
tested on a systems basis.
It is important that the project team and asset owner have a clear understanding of these
driving forces in order to develop the most effective schedules and project managers must be
aware of them, to ensure effective management of transitions between each phase. With the
early systemisation approach of Flawless Start-up, a continued focus is maintained on the
functional systems throughout the project enabling problems to be discovered and resolved
early thereby ensuring the system is fully functioning and available when required.

2.0 PRINCIPAL OF SYSTEMISATION
The Complex shall be broken down into Phase, Plants, Units, Start-up Blocks and Systems
to facilitate the work process during pre-commissioning, commissioning, start-up and testing.
Asset Breakdown Hierarchy diagram

The first step in preparation of a model for a work process is to separate the total assets in
smaller pieces to be able to define the individual pieces of work which will be executed on
the assets (Systems) This process is called systemisation; resulting in system definitions.
A system is being defined as a functional-identifiable section of the assets that shall be
commissioned and brought to ready for start-up (RFSU) to a significant extent isolated from
the adjacent systems. Subsequently systems are combined and started, to realise
production.
Following systemisation and a considered element of systemisation is the development of
the commissioning and start-up schedule via the following route;
1. Asset breakdown (Systemisation)

2. Work breakdown (Activity Definition)
3. Work flow logic diagram (Work Execution Flow Scheme)
4. Commissioning & Start-up schedule (C&SU Schedule)
Relationships
with other systems
Tests identified
Needs (temporary
facilities)
(Sub) System Activity lists WEFS

per (sub) system Road map for
definition (incl. tests) C&SU work
Durations
Planning /
Schedule
development
Reference document 1 describes this process in detail; it will also be covered further in section 4 & 6.

Defined systems will be indicated on Process Engineering Flow Schemes (for process
systems) and assigned a unique number. When defining the systems attention should be
given to the ability to isolate the system from other parts of the process in such a way that
the majority of commissioning activities can be completed for that system.
Although it is common practice for pre-commissioning and commissioning to work on a
system basis, systemisation is often not applied in the earlier design phase. The Flawless
start-up program aims to achieve its objective of trouble free start-up and operational
performance for the total project including first cycle operation, by focusing on functional
systems throughout design, construction and commissioning. This early and continued focus
will help to ensure that a system delivers its function (and capacity) from the moment it is
called upon. To achieve this goal each system will be individually reviewed and monitored for
risks via the 12Q areas and risk mitigation action plans put in place.
Systemisation has been started during the FEED phase with the development of the start-up
block definition and the level 2 commissioning & start-up schedule, the level 3-4
commissioning & start-up schedule will be completed early during the detailed design phase
of the project.
Each system will have a system engineer who will be the single point of contact, responsible
for that system throughout engineering, construction, pre-commissioning, commissioning,
start-up and testing. The system engineer will also be the owner of the associated system file
until the system is handed over to the Companys system owner. System files created for
each system will be the repository for system data including system definition, process &
control information, cleanliness, testing and QA/QC documentation (Ref: Section 5).
Systems are normally started in a specific sequence, as required, by the process operations.
The system that is placed in service first under the accepted start-up logic is considered the
provider of the service i.e. provider system; the system receiving the service is designated
the receiver system.

3.0 SYSTEM TEAM
For each identified system the Contractor shall have multidiscipline system teams that will
implement the FSI program throughout all phases of the Project until the system handed
over. System teams shall consist of representatives from the various relevant skill pools and
be lead by the system engineer, the composition of this team will shift throughout the
implementation of the project, although continuity of systems engineers and system
engineering coordinator is a project requirement.
The system engineer role is typically not a full time position, but an additional task of a
process or discipline engineer with multidiscipline skills and multiphase exposure. The
system engineer coordinates contribution of Contractor discipline engineers per process or
infrastructure system and is single point accountable for the functionality, operability,
maintainability, safety and environmental characteristics of systems throughout the entire
implementation.
Company will nominate for every system a system owner who will be a member of the
system team. The system owner may also be a member of the ADT and will be the focal
point on the company side for system handover.
To ensure consistency over the various system teams the Contractor shall also nominate
one full time system engineering coordinator (per work location). The Contractor shall
develop and roll out work processes, coordinate and follow up initiatives and corrective
actions resulting from system based work.
It is important to maintain continuity of personnel for system engineers and system
engineering coordination, to ensure that issues highlighted and mitigation measures put in
place during the early design phases are followed through to the later stages up until
handover.
3.1 Roles of the System Engineer

The system engineer is the key member of the system team and will lead the team through
all phases of the project. The system engineer would typically be involved in the engineering
of the system and have multidiscipline skills and multiphase exposure i.e. for a process
system, the lead unit process engineer. After attending all 12Q awareness workshops, the
system engineer shall organise & facilitate flaw identification and mitigation workshops
(System Q Workshops) for their system. The System Q Workshops will not involve the Q
Captains, however the out put of these workshops will be communicated where applicable to
the Q Captains. These meetings will be attended by the whole system team plus any other
relevant experts, and be convened throughout the project phases (Refer to section 6.1&10).
Key responsibilities:
Own the system file until the system is handed over to the Companys system owner.
Provide comment on all technical deviations & change requests impacting on the
system prior to implementation.
Implement mitigation measures and directives of the Q Captains as part of the FSI
program.
Be accountable for detailed system design and ensure the system is constructed and
commissioned as per specification.

Be accountable that the system information developed throughout implementation is
complete, consistent, accurate and precise.
Ensure that each assigned system will be smoothly transferred and be working
flawlessly at the moment of RFSU with demonstrated readiness for use.
Work closely with the system owner; the system owner facilitates smooth transfer to
Company.
Meet standards for system effectiveness, RCM, RBI and operations excellence in
defined operating windows for all modes. (e.g. number of alarms per hour at end of
commissioning).
Develop test and inspection plans per system.
Develop the basic operating and maintenance manuals. These have sufficient detail
that it can be established when a system would be performing substandard to the
required System Effectiveness and OPEX standards.
Establish standard durations for decommissioning, commissioning, decontamination,
routine reconditioning, start-up etc.
Compile evidence that selected equipment, materials, vendor packs have
demonstrated to work against system effectiveness targets (e.g. mean time between
failures) in equivalent (carbon copy) service.
3.2 Roles of the System Engineering Coordinator

The system engineering coordinator will be the focal point for correspondence between the
Contractor and the Company on system related issues. In addition to being the focal point for
correspondence, the system engineering coordinator shall develop and roll out work
processes as required, coordinate and follow up initiatives and corrective actions resulting
from system based work.
Key responsibilities:
Act as the focal point for correspondence between the Company and system
engineers.
Act as the focal point for correspondence between the Q captains and systems
engineers.
Develop and role out further work processes if required.
Ensure initiatives and flaw mitigations are being implemented by the system
engineers.
Check systems definition mark-up to ensure consistency across all systems and that
there are no omissions.
Maintain and communicate to the Company a list of defined systems and assigned
system engineers.
Monitor and feed back to the Company, FSI progress for each system.
Maintain high profile for systems based FSI and ensure that project schedule
pressures do not impact on scheduled FSI systems activities.

3.3 Q Coordinators
Although the Q Coordinators are not part of the system team they play an important part in
the Flawless program and help support/direct the Q Captains and the system teams. The
EPCM / IC Q Coordinator is accountable to EPCM / IC Project Manager and has the
authority coordinate and oversee FSI implementation to ensure that EPCM / IC understand
project requirements and comply with plans, directives and procedures.
The key roles and responsibilities are listed below;
Coordinates all FSI efforts on the Pearl Project; plans, organizes, directs and controls
all FSI activities
Assists the FSI PMC Q Coordinators in the implementation of the FSI programme
Participates in FSI workshops organized by PMC and Coached by SGSI Specialists
Conducts FSI workshops within his respective organisation, develops FSI awareness,
and identifies potential flaws and devises mitigation action
Ensures FSI program is actioned within his/her organisation in addition to flaw
mitigation arising from workshops
Liaise with PMC to ensure that these flaws are added to database and shared with
EPCM and IC groups
Monitor and report KPIs and Lead Indicators status
3.4 Q Captains
The Q Captains are also not part of the system team, but are the cornerstone of a Flawless
program focused on Q areas (Ref: Section 10.2), they will provide help support and continued
focus on Q areas to the project and system teams. The EPCM / IC Q Captain are
accountable to the EPCM / IC Project Manager.
The key roles and responsibilities are listed below;
The Q Captain is authorized to lead and implement the FSI plan for his Q Area
To lead, plan, direct & control all FSI activities related to his Q Area. Primary areas of
concern include work plan, FSI awareness, health checks of EPCM and ICs and Q Area data
base management
To lead the implementation of FSI in the respective Q Area
To prepare a working plan, and apply it through the project
To monitor the execution of the potential flaws mitigating action
To ensure that FSI is considered in the relevant project activities
To own the Q Area registers and documents
To report regularly to management, and take corrective actions in case of not meeting
the plan or the Lead KPIs
To identify and participate in Q syndicate

3.5 Asset Delivery Teams
For each defined scope of work an Asset Delivery Team (ADT) will maintain a continued
focus on the final objective of the project which is to deliver a world class reliable GTL facility
on time and within budget. The ADT is not within the contractors scope hence will be a
Shell/PMC team; it is most likely that the system owner will be part of the ADT. The
emphasis of the ADTs will be on the delivery of all elements required to achieve effective
start-up and operation, namely the six Ms (Ref: Section 1). The system teams are focused on
the first two phases on the project EPC & CSU, however the ADTs continue this focus
beyond start-up into the production phase. The consistency of personnel within each asset
delivery team and system team will help to foster a good working relationship and trust
between the teams to facilitate an efficient and speedy handover.
The following ADTs will be mobilised during the detailed engineering phase of the project;
1. PMC
2. Utilities
3. GTL
4. ETP
5. ASU
6. LPU
7. Tanks
8. FGP
9. Platforms
10. Pipelines
11. Common facilities
12. Buildings
13. Temporary facilities
14. Main Automation Contractor (MAC)
15. Corridors & Jetty
16. Well Delivery
17. AIT (technical, operation and IT interfaces)
18. AM/QORD (Asset management, Business/QP RLC interfaces
19. HSSE & HR
20. SU services
All ADTs will be initially located in the contractors offices through engineering prior to
relocating to site for construction, commissioning and start-up.

4.0 SYSTEM DEFINITION
The first step in preparation of a model for a work process is to separate the total assets in
smaller pieces to simplify the definition of the individual pieces of work. This process is called
systemisation; resulting in system definitions.
A system is defined as a functional-identifiable section of the plant that shall be
commissioned and brought to ready for start-up (RFSU) to a significant extent isolated from
the adjacent systems. Subsequently systems are combined and started to realise production.
On basis of the above, a system can be defined, as a complete assembly of piping, vessels,
equipment, instruments, and electrical supplies etc. that can be defined as having a singular
purpose within a unit. This definition will afford the ability to conduct meaningful and
complete tests within the system.
Systems are normally started in a specific sequence, as required, by the process operations.
It is suggested that operations personnel, with support of the commissioning manager and
system engineer, use flow schemes issued in the feed package (including updates) to start
identifying the systems and the sequence in which they will be started. The system that is
placed in service first under the accepted start-up logic that provides a service to other
systems is considered the provider system; the system receiving the service is designated
the receiver system.
Defined systems will be indicated on Process Engineering Flow Schemes (PEFS) or other
discipline drawing as applicable and assigned a unique number. However, for process
systems it is recommended that the first pass of systemisation be completed at PFS level,
taking into account circulation possibilities for dynamic testing and simulation runs.
The systemisation approach should also be applied to all projects civil and building works as
well as all supporting power and instrument facilities.
4.1 System Definition Guidelines

When defining systems (identifying system breaks) a number of considerations need to be
taken into account. These considerations may be related to the hardware, but also to the
work process and/or organisation.
Five categories of system breaks can be distinguished:
1. Functional breaks: Definition must meet requirements for all work processes planned on
that system, including any testing required as part of the Flawless Initiative e.g. novelty
or prototype testing.
2. Commodity breaks: Utilities, feed/product systems, process systems, electrical. DCS,
civil.
3. Scope breaks: IC contract to IC contract, IC contract to EPCM and IC/EPCM to non-
project scope. However, certain utility units/start-up blocks may be spread across IC &
EPCM scope breaks, in this case the system will still be bound by the scope breaks as
far as possible while maintaining a logical and practical system break point. Guidance
and governance on the location of system breaks where contract scope boundaries are
involved will be provided by PMC Commissioning. It is important for these cross
contract start-up blocks & systems, that a close working relationship is maintained
between all system engineers with systems in that start-up block. For each of these
cross contract units, start-up blocks and systems, there shall be a single system

engineer who will also have responsibility for coordinating all contractors within that
unit, start-up block or system and ensuring continuity and completeness throughout all
the applicable scopes. In most cases this responsibility will fall to a system engineer
within the EPCM utilities as they will have the major parts. However this will not always
be the case as some other utilities such as chilled water have their mayor parts in the
IC scope. This lead role will be agreed with the PMC during systemisation.
4. Plot breaks: Where possible systems should be wholly contained within a start-up block
and start-up blocks contained within a geographical commissioning area to promote
safe control of work during commissioning; the logical grouping of start-up blocks within
a commissioning area will become apparent during the development of the WEFS.
5. Time breaks: various project or operational phases.
Points of isolation between the systems will normally be at the open breakers for electrical
systems and at manual isolation valves for mechanical systems, system breaks at butt welds
shall be avoided. The isolation points are included in the provider system.
4.1.1 System size

There is no simple guideline for the right size of a system. If relative small systems are
defined the result will be a significant increase of relationships between systems and
therefore it will be difficult to separate activities on system level. This means that a (large)
number of systems will be needed to carry out a single activity, resulting in inefficiency. If on
the other hand too large systems are defined, parallel groups of activities can be defined.
This will often lead to definition of sub system to reduce the overall schedule time needed to
complete all activities of a system (Further guidance is available in reference 1)
4.1.2 Process Systems

As far as practical, system breaks shall coincide with blinds / isolation points provided as part
of the design. Deviation to this shall be identified and agreed with Company.
4.1.3 Telecommunication Systems

Telecommunication systems shall detail their interfaces with:
Instruments (DCS, F&G ESD, Electrical management etc.)
Qatar GTL supplied information technology systems(Engineered by Shell
International)
Qatar Telecom who supply the telecom connection to the plant.
Offshore installations (via sub sea cable)
The plant is the host for the offshore control and the telecommunication systems so it is a
key interface in terms of the final stages of start-up of the plant.
There is also a major interface with the building Contractor as it will be responsible for the
telecomm infrastructure within the buildings. The interface with electrical is relatively straight
forward in that they will supply the primary power to the telecommunication equipment.
Telecom SU block will share U-9800 unit number with the PAS, hence system numbers shall
be requested from EPCM-UTL

4.1.4 Instrument Systems
Instrument Systems shall include the PAS and associated sub-systems (i.e. DCS, IPS, F&G,
AMS, ODS) and other 3rd Party Control Systems.
Each FAR will be assigned an instrument SU block covering all instrument components
contained there in. The systems associated with the FAR building will be systemised as part
of the building SU block e.g. HVAC, F&G, Lighting, & small power etc. Other services such
as UPS and electrical supply from the breaker at the main FAR switchboard will be assigned
instrument system numbers. This is due to the anticipated involvement of instruments
discipline in commissioning these systems.
The break between Instrument systems and process systems shall generally be at the cable
marshalling cabinets. Subdivision will be applied to systems, which may serve more than one
system e.g. multi core cables, junction boxes. Individual cables and segment cables will be
assigned system numbers appropriate to the first process system served i.e. first system
requiring PAS functionality on the CSU shedule served. External Field Bus segments will
also be assigned system numbers appropriate to the first process system served,
consideration should be given to separation or systems and access requirements. Each field
instrument loop will be assigned to the process system, which it serves. Local indicators,
pressure relief valves and other in-line devices will be assigned a system number derived
from their locations as indicated in the process system definition drawings.
Each Analyser House (AH) will also be assigned an instrument SU block number; the QMIs
contained in the AH will maintain their process system number. Common elements of the AH
such as ventilation, lighting and common cooling will be part of the AH SU block.
Fibre optic (FO) infrastructure will be provided as part of EPCM-UTL scope and will be
assigned instrument system numbers between patch panel interfaces.
Refer to section 13.0 for overview diagram of instrument system systemisation
Rules for assigning tags to field Junction Boxes (JBs) [HOLD rules pending issue of TB-
00448]:
o A JB should only contain tags of a single parallel process string e.g. an SRU; where this
would result in significant cost or schedule impact, the PMC shall be consulted
(exceptions by PMC approval).
o A JB shall only contain tags of a single SU Block; where this would result in significant
cost or schedule impact e.g. for analyser houses, the PMC shall be consulted (exceptions
by PMC approval).
o Existing rules according to the Project Specification T-13.375.750 Section 20.8.22.1,
System segregation, still apply.
Rules for landing cables/ providing segregation within Main Distribution Frame (MDF) cabinets:
o Cables should be allocated to MDF cabinets grouped in such a way to provide
segregation by commissioning system, parallel process string and SU Block.
o Segregation defined above shall be achieved by physical separation (consider terminal
rail covers also)
o Preferably there should be no cross wiring across shipping breaks.
Rules for allocating I/O to I/O modules for PAS (except FGS):
o Existing rules according to the Project Specification T-13.375.750 Section 20.8.22.1,
System segregation, still apply.
Rules for allocating process control schemes and safeguarding functions to processors (C300
and SM):

o SU blocks for parallel process strings (e.g. parallel SRUs, SGPs, HPSs) shall not be
allocated to the same processor
o Processes that require to be taken out of operation between major turnarounds shall not
be allocated to the same processor.
o Phase 1 & Phase 2 configurations shall not be allocated to the same processor
Rules for systemisation of Safeguarding Schemes
o It is preferred that a UZ block is not split across SU blocks and SU blocks are not split
across Cause and effects, where this is not possible or practical all external safeguarding
signals entering a SU block shall be listed by the contractor and an isolation method
defined. This safeguarding isolation list shall be combined with the control isolation list
(see below) and handed over to the company at RFSU or Ready For Operation, from this
point forward the company will manage the list and the contractor shall be required to
obtain permission from the company prior to working on any listed item.
o Safeguarding logic should be systemised to facilitate commissioning with minimum
"forces" (system internal signal overrides).
o Safeguarding logic shall be systemised to facilitate start-up with no forces.
Rules for systemisation of Control Schemes:
o It is preferred that control schemes are not split across SU blocks and SU blocks are not
split across Control Narratives, where this is not possible or practical all external control
signals entering a SU block shall be listed by the contractor and an isolation method
defined. This control isolation list shall be combined with the safeguarding isolation list
(see above) and handed over to the company at RFSU or Ready For Operation, from this
point forward the company will manage the list and the contractor shall be required to
obtain permission from the company prior to working on any listed item.
o Control schemes should be systemised to facilitate commissioning with minimum forces.
o Control schemes shall be systemised to facilitate start-up with no forces.
o Control Narratives should indicate any special requirements (e.g. disabling part of the
scheme, forcing inputs, temporary reconfigurations, re-ranging, and retuning) required to
enable commissioning per system or per start-up block.
Rules for mapping PAS asset model:
o Each I/O tag requires the associated process equipment to be identified in the equipment
field (SPI) which will map the project asset model.
o I/O to be assigned to asset model as per equipment field
Rules for systemisation of integrated PAS plus 3rd party sub systems
o EPCM/MAC shall systemise, define activities, produce WEFS and schedule with PMC
support for the top layer of PAS.
o EPCM/MAC shall integrate FARs into the top layer of the PAS with PMC support.
Rules for allocation of devices to fieldbus segments:
o Allocation of devices to fieldbus segments, see rules for JBs above
o Refer to document T-13.369.251 Fieldbus design guidelines
Rules for FGS
o At SU of a SU block the FGS system shall be ready for the associated fire area
including all telecoms requirement.

4.1.4.1 FAR & Analyser House Start-up Block list
EQUIPMENT CONTRACTOR IN LEAD ROLE SU BLOCK (N-UU-Bb)

FAR 1 C2 (ASU) 1-98-A0
FAR 2 C2 (ASU) 1-98-B0
FAR 3 C5 (LPU) 1-98-C0
FAR 4 C6J (GTL) 1-98-D0
FAR 5 C4 (FGP) 0-98-A0
FAR 6 C4 (FGP) 1-98-E0
FAR 7 C8 (ETP) 0-98-B0
FAR 8 C6K (UTL) 0-98-C0
FAR 9 C2 (ASU) 2-98-A0
FAR 10 C2 (ASU) 2-98-B0
FAR 11 C5 (LPU) 2-98-C0
FAR 12 C6J (GTL) 2-98-D0
FAR 13 C4 (FGP) 2-98-E0
FAR 14 C6K (UTL) 0-98-D0
FAR 15 C3 (TANKS) 0-98-E0
FAR 16 (off plot) C3 (TANKS) 1-98-F0
Common sulphur facility C7 (OFFSITE / JETTY) 0-98-F0
Jetty control room C7 (OFFSITE / JETTY) 1-98-G0
Analyser House (AH01) C4 (FGP) 0-98-G0
Analyser House (AH02) C4 (FGP) 1-98-H0
Analyser House (AH03A) C4 (FGP) 0-98-H0
Analyser House (AH03B) C4 (FGP) 0-98-J0
Analyser House (AH04) C4 (FGP) 1-98-J0
Analyser House (AH05) C6J (GTL) 1-98-K0
Analyser House (AH06) C6J (GTL) 1-98-L0
Analyser House (AH08) C6J (GTL) 1-98-M0
Analyser House (AH09) C6J (GTL) 1-98-N0
Analyser House (AH10) C5 (LPU) 1-98-P0
Analyser House (AH11) C5 (LPU) 1-98-Q0
Analyser House (AH12) C7 (OFFSITE / JETTY) 1-98-W0
Analyser House (AH13) C8 (ETP) 0-98-L0
Analyser House (AH14A) C2 (ASU) 1-98-R0
Analyser House (AH14B) C2 (ASU) 1-98-S0
Analyser House (AH15A) C2 (ASU) 1-98-T0
Analyser House (AH15B) C2 (ASU) 1-98-U0
Analyser House (AH16) C5 (LPU) 1-98-V0
Analyser House (AH17) C6K (UTL) 0-98-N0
Analyser House (AH18) C3 (TANKS) 0-98-P0
Analyser House (AH19) C6K (UTL) 0-98-Q0
Analyser House (AH22) C4 (FGP) 2-98-F0
Analyser House (AH23) C4 (FGP) 0-98-R0
Analyser House (AH24) C4 (FGP) 2-98-G0
Analyser House (AH25) C6J (GTL) 2-98-H0
Analyser House (AH26) C6J (GTL) 2-98-J0
Analyser House (AH28) C6J (GTL) 2-98-K0
Analyser House (AH29) C6J (GTL) 2-98-L0
Analyser House (AH30) C5 (LPU) 2-98-M0
Analyser House (AH31) C5 (LPU) 2-98-N0
Analyser House (AH34A) C2 (ASU) 2-98-P0
Analyser House (AH34B) C2 (ASU) 2-98-Q0
Analyser House (AH35A) C2 (ASU) 2-98-R0
Analyser House (AH35B) C2 (ASU) 2-98-S0
Analyser House (AH36) C5 (LPU) 2-98-T0

4.1.5 Building Systems
Each building will be considered as one start-up block, service items within the building
(HVAC, F&G, Lighting, etc.) shall be considered as systems of the building SU block where
appropriate for testing. For FAR buildings and control rooms the instrument and control
elements contained there in will be systemised seperatly (see section 4.1.4) i.e. MDF
cabinates will be part of a U-9800 SU block. For SUB stations the electrical power
distrabution elements will be systemised seperatly (see section 4.1.8). i.e. the bus bars will be
part of a U-6800 SU block but the substation lighting will belong to the building SU block.
SU block
CONTRACTOR IN BUILDING
BUILDING NAME number
LEAD ROLE NUMBER
N UU Bb
Harbour Tankage Area Substation C3 (TANKS) 19130B01 1 92 Bb
FAR 16 (Harbour Tankage Area) C3 (TANKS) 19147B01 1 92 Bb
FAR 5 C4 (FGP) 0-B9305 0 93 A0
FAR 7 C8 (ETP) 0-B9307 0 93 B0
FAR 8 C6K (UTL) 0-B9308 0 93 C0
FAR 14 C6K (UTL) 0-B9314 0 93 D0
FAR 15 C3 (TANKS) 0-B9315 0 93 E0
FAR 1 (Phase 1) C2 (ASU) 1-B9301 1 93 A0
FAR 2 (Phase 1) C2 (ASU) 1-B9302 1 93 B0
FAR 3 (Phase 1) C5 (LPU) 1-B9303 1 93 C0
FAR 4 (Phase 1) C6J (GTL) 1-B9304 1 93 D0
FAR 6 (Phase 1) C4 (FGP) 1-B9306 1 93 E0
FAR 9 (Phase 2) C2 (ASU) 2-B9309 2 93 A0
FAR 10 (Phase 2) C2 (ASU) 2-B9310 2 93 B0
FAR 11 (Phase 2) C5 (LPU) 2-B9311 2 93 C0
FAR 12 (Phase 2) C6J (GTL) 2-B9312 2 93 D0
FAR 13 (Phase 2) C4 (FGP) 2-B9313 2 93 E0
Power Generation Substation 0PSS1 C6K (UTL) 0-B9401 0 94 A0
Utilities Substation 0SS100 C6K (UTL) 0-B9402 0 94 B0
Effluent Treatment Substation 0SS200 C8 (ETP) 0-B9403 0 94 C0
Tankage & Storage Substation 0SS300 C3 (TANKS) 0-B9404 0 94 D0
Plant Office Substation 0SS400 C1 (BUILDINGS) 0-B9405 0 94 E0
Water Treatment Substation 0SS500 C6K (UTL) 0-B9406 0 94 F0
SRU/SCOT Substation 0SS600 C4 (FGP) 0-B9407 0 94 G0
Main Intake Substation 0PSS2 (Phase 1) C6K (UTL) 0-B9408 0 94 H0
Temporary Construction Supplies Substation 0PSS4 C6K (UTL) 0-B9409 0 94 J0
Main Distribution Substation 1PSS1 (Phase 1) C6K (UTL) 1-B9401 1 94 A0
FGP Substation 1SS100 (Phase 1) C4 (FGP) 1-B9402 1 94 B0
SGP Substation 1SS200 (Phase 1) C6J (GTL) 1-B9403 1 94 C0
ASU Substation 1SS300 (Phase 1) C2 (ASU) 1-B9404 1 94 D0
LPU Substation 1SS400 (Phase 1) C5 (LPU) 1-B9405 1 94 E0
Main Distribution Substation 2PSS1 (Phase 2) C6K (UTL) 2-B9401 2 94 A0
FGP Substation 2SS100 (Phase 2) C4 (FGP) 2-B9402 2 94 B0
SGP Substation 2SS200 (Phase 2) C6J (GTL) 2-B9403 2 94 C0
ASU Substation 2SS300 (Phase 2) C2 (ASU) 2-B9404 2 94 D0
LPU Substation 2SS400 (Phase 2) C5 (LPU) 2-B9405 2 94 E0
Plant Office Building comprising: Security Lodge, Amenity
Block, Offices, Canteen & Medical Centre C1 (BUILDINGS) 0-B9551 0 95 A0
CCR / Lab / Main Plant Entrance Gatehouse C1 (BUILDINGS) 0-B9552 0 95 B0
0ST-6711 Shelter C6K (UTL) 0-S9501 0 95 C0
0ST-6721 Shelter C6K (UTL) 0-S9502 0 95 D0
0ST-6731 Shelter C6K (UTL) 0-S9503 0 95 E0
0ST-6741 Shelter C6K (UTL) 0-S9504 0 95 F0
Workshop / Warehouse C1 (BUILDINGS) 0-B9553 0 95 G0
Central HVAC Building C1 (BUILDINGS) 0-B9554 0 95 H0
Prayer Building C1 (BUILDINGS) 0-B9555 0 95 J0
2K-0781 Shelter C4 (FGP) 2-S9511 0 95 K0

CONTRACTOR IN BUILDING SU block
BUILDING NAME
LEAD ROLE NUMBER N UU Bb
Comfort Shelter CS1 (24 Person) C6J (GTL) 0-S9530 0 95 L0
Comfort Shelter CS2 (24 Person) C6J (GTL) 0-S9531 0 95 M0
Comfort Shelter CS3 (12 Person) C6K (UTL) 0-S9532 0 95 N0
Comfort Shelter CS4 (12 Person) C5 (LPU) 0-S9533 0 95 P0
Comfort Shelter CS5(12 Person) C5 (LPU) 0-S9534 0 95 Q0
Comfort Shelter CS6 (12 Person) C4 (FGP) 0-S9535 0 95 R0
Comfort Shelter CS7 (12 Person) C8 (ETP) 0-S9536 0 95 S0
Chemical Store C6K (UTL) 0-B9501 0 95 T0
Chemical Store Gate House C8 (ETP) 0-B9502 0 95 U0
1K-2111 / 1K-2112 Shelter C2 (ASU) 1-S9501 1 95 A0
1K-2211 / 1K-2212 Shelter C2 (ASU) 1-S9502 1 95 B0
1K-2311 / 1K-2312 Shelter C2 (ASU) 1-S9503 1 95 C0
1K-2411 / 1K-2412 Shelter C2 (ASU) 1-S9504 1 95 D0
1K-5181 Shelter C5 (LPU) 1-S9509 1 95 E0
1K-3041 & 1K-3001 Shelter C6J (GTL) 1-S9505 1 95 F0
2K-2111 / 2K-2112 Shelter C2 (ASU) 2-S9501 2 95 A0
2K-2211 / 2K-2212 Shelter C2 (ASU) 2-S9502 2 95 B0
2K-2311 / 2K-2312 Shelter C2 (ASU) 2-S9503 2 95 C0
2K-2411 / 2K-2412 Shelter C2 (ASU) 2-S9504 2 95 D0
2K-5181 Shelter C5 (LPU) 2-S9509 2 95 E0
2K-3041 & 2K-3001 Shelter C6J (GTL) 2-S9505 2 95 F0
4.1.6 Civil and Structural Steel

These are considered as systems on an area basis inc. roads, security, drainage, fire
proofing, structural steel etc.
As these systems will have little or no CSU involvement, the normal systemisation
requirements in addition to the system definition drawings will not apply i.e.
System engineer, owner & team are not required
System files are not required
SAS are not required
WEFS are not required
Civil and structural (ex. Buildings) are to be systemised using level 2 WBS; each area will be
assigned as one or more SU blocks as indicated below.
System numbering build-up is N-WB-Bb-Sxy, where:
WB is the geographical area work break down code (see reference 40)
The rest of the system number is as per other systems (see section 4.2)
4.1.7 Tie-ins
Tie-ins are an integral part of the corresponding system, unless otherwise specified. Tie-ins
that are required independently of the corresponding system, e.g. tie-ins to third parties
(electrical grid etc.) shall be clearly marked and assigned a separate system number.

4.1.8 Electrical Systems
Systemisation of electrical systems will generally be governed by distribution philosophy and
schedule requirements. Electrical SU block / system will generally be defined on substation,
bus bar and voltage levels
Refer to T-13.377.420 section 2.4.4 Electrical for a definition of the split between voltage levels and
process systems feeders.
In general each substation is systemised as a SU block with the exception of 1PSS1 &
2PSS1 which are further split by voltage level 33kV/6.6kV. In addition to the substations each
power provider is also given a SU block i.e. STGs, GTGs & EDGs. For the 132kV Bus Bar
(BB), isolation of provider systems i.e. STG & GTG will be at the BB selector/isolator switch.
For these systems breakers are included in the provider system.
Each voltage level distribution board will be considered a system which will include incomer
breakers, bus tie breakers, protection devices and all spare assemblies. System limits will
be defined to ensure that power isolators (breakers) are always in the next down-stream
system.
The electrical cabling will be systemised and included in the SU block / system that best fits
this philosophy i.e. from downstream of the 33kV breaker to the 33kV/6.6kV transformer will
be included in the 6.6kV bus bar SU block.
Equipment fed from MCCs including isolators, power & control cables and associated
instrumentation are assigned to the process system in which the mechanical equipment is
located.
The electrical systemisation shall also take into account testing requirements, contractor
scope, and safety during construction and commissioning etc.
See appendix section 13.0 for example diagram of electrical SU blocks
SU block
CONTRACTOR IN BUILDING
ELECTRICAL RESOURCE number
LEAD ROLE NUMBER
N UU Bb
0GT-6711
C6K (UTL) N/A 0 67 A1
0GT-6721
C6K (UTL) N/A 0 67 A2
0GT-6731
C6K (UTL) N/A 0 67 A3
0GT-6741
C6K (UTL) N/A 0 67 A4
0GT-6751(Future)
C6K (UTL) N/A 0 67 A5
0GT-6761
C6K (UTL) N/A 0 67 A6
0GT-6771(Future)
C6K (UTL) N/A 0 67 A7
0GT-6781(Phase 2)
C6K (UTL) N/A 0 67 A8
0ST-6711
C6K (UTL) 0-S9501 0 67 B1
0ST-6721
C6K (UTL) 0-S9502 0 67 B2
0ST-6731
C6K (UTL) 0-S9503 0 67 B3
0ST-6741(Phase 2)
C6K (UTL) 0-S9504 0 67 B4
Utilities Substation 0SS100
C6K (UTL) 0-B9402 0 67 C0
Power Generation Substation 0PSS1
C6K (UTL) 0-B9401 0 67 D0
Main Intake Substation 0PSS2; Karama link (Phase 1)
C6K (UTL) 0-B9408 0 67 E0
Temporary Construction Supplies Substation 0PSS4
C6K (UTL) 0-B9409 0 67 F0
Effluent Treatment Substation 0SS200
C8 (ETP) 0-B9403 0 67 G0

CONTRACTOR IN BUILDING SU block
ELECTRICAL RESOURCE
LEAD ROLE NUMBER N UU Bb
Tankage & Storage Substation 0SS300
C3 (TANKS) 0-B9404 0 67 H0
Plant Office Substation 0SS400
C1 (BUILDINGS) 0-B9405 0 67 J0
Water Treatment Substation 0SS500
C6K (UTL) 0-B9406 0 67 K0
SRU/SCOT Substation 0SS600
C4 (FGP) 0-B9407 0 67 L0
Main Distribution Substation 1PSS1 33kV (Phase 1)
C6K (UTL) 1-B9401 1 67 A0
Main Distribution Substation 1PSS1 6.63kV (Phase 1)
C6K (UTL) 1-B9401 1 67 B0
FGP Substation 1SS100 (Phase 1)
C4 (FGP) 1-B9402 1 67 D0
1G-6791
C6K (UTL) N/A 1 67 C1
1G-6792
C6K (UTL) N/A 1 67 C2
1G-6793
C6K (UTL) N/A 1 67 C3
SGP Substation 1SS200 (Phase 1)
C6J (GTL) 1-B9403 1 67 E0
ASU Substation 1SS300 (Phase 1)
C2 (ASU) 1-B9404 1 67 F0
LPU Substation 1SS400 (Phase 1)
C5 (LPU) 1-B9405 1 67 G0
Harbour Tankage Area Substation
C3 (TANKS) 19130B01 1 67 H0
Main Distribution Substation 2PSS1 33kV (Phase 2)
C6K (UTL) 2-B9401 2 67 A0
Main Distribution Substation 2PSS1 6.6kV (Phase 2)
C6K (UTL) 2-B9401 2 67 B0
FGP Substation 2SS100 (Phase 2)
C4 (FGP) 2-B9402 2 67 D0
2G-6791
C6K (UTL) N/A 2 67 C1
2G-6792
C6K (UTL) N/A 2 67 C2
2G-6793
C6K (UTL) N/A 2 67 C3
SGP Substation 2SS200 (Phase 2)
C6J (GTL) 2-B9403 2 67 E0
ASU Substation 2SS300 (Phase 2)
C2 (ASU) 2-B9404 2 67 F0
LPU Substation 2SS400 (Phase 2)
C5 (LPU) 2-B9405 2 67 G0

4.1.9 Tightness
Tightness items are addressed as an activity during EPC, pre-commissioning and
commissioning. The system PEFSs could be used as a starting point for the development of
tightness test packages. During the systems definition phase as a minimum a check needs to
be done to verify that the bulk of the tightness packages > 99% are not crossing any system
boundaries.
4.1.10 Cleanliness
The cleanliness aspects are addressed in the flushing, blowing, jetting and or steam blowing
activities during the (pre)-commissioning phase. The Systems PEFS should be used as a
starting point to develop the details for these activities. During the systems definition phase
as a minimum a check needs to be done to verify that the bulk of the tightness packages >
99% are not crossing any system boundaries.

4.1.11 Novelty and complexity
During the Novelty and Complexity identification some mitigation activities (test) may be
defined. These should be identified as activities and will be depicted in the activity sheets,
WEFS and schedule. Depending on the size and scope of the test it is preferred that the
systems definition will allow this test to be completed within the system boundaries.
4.1.12 Testing
Testing activities are identified on a systems level and defined in the activity sheets. In the
WEFS we typically highlight any testing activities to present a high level overview of the
defined test.
4.1.13 Coinciding events

Coinciding event can be found in the various integration aspects. These integration aspects
are visible on the WEFS and via the schedule. The WEFS in a complex project (multiple
process plants) is a user-friendly tool to depict the site integration aspects on system level,
section level and process plant level. This tool has been proven to be successful in
communicating the various integration issues
4.2 System numbering and identification

Start-up blocks and systems shall be defined in order to facilitate the pre-commissioning,
commissioning and initial start-up of the facility during the design phase of the project.
See reference 3 for list of identified start-up blocks.
System numbering build-up is N-UU-Bb-Sxy, where:
N is a one-digit number identifying common or train specific items
Identical equipment of identical parallel trains shall be given identical equipment numbers. A
unique number that identifies the train as follows shall precede the equipment number:
For Equipment that are common to all trains: N = 0
For Equipment in Train 1: N=1
For Equipment in Train 2: N=2
UU is the first 2 digits of the unit number e.g. Unit 0200 = 02
B is one letter A through Z except for I and O, indicating the different type of start-up
blocks within a unit.
b is the functional Block identifier in case of multiple strings (e.g. the nine parallel SGP
reactors); a zero (0) indicates that there are no parallel strings. If more than 9
parallel strings are required these should be split into more than one system.
S is a letter to identify a process system (P) or the first letter of a utility service code
x is the second part of a utility service code or part of a two digit process system
identifier.
y is the single alphanumeric utility service system identifier or part of a two digit
process system identifier.

Note: In the case of a utility system for each service within a start-up block there can be a
maximum of 34 systems (0 to 9 & A to Z excluding I & O). If more than 34 systems
are required these should be split into more than one start-up block. In the case of a
process system up to 100 systems can be specified (00 to 99).
Utility services used in the project specification Systemisation

Abbreviation Description utility service
AOC Accidental oil Contaminated AC
BB Boiler Blowdown BB
BF Boiler Feed Water BF
BB Buildings BS
CHWR Chilled Water Return CH
CHWS Chilled Water Supply CH
SS Civil & structural CS
SS Civil & structural (HVAC) HV
CCWR Closed Cooling Water Return CC
CCWS Closed Cooling Water Supply CC
CD Closed Drain (sweet, waxy hydrocarbon drain) CD
FLT Cold (Low Temp) Dry Flare Header FC
CWM Cooling Water Make up CM
CWR Cooling Water Return CW
CWS Cooling Water Supply CW
DF Defrost gas DF
DM Demineralised water DM
FDR Dry Flare header FD
ES Electrical & electrical supply ES
FD Fire and Gas Detection GD
FW Fire Water WF
FCD Flare Header Waxy Hydrocarbon FH
HP BF High Pressure Boiler Feed Water HB
HP FG High Pressure Fuel Gas HG
HP N2 High Pressure N2 HN
HTTFR High Temperature Heat Transfer Fluid Return HF
HTTFS High Temperature Heat Transfer Fluid Supply HF
DHTF HTF Drain HD
IA Instrument Air / Industrial Air IA
ID Instrumentation / DCS / telephone ID
IPS Intermediate Pressure Steam IS
N2 Low Pressure N2 LN

Utility services used in the project specification Systemisation
Abbreviation Description utility service
LPS Low Pressure Steam LS
LTTFR Low Temperature Heat Transfer Fluid Return LF
LTTFS Low Temperature Heat Transfer Fluid Supply LF
MPBF Medium Pressure Boiler Feed W ater MB
ID Network infrastructure NE
NCC Non contaminated Condensate NC
ID Non MAC equipment e.g. REDAS etc. NM
PW Potable W ater PW
PCC Potential contaminated Condensate PC
SG Safeguarding GU
SIA Secured Instrument Air SA
SW Service W ater SW
SOCOC Sour Continuously Oil Contaminated OC
FSG Sour Gas Flare FG
DSG Sour Hydrocarbon Drain DS
LPSFG Sour Low Pressure Fuel Gas SG
STC Steam Turbine Condensate SC
HPS Superheated High Pressure Steam HS
MPS Superheated Medium Pressure Steam MS
SW COC Sweet Continuously Oil Contaminated WC
LPFG Sweet Low Pressure Fuel Gas LG
DLT Sweet Low temperature Hydrocarbon Drain DL
DHC Sweet, Non waxy Hydrocarbon Drain DH
FSY Syngas Flare header FS
TA Tool Air TA
VLPS Very Low Pressure Steam VS
W PT W ax Pit WP
FW H W et High Pressure Flare header FW
FW L W et Low Pressure Flare header FL
Notes:
Civil & Structural codes
Instrument, DSC & telephone etc. codes
New or modified codes (In bold type)
Examples:
The Hydrocracker in train 1 is unit 1-4000; the start-up block comprises of the whole unit and
is numbered 1-40-A0. The feed pre-heater system of the Hydrocracker would have number
1-40-A0-P00.
The Hydrocracker in train 1 is unit 1-4000; the start-up block comprises of the whole unit and
is numbered 1-40-A0. An electrical supply system for this start-up block could be 1-40-A0-
ES0.
This numbering system shall also be used during system definition and throughout the life of
the project as part of the system based FSI program.
4.2.1 System activity numbering

This section has been deleted as the topic will now be covered in the pending PMC planning
document 5887-ON-PR-PC-010

4.3 System Definition Mark-Up Requirements
System limits and numbers can be added to the PFS / PEFS using intelligent CAD systems,
as an item to be filtered out during normal printing e.g. PEFS issue. Attribute fields shall be
set up within all piping equipment and instruments etc. such that all items within a system
boundary will have the system number identified with it and can be reported via that system
number. This will enable the production of single system drawings and the addition of system
boundary markers to the piping data sheets with again links to other databases i.e.
instrument, electrical, civil such that the compilation of components up to process/utility
system level can easily be seen.
System boundaries will be clearly indicated using the following system break symbol added
to the CAD file.
Note: All equipment, piping etc. to the left side of the system break symbol is in the scope
of system 1-40-A0-P00, where as all equipment piping etc. to the right side of the
symbol is in the scope of 1-40-A0-P01.
In addition to the above the following information block will be completed and added in the
same way covering the original drawing title block.
It is preferred that the systemisation colour coding is also marked up electronically in the
same way using the intelligent CAD package. However, if this is not feasible for a particular
intelligent CAD package or considered to costly or time consuming, colour coding by hand
for each issue of the system definition drawings is acceptable. For a hand mark-up a fresh
set of drawings incorporating the systems breaks and the information block shall be printed
off and marked up for colour coding of the individual systems so they can be easily
recognised when looking at the drawing. For each unit / facility a System Identification List
shall be compiled, showing assigned system engineers, system number, system descriptions

and colour code identified for systems. The use of the same colour code for adjoining
systems shall be avoided.
The System Identification Lists shall then be merged into a Contract System Identification
List for the applicable IC or EPCM contract e.g. C4 System Identification List; this is the
responsibility of the systems engineering coordinator. The Contract System Identification
Lists shall then be merged into an Overall Systems Identification List by the PMC systems
coordinator.
Process system mark-up requirements: A colour mark-up shall be produced on one set of
PEFS showing all process unit and utility systems. System limits / break points shall be
clearly indicated by the system break symbol.
Electrical system mark-up requirements: A colour mark-up will be produced on one set of
one line diagrams showing all electrical systems. System limits / break points shall be clearly
indicated by the system boundary break symbol.
Telecommunication system mark-up requirements: A colour mark-up shall be produced on
one set of block diagrams. System limits / break points shall be clearly indicated by the
system break symbol.
Instrument system mark-up requirements: A colour mark-up shall be produced on one
set of block diagrams showing HIPPS, SIS, Fire and Gas, and control systems. System limits
/ break points shall be clearly indicated by the system break symbol.
Building system mark-up requirements: A colour mark-up will be produced, where necessary,
on one set of layout drawings showing building systems. System limits / break points shall be
clearly indicated by the system break symbol.

4.4 System Activity Sheets
Once a system is defined the CSU activities for that system shall be assessed and recorded,
this will be done using the System Activity Sheet (SAS)
By utilising and populating the SAS, it is possible to capture & build an accurate listing of
activities through the CSU phases and in doing so prepare a detailed an accurate WEFS
and Level 3 / 4 CSU Schedule.
The following are the primary objectives of the SAS:
To define the activity, and the order / sequence of activity(s) for the Pre-
commissioning; Commissioning and Start Up phases
To describe the activity (in sufficient detail only), for the Pre-commissioning;
Commissioning and Start Up phases
To identify the relationships / logic (system interdependencies) that exist between the
various systems so that systems that are required as a prerequisite for a particular
Pre-commissioning / Commissioning / Start Up activity are identified.
To define the Testing Programme required to confirm design intent & functionality of
the Systems; Start Up Blocks; Units etc
To identify First Fill; Temporary Equipment and Vendor requirements for the CSU
phase activities
To assign realistic durations to the activities detailed in the CSU List
Reference document 39 describes this process in detail.
4.5 Work Execution Flow Scheme

During the development of the Commissioning and Start-up (CSU) phase of a project there is
a typical order in which activities are carried out:
Definition and mark up of systems
Definition of system activity sheets (SAS)
Development of a logic diagram (WEFS); a CSU execution road map
Development of the schedule (e.g. with Primavera)
The logic diagram is called a Work Execution Flow Scheme, or WEFS. It is a chart, showing
the logical sequence of activities to be performed in all identified systems and therefore
covers the total scope of CSU work. The links between these activities are also shown.
These links can be within the Contractors scope but can also represent interfaces with
outside battery limits, other ICs or EPCM interfaces outside plot (fence), temporary systems
or resources and other trains (if not included in this WEFS). The WEFS does not show
durations or time data, however, it does read from left to right when following a logical
sequence of events.
Reference, PMC commissioning will provide guidance on completion of WEFS

5.0 SYSTEM FILE
Contractor shall prepare a multi-disciplinary System File for each system. The system file
will contain but not be limited to information about the system such as purpose, scope
definition, procedure, Q items, handover requirements and QA sign-off sheets.
During CSU the system file will be a working file for the commissioning supervisor; this file
can be used to monitor current status against the system specific procedures contained
within. The file will also help to provide an efficient handover of current status and plan to
other members of the commissioning team at shift change and rotation of personnel.
Although the System File will be used on a day to day basis as the system moves through
pre-commissioning and commissioning activities towards RFSU it does not form opart of the
contractual handover documentation (SCM).
The system file does not replace any of the document requirements detailed in the project
Specification, although it is recommended that Part B of the Commissioning manual is made
system specific and moved into the system file.
5.1 System file index

The system file is split into 5 overall headings each with subdivisions.
5.1.1 General
The general section of the system file contains general system information such as process
description, capacity, alarms & safeguarding etc. The majority of this information is already
available in project documents such as process/safeguarding narratives & design
memorandum. This section will be completed during the design phase.
(FSI requirement)
Information held in
System File Index System File Description of section requirements
1 General
1.1 Purpose of system link to HLOM Reference only; Unit description available in HLOM
System specific data Relevant section of HLOM process description that specifically covers the
1.2 Process description of system required applicable system.
System specific data Edited section of HLOM relationships that specifically covers the
1.3 Relationship with other systems including I/M/E required applicable system.
System specific data Edited section of HLOM major system components that specifically covers
1.4 Main system component descriptions required the applicable system.
1.5 Performance criteria of system link to HLOM Reference only; Performance criteria of system available in HLOM
Reference only; Key operation parameters and operation windows
1.6 Key operation parameters and operation windows link to HLOM available in HLOM
1.7 Alarm descriptions and purpose link to HLOM Reference only; Alarm descriptions and purpose available in HLOM
1.8 Safeguarding systems and purpose link to HLOM Reference only; Safeguarding systems and purpose available in HLOM
1.9 Requirement for system availability link to HLOM Reference only; Requirement for system availability available in HLOM
1.10 Capacity/utility requirements link to HLOM Reference only; Capacity/utility requirements available in HLOM
1.11 Process risks and mitigation actions link to HLOM Reference only; Process risks and mitigation actions available in HLOM
1.12 Special areas for attention link to HLOM Reference only; Special areas for attention available in HLOM
1.13 Critical information requirements link to HLOM Reference only; Critical information requirements available in HLOM

5.1.2 Pre-commissioning, Commissioning & start-up
The pre-commissioning, commissioning and start-up section of the system file contains all
procedures, phased prerequisites, vendor support, testing and handover requirements. This
section will be largely completed during the design phase.
(FSI requirement)
Information held in
2 Pre-commissioning, Commissioning & start-up

2.1 Commissioning and start-up; work flow diagram Optional; data contained The WEFS are created by each contractor for their scope and will show all
in SAS systems in their scope. The detailed logic steps for a system are contained
in the SAS for the system, if the contractor feels that an additional system
specific WEFS would be benefit, they can be included
2.2 Commissioning and start-up; schedule (Level 4) Optional system specific Print of approved level 4 primavera schedule for system; it is not intended
data to continuously update this section as the schedule moves through
construction, the intent is to have the original approved schedule for
reference.
2.3 Commissioning and start-up; list of required Provider Optional; data contained Provider and receiver systems are shown on the SAS for the system, the
& Receiver Systems inc. timing in SAS contractor can include a summary sheet in this section if beneficial to the
contractor.
2.4 Commissioning and start-up; utilities, materials and Optional; data contained Utilities, materials and equipment requirements are shown on the SAS for
equipment requirements in SAS the system, the contractor can include a summary sheet in this section if
beneficial to the contractor.
2.5 Commissioning and start-up; vendor specialists Optional; data contained Vendor specialists requirements are shown on the SAS for the system, the
required in SAS contractor can include a summary sheet in this section if beneficial to the
contractor.
2.6 Required blinds/spading during commissioning and System specific data This section shall contain a live spade/blind list for the system and shall be
start-up required kept up to date throughout the implementation phase
2.7 Procedures
2.7.1 Cleaning procedures, including defined criteria and System specific data This section shall contain the cleaning procedure specific for this system,
required fluids required based on the generic procedures and requirements specified in part A of
the commissioning manual
2.7.2 Preservation procedures, including defined criteria System specific data This section shall contain the preservation procedure specific for this
and required fluids required system, based on the generic procedures and requirements specified in
part A of the commissioning manual
2.7.3 Tightness testing procedure, including defined System specific data This section shall contain the tightness testing procedure specific for this
criteria. required system, based on the generic procedures and requirements specified in
part A of the commissioning manual
2.7.4 Nitrogen inerting procedure, including defined criteria. System specific data This section shall contain the inerting procedure specific for this system,
required based on the generic procedures and requirements specified in part A of
the commissioning manual
2.7.5 Catalyst & chemical loading procedure, including System specific data This section shall contain the catalyst & chemical loading procedure
defined criteria. required specific for this system, based on the generic procedures and
requirements specified in part A of the commissioning manual
2.7.6 Special equipment/system procedures e.g. refractory System specific data This section shall contain the special equipment/system procedure specific
dry out required for this system, based on the generic procedures and requirements
specified in part A of the commissioning manual
2.7.7 Functional test protocols for mechanical static and System specific data This section shall contain functional test protocols for mechanical static
rotating equipment including defined acceptance required and rotating equipment specific for this system, based on the generic
criteria procedures and requirements specified in part A of the commissioning
manual
2.7.8 Functional test protocols for instrumentation systems System specific data This section shall contain the functional test protocols for instrumentation
including defined acceptance criteria required specific for this system, based on the generic procedures and
requirements specified in part A of the commissioning manual
2.7.9 Functional test protocols for electrical systems System specific data This section shall contain functional test protocols for electrical specific for
including acceptance criteria required this system, based on the generic procedures and requirements specified
in part A of the commissioning manual
2.7.10 Dynamic test protocols for control systems including System specific data This section shall contain dynamic test protocols for control specific for
defined acceptance criteria required this system, based on the generic procedures and requirements specified
2.7.11 Other procedures and test protocols System specific data This section shall contain other procedures & test protocols not specifically
required listed above, based on the generic procedures and requirements specified
2.8 Precommissioning current status Optional system specific This section is for the contractor to sub divide as required to suit their work
data methods
2.9 Commissioning & start-up current status Optional system specific This section is for the contractor to sub divide as required to suit their work
5.1.2 data methods

5.1.3 Quality assurance and Q areas
The Quality assurance and Q area section of the system file contains an index of all QA
documents required, indicating what phase they are required and will also contain QA sign-
off sheets as they are completed. In addition each Q area will have a subsection containing
all identified risks and mitigation measures applicable for that system. The last part of this
section is an exception list for each check/handover point, RFP, RFC & RFSU. This section
will be partly completed indicating requirements and agreed exceptions during the design
phase and completed and updated during construction/commissioning. An example of an
exception could be where temporary equipment or piping is installed for pre-commissioning
or commissioning activities.
(FSI requirement)
Information held in
3 Quality Assurance & Q areas
3.1 Index of QA documents required for this system inc. System specific data Index of QA documents required for this system inc. phased completion
phased completion requirements required requirements, this shall reflect the SCM requirements and completion
tracking
3.2 Process / Piping QA documents In progress documents This section can contain all partially completed pre-commissioning and
commissioning QA documents; once the QA document is complete it shall
be moved to the SCM and the index in section 3.1 updated to indicate this
requirement is complete.
3.3 Equipment QA documents In progress documents This section can contain all partially completed pre-commissioning and
3.4 Instrument QA documents In progress documents This section can contain all partially completed pre-commissioning and
3.5 Electrical QA documents In progress documents This section can contain all partially completed pre-commissioning and
3.6 Other QA documents In progress documents This section can contain all partially completed pre-commissioning and
3.7 Q areas
3.7.1 Tightness System specific data This section shall contain a list of Tightness flaws applicable to the
required system and their mitigation measures . It should also contain and tightness
flaws identified during the periodic system Q workshops and Q area
specific site observations.
3.7.2 Cleanliness System specific data This section shall contain a list of Cleanliness flaws applicable to the
3.7.3 Integrity System specific data This section shall contain a list of Integrity flaws applicable to the system
required and their mitigation measures . It should also contain and tightness flaws
identified during the periodic system Q workshops and Q area specific site
observations.
3.7.4 Operability/Maintainability System specific data This section shall contain a list of Operability/Maintainability flaws
required applicable to the system and their mitigation measures . It should also
contain and tightness flaws identified during the periodic system and Q
area specific site observations.
3.7.5 HSE System specific data This section shall contain a list of HSE flaws applicable to the system and
required their mitigation measures . It should also contain and tightness flaws
observations.
3.7.6 Prototypes System specific data This section shall contain a list of Prototypes flaws applicable to the
3.7.7 Complexity System specific data This section shall contain a list of Complexity flaws applicable to the
3.7.8 Testing System specific data This section shall contain a list of Testing flaws applicable to the system
observations.
3.7.9 Experience System specific data This section shall contain a list of Experience flaws applicable to the
3.7.10 Coinciding Events / Schedule System specific data This section shall contain a list of Coinciding Events / Schedule flaws
required applicable to the system and their mitigation measures . It should also
contain and tightness flaws identified during the periodic system Q
workshops and Q area specific site observat
3.7.11 Information System specific data This section shall contain a list of Information flaws applicable to the
3.7.12 Interface System specific data This section shall contain a list of Interface flaws applicable to the system
observations.

(FSI requirement)
Information held in
3.8 Exceptions lists
3.8.1 RFP Exception list link to SCM Reference only; RFP Exception list is stored in the SCM
3.8.2 RFC Exception list link to SCM Reference only; RFC Exception list is stored in the SCM
3.8.3 RFSU Exception list link to SCM Reference only; RFSU Exception list is stored in the SCM
This section is for the system engineer on site to make general
observations prior to punch listing and monitor if the problem has been
resolved. This section is optional for the contractor to d use as best suits
3.8.4 Day to day observations Optional their requirements
See reference 9 for further indicative guidance on activities and documents required per completion
points, Ready for Pre-commissioning (RFP), Ready for Commissioning (RFC) & Ready for Start-up
(RFSU).
5.1.4 Health, Safety & Environment

The HSE section shall contain all applicable MSDS sheets for chemicals used during the
construction, pre-commissioning, commissioning and start-up of the unit. It shall also be the
repository for system waste materials handling and specific job hazard analysis (process risk
assessment) completed for this system.
(FSI requirement)
Information held in
4 Health, Safety & Environment
System specific data Copy of MSDS for all chemicals used during the pre-commissioning,
4.1 Material Safety Data Sheets (MSDS) required commissioning & start-up of the system
This section shall contain a list of all waste materials that will be created
System specific data during the pre-commissioning, commissioning & start-up of the system
4.2 Waste materials handling required and the plan for collection and disposal of this waste
This section shall contain job hazard analysis for all major activities to be
System specific data completed in accordance with the system plans e.g. chemical loading,
4.3 Job Hazard Analysis required manual cleaning in confined spaces etc.
5.1.5 Appendices
The appendices section of the system file contains system definition documentation and
supporting project documents. This section will be completed during the design phase.
(FSI requirement)
Information held in
5 Appendices
System specific data The system activity sheet shall be stored in this section and updated
5.1 System Activity Sheet (SAS) required throughout the implementation phase as required
A marked up unit area plot plan shall be included highlighting major
System specific data equipment items for that system and may also show proposed
5.2 Plot plans required commissioning controlled area
System specific data An up to date set of system definition drawings (for process systems this
5.3 System definition drawings required would be marked-up PEFS's)
Start-up block specific An up to date set of system definition drawings (for process systems this
5.4 Systemisation mark-up (start-up block) data required would be marked-up PFS's)
List of test packs within the system to be marked-up as the CSU group
System specific data takes ownership. Note: if required this section can also include marked-up
5.5 System test packs required PEFS for each test pack.
System specific data
5.6 System Equipment list required List of equipment within the system
System specific data
5.7 System instrument list required List of instruments within the system
5.5 Instrument alarm settings link to HLOM Reference only; data available in HLOM
5.6 Safeguarding cause and effect diagrams Unit data An up to date copy of the unit C&E diagram
This section can contain vendor data such as P&ID's, general
5.7 Vendor information Optional vendor data arrangement drawings & extracts from manuals etc.

6.0 SCHEDULE
This section deals with the requirements for systemisation and system based review during
engineering.
During the design phase the asset breakdown activity defines the systems and the system
teams are formed. Periodically the system team will meet for a System Q Workshop where,
each Q area it considered and risks identified. Also, throughout the design phase the system
file will gradually be populated with the required information for this phase.

The first set of system definition drawings will be reviewed by the PMC to ensure cross
contract consistency. However, consistency within a contract scope is the responsibility of
the Contractor systems engineering coordinator.
The system definition drawings shall be maintained up to date throughout the project via
mark-up to the original CAD drawings. However, as a minimum the drawings shall be up
dated electronically and issued twice following the approved system definition issue.
Minimum drawing issued for system definition;
Draft system definition issue for comment
Approved system definition
Updated system definition based on Issued for Design drawings
Updated system definition based on Issued for Construction drawings
Note: If large engineering changes dictate, intermediate issues will be required to maintain
effective system definition; this shall only be required for effected drawings.
6.1 Schedule for system file completion

The system file will be created following the issue of the approved system definition drawings
and will be maintained and sequentially completed throughout the project until handover. At
each sequenced completion point certain predefined content shall be finalised.
Refer to section 5 for System File index
The sequenced major completion points are as follows:
System File generation (following approved issue of systemisation drawings)
Completion of design phase (System file moves to the field)
Ready for Pre-commissioning (RFP)
Ready for Commissioning (RFC)
Ready for Start-up (RFSU); system file handover to Company
Other milestones such as completion of design review, start of construction completion by
system at 60% completion, pre-punching and mechanical completion are not directly
mentioned as major completion points but are mid points or precursors to the above.
6.1.1 System File generation

The system file is initially generated to hold the system definition drawings and edited Flaw
List with only items applicable to that system remaining on the list.
Completion of design phase
At the end of the design phase a large part of the System File shall be complete ready for the
file to move to the field with the field engineering support and commissioning teams.

The following sections shall be finalised at this point (Ref: Section 5.1):
Chapter 1 (complete chapter)
Chapter 2 (2.1 through to 2.7)
Chapter 3
o 3.1, (section complete)
o 3.7, (section up to date with project flaw list)
Chapter 4
Chapter 5 (complete chapter inc. updated issued for construction system definition)
6.1.2 Ready for Pre-commissioning

Prior to pre-commissioning all procedures shall be in place and RFP exceptions list
completed and agreed.
Chapter 2
o 2.1 ~ 2.7, (sections complete)
o 2.8 , (used as required)
Chapter 3
o 3.1, (complete section)
o 3.2 ~ 3.6 (phased completion as defined in section 3.1)
o 3.8.1, (section complete and agreed)
Chapter 4
o 4.2 & 4.3, (section updated as required)
Chapter 5 (complete chapter, with updates as required)
6.1.3 Ready for Commissioning

Prior to commissioning the RFC exceptions list shall be completed and agreed.
Chapter 2
o 2.1 ~ 2.8, sections complete
o 2.9, used as required
Chapter 3

o 3.8.1, (section updated to remove completed items)
Chapter 4
6.1.4 Ready for Start-up

Prior to commissioning the RFC exceptions list shall be completed and agreed.
Chapter 3
o 3.8.1, (section complete)
o 3.8.2, (section updated to remove completed items)
Chapter 4
6.1.5 Commissioning and Start-up Schedule

This section has been deleted as the topic will now be covered in the pending PMC planning
document 5887-ON-PR-PC-010.

7.0 HANDOVER REQUIREMENTS
The first completion point is following the reissue of the system definition drawings based on
issued for construction data; this marks the completion of the major design engineering
activities. Although this marks the handover between the office and field engineering teams,
the handover is internal within the contract scope.
Subsequent completion points are linked into the C&SU schedule up until the final
completion point at RFSU which marks the handover from Contractor to Company.
Handover refers to Companys agreement to take over operational responsibilities at a Start-
up Block level from Contractor when RFSU is achieved; all related and required completion
and handover documentation is complete and signed off by duly authorised officer(s) of
Contractor and Company. However for certain Phase 1 Utility Start-up Blocks/Units handover
will occur after Performance Testing.
Systems shall not be handed over on a piece meal basis, without specific agreement for that
system by the Company.
See reference 8 for further information regarding handover.
The handover of start-up block shall be staged so as not create excessive peak resource
requirements and agreed with the Company during the design phase e.g. prior to first

completion point. In addition, the number notifications of systems ready for punching by the
Company per week shall be limited to an amount agreed with the Company during the
design phase for the same reason. This staged system punching and start-up block
handover shall be reflected in the C&SU schedule agreed with the Company. Prior to
notification of system ready for punching, the system shall already have been punched by
the Contractors commissioning team and relevant issues resolved. If excessive amounts of
items are found by the Company during punching the punch shall be stopped and the system
deemed not ready for punching, these systems shall be resubmitted for punching once it has
been rechecked by the Contractor commissioning team and issues resolved.
Note: Systems resubmitted for punching shall be included in the weekly quota for systems
ready for punching by the Company. Hence, resubmission may impact schedule
dependent on the number of system punches scheduled for that week.
7.1 Activity check list

During the construction, pre-commissioning, commissioning and start-up certain activities
shall be completed and inspected or witnessed. These activities are listed in the Activity
Check List (Reference 9 & 39). For each activity the Contractor and Company responsibilities
are indicated for each stage e.g. construction, pre-commissioning, commissioning and start-
up.
The overall Activity Check List (Reference 9 & 39) shall be updated to make it specific for each
system and included in chapter 5 of the System File. Many of these activities will require QA
documentation to be completed and filed in chapter 3 of the System File.
Note: The Activity Check List provided in the FEED documentation shall be updated
during the detailed engineering phase to incorporate any additional QA/QC and
Flaw mitigation requirements.

8.0 COORDINATION & INTERFACE
The development of the Pearl GTL Project is characterised by the presence of many
execution Contractors who will have to interact with each other to successfully achieve
project objectives. This interaction between execution Contractors will be managed following
the interface management procedure developed by the PMC and the interface register (Ref:
5887-ON-PR-EM-21).In terms of systemisation, interfaced exist both inside the execution
Contractors scope and between execution Contractors scopes.
It is vital that during systemisation that there are no gaps between systems i.e. system
definition is consistent across all Contractors. It is the responsibility of the systems
engineering coordinator assigned by the execution Contractor to ensure there are no gaps or
overlaps within their scope and to agree system boundaries that coincide with scope
boundaries with the PMC systems engineering coordinator.
Following the issue of the approved system definition drawings, any change to system
boundaries shall be agreed with the Contractors system engineering coordinator and the
PMC system engineering coordinator if the change affects Contractor scope.
Certain start-up blocks will run across Contractor scopes. For these systems it is likely that
the majority of the start-up block is within the EPCM utilities scope, in this case the EPCM
system engineer shall take the lead and ensure that all systems within that start-up block are
aligned in terms of schedule, cleaning and testing etc. all correspondence shall be copied to
both the Contractors, EPCM and PMC system engineering coordinator.
8.1 Correspondence
All email correspondence relating to a particular system shall have the unique system
identifier at the start of the subject line; if the correspondence is relating to an interface issue
between two systems the subject shall start with the system identifier from the originating
system engineer, followed by the identifier of the effected system. An example of few email
correspondences is given below.
From: IC System Engineering Coordinator

To: PMC Systems Engineering Coordinator
Subject: N-UU-Bb-Sxy; First system definition mark-up ready for review
The attached files are the first systemisation mark-up for system N-UU-Bb-Ss, this system
has a boundary that coincides with the C3/C4 contract split hence, is submitted for review.
From: EPCM System Engineer

To: IC System Engineer
CC: PMC Systems Engineering Coordinator
Subject: 1-77-A0-SG1, 1-05-D0-SG1; Fuel gas supply to F-0511
It is agreed that sections of 1-77-A0-SG1 detailed in the 1-05-D0-SG1 cleaning procedure
will be available for use at the stated time of requirement.

From: IC System Engineer
To: IC Q Captain Prototypes
CC: IC Systems Engineering Coordinator
Subject: N-UU-Bb-Sxy; New vendor X prototype risk
Following the recent Flawless workshop with vendor X, the following two items were
identified as prototypes items, please add these items to the Flaw List.
1. Wigit not manufactured at this size before.
2. Rubber Z1 seals have not been used in this service before
We are currently working with the vendor to put in place a mitigation plan and I will inform
you once this has been finalized.
From: IC Q Captain Prototypes

To: PMC Q Captain Prototypes
Subject: N-UU-Bb-Sxy; New vendor X prototype risk
I have added the two items below to the Flaw List; vendor X informed us that the materials
used in the Z1 seals are industry standard but they have no experience with our fluid. Please
check if there is any other equipment on the project in a similar service and check this item
with its vendor
1. Wigit not manufactured at this size before.
2. Rubber Z1 seals have not been used in this service before
We are currently working with the vendor to put in place a mitigation plan and your input
would be appreciated.

9.0 CHANGE MANAGEMENT
Change management shall follow the project change management systems (Ref: 5887-ON-
PR-EM-020) for engineering changes within the system. Changes to system scope are to be
agreed with the relevant system coordination engineer as discussed in section 8.
Engineering changes affecting a system and originating from outside that system should
preferably be reviewed and commented on by the system engineer and system owner prior
to final approval.

10.0 Q AREAS & SYSTEM BASED REVIEW
Q areas and systemisation are the foundations of the Flawless Start-up initiative, the aim to
provide focus on specific risk areas (Q areas) and also provide a framework for mitigating
identified risks. Sitting behind the Q areas is the project Flaw List in which flaws are assigned
and mitigated within the most relevant Q area. Unknown flaws can not be mitigated; hence
the effectiveness of this initiative is highly dependent on how extensive, complete and
relevant the Flaw List is.
10.1 System based review

For each type of engineering review such as model, plot plan, PEFS, WEFS and vendor
drawing etc. the system engineer shall review and provide comment were applicable
maintaining focus on their system. If required the system engineer/system owner can call
upon all or part of their system team to participate.
10.1.1 System Q Workshops

As detailed in section 6.1, each system team should convene for a System Q Workshop at
key intervention points; approximately every 3 months throughout the design phase. During
these workshops each Q area shall be discussed in turn and developed flaws / mitigations
communicated to the Q Captains and the systems engineering coordinator. This workshop
will be minuted and copys sent to the Contractors systems engineering coordinator & Q
captains plus the PMC systems engineering coordinator.
Key Intervention points
The system team should convene for a System Q Workshop at the following key intervention
points;
Systemisation drawings completed
Issued for design (initial issue for Company comment and layout)
30% model review
Approved for design (Company comments incorporated)
Re-issued for design (Vendor data incorporated)
60% model review
Issued for construction
90% model review
Note: If two key intervention points are scheduled in close proximity to each other (i.e.
within 6 weeks), one System Q Workshop can be omitted to maintain and
approximate 3 month gap between reviews. Also, if there is a long duration between
adjacent intervention points (i.e. greater than 20 weeks) an interim System Q
Workshop should be scheduled.

10.2 Q Areas
There are 12 identified Q areas for this project, an overview of each Q area is given below
and Q books have been developed which cover each area in greater detail. Certain Q areas
such as Novelty, Complexity and Testing should be considered when developing
systemisation.
10.2.1 Q1 Tightness
The Tightness Q-area addresses engineering, procurement, construction, commissioning
and start-up risks to producing a tight system, and identifies the required measures to ensure
that these risks are adequately mitigated.
This is to prevent internal and external leaks occurring during shop-testing, construction (e.g.
hydro-testing), commissioning, start-up and the initial operation through to the first scheduled
major maintenance turnaround.
Tightness of a system has two elements, external and internal.
External tightness focuses on the leak free operation of all system connections including
flanges, caps, clamps, manholes, pump casings, compressor casings, instrument fittings,
and all other joints that require sealing for operation of a system
Internal tightness focuses on the internal leak free operation of valves, especially valves
classified as ESD (Emergency Shutdown), TSO (Tight shut off) and any other valves
required for containment of fluids within a system.
See reference 20 for further information
10.2.2 Q2 Cleanliness
The Cleanliness Q-area addresses engineering, procurement, construction, commissioning
and start-up risks to producing clean systems, and identifies the required measures to
ensure that these risks are adequately mitigated.
Before commissioning of systems can precede, removal of sand, dirt, scale, stones, welding
slag water, and all other debris from piping systems, columns, vessels, reactors etc. must be
accomplished such that the plant is clean. Debris and dirt within a system can cause many
problems and delays during start-up and could even result in equipment damage.
10.2.3 Q3 Integrity
Functional Integrity is defined as the system or component functioning as it was intended to
in the original design. Failure to operate in accordance with the design intent can have
unforeseen consequences ranging from a requirement for additional operator intervention
and consequential delays to the start-up through to a complete failure and resultant
shutdown of the facilities.
Functional Integrity is far reaching and as a result has been divided into the following six
areas:
Process integrity (See reference 22 for further information)
Static equipment integrity (See reference 23 for further information)

Rotating equipment integrity (See reference 24 for further information)
Instrument integrity (See reference 25 for further information)
Electrical integrity (See reference 26 for further information)
Civil integrity (See reference 27 for further information)
Each of these areas has different characteristics, but also a common theme in that failure to
perform as intended results in economic loss to the project. Some integrity mitigations may
involve testing and hence should be considered during systemisation.
10.2.4 Q4 Operability and Maintainability

Operational integrity requires to satisfy customer needs and to be in control at all times
Satisfy customer needs in this case means delivery of products (quantity and quality) as per
the business requirements, whilst using the resources (people, utilities, etc.) as per the same
business plan. The delivery of products requirement is a result of actual capacity and
achieved system effectiveness.
System effectiveness at start-up is in fact the quantitative goal of Flawless. The system
effectiveness targets during start-up require a full comprehension of risks that jeopardise
production at those early stages of the projects production life. The flawless program is
designed to understand and mitigate those risks during and just after start-up.
To be in control at all times means that under all circumstances, risks for people,
environment, and asset are tolerable. The combination of satisfy customer needs & be in
control at all times dictates the quantitative requirements for operability and maintainability
Operability in this respect is defined as the speed and effort required establishing a functional
system:
in stable & continuous operation for a specified period,
in readiness for intended services and duty,
at a desired performance, while meeting required mechanical, functional, operational,
safety and operating license criteria (as set by the respective stakeholders).
Speed is the time required to effect a standard change in the status of operation, service
mode, or performance level of the system i.e. the speed with which a system can be brought
to a condition of readiness for operation. This time required will be considerably extended if
e.g. scaffolding has to be removed, unidentified blinds have to be located and removed, etc.
Effort is the level of attention, and degree of difficulty required to be able to use a complex
system first time right, e.g. the attention level required in acknowledging alarms, preparation
of work permits, supervising of operations tasks, craft tasks, etc.
10.2.5 Q5 Health Safety & Environment

The HSE Q area of the Flawless Start-up Initiative addresses the commissioning & start-up
HSE risks and identifies the HSE management processes that shall be implemented by the
Contractor to mitigate those risks. This emphasis on HSE is intended to supplement, not
replace, the normal requirement for the Contractor to apply its own policies, standards and

procedures to devise and implement an HSE management plan to cover the commissioning
phase of the project.
10.2.6 Q6 Prototypes
Prototypes are defined as any new process, piece of equipment, components in a piece of
equipment, packaged unit, or novel application with which there is no sufficient operating
experience yet. Prototype and novel are synonyms from the flawless start-up point of view.
For practical purposes, a distinction is made between:
Process Prototypes i.e. Major Equipment Component
Equipment Prototypes i.e. Packaged, and Standard Equipment
Opinion of what constitutes novelty will vary. For equipment prototypes, Contractors
engineers will need to employ their engineering judgement, in consultation with Vendors, to
identify equipment viewed as novel in terms specified requirements, and size, material
selection, process fluid, manufacturing methods, quality changes, material substitutions, new
combinations of known elements, or process requirement.
The process of managing prototypes includes the following steps:
Identification and recording,
Risk assessment
Definition of the mitigating actions,
Implementation
Monitoring of performance during the initial operating phase.
Mitigating actions may comprise design changes, design verification, dynamic simulation,
testing, specific procedures, extra training, monitoring during initial operations phase,
readiness for field modifications, etc. As some prototype mitigations may involve testing and
hence should be considered during systemisation.
See reference 30 & 31 for further information
10.2.7 Q7 Complexity
A complex system is defined as any system for which the operation, the functioning or the
internal mechanics is not immediately obvious to an experienced operator and that would
require him to consult documents like plant/equipment manuals and drawings for a full
understanding of it.
Complexity in the context of this flawless start-up initiative is restricted to functional or
plant/equipment systems only. Other forms of complexity are not considered, like project
execution, project organization, etc.
The process of managing complexity includes the following steps:
Identification and recording
Risk assessment
Definition of the mitigating actions

Implementation
Monitoring of performance during the initial operating phase.
Mitigating actions may comprise simplification by redefinition or redesign, provide further
documentation and training, purchasing of packages, testing, monitoring during initial
operations phase, and readiness for field modifications, etc. Some Complexity mitigations
may involve testing and hence, should be considered during systemisation.
10.2.8 Q8 Testing
The "Testing Q" part of the Flawless Start-up Initiative involves all the necessary activities to
be carried out to define and execute a systematic and structured commissioning functional
test programme that results in both a "first time right" start-up and plant performance as per
design.
The failure to apply a comprehensive and structured testing plan will result in system failures
interrupting the commissioning and start-up programme causing costly delays.
The following philosophies are to be followed in consideration of testing:
A holistic approach to testing is required, recognising that components shall be built
into systems. Each successive test shall be based on a logical sequence of testing.
All specified tests of both components and systems shall be carried out at the earliest
opportunity and at the lowest "severity" level to minimise impact of failure and to allow
maximum time for any rectification work that may be required. "Lowest severity" here
means utilizing benign fluids at low temperatures and pressures when it is practicable
to do so.
The scope of testing of components and systems shall be maximized in order to
minimize start-up flaws, subject to such tests yielding meaningful results and being
cost effective. The cost of a particular test is to be evaluated against the risk that is
being mitigated by the particular test.
Engineering design should have a positive role in formulating the commissioning and
start-up testing programme.
Particular attention shall be paid to the adequacy of testing plans in respect of
prototypes, critical equipment and complex systems.
Consideration shall also be given to "opportunity tests" (such as load shedding on a
gas turbine trip) to ensure that required data is gathered on an opportunity basis
rather than necessarily with a prescribed test.
Particular attention shall be given to testing requirements during systemisation such
that the test can wherever possible be completed within a defined system.
10.2.9 Q9 Experience
Experience is defined as establishing a competency base in the organisation that has the
responsibility for completing the new facilities designed, built and in operation with a flawless

performance record. It is important that there is sufficient experience within the system team
to get the maximum benefit from the System Q Workshops and help populate the Flaw List.
10.2.10 Q10 Coinciding Events

Coinciding Events is defined as the undesirable events taking place during a project, either
individually or as a combination. These events can be grouped as Surprises, Incidents, Near
Misses, and Deviations. A consequence of these events occurring can be classified in two
categories:
One that draws immediate must attention, when things need to be corrected without
hesitation
One that draws immediate undesirable attention when things consume valuable
time that was planned to be dedicated elsewhere.
Coinciding events can give rise to unwanted HSE, asset and schedule risks, the common
scheduling software format and integrated overall commissioning & start-up schedule (Ref:
section 4.2 & 6) can be used as a tool to highlight these events.
10.2.11 Q11 Information

The Information Q area addresses the availability of information to facilitate the
commissioning and start-up. Appropriate information management give an organisation the
ability to effectively, efficiently and confidently make decisions. Lack of information causes
indecision and errors.
10.2.12 Q12 Interface

The Interface Q area addresses the fact that this large highly integrated project will be
engineered in multiple locations by multiple engineering Contractors. The construction of this
huge complex will also involve many construction Contractors with simultaneous
requirements for resources. The interface will be managed under to general areas i.e.
Design interface & Construction interface.
Interface between adjoining systems and systems within a common start-up block/unit is
crucial to assuring the flawless pre-commissioning, commissioning & start-up and functional
integrity of that system, start-up block or unit.
See reference 37 & 38 for further information

11.0 NOMENCLATURE
ADT Asset Delivery Team
CCR Central Control Room
CRAR Control Room Auxiliary Room
CSU Commissioning & Start-up
DCS Distributed Control System
EPCC Engineering, Procurement, Construction & Commissioning
EPCM Engineering, Procurement, Construction & Management
FAR Field Auxilary Room
FSI Flawless Start-up Initiative
F&G Fire and Gas System
GTL Gas to Liquids
HIPPS High Integrity Process Protection System
HLOP High Level Operating manual
HVAC Heating ventilation and Cooling
IC Implementation Contractor
IPS Instrument Protective System
KPI Key performance Indicator
MAC Main Automation Contractor
OPEX Operational Expenditure
PAS Process Automation System
PFS Process Flow Scheme
PEFS Process Engineering Flow Scheme
RBI Risk Based Inspection
RCM Reliability Centred Maintenance
RFC Ready for Commissioning
RFP Ready for Pre-commissioning
RFSU Ready for Start-up
SAS System Activity Sheet
SAT Site Acceptance Testing
SCM System Completion Manual
UPS Uninterrupted Power Supply
WEFS Work Execution Flow Scheme

12.0 REFERENCE DOCUMENTS
This section contains a list of documents referenced in this systemisation manual plus other
related documents that should be reviewed for information in conjunction with systemisation.
1. Guidelines for systemisation, Preparation of logic diagrams and schedule
development for Pre-Commissioning, Commissioning and Start-Up, T-13.377.420
2. Guidelines for punching, T-13.377.421
3. Project spec part I, Ch 2; General Information, Appendix 2, Start-up blocks, T-
13.377.518
4. Project spec part II, Ch 2; General Design Considerations, Section 2.4 Operational
Systems, T-13.377.374
5. Project spec part III, Ch 5; Commissioning and handover T-13.377.533
6. Project spec part III, Ch 5; Commissioning and handover (appendix 1,
commissioning deliverables and activities during engineering) T-13.377.538
7. Project spec part III, Ch 5; Commissioning and handover (appendix 2,
commissioning deliverables and activities on site) T-13.377.592
8. Project spec part IV, Ch 5; Commissioning and handover T-13.377.779
9. Project spec part IV, Ch 5; Commissioning and handover (appendix 1, activity
checklist) T-13.377.553
10. Project spec part IV, Ch 5; Commissioning and handover (appendix 2, systemisation
breakdown principal) T-13.377.554
11. Project spec part IV, Ch 5; Commissioning and handover (appendix 3, turnover flow
chart) T-13.377.556
12. Project spec part IV, Ch 5; Commissioning and handover (appendix 4, Turnover
block diagram) T-13.377.567
13. Project spec part IV, Ch 5; Commissioning and handover (appendix 5, punching flow
chart) T-13.377.568
14. Project spec part IV, Ch 5; Commissioning and handover (appendix 6, testing flow
chart) T-13.377.591
15. Project spec part IV, Ch 10; Flawless start-up T-13.377.578
16. Work Flow Scheme WFS level 2 Pre-commissioning, Commissioning & Start-up for
Utilities; GTL Project Qatar, T-13.377.417
phase 1 (mainly Train 1); GTL Project Qatar, T-13.377.418
phase 2 (mainly Train 2); GTL Project Qatar, T-13.377.419
19. Work Flow Scheme WFS level 1 Pre-commissioning, Commissioning & Start-up;
GTL Project Qatar
20. Q Book; Tightness, 5887-ON-PR-FS-001
21. Q Book; Cleanliness, 5887-ON-PR-FS-002

22. Q Book; Integrity Process, 5887-ON-PR-FS-003
23. Q Book; Integrity Static equipment, 5887-ON-PR-FS-004
24. Q Book; Integrity Rotating equipment, 5887-ON-PR-FS-005
25. Q Book; Integrity Instrumentation, 5887-ON-PR-FS-006
26. Q Book; Integrity Electrical, 5887-ON-PR-FS-007
27. Q Book; Integrity Civil, 5887-ON-PR-FS-008
28. Q Book; Integrity Operability & Maintainability, 5887-ON-PR-FS-009
29. Q Book; Integrity HSE, 5887-ON-PR-FS-010
30. Q Book; Integrity Novelty - Process, 5887-ON-PR-FS-011
31. Q Book; Integrity Novelty Rotating equipment, 5887-ON-PR-FS-012
32. Q Book; Integrity Complexity, 5887-ON-PR-FS-013
33. Q Book; Integrity Testing, 5887-ON-PR-FS-014
34. Q Book; Integrity Experience, 5887-ON-PR-FS-015
35. Q Book; Integrity Coinciding events, 5887-ON-PR-FS-016
36. Q Book; Integrity Information, 5887-ON-PR-FS-017
37. Q Book; Integrity Interface - Design, 5887-ON-PR-FS-018
38. Q Book; Integrity Interface - Construction, 5887-ON-PR-FS-019
39. PMC Commissioning / Start Up Activity List, 5887-ON-PL-CO-002
40. Project Work Breakdown Structure proceedure, 5887-ON-PR-PC-007

13.0 APPENDIX
This section contains large A3 size drawings
1. PAS systemisation overview
2. Electrical systemisation overview





QSGTL T-4144232 Systemisation Book

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

QSGTL T-4144232 Systemisation Book

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

QSGTL T-4144232 Systemisation Book

Uploaded by

Copyright:

Available Formats

Flawless Start-up Initiative

Implementation Book for Systemisation

A 22/05/07 DTP MV DK IFL Issued for implementation

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 1 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

2.0 PRINCIPAL OF SYSTEMISATION ....................................................................................................6

3.0 SYSTEM TEAM ..................................................................................................................................9

3.1 Roles of the System Engineer ........................................................................................................... 9

4.1 System Definition Guidelines ........................................................................................................... 13

5.1 System file index.............................................................................................................................. 29

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 2 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

6.1 Schedule for system file completion ................................................................................................ 34

7.1 Activity check list .............................................................................................................................. 38

8.1 Correspondence .............................................................................................................................. 39

10.0 Q AREAS & SYSTEM BASED REVIEW .........................................................................................42

10.1 System based review....................................................................................................................... 42

12.0 REFERENCE DOCUMENTS............................................................................................................49

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 3 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 4 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 5 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

Asset Breakdown Hierarchy diagram

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 6 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

1. Asset breakdown (Systemisation)

(Sub) System Activity lists WEFS

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 7 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 8 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

3.1 Roles of the System Engineer

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 9 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA

3.2 Roles of the System Engineering Coordinator

Shell Project No.: HP-3000-QAT Contractor name: Unit: 0-0000

Contractor Project No.: 5887 MWKL- JKP

Contractor Contract No.: PI-093 Sheet: 10 of 54 PCWBS: NA

PEARL GTL PROJECT Orig. Org.: Contractor Doc No: NA