Project, Planning and Activities Requirements Specification · Project, Planning and Activities Requirements Specification PICS_R ... SRS System Requirement ... Planning and Activities

PRASA In-Cab Signalling

PICS Request For Proposal 1/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx

PRASA In Cab Signalling

Project, Planning and

Activities Requirements

Specification

Document Management

This document has been approved for issue. The version history and approval cycle are available in the version stored in the QMS of the PICS project within Transurb-Focus consortium.



Table of Contents

1. Introduction ................................................................................................................................................................ 4

1.1. Purpose of this document ........................................................................................................................... 4

1.2. Application domain ........................................................................................................................................ 4

1.3. Definitions, symbols and abbreviations ................................................................................................ 4

1.4. Reference documents .................................................................................................................................... 5

1.5. Appendices ........................................................................................................................................................ 5

2. Program and projects ............................................................................................................................................. 6

3. Typical Development subProject ....................................................................................................................... 8

3.1. Scope .................................................................................................................................................................... 8

3.2. Life Cycle ............................................................................................................................................................ 8

3.3. Deliverables ................................................................................................................................................... 11

4. The Pilot Line subProjects ................................................................................................................................. 13

4.1. Scope ................................................................................................................................................................. 13

4.1.1. Pilot Line 1 in Gauteng: GAU-01-PLP ......................................................................................... 14

4.1.2. Pilot Line in Kwa-Zulu Natal: PLP-KZN-01 .............................................................................. 14

4.1.3. Pilot Line in Western Cape: PLP-WC-01 ................................................................................... 15

4.2. Life Cycle and planning ............................................................................................................................. 15

4.3. Schedule ........................................................................................................................................................... 18

4.4. Deliverables ................................................................................................................................................... 18

5. The Roll-Out subProjects ................................................................................................................................... 21

5.1. Scope ................................................................................................................................................................. 21

5.2. Life Cycle ......................................................................................................................................................... 22

5.3. Schedule ........................................................................................................................................................... 22

5.4. Deliverables ................................................................................................................................................... 23

6. Dependencies between projects ..................................................................................................................... 23

7. Planning Procedure and tools .......................................................................................................................... 26

7.1. Reporting......................................................................................................................................................... 27

7.2. Revision ........................................................................................................................................................... 28

8. Requirements for the Tenderer ....................................................................................................................... 29

8.1. Time Schedule ............................................................................................................................................... 29

8.2. Work Breakdown Structure .................................................................................................................... 30

8.3. Workload management ............................................................................................................................. 31



8.4. Project Deliverables .................................................................................................................................... 32

9. Requirements List ................................................................................................................................................. 33

10. Appendix 3: The planned development of the PRASA network .................................................... 35

10.1. From mechanical and relay signalling to electronic interlocking (2011- 2017)… ...... 35

10.2. Optical fiber network (2012-2014) ................................................................................................. 35

10.3. Radio digital signalling network (2012 – 2017) ........................................................................ 35

10.4. Asset protection program (today – 2014) .................................................................................... 35

10.5. New PRASA Rolling stock (2016 – 2027)...................................................................................... 36

10.6. PRASA In-Cab Signalling ...................................................................................................................... 36



1. Introduction

1.1. Purpose of this document

This document defines the different projects inside the PRASA In-Cab Signalling program and

their interactions. It also defines the scope, the life cycle, the schedule and the deliverables of

each project. It yields the requirements to be answered by the Tenderer in this topic.

This document does not define the way the management will be carried out for these program

and projects. This is demonstrated by another document [REF.4], which is complementary to

this one.

1.2. Application domain

This document is part of the PICS Technical Request For Proposal and is applicable for the

Tendering Process. It shall be used as basis for the execution phase.

1.3. Definitions, symbols and abbreviations

For main definition, symbols and abbreviations see also [REF.1].

FTE Full Time Equivalent

FRS Functional Requirements Specification

GASC Generic Application Safety Case

GR Gate Review

IL Interlocking

PICS PRASA In-Cab Signalling Programme

PLC Project Life Cycle

PLP Pilot Line subProjects

PMBoK Project Management Body of Knowledge®

PMI Project Management Institute®

PMP Project Management Plan

RACI Responsible, Accountable, Consulted, Informed

ROP Roll-Out subProjects

SASC Specific Application Safety Case

SAT Site Acceptance Tests

SRS System Requirement Specification

SyAD System Architecture Description

TDP Typical Development subProject

V&V Verification and Validation

WBS Work Breakdown Structure

Note that the wording “Typical” is used in South Africa and can be understood as “Generic” in the

sense of the CENELEC norms. However, the Typical Development subProject is a larger than that,

as it includes also the activities to start the contract (setup of collaborative environment, etc.).

The PICS is seen as a program according to the definition in the PMI PMBoK and ISO21500:2012:

“a group of related projects managed in a coordinated way to obtain benefits and control not



available from managing them individually”. However, in the frame of this contract, the PRASA

In-Cab Signalling contract is called a project and the projects will be called subprojects.

It must be noted, especially for this document, that the vocabulary used is the one coming from

the international standard ISO21500:2012 – guidance on “Project Management”.

1.4. Reference documents

References hereafter are always meant to be the last available version of the document, as

recorded in the Quality Management System.

Reference Name Title [REF.1] PICS_R_30006_RFP Glossary General Glossary of the RFP [REF.2] PICS_R_30072_Technical_RS Technical Requirements Specification [REF.3] PICS_R_30056_RAM_RS RAM Requirements Specification [REF.4] PICS_R_30055_PM_RS Project Management Requirements

Specification [REF.5] PICS_R_30053_Tech RFP PICS Technical RFP Master Document [REF.6] PICS_R_30098_Quality_RS Quality Requirements Specification [REF.7] PICS_R_30072_Technical_RS Technical Requirements Main Document [REF.8] PICS_R_30061_ETCS_RS ETCS Requirements Specification [REF.9] PICS_R_30077_Safety_RS Safety Requirements Specification [REF.10] PICS_R_30063_ProdEngineering_RS Production Engineering Requirements

Specification [REF.11] PICS_R_30071_TestAcc_RS Testing and Acceptance Requirements

Specification [REF.12] PICS_R_30062_Products_RS Products Requirements Specification [REF.13] PICS_R_30086_Installation_RS Installation Requirements Specification [REF.14] PICS_R_30097_Maintenance_RS Maintenance Requirements Specification [REF.15] PICS_R_30085_Training_RS Training Requirements Specification

1.5. Appendices

Appendices hereafter are always meant to be the last available version of the document, as

recorded in the Quality Management System.

Reference Name Title [APP.1] PICS_R_30021_Projects_RS_APP01_GeogScope Geographical Scope [APP.2] PICS_R_30021_Projects_RS_APP02_WBS WBS Template [APP.3] See section 10, p. 35 The planned development of the

PRASA network



2. Program and projects

R0021_01. [CT] The Contractor shall carry out the PICS contract with strict observance of the

information (about organization, schedule, life cycle, etc.) given in this section 2 and

in the section 6.

The PICS is one part of the renewing programme of PRASA’s network. The context of the PICS

project (interaction with other projects by PRASA, goals of the renewing programme, etc.) can be

found in [APP.3].

R0021_02. [CT] The Contractor shall organize the PICS contract into 19 subprojects:

1. The Typical Development subProject (TDP);

2. The 3 Pilot Line subProjects (PLP) for the three regions: Gauteng (GAU-01-PLP),

Kwa-Zulu Natal (KZN-01-PLP) and Western Cape (WC-01-PLP);

3. The 15 Roll-Out subProjects (ROP) which are distributed amongst the regions as

followed:

a. 7 projects in Gauteng; (GAU-XX-ROP with XX from 02 to 08)

b. 3 projects in Kwa-Zulu Natal (KZN-YY-ROP with YY from 02 to 04);

c. 5 projects in Western Cape (WC-ZZ-ROP with ZZ from 02 to 06).

If the contract is awarded to multiple suppliers, the number of subprojects will be 21, as there

will be three different Typical Development Projects (one for each region). Except if stated

otherwise, all the requirements in the PICS Technical RFP are applicable in both cases (single or

multiple suppliers).

During the contract execution, any suggestion to adapt the project decomposition as proposed in

R0021_02 can be considered, as far as contractual agreement is reached between PRASA and the

Contractor.

R0021_03. [CT] The Contractor shall execute the PICS contract according to the following high

level time schedule (also illustrated in the Figure 11):

The Roll-Out subProjects (ROP) shall all be commissioned within 53 months

after contract award;

The Pilot Line subProjects (PLP) shall not take more than 20 months to be put

into service;

The Typical Development subProject (TDP) – without Updates & Upgrades

phase – shall not take more than 27 months.

1 The Figure 1 does not show the RAM monitoring periods nor the maintenance periods, nor the performance period as defined in the Volume 2 of the PICS RFP.



Figure 1 : High-level time schedule of the programme

As seen in the high-level time schedule above, these subprojects are strongly related and some of

them are overlapping. The dependencies between them are defined and explained in section 6.



3. Typical Development subProject

R0021_04. [CT] The Contractor shall carry out the PICS Typical Development subProject with

strict observance of the information (about organization, schedule, life cycle, etc.)

given in this section 3.

3.1. Scope

The scope of the Typical Development subProject (TDP) covers all the activities and supply

needed to:

define the conceptual design for the implementation of ETCS level 2 customized for the

PRASA network and get a generic application for PRASA;

get adapted products (RBC,…) to fit the PRASA needs and the necessary design and

testing environment (ETCS automated data preparation tool, laboratory testing

environment,…) to start the rollout;

start up the PICS project by setting up the needed tools (collaborative environment, fine-

tuning the planning and the processes, etc.).

The main high-level outputs of this project are:

A full conceptual design (architecture, functions, engineering and programming rules for

the rollout …), including the feedback coming from the pilot lines, for the implementation

of the ETCS level 2 trackside sub-system to be overlaid on IL subsystems in the different

PRASA regions;

A certified Generic Application Safety Case (GASC) for the ETCS level 2 conceptual

design;

ETCS products (RBC, anti-theft balise system,..) adapted to fit the PRASA needs and the

South-African context;

A development environment fully customized (automated ETCS data preparation tool,

processes,…) to be used for the production engineering for the PICS rollout projects;

Testing and validation principles and tools to be applied and used for the PICS rollout

projects;

A laboratory test environment in PRASA premises of each PRASA region.

This list is not exhaustive. The detailed technical scope of the TDP is mainly described in [REF.8].

3.2. Life Cycle

The TDP begins with the contract award and ends after the commissioning of the last Pilot Line

subProject. However, the Updates and Upgrades phase goes on until the end of the last Roll-Out

Project. The phases of the TDP are presented on Figure 2.

R0021_05. The Contractor shall organize the TDP kick-off meeting within two weeks after the

Contract Award.

R0021_06. The SW development and HW development phases are not bound to specific

milestones. The Contractor will plan these phases as it wishes in order not to

jeopardize the planning of the other phases. No payment shall be bounded to these

phases. Those SW development and HW development phases correspond with the



customization of the ETCS products (i.e.: adaptation of the RBC to implement the

South African signalling principles and the standard Ixl-RBC protocol, the anti-theft

system for the balises, etc…), the development environment and the test

environment.



Figure 2: Typical Development Project Life Cycle



3.3. Deliverables

The Contractor shall deliver specific documents to the PRASA at each defined milestone. The

Table 1 defines which deliverables must be delivered for which milestone of TDP.

To successfully reach the milestone, each deliverable must be approved by PRASA. This approval

means a “notice to proceed further” and does not transfer any responsibility from the Contractor

to PRASA. The Contractor remains fully responsible as defined in section 4.2.

The list in Table 1 is an overview of the deliverables and conditions for the Typical Development

subProject. This list is not exhaustive and gives only an indication of the content expected at

each milestone; for example, it does not necessary include all the conditions and deliverables

expected from a professional way of working or from a classical development according to the

normative reference. However, each deliverable already identified is mandatory. This list must

be completed and agreed at the latest at the Preliminary Gate Review of the Typical

Development Project.

Milestones Deliverables Required in Preliminary GR Project Management:

Details of the Collaborative Environment finalized Program Management Plan Project Management Plan Project Management Plan template Exhaustive List of Deliverables (ELOD) – based on

this list Definition of parameters for the Earned Value

Management (EVM) Scope Baseline Schedule Baseline Documents Management Plan Requirements Management Plan Configuration Management Plan Risk Management Plan and Risk Register Stakeholder Management Plan Final form of the reporting

[REF.4]

RAM: Generic RAM PLAN

[REF.3]

Quality: Quality Plan Definitive List of equipment for review and

inspection Evidence of qualified and trained staff

[REF.6]

Technical: Development / Engineering Plan

[REF.7]

Safety: Generic Safety Plan HAZOP

[REF.9]

ETCS: Driving ergonomics proposal

[REF.8]

Testing & Acceptancy: Assessment and Certification Plan

[REF.11]



Milestones Deliverables Required in Products: Environmental Plan and test evidences of product

compliance by independent laboratory EMC Plan Earthing Concept (can be included in EMC Plan) Procedure for KMAC keys approved

[REF.12]

Programme and planning Detailed Contract Programme

See section 7

Installation: Theft and Vandalism document Balise Theft-Test Campaign

[REF.13]

Generic Subsystem Design GR

Management: Tested and fully working Collaborative

Environment (must have been available 2 months after the Preliminary GR)

[REF.4]

Quality: Pre-manufacturing Review done Skills training plan Production planning and reporting in place

[REF.6]

ETCS design: Generic Application FRS (Functional Requirement

Specification) System Architecture Description Implementation of the Stop if in SR function by

GSM-R (first step)

[REF.8]

Engineering: Gradient Modelling Process Measurement Strategy, processes and tools

[REF.10]

Training: Training Plan

[REF.15]

Data Engineering Design GR

ETCS design: Generic Programming Rules

[REF.8]

Safety: All safety analyses and safety studies Generic Hazard Log Report with measures

implemented

[REF.9]

Testing Principles GR

Testing & Acceptancy: Overall Test Plan Migration Strategy Document Laboratory Test Environment Description

[REF.11]

Generic Case Validation GR

Safety: Generic Application Safety Case Generic Product Safety Cases + their certificate

[REF.9]

Testing & Acceptancy: Principles Validation Report ETCS simulator user’s manual and other

equipment user’s manual All assessment reports Intermediate Statement of Conformity ISA Discrepancies Register (draft version) NoBo Discrepancies Register (draft version)

[REF.11]



Milestones Deliverables Required in Safety: Generic Hazard Log Report (records « closed »)

[REF.9]

All above mentioned documents updated to take into account the necessary adaptations (feedback from the pilot lines)

The all set of documents will define the first baseline for the Generic case ; therefore, all the needed documents to issue a Generic Case are mandatory at this gate review.

Generic Application Updates GR

All above mentioned documents updated to take into account the necessary adaptations (feedback and lessons learned from the subprojects) and produce a new generic baseline whenever needed

Recurrent Deliverables

Management: Adequate reporting and communication Risk Register (update if any) Planning and programme

[REF.4]

RAM: Annual Performance Monitoring Report (in

December) [REF.3]

Safety: Hazard Log

[REF.9]

Updates & Upgrades phase

Inclusion of all feedbacks and lessons learned from the subprojects

All above mentioned documents updated to take into account the necessary adaptations (feedback and lessons learned from the subprojects) and produce a new generic baseline whenever needed

Lessons Learned documents

Table 1 : Milestones and deliverables for TDP

The payment for the Typical Development Project shall be made at successfully reached

milestones as defined in the (non-technical) RFP.

4. The Pilot Line subProjects

R0021_07. [CT] The Contractor shall carry out the PICS Pilot Lines Projects with strict

observance of the information (about scope, organization, schedule, life cycle, etc.)


4.1. Scope

The scope of the Pilot Line subProjects (PLP) covers all the activities and supply needed to get a

commissioned and certified ETCS trackside subsystem on the identified pilot lines. Beside the

commissioning of the lines, the goal of the Pilot Lines is also to help validating the generic

principles and building a better generic design (in the Typical Development subProject) and, as a

consequence, to allow a faster and more reliable deployment of the PICS system on the PRASA

network.



The main high-level outputs of these pilot projects are:

Safety and interoperability certificates of ETCS level 2 trackside sub-system on each pilot

line;

Specific Application Safety Case for the PICS system on each pilot line;

Acceptance and authorisation by the Railway Safety Regulator to put in operation the

ETCS level 2 on each pilot line;

Training session carried out for the users on each pilot line;

As-built documentation of the delivered ETCS level 2 installations for each pilot line;

Integration of the feedback from each pilot line into the generic design.

This list is not exhaustive. The technical scope of the PLP is described in the [REF.2] and all its

subdocuments. The geographical scope is defined in the following sections and in [APP.1].

4.1.1. Pilot Line 1 in Gauteng: GAU-01-PLP

The GAU-01-PLP is the Pilot Line for Gauteng PRASA region. The characteristics of this line are

summarized in the Table 2. This information is given for tendering purpose only.

Info Description From Station Houtheuwel included – KP 58.63

To Halt Tshiawelo included – KP 17.37 Track Double track track Length +/- 41.26 km Traction Power 3 kV DC Interlocking SICAS S7 from Siemens (installed in the frame of the re-signalling

program) located in each station on the line Computer Room In each station Stations Houtheuwel– 4 tracks

Residensia – 7 tracks Grasmere – 6 tracks Lawley – 4 tracks Lenz – 5 tracks Midway – 5 tracks

Layout The detailed layout can be found in [APP.1] of this document.

Table 2 : Pilot Line Gauteng region characteristics

4.1.2. Pilot Line in Kwa-Zulu Natal: PLP-KZN-01

The PLP-KZN-01 is the Pilot Line for KwaZulu-Natal PRASA region. The characteristics of this

line are summarized in the Table 3. This information is given for tendering purpose only.

Info Description From Station Pinetown included – KP 77.67 To Halt Umbilo included – KP 99.64 Track See [APP.1] Length +/- 21.97 km Traction Power 3 kV DC Interlocking. Computer room

Ebilock 950-R4 from Bombardier (installed in the frame of the re-signalling program) located at the new CTC centre in Rossburg.

Stations Pinetown – 5 tracks Northdene – 3/4 tracks



Malvern – 2 tracks Bellair - 3 tracks Rossburgh – 4 tracks Umbilo – 4 tracks

Layout The layout can be found in [APP.1] of this document.

Table 3 : Pilot Line Kwa-Zulu Natal region characteristics

4.1.3. Pilot Line in Western Cape: PLP-WC-01

The PLP-WC-01 is the Pilot Line for Western Cape PRASA region. The characteristics of this line

are summarized in the Table 4. This information is given for tendering purpose only.

Info Description From Station Wynberg included – KP 12.88

and Halt Athlone – KP 5.74

To Station Simonstown included – KP 36.05 Track Double track Length 33.78 km Traction Power 3 kV DC Interlocking/ Computer room

LockTrac 6151 L905 from Thales (installed in the frame of the re-signalling program) located in Retreat station

Stations Wynberg – 4 tracks Plumstead – 3 tracks Wetton – 3 tracks Retreat – 8 tracks Muizenberg – 3 tracks Fish Hoek – 3 tracks Simonstown – 5 tracks

Layout The layout can be found in [APP.1] of this document.

Table 4 : Pilot Line Western Cape region characteristics

4.2. Life Cycle and planning

The phases of the PLP and ROP are presented on Figure 3.



Figure 3: Project Life Cycle for Pilot Line subProjects (PLP) and Roll-Out subProjects (ROP)



R0021_08. [CT] Within one month (30 calendar days) after PRASA sends a formal notice to

proceed for a PLP or ROP subproject, the Contractor shall organize the subproject

kick-off meeting. The formal notice to proceed shall take the form of a project

charter.

As a mandatory condition to start a subproject, the re-signalling must be completed for the

concerned area and the corresponding as-built documentation must be available.

R0021_09. [CT] The Contactor shall take the lead and the responsibility of the Project

Definition phase but the formal approval from PRASA shall be required. Therefore,

in order to successfully reach the Preliminary Gate Review maximum one month

after the Project Kick-off meeting, the Contractor shall be responsible to take all

necessary precautions to request PRASA approval on time. The period of time

between Project Kick-off and the Preliminary Gate Review shall not exceed one (1)

month.

R0021_10. [CT] The Contractor shall submit the detailed subproject programme for

Preliminary Gate Review. In order to successfully reach this milestone, the

Contractor shall submit the detailed subproject programme for review and

interrogation during the Project Definition phase (see also section 7).

R0021_11. [CT] The Contractor shall ensure that the period of time between the Preliminary

Gate Review and the Preliminary Acceptance shall not exceed twenty (20) months

for Pilot Line Projects and fourteen (14) months for Roll-Out Projects. The

Contractor shall take the lead of the needed Joint Workgroup with other suppliers if

needed (see [REF.7]) and shall take the responsibility to meet deadlines unless it is

proven that another supplier is faulty. The burden of proof lies on the Contractor

side.

R0021_12. [CT] At the Design Gate Review and Data Engineering Gate Review, the Contractor

shall be responsible to get the authorisation from PRASA to proceed but this

authorisation is neither an approval nor a review of the work carried out by the

Contractor. The Contractor shall remain fully responsible for the content of his work

until the Preliminary Acceptance milestone.

R0021_13. [CT] The Contractor shall ensure that the period of time between the milestones

Laboratory Validation and the Preliminary Acceptance shall be at least one (1)

month. As a consequence, the period of time between the Preliminary Gate Review

and the Laboratory Validation milestone shall not exceed nineteen (19) months for

Pilot Line Projects and thirteen (13) months for Roll-Out Projects.

R0021_14. [CT] The Installation and Manufacturing phases are not bound to specific

milestones. The Contractor shall plan these phases as it wishes in order not to

jeopardize the planning of the other phases. No payment shall be bounded to these

phases.



The period of time between the Preliminary and Final Acceptance shall be two (2) years and shall

be used for the review of the performance and is described in [REF.3].

R0021_15. The Contractor shall organize six (6) Performance Gate Reviews, occurring every six

(6) months, during the Performance Monitoring phase which ends at the issue of

performance certificate (as defined in the Volume 2 of PICS RFP). The last

Performance Gate Review shall occur at the same time than the Final Acceptance.

4.3. Schedule

R0021_16. Within the high level schedule given in section 2 (Figure 1), PRASA will plan the

start date of the PLP according to PRASA needs and constraints (availability of the

interlocking, capacity needs, safety needs, etc.) and according to the dependencies

(see section 6). The Contractor shall be flexible to start at the set date and shall take

the responsibility of any delay due to the dependencies (e.g. TDP activities not

completed or done properly).

4.4. Deliverables

The Contractor shall deliver specific documents to the PRASA at each defined milestone. The

Table 5 defines which deliverables must be delivered for which milestone of PLP/ROP.




The list in Table 5 is an overview of the deliverables and conditions required within the whole

PICS Technical RFP for a Pilot Line subProject. This list is not exhaustive but gives already a good

indication of the content required at each milestone; for example, it does not include all the

conditions and deliverables expected from a professional way of working or from a classical

development according to the normative reference (e.g. the delivery of new ISO9001 certificate

after renewal). However, each deliverable already identified is mandatory. This list must be

completed for the Preliminary Gate Review of the Typical Development Project.

Milestone Deliverables Required in

Preliminary Gate Review

RAM: Specific RAM Plan

[REF.3]

Management: (Specific) Project Management Plan, including WBS,

RACI and planning Scope Baseline Schedule Baseline

[REF.4]

Safety: Specific Safety Plan

[REF.9]

Testing: Specific Verification and Validation Plan

[REF.11]

Engineering: Specific Application System Requirements

Specification (SRS) [REF.10]



Milestone Deliverables Required in Quality: Specific Project Quality Plan Evidence of qualified and trained staff Reporting on the Production Planning

[REF.6]

Products: KMC Documentation

[REF.12]

Important remark: the deliverables of the Generic Subsystem Design phase must also be delivered and approved in order to start the PLP Detailed Design phase (see Figure 4).

Design Gate Review

Performance: RAM Analysis Specific RAM Plan

[REF.3]

Quality: Pre-Manufacturing Review conducted before starting of production

[REF.6]

ETCS design: Implementation of the Stop if in SR function by

GSM-R (second step) Track Data Collected

[REF.8]

Safety: Specific Safety and Risk Analysis Intermediate Hazard Log

[REF.9]

Design: Detailed Design Report Specific Design Documents Detailed Design plans and installation/execution

plans Earthing Plan Detailed Design System Interfaces Description

(SyID)

[REF.10]

Testing & Acceptancy: Specific Tests Specifications for the ETCS trackside

static SAT Interoperability Constituents Certificates

[REF.11]

Management: Updated Project Management Plan (incl. Scope

Statement and Planning) Updated WBS, RACI and planning

[REF.4]

HSE: Health Safety and Environment Plan

[REF.5]

Products: Products description

[REF.12]

Installation: Adapted installation plans (room plans, etc.) Products installation directives

[REF.13]

Data Engineering GR

Engineering: Subproject Data Engineering Report Data files for all equipment (RBC, balises, LEU if

any) Measurement Survey Report (shall be delivered to

PRASA one month after the end of the Measurement Survey, and at latest at this gate

[REF.10]



Milestone Deliverables Required in review).

Testing : Specific Tests Specifications for all the tests phases

belonging to Laboratory Testing and Validation. [REF.11]

Quality: First Article Inspection review done (for the first

application and for after each product change)

[REF.6]

Safety: Specific risk analyses, if any Specific Hazard Log Report with measures

implemented

[REF.9]

Laboratory Validation GR

Testing : Specific Tests Specification for all the tests phases

belonging on site Testing and Validation. Specific Tests Reports for all the tests phases

belonging to Laboratory Testing and Validation Laboratory Testing and Validation Summary Report

[REF.11]

Preliminary Acceptance GR

RAM: Maintainability demonstration of every products

[REF.3]

Quality: First System Installation Inspection conducted

before the commissioning tests.

[REF.6]

Testing & Acceptancy: Specific Tests Reports for all the tests phases (as

defined in [REF.11]) belonging to on-site Testing and Validation.

On site Testing and Validation Summary Report Global Testing and Validation Summary Report ISA Discrepancies Register NoBo Discrepancies Register Certificate of Verification of the PICS CCS ISA and NoBo Assessment Reports, Certificates and

dossiers

[REF.11]

Safety: Specific Hazard Log Report (records “closed”) Generic and Specific Application Safety cases

[REF.9]

Products: KMC tool User Manual “Management of Track possession” function

documentation (User manual, procedures to be applied, etc…)

Data File Management Tool Documentation ETC maintenance server and Local RBC terminal

full documentation Portable Maintenance Tools full documentation

(user’s manuals, certificates, etc…)

[REF.12]

Maintenance: Maintenance documentation Maintenance tools received and working Maintenance Plan PRASA maintainers Maintenance Plan Contractor maintainers

[REF.14]



Milestone Deliverables Required in Training: All needed training held Training report

[REF.15]

All above mentioned documents updated to take into account the necessary adaptations (after possible previous applications)

All information needed for PRASA to be able to operate the subproject put into service.

Performance GR RAM: Performance Monitoring Report Reliability and Availibility Demonstration Update of the RAM plan, if any

[REF.3]

Engineering: As-built plans (at first performance GR)

[REF.10]

Maintenance: Change Analysis on Maintenance Plans

[REF.14]

All feedbacks and lessons learned are sent to the Typical Development Project

Final Acceptance GR

RAM: (Final) Performance Monitoring Report

[REF.3]

Maintenance: Change Analysis on Maintenance Plans

[REF.14]


Recurrent Deliverables

Management: Adequate reporting and communication Risk Register (update if any) Planning and programme

[REF.4]


Table 5 : Milestones and deliverables for PLP

The payment for the Pilot Line Projects shall be made at successful milestones completion as

defined in the (non-technical) RFP.

5. The Roll-Out subProjects

R0021_17. [CT] The Contractor shall carry out the PICS Roll-Out subProjects with strict

observance of the information (about scope, organization, schedule, life cycle, etc.)


5.1. Scope

The scope of the Roll-Out subProjects (ROP) covers all the activities and supply needed to get a

commissioned and certified ETCS level 2 trackside subsystem on the identified lines. The main

high-level deliverables of these projects are:

Safety and interoperability certificates of ETCS level 2 trackside sub-system on each roll-

out project;



Specific Application Safety Case for the ETCS level 2 trackside subsystem on each line;

Acceptance and authorisation by the Railway Safety Regulator to put in operation the

ETCS level 2 on each line;

Training session carried out for the users on each line;

As-built documentation of the delivered ETCS level 2 installations for each line.

This list is not exhaustive. The technical scope of the ROP is the application of the generic design

and is described in the [REF.2] and its subdocuments. The geographical scope is defined in

[APP.1].

The geographical scope of the Roll-Out subProjects is defined in the Table 6, according to the

phasing of the re-signalling (see [APP.1] for the information about the re-signalling phases).

Roll-Out subProject in Gauteng ROP-GAU-02 Phase 3 + Phase 5 + Phase 7 ROP-GAU-03 Phase 6 + Phase 8 ROP-GAU-04 Phase 2 + Phase 4 + Phase 9 ROP-GAU-05 North part Phase 10 + Phase 11 + Phase 12 ROP-GAU-06 South part Phase 10 + Phase 13 ROP-GAU-07 Phase 14 ROP-GAU-08 Phase 15

Roll-Out subProject in KwaZulu-Natal ROP-KZN-02 Phase 3a + Phase 3b ROP-KZN-03 Phase 4 + Phase 5 ROP-KZN-04 Phase 6 + Phase 7

Roll-Out subProject in Western Cape ROP-WC-02 Phase 1.3 + Phase 1.4 ROP-WC-03 Phase 3.1 + Phase 3.2 + Phase 2.3 ROP-WC-04 Phase 2.2 ROP-WC-05 Phase 1.1 + Phase 2.1 ROP-WC-06 Phase 4.1 + Phase 4.2

Table 6 : List of Roll-Out subProjects

The splitting of Gauteng phase 10 shall be around Schuttestraat.

5.2. Life Cycle

As the project life cycle is the same for pilot line subproject and for roll-out subproject, please

refer to section 4.2 for project life cycle and milestones. The whole section is applicable for ROP,

except where explicitly limited to PLP (e.g. for duration limits).

5.3. Schedule

R0021_18. Within the high level schedule given in section 2 (Figure 1), the ROP shall be

executed according to PRASA needs and constraints (availability of the interlocking,

capacity needs, safety needs, etc.). As a consequence, the Contractor shall be flexible

to adapt the “Program and Project Schedule Chart” proposed in its Tender if

required by PRASA for the Contract execution.



5.4. Deliverables

The Contractor shall deliver specific documents to PRASA at each defined milestone of the ROP

as defined in [REF.4]. These deliverables are the same as for the pilot lines and the Table 5

defines which deliverables must be delivered for which milestone.




The list in Table 5, which gives an overview of the deliverables and conditions required within

the whole PICS Technical RFP for a Pilot Line subProject, is also applicable for a Rollout

subProject. Nevertheless, some of the deliverables identified in this table may be delivered only

once for the whole project (e.g. the product descriptions only during pilot lines). This list is not

exhaustive but gives already a good indication of the content required at each milestone; for

example, it does not include all the conditions and deliverables expected from a professional

way of working or from a classical development according to the normative reference (e.g. the

delivery of new ISO9001 certificate after renewal). However, each deliverable already identified

is mandatory. This list must be completed for the Preliminary Gate Review of the Typical

Development Project.

The payment for the Rollout subProjects shall be made at successful milestones completion as

defined in the (non-technical) RFP.

6. Dependencies between projects

As seen in the high-level time schedule (Figure 1 in section 2), the TDP, PLP and ROP are

strongly related and some of them are overlapping. The high-level dependencies between them

are listed here and illustrated in Figure 4:

The design of the pilot lines shall begin after the system design carried out at typical

level (Typical Development subProject).

The Validation of the Generic Principles (in the TDP – see section 3.2 for the definition of

this phase) shall not end before having taken into account the feedback of On-site

Testing and Validation phases from all PLP.

The TDP (without Updates and Upgrades phase) cannot end before the commissioning (=

Preliminary Acceptance) of all PLP2 and the consolidation of the Generic Case.

The ROP shall begin after the end of the TDP (not taking into account the Updates and

Upgrades phase of the TDP).

Each ROP shall feed the TDP Updates and Upgrades with the feedback before its end.

2 In case of multiple suppliers, this condition is limited to the applicable PLP.



Figure 4: Dependencies between subprojects inside PICS project

More detailed dependencies between phases of the project are illustrated in Figure 5. The

following elements must also be taken into account to understand this figure and to define the

concept:

Each arrow from element A to element B implies that A must be finished to begin B. It is

a necessary condition but not a sufficient one. It is not a logical condition meaning that

finishing A implies that B begins.

The lighter blocks (i.e. SW Development, HW Development, Manufacturing and

Installation) are phases that are not fully delimited by gate reviews (milestones); the

supplier can manage and organize them himself without jeopardizing the planning of the

other phases.



Figure 5: Dependencies between TDP and PLP project phases



7. Planning Procedure and tools

R0021_19. [CT] The Contractor shall produce the required programme scheduling in ASTA

PowerProject planning software. Planning deliverables shall always be ASTA

PowerProject electronic file and a PDF version as well.

R0021_20. [CT] Before every Preliminary Gate Review (TDP, PLP or ROP), the Contractor shall

submit the related subproject (or project for TDP) programme (in ASTA

PowerProject electronic file) in order to allow review and interrogation. Sequencing,

logic, and resource allocations will be checked by PRASA to ensure the accuracy and

workability of the programme.

R0021_21. [CT] The Contractor shall use the following guidelines during the planning

activities:

The Contractor shall fully logic link the programme scheduling applying the

Contractor’s mind to the logic to ensure the logic is as complete as possible. The

Contractor shall not continuously add or delete logic links as the project

progresses. The full logic linking process shall be carried out completely by the

Contractor at the outset. The logic must be true between activities and have as

few or no dummy links between activities as possible.

The Contractor shall not use negative links as these can result in inaccurate

progress reporting and the requirement to insert the correct logic later to

correct this error.

The Contractor shall use Start and Finish constraints only where there is no

suitable logic link that can be applied. In such instances a start constraint date

may be inserted but may need to be adjusted as the project proceeds or a

‘Dummy’ link is inserted so as to allow this string of activities to move in

relation to other relevant strings once progress is calculated. This logic may

require adjustment as the project proceeds.

The Contractor shall include contingencies for inclement weather for site

installations. Contractor is required to submit a schedule of rain days assumed

or as a minimum the number of days allowed for within the programme. The

Technical Advisors to PRASA will discuss and seek agreement on the allowance.

The Contractor shall include within the programme procurement of equipment

and materials which identifies pricing/tendering periods, award, placement of

order, any shop drawings or supplier design periods, manufacturing periods,

factory acceptance testing, shipping times, customs clearances and delivery to

yard or site. Progress reporting on these activities is required to ensure

compliance with the site installation date and identify possible time risks early.

The subproject programme must refer back to the project programme and must

fall within the time frame of the project programme. Should it be found that the

periods or sequence within the project programme is unworkable the

subproject programme must either be crunched if this area sits on or near the

critical path or the subproject programme used as a basis for the revision of the

project programme.



In line with international standards the Contractor shall use the float as

belonging to the project and not solely to either party.

The procedure for carrying out the progress update on the software will be to

standard practices, that is, to define the progress cut-off date or Status Date and

calculate incomplete and activities not started to commence or finish after this

date. The use of constraint dates to predict the end or start of activities during

the life of the programme should only be used in the cases where activities such

as delivery dates are known in writing.

R0021_22. [CT] With every programme submitted throughout the project lifecycle, the

Contractor shall include within the electronic copy of the programme the key

resources required to execute the plan. The resources required will include key

designers/teams and extend through to site installation. The Contractor shall submit

resource histograms for each resource to demonstrate that the programme has been

constructed with resources in mind and resources levelled prior to submitting the

programme to ensure that a workable programme has been compiled. The

Contractor shall also submit a detailed Approach Paper describing the sequence and

methods and the reasons for the chosen strategy.

R0021_23. [CT] For subproject programmes (short term), the Contractor shall deliver a

detailed method statement indicating sequencing, anticipated resources,

reasoning for sequencing and methods chosen, access routes, public protection,

occupations anticipated and type of occupation. This serves to ensure that the

Contractor has thoroughly thought through the work to be undertaken. Also

activities sensitive to weather should be protected by including suitable weather

allowance within the programme. Key resources must be considered in the

programme to ensure a workable programme.

7.1. Reporting

R0021_24. [CT] The Contractor shall submit monthly progress updates in electronic format

for interrogation. This reporting shall be derived from the global programme in

ASTA PowerProject format. Once on site operations begin the progress updates will

be carried out jointly and agreed prior to the formal issue of the progress update

and report. In this way bottle necks and planning issues can be identified

immediately and plans put in place to mitigate any delay or disruption. This

reporting shall be done by the Contractor with respect to the following guidelines:

Progress will be recorded both against the critical path and an ‘S’ curve

The progress trend will be shown against an “S-Curve” based on an activity

count or so as to track against percentages, actual percentage achieved against

planned. Although the critical path is the key mode of measurement for the end

date the S-curve will give a trend and establish a pictorial view of the work

volumes achieved or not achieved as the case may be.

The progress report must include the reasons for time gain or loss for key

activities while a record of gains and losses or changes for each affected activity

should be kept in the notes column of the programme



The aim of the Progress Report is to establish exactly where the project is and

not where it is thought to be either at the time of the report or sometime in the

near future.

This progress report shall be combined with the monthly report as defined in

[REF.4].

Once the progress has been calculated it is often the case that the result no longer reflects

current events or developments thereby producing a result that is too far behind programme or

indeed too far in front.

R0021_25. [CT] The Contractor shall record the result of the progress calculation and

communicate it to PRASA and the correction and the reasons for the correction

recorded in the ‘Programme Change Log’. The logic or duration change must be

agreed with the PRASA. Where progress has fallen behind, a mitigation statement

shall be produced by the Contractor detailing how the time will be recovered and

with what resources and accompanied by a programme showing the recovery.

Where the programme falls behind the Contactor is urged to not only address the

Critical Path but also the volume of work on non-critical activities as the increase in

work volumes will cause the Contractor to address too many fronts and lead to

inefficiencies and a higher risk of failure in the future.

R0021_26. [CT] Where the Contractor is faced with several options to save time or work more

efficiently than that originally envisaged, or PRASA needs to review the impact of

possible future instructions, the Contractor shall produce a series of ‘what-if’

programmes to ascertain a better understanding of the benefits in time for each

option available. Where such action is required the Contractor is to notify PRASA

and submit the ‘what-if’ programmes and the attractors and detractors of each

option. The purpose of this review is to constructively comment and offer a possibly

different viewpoint or option to consider.

7.2. Revision

R0021_27. [CT] Revisions to the Contract Programme must be agreed prior to formal issue.

The Contractor shall clearly state the reasons for change in a Programme Change

Log produced and submitted for record purposes. This Change Log shall identify the

activities affected stating what changes have been made to sequence, duration and

any logic changes for each affected activity.

It is accepted that the programme may, at some point during the life of the project, no longer

represent what will transpire or what needs to be achieved either through new understanding

or changes to scope or sequence for various reasons. It is not the intention that should the

contractor pull significantly ahead or fall behind programme that the programme is revised. A

well constructed, robust programme regardless of substantial progress gains or losses, should

still be able to provide accurate progress feedback and be able to remain the working document

that the Contractor can organize the tasks and resources to execute the works, and therefore not

require change.



R0021_28. [CT] Where an extension of time is requested the Contractor shall submit the

programme clearly showing the effects of the delay against the project programme

along with other supporting evidence that is required under the terms of the

contract. All claims and their effects on the Critical Path must be clearly

demonstrated to justify any extension of time. It is not sufficient to adjust and

extend existing activities. The Contractor shall insert the events, and possibly

correspondence trail, leading up to the delay as new activities in the ‘What If’ or

Delay Demonstration Programme, and linking these events to the relevant activities.

Where the delay cannot be clearly shown on the project programme the subproject

programme in operation at the time shall be used by the Contractor to demonstrate

that the subproject programme falls within the framework of the project

programme and that the subproject programme has been vetted by PRASA3 prior to

its use.

8. Requirements for the Tenderer

R0021_29. [EV] The Tenderer shall deliver a dedicated document named “Program and

Project Schedule”. This document shall address all the topics considered in the

present document about the planning of the projects. In appendix to this document,

the Tenderer shall deliver:

a “Program and Project Schedule Chart” (in ASTA PowerProject format and

in PDF format as well) as defined in R0021_30;

a “Work Breakdown Structure Chart” (in MS Excel “.xlsx” format) as defined

in R0021_36 (and following).

A “Company Structure”, as required in document [REF.5].

The “Key CV”, as required in document [REF.5].

The requirement R0021_29 is the subcriterion “Program and Project Schedule” as defined in

[REF.5]. Its evaluation by PRASA shall be carried out regarding the expected content of the

“Program and Project Schedule” document and its appendices, as described throughout this

document (i.e. requirements about the time schedule, the WBS, the workload analysis and the

project deliverables). It must be noted that the sub-criterion “Company Structure”, “Team

Structure” and “CV” will be evaluated separately and are not part of the evaluation “Program and

Project Schedule”.

8.1. Time Schedule

R0021_30. [CP] The Tenderer shall deliver a “Program and Project Schedule Chart” (as

defined in R0021_29) of all activities related to the TDP, PLP and ROP. This overall

schedule shall respect all requirements presented in this document. The “Program

and Project Schedule Chart” shall be fully explained (assumptions, rationales, links

between projects or milestones, topics identified in the following requirements, etc.)

in the “Program and Project Schedule” document.

3 It is not the intention PRASA to vet weekly or monthly programmes unless they have the possibility of affecting PRASA/Metrorail operations or indeed may affect the ‘Master’ or Baseline programme.



R0021_31. [CP] In the “Program and Project Schedule Chart”, the Tenderer shall use the

same activities as defined in the overall WBS (see section 8.2).

R0021_32. [CP] The Tenderer shall give a description of each new milestone it proposes and

what it commits to deliver at these milestones. These milestones must help PRASA

to accurately follow the project.

R0021_33. [CP] For TDP and each of the PLP, the Tenderer shall show the four levels (as

defined in R0021_37) in its “Program and Project Schedule Chart”. If the Tenderer

is able to propose a shorter time for the PLP, the Tenderer shall do so and explain in

detail how this shorter period is to be achieved.

R0021_34. [CP] For ROP, the Tenderer shall discuss and optimize the duration of the project

life cycle (i.e. all phases and activities) in the frame of the dependencies given in

section 6. The discussion and optimization shall take into account at least the

following elements of a project: complexity, PRASA regions, location, PRASA

operational needs (as far as possible), workload peak, available resources, critical

path, buffer time, etc. As a conclusion, the Tenderer shall define different types of

project duration and shall allocate each Roll-Out Project to one type. The number of

project type shall be maximum five (5).

In the “Program and Project Schedule Chart”, the Tenderer shall show the four

levels for at least one project of each proposed type. Other projects can be simplified

to the first level (start and end dates).

R0021_35. [CP] The proposed schedule shall take into account the discussion made to

answer the requirement R0021_45 (estimated workload and resources) in the limits

of the constraints mentioned in this document. Proposals which do not respect any of

the constraints given in this document may not be included by the Tenderer in the

proposed planning.

8.2. Work Breakdown Structure

R0021_36. [CP] The Tenderer shall deliver an overall work breakdown structure of all

activities related to the TDP, PLP and ROP. This overall WBS shall respect all

requirements presented in this document. It shall be based on the template given in

[APP.2]. The template, the layout and the first levels of this document shall be

respected. This overall WBS shall be given in the “WBS Chart” (as defined in

R0021_29) and fully explained (assumptions, rationales, links between projects or

milestones, WBS dictionary, etc.) in the “Program and Project Schedule”.

R0021_37. [CP] In the overall WBS, the Tenderer shall use four levels for the activities: (1)

Subproject, (2) Phase, (3) Topics and (4) Work Package (also used for milestones).

The activities identified in the WBS shall correspond to the ones identified in the

overall schedule.

Note that this Overall WBS is a WBS to be used by PRASA as a base to follow the project. The

internal WBS of the Contractor may and should probably be more detailed. However, it is



strongly recommended that the internal WBS of the Contractor is in line (i.e. use the same

structure) with the Overall WBS.

R0021_38. [CP] The Tenderer shall give a description (WBS dictionary) and the

dependencies of each activity (phase, topic or work package) in the “Program and

Project Schedule”.

R0021_39. [CP] In the overall WBS, the Tenderer shall propose one instance of the WBS for

the three PLP, as the three projects must have the same WBS.

R0021_40. [CP] In the overall WBS, the Tenderer shall give as many instance of the WBS as

the number of ROP type identified (see R0021_34 for the type), as they can be

(slightly) different. If the WBS does not vary from one type to another, the Tenderer

shall clearly mention this and is allowed to reduce the number of instance to the

minimum needed.

8.3. Workload management

R0021_41. [CP] In the “Program and Project Schedule” document, the Tenderer shall develop

a dedicated section called “Workload management” where it includes the answer to

all the requirement of the section 8.3.

R0021_42. [CP] The Tenderer shall propose a way to ensure an efficient collaboration

between TDP team and PLP team(s) if they are different. This proposal shall

describe:

the organization of the different projects;

how the human resources are shared between them;

the processes to be put in place.

The Tenderer proposal shall have a dedicated section to thoroughly cover this topic.

If accepted by PRASA, this proposal shall be fully part of the contract and the non-

respect of it will lead to penalties.

R0021_43. [CP] The Tenderer shall give an estimation of the workload of the program. This

estimation shall contain a graph of the FTE needed in function of the time and shall

be fully explained and discussed (assumptions, explanations of figures, etc.) in the

“Program and Project Schedule” document. Workload peaks shall be clearly

identified and mentioned by skill category (e.g. data prep engineer, design engineer,

test engineer, etc.)

R0021_44. [CP] The Tenderer shall give information about his current and planned human

resources, by skill category (like data prep engineer, design engineer, test engineer,

etc.) relevant for this project. The Tenderer shall mention when and how many

engineers will be available for the PICS program should the Tenderer be successful.

R0021_45. [CP] The workload estimation and the available resources shall be presented by the

Tenderer in a way that allows PRASA to make a comparison between these two data.



The Tenderer shall discuss the “estimated workload vs available resources”

question. The following elements shall, at least, be addressed:

The action plan to ensure the availability of the resources (hiring: when, where,

what type of profile, etc.);

The adaptations of the planning in order to limit the workload peaks by

resource levelling techniques;

Any proposal to fulfil the program requirements in a more optimal way4.

8.4. Project Deliverables

R0021_46. [CP] The Tenderer shall check the lists of deliverables (Table 1, Table 5 and Erreur !

Source du renvoi introuvable.) and notify every modification proposal he finds

useful to PRASA through a section called “Deliverables” within the “Program and

Project Schedule” document. PRASA holds the right to refuse any proposal.

R0021_47. [CP] The Tenderer shall give a list of the inputs he will need for each activity

(normally only for WBS level 4: Work package or milestones). This list can be in the

“WBS chart” or in the “Program and Project Schedule” document. PRASA holds

the right to refuse an element of the list and delete it, if he judges it not needed or if

it requires activity (like engineering) at the PRASA side. The Tenderer shall

particularly pay attention to the inputs needed for the first phases of the Typical

Development Project and the Pilot Line Projects, as they are critical for the start of

the PICS program. This list of inputs from PRASA may be updated after Contract

Award on mutual agreement.

R0021_48. [CT] During Contract execution, the Contractor shall not expect more from PRASA

than the document identified in this list.

4 Any proposal which do not respect any of the constraints given in this document (e.g. not respecting the deadline of May 2019) can be discussed with PRASA but shall not be accepted before the Contract Award, in order to ensure the comparability of the Tenders. As a consequence, the Tenderer shall take this situation into account to deliver his offer.



9. Requirements List

The requirements from this document are listed in Table 7 and the type of the requirement is

given in the last column. Explanation about the “type” is given in [REF.5].

Requirement Name Type R0021_01 Contract executed according to the requirements Contractor R0021_02 Decomposition into 22 subprojects Contractor R0021_03 High Level Time Schedule Contractor R0021_04 Typical Project executed according to the requirements Contractor R0021_05 TDP Kick-Off Contractor R0021_06 TDP SW development and HW development Contractor R0021_07 Pilot Lines executed according to the requirements Contractor R0021_08 Project Charter Contractor R0021_09 Project Definition Phase Contractor R0021_10 Detailed Program for subproject Contractor R0021_11 Time duration for phases (I) Contractor R0021_12 Responsibility during phases Contractor R0021_13 Time duration for phases (II) Contractor R0021_14 Installation and Manufacturing phases Contractor R0021_15 Performance Monitoring Phase Contractor R0021_16 Start date of PLP Contractor R0021_17 Roll Out executed according to the requirements Contractor R0021_18 Start date of ROP Contractor R0021_19 ASTA PowerProject Format Contractor R0021_20 Subproject and project programme for Preliminary GR Contractor R0021_21 Guidelines for planning activities Contractor R0021_22 Key resources and histograms Contractor R0021_23 Detailed method statement Contractor R0021_24 Monthy progress updates Contractor R0021_25 Progress calculation and change log Contractor R0021_26 What-if programmes Contractor R0021_27 Revision of programme Contractor R0021_28 Extension of time Contractor R0021_29 Delivery of “Program and Project Schedule” document

and its appendices [subcriterion Program and Project Schedule]

Evaluation

R0021_30 Overall Schedule Compliance R0021_31 Planning: four levels of activity Compliance R0021_32 Planning: requirements for TDP and PLP Compliance R0021_33 Planning: requirements for ROP Compliance R0021_34 Planning: duration discussion Compliance R0021_35 Planning: estimated workload and resources discussion Compliance R0021_36 Overall Work Breakdown Structure (WBS) Compliance R0021_37 WBS; four levels of activity Compliance R0021_38 WBS: description and dependancies Compliance R0021_39 WBS: instance for PLP Compliance R0021_40 WBS: instance for ROP Compliance R0021_41 Workload: specific section Compliance R0021_42 Workload: collaboration between TDP and PLP Compliance



R0021_43 Workload: estimation of the workload Compliance R0021_44 Workload: current and planned human resources Compliance R0021_45 Workload: workload estimation vs human resources Compliance R0021_46 Deliverables Compliance R0021_47 List of inputs needed Compliance R0021_48 Limitation of inputs in execution phase Contractor

Table 7: Requirements list



10. Appendix 3: The planned development of the PRASA network

10.1. From mechanical and relay signalling to electronic interlocking

(2011- 2017)…

PRASA is currently implemeting re-signalling program to the three main Metroline networks

within South Africa which includes the following in each region:

PRASA Regional CTCs;

Bidirectional traffic;

Suppression of the bottlenecks;

Communication through a fibre optic network;

Replacing the old technology (mechanical, relays).

The re-signalling program is the first building block for the future Wireless Signalling System.

Indeed, the implementation of electronic interlocking offers the possibility to overlay with an

ATC/ATP system to achieve In-Cab signalling on the PRASA network as well as to achieve semi-

automatic train operation.

10.2. Optical fiber network (2012-2014)

In parallel with the re-signalling program, PRASA is installing optical fibers in order to complete

the ring for high reliability communication required in Signalling.

The optical fiber network will become the main mean of communication in signalling eliminating

most of the copper cables.

The Optical Fiber Network program is the second building block for the Wireless Signalling

System as it offers high reliability communication which is required for Signalling.

10.3. Radio digital signalling network (2012 – 2017)

A new GSM-R network is being installed to replace the obsolete analogue trunk radio.

The GSM-R program is the third building block for the Wireless Signalling System as it supports

signalling transmission.

10.4. Asset protection program (today – 2014)

Theft and Vandalism is a major concern for PRASA. Besides the technical choices done in the

frame of the re-signalling (e.g.: copper cables are eliminated as much as possible), an asset

protection program is ongoing comprising:

Lobby for change of legislation for scrap dealers (one regional dealer for

Eskom/Prasa/Gautrain, heavy punishment for asset thieves)

Protect rail land (brick & electric fence, alarms, video)

Code and chip the outside assets starting with copper cables (dot tint, invisible paint)



10.5. New PRASA Rolling stock (2016 – 2027)

PRASA has launched a significant renewing program for the commuter trains fleet as a contract

for 600 trains was awarded. The contract requires the trains to be ERTMS equipped ensuring:

Radio communication through the GSM-R network;

Safe train movement (ATC/ATP functions) with in-cab signalling provided that the ETCS

signalling information is sent to the trains.

10.6. PRASA In-Cab Signalling

The PRASA In Cab Signalling project aims at:

moving the PRASA commuter network from the lineside signalling to the wireless In Cab

signalling improving significantly the safety of the train movements ;

making possible future technical evolutions towards semi-Automatic Train Operation

and Virtual blocks;

helping make the network more secure and less prone to theft and vandalism in the

future with the removal of the lineside signalling.

The implementation of In-Cab signalling shall also take into account current

considerations regarding theft and vandalism.