TRANSNET PIPELINES - Welcome to eTenderPublication | … · 2017-05-25 · TRANSNET PIPELINES PCS Upgrade Project Document Number Rev Page RFI Technical Specification H354086-00000-300-078-0001

TRANSNET PIPELINES

PCS Upgrade Project Document Number Rev Page

RFI Technical Specification H354086-00000-300-078-0001 0 1 of 35

PCS Upgrade Project

RFI Technical Specification

DOCUMENT APPROVAL PROCESS

NAME POSITION/MEETING NO. SIGNATURE DATE

Originator Stuart Florence Hatch – Senior Control Engineer

Approver Alan Parsons TPL Manager – MC&I

Original date 2017-04-19

Effective date 2017-05-17

TRANSNET PIPELINES



REVISION REVIEW RECORD

Rev NAME POSITION/MEETING NO. SIGNATURE DATE

0

Doc Status

Hatch Review

Hatch Approve

TPL Review

TPL Accept

1

Doc Status

Hatch Review

Hatch Approve

TPL Review

TPL Accept

2

Doc Status

Hatch Review

Hatch Approve

TPL Review

TPL Accept

3

Doc Status

Hatch Review

Hatch Approve

TPL Review

TPL Accept

4

Doc Status

Hatch Review

Hatch Approve

TPL Review

TPL Accept

5

Doc Status

Hatch Review

Hatch Approve

TPL Review

TPL Accept

TRANSNET PIPELINES



Page 3 of 35 Originator: Stuart Florence Original date: 2017-04-19 Always refer to the electronic copy for the latest version.

TABLE OF CONTENTS

1. Purpose ................................................................................................................................. 5

2. Scope and Applicability ........................................................................................................ 5

3. Document Usage .................................................................................................................. 5

4. References ............................................................................................................................ 6

4.1 TPL Applicable Specifications and Standards .......................................................................... 6 4.2 Other Applicable Specifications and Standards ....................................................................... 6

5. Abbreviations And Definitions .............................................................................................. 7

5.1 Abbreviations ....................................................................................................................... 7 5.2 Definitions ........................................................................................................................... 8

6. Process Control, Metering and Pipeline Monitoring Systems Overview .............................. 9

6.1 Background ......................................................................................................................... 9 6.2 General ............................................................................................................................... 9 6.3 Execution Strategy ............................................................................................................. 10 6.4 Site Details ........................................................................................................................ 11 6.5 RFI Modules ...................................................................................................................... 12

7. Critical Requirements .........................................................................................................13

8. System Module 1: Process Control System ........................................................................14

8.1 Overview ........................................................................................................................... 14 8.2 Critical Requirements ......................................................................................................... 15 8.3 Module Requirements ......................................................................................................... 16

8.3.1 General .................................................................................................................... 16 8.3.2 Control ..................................................................................................................... 16 8.3.3 Alarming ................................................................................................................... 17 8.3.4 Interfaces ................................................................................................................. 17 8.3.5 Data Archiving .......................................................................................................... 17 8.3.6 Development ............................................................................................................ 17 8.3.7 System Performance ................................................................................................. 17 8.3.8 Security .................................................................................................................... 18 8.3.9 Maintenance and Upgrades........................................................................................ 18 8.3.10 Replay ...................................................................................................................... 18 8.3.11 HMI Trainer/Simulation ............................................................................................. 19 8.3.12 Proof of Concept Workshop ....................................................................................... 19

8.4 Capability .......................................................................................................................... 20 8.4.1 Operational Data Warehouse ..................................................................................... 20 8.4.2 Terminal Management ............................................................................................... 20

9. System Module 2: Custody Metering ..................................................................................22

9.1 Overview ........................................................................................................................... 22 9.2 Metering Process Equipment ............................................................................................... 22 9.3 Scope of RFI ...................................................................................................................... 22 9.4 Critical Requirements ......................................................................................................... 23 9.5 Module Requirements ......................................................................................................... 24

9.5.1 General .................................................................................................................... 24 9.5.2 Certification and Approvals ........................................................................................ 24 9.5.3 Alarming ................................................................................................................... 24 9.5.4 Interfaces ................................................................................................................. 25 9.5.5 Archiving .................................................................................................................. 25

TRANSNET PIPELINES




9.5.6 Reporting ................................................................................................................. 25 9.5.7 Development ............................................................................................................ 25 9.5.8 Performance ............................................................................................................. 25 9.5.9 Security .................................................................................................................... 26 9.5.10 Maintenance ............................................................................................................. 26 9.5.11 Proof of Concept Workshop ....................................................................................... 26

9.6 Capability .......................................................................................................................... 27 9.6.1 Metering Trainer ....................................................................................................... 27 9.6.2 Flow Computers ........................................................................................................ 27

10. System Module 3: PLMS .....................................................................................................28

10.1 Overview ........................................................................................................................... 28 10.2 Critical Requirements ......................................................................................................... 28 10.3 Module Requirements ......................................................................................................... 28

10.3.1 General .................................................................................................................... 28 10.3.2 Alarming ................................................................................................................... 28 10.3.3 Interfaces ................................................................................................................. 28 10.3.4 Archiving .................................................................................................................. 29 10.3.5 Development ............................................................................................................ 29 10.3.6 Performance ............................................................................................................. 29 10.3.7 Security .................................................................................................................... 29 10.3.8 Maintenance ............................................................................................................. 29 10.3.9 Proof of Concept ....................................................................................................... 29

10.4 Capabilities ........................................................................................................................ 29 10.4.1 Pressure Dynamic Tracking System ............................................................................ 30 10.4.2 Batch Tracking System .............................................................................................. 30 10.4.3 Pig Tracking System .................................................................................................. 30

11. Project Wide/Common Module ..........................................................................................31

11.1 Overview ........................................................................................................................... 31 11.2 Common Requirements ...................................................................................................... 31

11.2.1 Regulatory Compliance .............................................................................................. 31 11.2.2 General Quality ......................................................................................................... 31 11.2.3 Software Lifecycle Quality .......................................................................................... 31 11.2.4 Documentation ......................................................................................................... 31 11.2.5 Support/Lifecycle ...................................................................................................... 32 11.2.6 Project Experience .................................................................................................... 32 11.2.7 Project Execution ...................................................................................................... 33 11.2.8 Commissioning and Support ...................................................................................... 33 11.2.9 Ops Readiness Training ............................................................................................. 33 11.2.10 Maintenance Training ................................................................................................ 33 11.2.11 System Architecture .................................................................................................. 33 11.2.12 Localisation .............................................................................................................. 33

11.3 Common Capabilities .......................................................................................................... 34 11.3.1 E&I Design ............................................................................................................... 34 11.3.2 E&I Installation ......................................................................................................... 34 11.3.3 Panel Manufacture and Hardware Integration ............................................................. 34

12. Document Lifecycle Management ......................................................................................35

12.1 Revision History ................................................................................................................. 35 12.2 Comments Resolution ......................................................................................................... 35

TRANSNET PIPELINES




1. Purpose

The purpose of this Request For Information (RFI) Specification document is to,

Detail the high level scope requirements for the Process Control, Custody Metering and

Pipeline Monitoring System(s) required to be deployed on Transnet Pipeline multi-product petroleum pipeline infrastructure,

Detail the core requirements which will establish the basis for selecting the Process

Control, Custody Metering and Pipeline Monitoring System(s),

Support identification of suitable Process Control, Custody Metering and Pipeline

Monitoring System(s) from the market.

2. Scope and Applicability

The system scope of this specification is,

Process Control System (PCS),

Custody Metering System (CMS).

Pipeline Monitoring System (PLMS),

The scope of the project includes the supply/provision of Process Control, Custody Metering and

Pipeline Monitoring System/s suitable for use on all Transnet Pipeline infrastructure.

Only systems that have an established/ and proven track record on multi-product petroleum

pipeline installations will be considered.

Once developed, the system/s shall be deployed to all Crude Oil Pipeline stations, from Fynnlands Intake Station to Coalbrook Delivery Station. Note that in addition to catering for

crude product deliveries, the Coalbrook station also caters for catpoly (component) product deliveries, avtur product intakes and multi-product through station pumping which is included in

the scope of works. The latter products are distributed via pipeline networks that are separate

to the Crude Oil Pipeline.

3. Document Usage

In this specification,

the word shall is to be understood as a mandatory requirement,

the word should as a preference,

the word may as a permissive (i.e. neither mandatory nor necessarily recommended),

and the word will as a declaration on behalf of something/ someone else.

The word should shall be treated as a requirement, although it is acknowledged that it may be

negotiated based on appropriate justification.

Text indicated as 'Note' does not form part of this specification. Notes aid the reader's understanding of the associated requirements.

TRANSNET PIPELINES




4. References

4.1 TPL Applicable Specifications and Standards

No. Doc. No. Rev.

[1] Custody Metering User Requirements Specification TPL-TECH-I-M-SPEC-011 02a

[2] Control System User Requirements Specification TPL-TECH-I-C-SPEC-012 02d

[3] PCS Software Control Module Standard TPL-TECH-I-C-STD-013 01c

[4] Automation Standard PL723 4 (draft)

4.2 Other Applicable Specifications and Standards

No. Doc. No. Rev.

[5] Dynamic Measuring Systems for Liquids other than water

OIML R117-1 2007

[6] API Manual of Petroleum Measurement Standards -

Chapter 5: Metering Systems

Section 3: Measurement of Liquid Hydrocarbons by Turbine Meters

Section 5: Fidelity & Security of Flow Measurement Pulsed-Data Transmission Systems

API Chapter 5: Ed 4 2005

[7] RSA Trade Metrology Act 77 of 1973 Act 77 of 1973 1973

[8] RSA Legal Metrology Act 9 of 2014 Act 9 of 2014 2014

TRANSNET PIPELINES




5. Abbreviations And Definitions

5.1 Abbreviations

Abbr Definition

Avtur Aviation Turbine Fuel

BTS Batch Tracking System

CMS Custody Metering System

COP Crude Oil Pipeline

COTS Commercial Off-The-Shelf

Dual Manifold Fuel manifold have two metering paths

E&I Electrical and Instrumentation

ERP Enterprise Resource Planning (Business System)

F&G Fire & Gas

FC Flow Computer

HMI Human Machine Interface (SCADA Workstation)

IO Input/Output

KPI Key Performance Indicator

LAN Local Area Network

LDS Leak Detection System

MCC Master Control Centre

MDS Metering System Database

MES Manufacturer Execution System

MIS Management Information System

MP Multiproduct

OPC UA Object Linked Embedding for Process Control Unified Architecture

PCS Process Control System

PDTS Pressure Dynamic Tracking System

PLC Programmable Logic Controller

PLMS Pipeline Monitoring System

PTS Pig Tracking System

RFI Request for Information

RFP Request for Proposal

SAP Systems, Applications, Products (ERP)

SCADA Supervisory Control And Data Acquisition

SCC Secondary Control Centre

SD Supplier Development

SIS Safety Instrumented System

TPL Transnet Pipelines

NOC National Operations Centre

TRANSNET PIPELINES




Abbr Definition

VSD Variable Speed Drive

WAN Wide Area Network

5.2 Definitions

Concept Definition

Device Group A Device Group is defined as a collection of devices, grouped both logically and functionally for the purposes of control and monitoring e.g. Receivers and Launchers

Mode Of Control Location of control from which control is effected from. From a control system point of view this can be,

Station – Control is by the local station operator. Only commands originating from the Station are accepted.

MCC – Control is from the CO in the MCC. Only command originating from the MCC are accepted.

Note: Alarm annunciation and its associated acknowledgment follows Mode of Control.

Mode of Operation Location from which operation is effected from. From a control system point of view this can be,

Local – Operation of a device occurs either from the device itself (in the case of valve actuators) or from Starter Panels in the Switchgear Room (in the case of Motors).

Manual – Operation of a device occurs from the PCS System via the device faceplate.

Automatic – Operation of a device/group of devices occurs from the PCS System via control sequences.

TRANSNET PIPELINES




6. Process Control, Metering and Pipeline Monitoring Systems Overview

6.1 Background

Transnet Pipelines, a division of Transnet SOC Ltd, provides strategic pipeline infrastructure, with associated world class pipeline logistics, for the petroleum and gas industries of South

Africa. Established in 1965, Transnet Pipelines owns, maintains and operates a network of some

3800km of high-pressure petroleum and gas pipelines. The Transnet Pipelines pipeline network and associated infrastructure is geographically spread across five provinces. Transnet Pipelines

transports petroleum products ranging from crude oil to refined products (Petrol, Diesel and Jet Fuel) through the pipeline network comprising of underground steel pipelines, delivery depots

and pump stations.

The Crude Oil Pipeline comprises of an intake station located at Fynnlands, KwaZulu-Natal (KZN), South Africa; ten (10) pump stations and booster pump stations; and a delivery station

located at Coalbrook, Free State Province, South Africa.

All stations are remotely monitored and controlled from the Master Control Centre (MCC)

currently located in KZN. There are currently both manned and unmanned stations.

The principle technologies used to meet these requirements are Supervisory Control and Data

Acquisition (SCADA) systems located at the MCC and the respective sites, together with site-

based Programmable Logic Controllers (PLC), communicating across a Wide Area Network comprising fibre, microwave and frame relay communications equipment.

Specialised metering systems are utilised to measure the intake and delivery volumes to international custody transfer standards.

Pipeline Monitoring Systems are installed and are used for the purposes of Leak Detection

(LDS), Batch Tracking (BTS), Pig and Sphere Tracking (PTS) and Pressure Dynamic Tracking (PDTS) in the pipeline segments.

PLMS functionality is limited to Leak Detection (LDS) on the Crude Oil Pipeline.

The SCADA, PLC and Metering systems will hereinafter be referred to as the Process Control

System (PCS) and Custody Metering System (CMS). The existing Wide Area Network installed between the Master Control Centre and the respective stations will hereinafter be referred to as

the WAN.

The existing Crude Oil Pipeline PCS and CMS have been in operation since the early 1990’s.

The WAN linking the Crude Oil Pipeline stations to the Master Control Centre is supported by

fibre, microwave and frame relay communications.

The Crude line is a 16” line of 587km long with a maximum flow rate of 840 m3/hr

6.2 General

The Employer, Transnet Pipelines (TPL), requires the development of modern automated process control, custody metering and pipeline monitoring systems for its pipeline infrastructure

and the subsequent deployment to the Crude Oil Pipeline stations (intake station, pump stations, delivery station - referred to as ‘stations’), as well as at a central master control centre

(MCC), from where it controls, manages and supervises these operations. The MCC will be

relocated to TPL’s newly constructed National Operations Centre (NOC) in Pinetown, KZN, South Africa. The new automated process control, custody metering and pipeline monitoring systems

will utilise the existing LAN and WAN infrastructure.

TRANSNET PIPELINES




The Coalbrook delivery station has been identified as a pilot station, where the newly developed automated process control and custody metering systems will be deployed first in order to

validate their performance, prior to further deployment. This station comprises the delivery point for product from the Crude Oil Pipeline, whilst also catering for Catpoly (component)

product deliveries, Avtur product intakes and multi-product through station pumping into other pipelines.

The aim of the project is to ensure that the Process Control System developed for TPL’s pipeline

infrastructure and its subsequent roll-out on the Crude Oil Pipeline has a sustainable useful service life until 2035.

6.3 Execution Strategy

The following execution strategy shall be employed in the development and deployment of the

new Process Control, Custody Metering and Pipeline Monitoring system/s.

System Framework

Development

Device/Metering

Typical Development

and Testing

Integration

Testing

Pilot Site (Coalbrook)

Deployment &

Validation

Multi-Station

Deployment

(Staggered)

Updates

and

optimisations

Other

Systems

RFP

Proof of Concept

Testing/Demonstration

RFI

Figure 1: High Level Execution Methodology

1. The first stage is the RFI (this process).

2. Proof of Concept: As part of the RFI, the respondent(s) demonstrate\test key system

concepts in order to meet specific requirements (this process).

TRANSNET PIPELINES




3. System framework development: This includes detailed design documentation, alarm concepts, control and hierarchy concepts, thin slices and demonstrations of functionality.

4. Device/metering typical development: This includes the development of detailed design documentation for interfacing to equipment, controlling devices, instrumentation and other

typicals which will form part of a library.

5. Integration Testing: This includes the validation and testing of all the modules of the

Process Control and Custody Metering systems as well as other systems in an integrated

fashion.

6. Pilot Site (Coalbrook) Deployment: This is the first site to validate the Process Control,

Custody Metering systems before rolling out to the Crude Oil Pipeline.

7. Multi-Station Roll out: This is the roll out of the full set of Process Control, Custody

Metering and Pipeline Monitoring systems across the Crude Oil Pipeline.

6.4 Site Details

The following table identifies the stations along the Crude Oil Pipeline, with associated process

control system, metering and IO information.

Table 1: Site Details

No Station Type Metering

Configuration

Control System Quantity and Designation

DIO Quantity

AIO Quantity

1 Fynnlands Intake 1 Dual Manifold 1 – Crude 225 70

2 Mngeni Booster None 1 – Crude 145 20

3 Hillcrest Pump None 1 – Crude 205 65

4 Duzi Booster None 1 – Crude 145 20

5 Howick Pump None 1 – Crude 205 65

6 Mooi River Booster None 1 – Crude 145 20

7 Ladysmith Pump None 1 – Crude 205 65

8 Fort Mistake Booster None 1 – Crude 145 20

9 Newcastle Pump None 1 – Crude 205 65

10 Quaggasnek Pump None 1 – Crude 205 65

11 Wilge Booster None 1 – Crude 145 20

12a Coalbrook - Crude Delivery 1 Dual Manifold 1 – Crude 155 20

12b Coalbrook - Avtur Intake 1 Single Manifold 1 – Avtur 220 50

12c Coalbrook - MP Pump None 1 – Multi Product & Catpoly

540 80 12d Coalbrook - Catpoly Intake 1 Single Manifold

13 MCC Central Control N/A Combined Sites N/A N/A

A characteristic of the Employer’s sites are that they are geographically distributed, with limited data connectivity. See section 7 for details.

TRANSNET PIPELINES




6.5 RFI Modules

Refer to Figure 2. For purposes of this RFI, the Process Control, Custody Metering and Pipeline

Monitoring Systems have been divided into three technical/system modules and a common (project-wide) area. The RFI Respondent(s) are invited to respond to one or more of the

technical/system modules where they can provide a solution in accordance with the

requirements of this document.

CA

PA

BIL

ITY

RE

QU

IRE

ME

NT

S

Archive

LDS

Inte

rfa

ce

s

Archive

SCADA

PLC

IO

Inte

rfa

ce

s

Re

pla

y Archive

Metering

System Inte

rfa

ce

s

HMI Trainer

General QualityProject

Experience

Software

Quality

Lifecycle

Localisation

Documentation

Support/

Lifecycle

Project

Execution

Commissioning

Support

Ops Readiness

Training

Maintenance

Training

E&I Design

E&I Installation

Panel

Manufacture

Lo

ca

l

Ca

pa

bili

ty

Flow

Computers

Operational

Data Warehouse

Terminal

Management

SIS

BTS

PTS

PDTS

MODULE 3:

PLMS

MODULE 1:

PROCESS CONTROL

MODULE 2:

METERING

COMMON MODULE:

PROJECT-WIDE

Proof of

Concept

Proof of

Concept

Proof of

Concept

Figure 2: RFI Module Breakdown

All RFI respondents must respond to at least one module and the associated requirements

there-in, as well as the common critical requirements given in Section 7, which all modules must comply to.

The common (project-wide) requirements are also required to be responded to by all RFI Respondents.

Each module consists of two sections, namely:

A critical requirements section which details the critical requirements which the system

is required to have or comply with. The RFI Respondent shall indicate it’s level of compliance, and include any supporting documentation and material to support and

substantiate the claims.

A requirements section which details the basic requirements which the system is

required to have or comply with. The RFI Respondent shall indicate it’s level of

compliance, and include any supporting documentation and material to support and substantiate the claims.

A capability section which details functionality and characteristics which the RFI

Respondent is invited to provide details on for the system or service which they could

provide, which will meet the identified need.

TRANSNET PIPELINES




The RFI Respondents should provide the following:

Respond to the common critical requirements given in Section 7.

Respond to one or more of the modules (1, 2, 3), where they can comply with the

critical requirements and basic requirements stated in this document, and the capability

section related to each module.

Respond to the common (project-wide) requirements and the capability section.

7. Critical Requirements

The following criteria are considered critical in the context of this project and non-compliance

will disqualify the module and system. Each module has additional critical criteria specific to that module.

#1 The systems shall have a proven track record in a petroleum pipeline environment – details of system architectures, client references will need to be provided. Indication of market share

within the petroleum pipeline industry should be provided.

#2 The RFI Respondent(s) shall indicate the level of their experience (developing, executing and

integrating ) with projects of similar technical scope and size. This shall include brown field and

multi-product pipeline system upgrades.

#3 The systems shall have the ability to operate over a high latency (max 150 ms), bandwidth

restricted (max 100 Mbps) network within performance specifications. The systems should also be robust to loss of communications and be able to run islanded. This includes the ability to

engineer and maintain an islanded site.

#4 All systems and equipment shall have a declared product lifecycle plan. The product shall have a minimum declared end-of-life of five years.

#5 The system/s shall be supported and have a sustainable useful service of 15 years.

#6 The systems shall not have high operating and maintenance costs. Evaluation of this criteria will

include OS and application software update and upgrade frequencies, software patching requirements, and an assessment of the immunity to cyber security threats and associated anti-

virus update requirements.

#7 The respondent is required to indicate and identify any specific requirements outside the bounds of the standard product that are required in order to meet any stated requirement. This

is to include any customisation, modification or “external” systems or hardware and software components.

TRANSNET PIPELINES




8. System Module 1: Process Control System

8.1 Overview

The Process Control System consists of a SCADA/PLC (or DCS) and support systems required for control and monitoring of the Transnet Multi-product, Crude Oil and Avtur Pipeline

Operations.

The Process Control System is distributed across 50 sites, over approximately 3800km, linked to a Master Control Centre (MCC). It shall be possible to control each station either locally from

the station, or remotely from the MCC. Each site shall be self-sufficient such that a loss of communication to a station does not prevent the local control of that station.

When control is run locally for a section of the station, control shall be passed to the local

station operator explicitly such that there are no two points of control at a single time.

It is also important that the stations’ software can be individually upgraded (offline) and put

into operation while still maintaining the ability to operate/monitor from the MCC after the site upgrade is complete, without requiring additional workstations in the MCC.

The performance of the SCADA locally at the station and in the MCC is critical for effective operations in a hydraulic pipeline environment, as delays in switching of product can lead to

late product switches and inability to maintain the safe operational status of the pipeline during

an upset event, product losses, contamination and unsafe or unstable pipeline conditions.

Each station’s control system may interface to a local metering system, VSDs, field device,

electrical switchgear, motor control centres, and other local systems.

TRANSNET PIPELINES




STATION SCADA

STATION CONTROL

FIELD INTERFACE

MCCSCADA

MCC CONTROL

STATION SCADA

STATION CONTROL

FIELD INTERFACE

SCCSCADA

SCC CONTROL

SITE INTERFACES

SITE INTERFACES

MCC INTERFACES

WAN

OTHER STATIONS/PIPELINES

COLD STANDBY

SITE METERING

Figure 3: Process Control System Functional Architecture

8.2 Critical Requirements


will disqualify the module and system:

#8 The system shall be able to be operated by the respective operator locally when the site is

islanded.

#9 The design should support redundancy (or hot swappable) at various levels of the control system to support high availability and maintainability. The RFI respondents shall be expected

to perform an availability and maintainability assessment on the system during the development as well as an FMEA to identify failure areas and mitigations.

#10 The system shall have the ability to upgrade individual sites (during a shutdown) while still maintaining the ability to operate/monitor from the MCC after the site upgrade is complete,

without requiring additional workstations in the MCC. This means the system should allow

different versions of system and application software to be used on various sites while still being accessible for operation at the MCC.

#11 The RFI respondents shall indicate the level of local vendor support for the system(s) offered and their commitment to developing local resources for local support of the system.

TRANSNET PIPELINES




#12 The system shall be scalable to support the many pipelines which form part of the TPL network. The system should support up to 50 sites visible from the MCC from a single Operator

Workstation.

#13 The system shall comply with the System Performance requirements specified in Section 8.3.7

of this document.

8.3 Module Requirements

The detailed requirements for the Process Control System are given in the PCS User

Requirements Specification [2].

The following items are required functionality and/or characteristics for the Process Control System:

8.3.1 General

The PCS should be based on open software and communication standards. Any non-

industry standard technology shall be declared. The RFI Respondent(s) should indicate which open standards they support for interfacing to other systems.

The PCS and its components shall have a proven track record in similar petroleum

pipeline and terminal operations. Any design or device which has limited operating experience shall be declared. Prototypes or equipment out-of-date shall not be used.

Commercially available off-the-shelf equipment should be used as far as reasonable.

A cold standby Secondary Process Control System shall be installed. Capability for

Warm/Hot Standby shall be declared.

The Operating System platform should support Unix style systems (e.g. Linux), although

Windows based systems will be considered. This is required to satisfy system vulnerability and maintainability concerns which are to be explicitly addressed in the

response.

Demonstration of security robustness, and virus and operating system update

frequency, with evidence from existing sites shall be provided.

The system should support real-time coordination control (Line Wide Control) of the

pipeline from the MCC. This includes startup\shutdown sequences, pipeline optimisation

and other line wide functions. This may invoke a separate controller dedicated to such a function.

The RFI respondents shall indicate the level of local support for the system(s) offered

and their commitment to developing local resources for local support of the system(s).

8.3.2 Control

The sites are controlled locally and remotely, and as a result a means of transfer of

control (mode of control) is required for device groups of plant operations. The mode of

control transfer shall meet the following:

i. When the MCC is in control of a portion of the plant (device group), the Station HMI

shall be “view only” with no active alarms for those portions.

ii. When the Station has control of the portion of the plant (device group), the MCC shall be “view only” with no active alarms for those portions of plant.

iii. It shall be possible for the MCC to remotely disable control from the Station and vice versa under operations supervisor password, but normally transfer between the 2 sites

will be an operator request and handover type transfer.

The RFI Respondent(s) should indicate how this is achieved for the system.

TRANSNET PIPELINES




8.3.3 Alarming

The system should have a comprehensive alarm system with multiple priorities and

support multiple methods of suppression and alarm minimisation.

Alarms shall automatically follow the mode of control to which the subset of plant

operations has been transferred i.e. alarms will only be annunciated in MCC if the subset of plant operations is being controlled from the MCC, and only from the Station if the

subset of plant operations is being controlled locally from the station.

The alarm should only be audible and acknowledgeable for the operator in control of the

portion of plant section.

8.3.4 Interfaces

The system shall support OPC 2.0, OPC UA, Profibus DP, Modbus TCP/485. The RFI

Respondents should indicate all standard interfaces that the system supports.

The Process Control System shall be required to interface to:

Custody Metering System (CMS) at a site level,

Equipment at a site level eg. VSDs, F&G, etc.,

Pipeline Monitoring System (PLMS) at the MCC,

MES/MIS operations systems at the MCC

Transnet Pipelines has an existing installed base of Siemens Simatic S7 S400 PLCs. The

RFI Respondents should indicate whether standard interfaces to these PLCs are available or S7 300 I/O and Profibus networks.

8.3.5 Data Archiving

Short term trending of 3 months shall be available online on the operator interface.

The system shall support archiving of up to 10,000 different variables per site, scanned

at 1000 per sec.

Long term archiving for two years shall be available for all alarms, events, digital and

analog variables. The system should support basic analysis of plant operation and trending.

8.3.6 Development

The PCS engineering system shall support versioning and revision control of the PCS at

all levels.

It should be possible to compare multiple versions of application software for conflict

resolution.

The system shall support local engineering on a station when the station is islanded (i.e.

not connected to the WAN).

The system shall support standard and custom libraries which can be managed and

controlled over widely separated sites.

8.3.7 System Performance

The system is expected to perform over a low bandwidth, high latency environment. The RFI Respondents should provide indicative performance based on past projects in a similar

environment.

Local Performance

A typical control function on the PCS (excluding sensors and actuators) shall have an

availability of 99.98%.

TRANSNET PIPELINES




If a single failure can impact multiple functions, the single point of failure should be

mitigated where practical. The RFI Respondent should provide information on redundancy configurations, and how single points of failure can be mitigated.

Loss of WAN connectivity shall not impact the ability of the operator to control the

station locally. Upon WAN recovery, system recovery enabling remote control from the MCC should be an automatic process, with no adverse effect on system performance.

For a graphic with 300 control objects (e.g. valves, motors):

i. time to display an input from the process on the operator interface: 1.5 s;

ii. time for an operator action to be actuated to the process: 1.5 s;

iii. time for a graphic page to display after call-up: 2 s;

iv. time for feedback of a selection (e.g. border on a button): 0.2 s; and

v. time between screen updates: 1 s.

Performance requirements listed above shall include of the communication overhead in

terms of bandwidth and latency constraints identified in Section 7.

MCC over WAN Performance

For a graphic with 300 control objects (e.g. valves, motors):

i. time to display an input from the process on the operator interface: 2 s;

ii. time for an operator action to be actuated to the process: 2 s;

iii. time for a graphic page to display after call-up: 2.5 s;

iv. time for feedback of a selection (e.g. border on a button): 0.2 s; and

v. time between screen updates: 1.5 s.

Performance requirements listed above shall include of the communication overhead in

terms of bandwidth and latency constraints identified in Section 7.

8.3.8 Security

The system shall support system wide security management.

The system shall support a tight cyber-security philosophy. The RFI Respondent to

indicate how typical cyber security provisions are met.

The PCS shall support physical ‘system (hardware& software) lock down’.

8.3.9 Maintenance and Upgrades

The system shall be upgradeable in a staged approach without the necessity of parallel

old and new systems i.e. it shall be possible for stations to be upgraded individually without impacting MCC connectivity or requiring additional Operator Stations. This

means that a single station can be operating on a different version of system/project

software and still be visible at the MCC without requiring separate hardware. Limited site downtime is acceptable for a system upgrade.

Project specific application software shall not require modifications in order to be able to

run under new releases of the system operating software. Any new release of system software shall be backward compatible with files created using the previous software

releases.

Operating system patching should have a minimal impact on operations.

8.3.10 Replay

The PCS should have the capability of replaying process inputs, operator actions, alarms

and events.

The result of the replay shall be visible on standard HMI displays.

TRANSNET PIPELINES




The initiation of a replay shall not require significant engineering effort, but be possible

by a trained supervisor.

The replay system should be suitable for incident investigation. The RFI Respondents to

indicate similar systems which have been implemented on petroleum pipelines.

8.3.11 HMI Trainer/Simulation

The PCS shall have the capability of simulating the field inputs and other defined

interface inputs (e.g. MODBUS, OPC).

The simulation interface should be similar to the HMI screens to support ease of

simulation.

The simulation subsystem shall support the loading of scenarios for the field interface.

The trainer system shall provide control simulation of the actual operation of the

Station.

Device and equipment simulation shall be automatic. Hydraulic simulation is not

required.

The trainer system shall run the same software as the station software.

8.3.12 Proof of Concept Workshop

The RFI Respondent(s) shall perform a proof of concept by test or demonstration at the RFI stage which will demonstrate:

1. Performance over a high latency bandwidth limited system (Section 7) – The respondent

shall test performance over a simulated slow network.

2. MCC/Station operation architecture – The architecture of the proposed system should be

presented and discussed.

3. The RFI respondent will be required to demonstrate required performance with 20 sites

visible from the MCC from a single Operator Workstation.

4. The RFI respondent will be required to provide an assessment of the TPL requirements

contained in the PC Software Control Modules Standard (Ref [3]), in particular as regards

engineering effort and system performance.

5. Alarm locality – The mechanism of how alarm locality operates and follows mode of control

should be demonstrated.

6. Mode of control handover – the mechanism of how mode of control is implemented and the

handover should be demonstrated.

7. Critical interface concepts – The OPC interface, Modbus, Profibus interface should be

demonstrated.

8. Method of upgrading the system as per Section 8.2 – A demonstration should be done

showing how the system application and system software should be upgraded and its

impact on operations and maintenance.

9. HMI frameworks – The mechanism for managing alarms, typicals, navigations, trending, et

al should be demonstrated.

10. Reporting – The configuration and execution of the reporting\trending system proposed


TRANSNET PIPELINES




8.4 Capability

8.4.1 Operational Data Warehouse

The RFI Respondent(s) should indicate their capability to provide a system which meets the

following needs,

Link to various data sources on a site. The system may store the data or link to the

respective data store. These sources may include electrical metering, control system,

alarm system, PLMS, Custody Metering, condition monitoring, fire and gas, and internet data if required.

Allow reporting of KPIs for operational and maintenance of the pipeline.

The system should be user configurable such that analysis, investigation and reporting

can be performed by operational and maintenance staff. This would allow reports and

investigations supporting:

Preventative maintenance

Cost optimisations

Equipment performance

Incident investigations

Trip avoidance

Setpoint analysis

Alarm Analysis

The system should support functions such as:

Cross correlations across variables

Meta Tagging data and events

Basic data analytics (clustering, regression, time series analysis, pattern recognition,

spatial)

Utilise geospatial information as a means of visualising data

Signal processing (filtering/frequency/time)

Strong visualisation tools

The system should support the following type of data:

Geospatial data

Time series data

Transactional data

Event/Alarm data

Text and complex data

8.4.2 Terminal Management

The RFI Respondent(s) should indicate their capability to provide a system which meets the

following needs:

Interface to Tank Gauging and other metering systems to track product into and out of

a terminal.

Support management of road and rail loading including management of fuel additives.

Support inventory reconciliation.

Support product quality tracking and management, including interface to lab

instrumentation.

Support reporting of inventory and operations.

TRANSNET PIPELINES




Support integration into a SCADA system and other aspects of the Operation Systems

platform.

TRANSNET PIPELINES




9. System Module 2: Custody Metering

9.1 Overview

The Custody Metering module consists a metering system with flow computers to support the Fiscal/Custody Measurement of petroleum multi-products entering or leaving the Transnet

Pipeline infrastructure.

The Metering System is to be a stand-alone, automated, electronic metering system used to measure the volume transfer of product at these sites and will comprise of the following five

main components:

Metering System Database (MDS), used for collating and storing metering data. It is

also used to interface to the SCADA and ERP (SAP).

Metering System HMI, used for operator interface.

Metering System Flow Computers, used to measure product transfer to API Product

Measurement, OIML and SA Trade Metrology Standards. Flow Computers interface directly to field instrumentation and large volume provers.

Metering Instrumentation, including turbine flow meters, pressure, temperature and

density measurements.

Meter Proving facilities that should be monitored and controlled by the CMS.

The CMS shall have the ability to generate metering reports for deliveries, proving and

other technical metering reports.

The CMS shall interface to existing metering process equipment installed on TPL sites,

and specifically into turbine flow meters and large volume, bi-directional pipe provers.

Metering is only required to be operational from the respective stations themselves.

9.2 Metering Process Equipment

Metering manifolds installed on TPL sites comprise of de-aerators, strainers, turbine meters,

flow conditioners where required, proving systems, consignee/nor valves and metering

instrumentation (temperature, pressure and density measurements). On intake sites, product passes from the consignor valve to the meter and then to the prover; whilst on delivery sites,

product passes through the prover followed by the meter and lastly the consignee valve.

Backpressure is maintained on the turbine flow meters by means of pressure-sustaining valves

where necessary. Temperature and pressure of the product at the meter is measured and the

values fed back to the Flow Computer for volume calculation purposes. Density is measured and entered manually by the operator.

Meters are calibrated regularly using permanent on-site large volume pipe prover facilities, comprising of bi-directional provers with flow direction controlled by means of four-way valves.

Six sphere detector switches are installed on the prover, two detector switches used to detect the sphere in its home and away positions, with the other four detector switches used as base

volume switches. The four-way valve cavity is fitted with a differential pressure switch to

indicate if the valve is leaking or not. Temperature and pressure of the product at the prover is measured and the values fed back to the flow computer for metering compensation calculation.

9.3 Scope of RFI

The scope of supply for this RFI is the custody metering system database and HMI. The flow

computers may be in the scope depending on the RFI Respondents ability to interface to an

Emerson S600+ flow computer. The field instrumentation is not in the scope of this RFI.

TRANSNET PIPELINES




The scope of the RFI includes:

CMS Database,

CMS HMI,

Flow Computers or Interface to Emerson S600+,

Interface to SCADA and SAP/MII ERP

Metering Reports

The following is excluded

Metering Instrumentation

WAN

SAP (MCC)

SAP (Site)

CMS MDS DATABASE

CMS HMI

FLOW

COMPUTERS

STREAM

FLOW

COMPUTERS

PROVER

Field Instrumentation

(Flowmeters,

Instrumentation)

SYSTEM

INTERFACES

SCOPE

OF

SUPPLY

Figure 4: Metering Functional Architecture



will disqualify the module and system:

#14 The system shall be able to be operated by the respective operator locally when the site is islanded. Metering is only required to be operational from the stations.

#15 The Fiscal/Custody Volume Measurement shall be in compliance with API Manual of Petroleum Measurement, OIML and SA Trade Metrology Standards (Refer to Section 9.5.2 below).

#16 The CMS shall either interface to the Emerson S600+ or the RFI Respondent shall provide

compliant flow computers.

#17 The CMS shall be configured as a standalone application from the PCS.

TRANSNET PIPELINES




#18 The RFI respondents shall indicate the level of local support for the system(s) offered and their commitment to developing local resources for local support of the system.

#19 The system shall comply with the System Performance requirements specified in Section 9.5.8 of this document.


The detailed requirements for the Custody Metering System are given in the CMS User Requirements Specification [1].

The following items are required functionality and/or characteristics for the Custody Metering System:

9.5.1 General

The CMS should be based on open standards. Any non-industry standard technology

shall be declared in the response.

The CMS should preferably be a commercially off-the-shelf application, requiring only

configuration.

The CMS should be able to meet the functional requirements using the standard

manufacturers system. Any requirements which impose high levels of customisation

shall be declared in the response.

The CMS and its components shall have a proven track record in a similar pipeline and

terminal operation. Any design or device which has limited operating experience shall be

declared. Prototypes or equipment out-of-date shall not be used.

The CMS shall support a HMI for the operator to:

manage the reconciliation of deliveries

trouble shoot problems

respond to alarms

initiate and monitor proving status and other metering operations, including the ability

to control 4-way valve when proving manually

configure and manage flow computers

monitor deliveries, with associated volumes, flows and other variables.

generate metering reports

The RFI respondents shall indicate the level of local support for the system(s) offered

and their commitment to developing local resources for local support of the system(s).

9.5.2 Certification and Approvals

The CMS shall support Fiscal/Custody Volume Measurement in accordance with API

Manual of Petroleum Measurement Standards (Ref [6]).

All components of the CMS shall be certified for use in fiscal/custody transfer

applications by OIML [5] (i.e. OIML R117 Certificates of Conformity will need to be

issued for all components of the system).

The CMS should be certified by the SA Authorities body for use in accordance with the

SA Trade Metrology Act.

The RFI Respondent(s) should indicate how these requirements are achieved for the

system.

9.5.3 Alarming

The system shall support an alarm and event system which can interface to a SCADA

system. Batch alarms shall be made available on a SCADA system.

TRANSNET PIPELINES




The system shall maintain events for event investigation and diagnostics.

9.5.4 Interfaces

The Respondent(s) CMS shall either:

Interface to the Emerson S600+ using Modbus or similar technology,

OR:

Include certified (API/OIML) flow computers suitable for custody transfer and use with large volume provers and turbine meters as installed at the Fynnlands and Coalbrook

sites.

The CMS shall interface to a minimum of sixteen (16) Flow Computers (stream and

prover) and shall support a minimum of eight (8) simultaneous product volume transfers

and 8 provers.

The CMS shall interface to SAP/MII via XML B2MML to return docket information.

The CMS shall interface to the SCADA through OPC 2.0/UA with basic information such

as flow rates, volumes and delivery status.

Values for Flowrates, Volumes, Temperature and Pressure shall be interfaced to the

SCADA from the flow computer via the CMS.

The CMS interface to flow computers shall enable reconfiguration to accommodate

future changes.

9.5.5 Archiving

Operator actions shall be captured; time stamped and logged in the operator log.

The CMS shall provide a complete historical (archiving) subsystem providing the ability

to capture and analyse historical data (CMS Database).

The HMI shall provide an integral reporting subsystem to be used to print any variable,

event or history of both current and archived data.

The system store historical data for years for reporting (e.g. 2 year archiving of meter

factor trends)

9.5.6 Reporting

The HMI shall provide an integral reporting subsystem to be used to print any variable,

event or history of both current and archived data.

Reports shall be easily configurable and customisable and shall provide the capability to

define reports for visualisation on the Metering HMI and for printing.

Reports shall be activated in any of the following manners: upon demand, or scheduled,

or upon event occurrence.

9.5.7 Development

The CMS should preferably use a standard library; if not possible then only standard

CMS components shall be used in the building of the custom library.

The CMS engineering system shall support versioning and revision control of the PCS at

all levels.

It should be possible to compare multiple versions of software for conflict resolution.

The system shall support local engineering on a station.

9.5.8 Performance

Failures of instrumentation, equipment, I/O and other detectable failures shall be visible

to the operator and be alarmed.

TRANSNET PIPELINES




Failure of an operator station shall not prevent other operator stations from operating or

introduce unwanted control actions.

Failure of a flow computer shall not affect any of the other flow computers at a site.

Failure of the CMS system and associated networks shall not affect Flow Computer

operation.

A typical control function on the CMS (excluding sensors and actuators) shall have an

availability of 99.98%.

Loss of WAN connectivity shall not impact the ability of the operator to meter product

volume movement from the CMS at the station locally.

CMS shall meet the following performance criteria,

Maximum 60 seconds response time when initiating a report print from the Flow Computer to printing the report from the CMS.

Maximum 1 second response time for real-time data from the Flow Computer to be

displayed on the CMS HMI graphics.

Maximum 3 seconds for non-real time data and 60 seconds for configuration data to be

sent from the CMS to the FC and back, including Screen Update response times within the CMS System.

Maximum two minutes data processing time for data transfer between CMS and SAP.

9.5.9 Security

The CMS shall support system wide security management.

The CMS shall support a tight cyber-security philosophy. The RFI Respondent to indicate

how typical cyber security provisions are met.

9.5.10 Maintenance

The system should be upgradeable in a staged approach without the necessity of

parallel systems. Limited downtime is acceptable for a system upgrade.

Software design shall be such that future revisions or updates of the system operating

software will not affect the successful operation of the system.

Project specific application software shall not require modifications in order to be able to

run under new releases of the system operating software. Any new release of system

software shall be backward compatible with files created using the previous software releases

9.5.11 Proof of Concept Workshop

The Respondent(s) shall perform a proof of concept by test or demonstration at the RFI stage

which will demonstrate:

1. If the architecture is dependent on WAN infrastructure: performance over a high latency

bandwidth limited system (Section 7) – The respondent should show indicative

performance over simulated slow network.

2. Critical interface concepts – The interfacing to a Floboss S600+ (or the respondents flow

computer), as well as the typical SCADA interface should be demonstrated, including

protocol mapping and reporting.

3. Method of upgrading the system as per Section 9.4 - 8.2 – A demonstration should be done

showing how the system application and system software should be upgraded and its

impact on operations and maintenance.

TRANSNET PIPELINES




4. HMI and operational frameworks – The mechanism for managing alarms, typicals,

navigations, trending, et al should be demonstrated.

5. Reporting - The standard reporting as well as custom report configuration and execution


6. Demonstration of metering and proving - The mechanism of executing a metering run and

proving run should be demonstrated.

9.6 Capability

9.6.1 Metering Trainer

The RFI Respondents should indicate their solution to a metering trainer, including:

The Metering Trainer should simulate the actual operation of the Metering System

The Metering Trainer should is capable of simulating the field inputs and other defined

interface inputs (e.g. MODBUS, OPC).

The Metering Trainer should run the same software as the CMS software.

9.6.2 Flow Computers

The RFI Respondents should indicate their solution to flow computers based on the following

requirements:

Flow Computers shall support Fiscal/Custody Volume Measurement in accordance with

OIML, SA Trade Metrology, API Manual of Petroleum Measurement Standards as well as

interfacing to large volume provers.

Electronic measuring systems (Flow Computers) shall be designed and manufactured to

Accuracy Class 0.3 (OIML R117 Section 2.4 Table 1 [5]), ensuring that their errors do not exceed the maximum permissible errors as defined in OIML R117 Section 2.5 under

rated operational conditions.

Flow Computers shall be standalone units, fitted with front panel keypads and displays

to enable local operator control and logging functions as well as provide status of all

inputs and configuration settings.

Transnet Pipelines currently has a large installed base of Emerson Floboss S600 and

S600+ Flow Computers installed. Supply of an alternative make of flow computer shall

be considered, provided compliance to the CMS User Requirements Specification [1] is

declared and all requirements are separately validated.

One Flow Computer should be supplied per meter stream and used to provide flow

meter pulse integrity checks as well as both metering and proving functions.

The Flow computer shall have the ability to interface to 10 or more consignees.

The flow computer components shall be modular for ease of replacement when cards

are faulty.

The FC are to operate independently to each other and independently of the CMS and

robustly handle failure of field I/O’s.

TRANSNET PIPELINES




10. System Module 3: PLMS

10.1 Overview

The PLMS modules consist of Leak Detection (LDS), Batch Tracking (BTS), Pig and Sphere Tracking (PTS) and Pressure Dynamic Tracking (PDTS), required for the monitoring of Transnet

Multi-product Pipeline infrastructure. Note that only a Leak Detection System required for

operation on the Crude Oil Pipeline. The RFI Respondent(s) should indicate the functionality of the other modules under the capability section with a view to future use.


The following criteria are considered critical in the context of this project and non-compliance will disqualify the module and system:

#20 The system shall operate in shut-in, transient and steady state conditions.

#21 The system shall be able to detect a leak of 10% of flowrate size on a pipeline of flow segment

size 100km within 10 minutes, with a leak location accuracy of 5%. The RFI Respondent(s) are

to indicate what the requirements are on process instrumentation accuracy to achieve this. The RFI Respondent(s) are also to indicate actual detection times for a 1%,5%, 10% and 30% leak.

#22 The LDS shall support an open technology (e.g. OPC UA) to interface alarms and signals through to and from the SCADA system.

#23 The system shall minimize the reliance on flow meters. Failure of a single flow meter should not

prevent LDS operation. The RFI Respondent(s) are invited to offer alternative technologies, measurements or instruments which may be used.


The following items are required functionality for the Leak Detection System:

10.3.1 General

The system shall operate in shut-in, transient and steady state conditions.

The system shall comply to API1155, API1130 and API1149 as applicable to the

technology of the LDS.

The system shall minimize the reliance on flow meters. Failure of a single flow meter

should not prevent LDS operation. The RFI Respondent(s) are invited to offer alternative

technologies, measurements or instruments which may be used.

The RFI Respondents should indicate if they offer local or remote (relative to South

Africa) support of the LDS system to assess the system state, tuning of the system and analysis of potential leaks.

The system shall support rupture detection. The RFI Respondent(s) to indicate the

typical performance achieved.

10.3.2 Alarming

The system shall support an alarm and event system which can interface to a SCADA

system. All alarms shall be made available on a SCADA system.

The system shall maintain events for event investigation and diagnostics.

10.3.3 Interfaces

The LDS shall support an open technology (e.g. OPC UA) to interface alarms and signals

through to and from the SCADA system.

TRANSNET PIPELINES




The LDS shall support an open technology to get field data either from the SCADA/PLC

or from field instruments directly.

10.3.4 Archiving

The system shall be designed to retain 2 years of data relating to leak alarms and leak

analysis.

10.3.5 Development

The LDS system shall support versioning and revision control of the LDS at all levels.

It shall be possible to see the current custom version of software which is in operation.

10.3.6 Performance

The system shall be able to detect a leak of 1% of flowrate size on a pipeline of flow

segment size 100km. The RFI Respondent(s) are to indicate what the requirements are

on process instrumentation accuracy to achieve this. The RFI Respondent(s) are also to

indicate typical detection times for a 1%,5%, 10% and 30% leak.

The system should support leak location to 3% of segment length. The RFI

Respondent(s) are to indicate what the requirements are on process instrumentation

accuracy to achieve this.

10.3.7 Security

The system shall support system wide security management.

The system shall support a tight cyber-security philosophy. The RFI Respondent to

indicate how typical cyber security provisions are met.

10.3.8 Maintenance

Project specific application software should not require modifications in order to be able

to run under new releases of the system operating software. Any new release of system software shall be backward compatible with files created using the previous software

releases, or a migration path should be allowed for.

10.3.9 Proof of Concept

The Respondent(s) shall indicate their willingness to perform a proof of concept at the RFI stage

which will demonstrate:

1. Performance over a high latency bandwidth limited system (Section 7) – The respondent

should show indicative performance over simulated slow network.

2. Critical interface concepts – The OPC interface to the SCADA and it requirements should be

demonstrated.

3. Demonstration of HMI frameworks – The mechanism for managing alarms, typicals,

navigations, trending, et al should be demonstrated

4. Reporting – The configuration and execution of the reporting\trending system proposed


10.4 Capabilities

RFI Respondents should indicate the level of functionality for the identified systems:

TRANSNET PIPELINES




10.4.1 Pressure Dynamic Tracking System

The RFI Respondents should indicate if they are capable of delivering a Pressure

Dynamic Tracking System which models the hydraulic profile of a pipeline in real-time.

The calculated values should be visible on the SCADA system. The typical performance, requirements on instrumentation and other relevant system details should be provided.

10.4.2 Batch Tracking System

The RFI Respondents should indicate if they are capable of delivering a Batch Tracking

System which models the location of batches in a pipeline in real-time. The typical performance, requirements on instrumentation and other relevant system details should

be provided.

10.4.3 Pig Tracking System

The RFI Respondents should indicate if they are capable of delivering a Pig Tracking

System which models the location of pigs and spheres in a pipeline in real-time. The

typical performance, requirements on instrumentation and other relevant system details

should be provided.

TRANSNET PIPELINES




11. Project Wide/Common Module

11.1 Overview

All RFI respondents are required to address the project wide (common) requirements and capabilities listed below.

11.2 Common Requirements

Each RFI Respondent is required to address their level of compliance to the requirements listed below:

11.2.1 Regulatory Compliance

The execution of the project, including system hardware, software and contracted

services shall comply with applicable South African Regulations.

11.2.2 General Quality

The execution of the project including all hardware and software shall be subject to

formal quality management plans and procedures, approved by the Employer.

The RFI Respondents shall be ISO9001 certified.

The RFI Respondents’ ISO9001 certification shall cover the full scope of products and

services relevant to this RFI.

11.2.3 Software Lifecycle Quality

All configuration and development shall be done according to an approved software

lifecycle and quality plan according to the lifecycle requirements laid out by the

Employer.

All software shall be:

formally managed by a change control process, including formal configuration

management,

tested according to documented software test plans and procedures,

configuration managed and version controlled.

The software lifecycle plan shall be based on a recognised international lifecycle

standard such as IEEE 12207.

The development standards (for both standard modules and site software) for the

project shall be documented and enforced.

All interfaces shall be subject to formal validation.

All project software shall be subject to a formal defect correction process.

Control simulation shall be implemented during the FAT process as a means to fully test

the functional scope.

RFI Respondents are to provide traceable references to comparable projects performed

in a formal, quality controlled environment.

11.2.4 Documentation

RFI Respondents will be required to adhere to Employer’s standards with respect to

documentation format and templates.

TRANSNET PIPELINES




A full compliance assessment shall be retained by the RFI Respondent(s) for the

development and rollout of software against the Employer’s requirements documentation and the RFI Respondents requirements documentation.

All project documentation shall be as-built.

A full suite of project documentation shall be developed including:

Functional design specifications

Hardware detail design documentation

System and Software design documentation

Software test documentation

Operations and Maintenance documentation

Configuration and setup documentation

System, Operator and Technician/Engineer Training Manuals

Project Records e.g. Compliance, Manufacturing, Test, Quality

11.2.5 Support/Lifecycle

The system shall be designed for a Service Life of 15 years before the product is End of

Life.

The system shall be designed such that system update frequency and version support

exceeds 5 years.

The RFI Respondent shall identify the proposed location for software development, and

the depth of resourcing and competence.

The Respondent(s) shall indicate the level of support offer for operations and

maintenance. The response should indicate where the support would be delivered from.

First and Second line support should be localised (South Africa). The RFI Respondent(s)

to indicate their willingness to develop local (South African) expertise to support the

systems, or demonstrate the such expertise already exists locally.

The RFI Respondent(s) shall indicate how the custom developments for this project will

be integrated into mainline product development to ensure future support.

The RFI Respondent(s) should demonstrate what provisions exists for integration of

future operational needs and requirements from the Employer to inform mainstream

system development.

11.2.6 Project Experience

The RFI Respondent(s) shall indicate the level of their experience with projects of

similar technical scope and size. This shall include brown field and multi-product pipeline system upgrades.

The RFI Respondent(s) shall indicate where the proposed system(s) have been used in

a similar pipeline/terminals operation. Traceable references should be provided. The

maturity of the product should also be detailed.

The RFI Respondents shall indicate the size of user base for the proposed system(s) in a

similar pipeline/terminal environment.

The RFI Respondents should indicate lessons learnt associated with the development,

installation, operation and maintenance of the proposed system(s).

TRANSNET PIPELINES




11.2.7 Project Execution

The RFI Respondent(s) shall indicate the level of their experience in developing,

executing and integrating projects of similar technical scope and size. This shall include

brown field and multi-product pipeline system upgrades.

The RFI Respondent(s) shall indicate the level of experience in integrating third party

systems and management of the interfaces.

The RFI Respondent(s) shall indicate the level of experience in developing software

according to a formal quality process as detailed in Section 11.2.3.

The RFI Respondent(s) should indicate how a project of this type would be executed.

The RFI Respondent(s) should provide a proposed organogram for this project, listing

local and/or international organisations if applicable; and including roles, responsibilities,

and the location of system and software FAT testing.

11.2.8 Commissioning and Support

The system shall be commissioned and formally validated against the performance

specification.

The RFI Respondents shall indicate similar projects where this process has been

followed.

The Respondent(s) shall indicate what levels of support are available for the system(s),

both locally and internationally.

The Respondent(s) shall indicate their ability to assist in site readiness assessments and

detailed shutdown planning.

11.2.9 Ops Readiness Training

The RFI Respondents shall indicate their ability to support operational readiness

processes including,

Training of operations staff

Development of procedures for operation of the system,

11.2.10 Maintenance Training

The RFI Respondents shall indicate their ability to support maintenance readiness

including,

Training of maintenance staff

Development of procedures for maintenance and upgrades of the system.

11.2.11 System Architecture

The RFI Respondents should include a high-level system/network architecture that

demonstrates the ability to meet the requirements of this RFI.

The RFI Respondent should include typical system architectures which have been used

on similar projects.

11.2.12 Localisation

The RFI Respondents shall detail their existing local South African technical capability,

including actions which are in the process, or which would be required to establish a centre of technical competence in South Africa.

TRANSNET PIPELINES




11.3 Common Capabilities

The following capabilities are optional for each RFI Respondent to address:

11.3.1 E&I Design

The RFI Respondent(s) to indicate their capability to either perform in-house or contract

directly:

Electrical and Instrumentation panel design,

Loop drawings and terminal schedules,

IO Schedules,

Loop certifications (IS).

11.3.2 E&I Installation

The RFI Respondent(s) to indicate their capability to either perform in-house or contract

directly:

Electrical and Instrumentation installation,

Profibus, network, fibre optic and other cable installation,

Cable installation and termination,

Issuing of Certificates of Compliance (CoCs),

Installation and Safety management.

11.3.3 Panel Manufacture and Hardware Integration

The RFI Respondent(s) to indicate their capability to either perform in-house or contract directly:

Design and build electrical and instrumentation panels according to an Employer’s

standard,

Design and build server panels according to an Employer’s standard,

Factory acceptance test and provide full quality control on the panel manufacture.

Perform system hardware integration.

TRANSNET PIPELINES




12. Document Lifecycle Management

12.1 Revision History

The owner of this document is responsible for the revision and control of the document, including updating of the table below, which contains the history of the document with details of each revision.

Date Previous

Rev No.

New

Rev No.

Details of Revision

2017-04-19 -- A Commented First Draft for discussion forum

2017-05-17 B C Updated at Review Workshop at TPL 2017-05-17

2017-05-18 C 0 Issued for RFI

This table summarises what has been changed in the document so that it is easy to keep track

of the effected changes.

12.2 Comments Resolution

Date Section Comment Resolution

This table lists comments and the basis of resolution to keep track of decision outcomes and reasoning.

Documents

TRANSNET PIPELINES - Welcome to eTenderPublication | … · 2017-05-25 · TRANSNET PIPELINES PCS Upgrade Project Document Number Rev Page RFI Technical Specification H354086-00000-300-078-0001