digital railway joint development group outcome based ... · the interim joint development group...
Post on 19-Mar-2020
13 Views
Preview:
TRANSCRIPT
Reference:157319NWRREPCPO000002
Issue/ver: 1.0
Date: 10/08/2018
Digital Railway – Joint Development Group
Outcome Based Project Delivery Strategy
Case Study: Moorgate – Northern City Line Renewal with ETCS Technology
Prepared By: Keith Attwood, Professional Head of Signalling, Alstom
Prepared By: Simon D’Cruz, Chief Engineer, Atkins .................................. Date: ......................... Prepared By: Ben Lane, Regional Commercial Manager, Siemens .................................. Date: ......................... Prepared By: Andrew Woods, Senior Systems Engineer, Siemens .................................. Date: ......................... Approved By: Christos Panou, Senior Project Engineer, on behalf of Daniel Holder, Programme Engineer Manager, Network Rail .................................. Date: ......................... Approved By: Graham Lawrence, Project Manager, Network Rail .................................. Date: .........................
2
Document Control
Electronic file reference: 157319NWRREPCPO000002
Disclaimer
Group Digital Railway has used its best endeavours to ensure that the content, layout and text of this document are accurate, complete and suitable for its stated purpose. It makes no warranties, expressed or implied, that compliance with the contents of this document will be sufficient to ensure safe systems of work or operation. Group Digital Railway will not be liable to pay compensation in respect of the content or subsequent use of this document for any purpose other than its stated purpose or for any purpose other than that for which it was prepared, except where it can be shown to have acted in bad faith or there has been wilful default.
© Copyright 2017 Group Digital Railway.
This document is the property of Group Digital Railway. It shall not be reproduced in whole or in part, nor disclosed to a third party, without the written permission of Group Digital Railway.
Document owner: Joint Development Group (JDG) – jointdevelopmentgroup@networkrail.co.uk
Distributed to: Public
Issue/Version: 1.0
Feedback to be provided to: Daniel Holder dan.holder@networkrail.co.uk, Graham Lawrence: Graham.Lawrence@networkrail.co.uk, and Joint Development Group (JDG) - jointdevelopmentgroup@networkrail.co.uk
Version Comments Updated By Reviewed By Date
0.5 Final Draft SDC 1st June 2018
0.6 JDG Preface included PW SDC 7th June 2018
0.7 Updated Exec Summary. Renamed System Integrator to RSIP. Updated RSIP/TI roles
SDC 8th June 2018
0.8 Updated report with B Lane’s comments.
BY 13th June 2018
0.9 Updated report with DR comments. BY BY, QZ, GL, DH 19th June 2018
0.10 Updated with Recommendations highlighted
SDC 6th July 2018
1.0 Final version for publication JDG Team 14th August 2018
3
Contents
EXECUTIVE SUMMARY ................................................................................. 6
1 INTRODUCTION ....................................................................................... 8
1.1 JOINT DEVELOPMENT GROUP (JDG) ..............................................................................................8
1.2 PROJECT BACKGROUND AND PROBLEM STATEMENT ..............................................................8
1.3 THE IJDG PROJECT TEAM ................................................................................................................9
1.4 KEY MILESTONES ........................................................................................................................... 10
1.5 EXPECTED OUTPUTS ..................................................................................................................... 10
1.6 FINDINGS .......................................................................................................................................... 11
2 OUTCOME SPECIFICATIONS ................................................................ 12
2.1 INTRODUCTION ............................................................................................................................... 12
2.2 THIN CLIENT ENGINEERING MODEL ............................................................................................ 13
2.3 DEFINING REQUIREMENTS ............................................................................................................ 14
2.4 THE V-LIFE CYCLE .......................................................................................................................... 15
2.5 SYSTEM OF SYSTEMS .................................................................................................................... 17
2.6 SAFETY MANAGEMENT ................................................................................................................. 18
2.7 VERIFICATION AND VALIDATION ................................................................................................. 19
2.8 GATEWAYS AND AUDITS ............................................................................................................... 19
2.9 CONFIGURATION CONTROL AND CHANGE MANAGEMENT ..................................................... 21
3 REQUIREMENT MANAGEMENT PROCESS AND TOOLS ................... 22
3.1 PROGRESSIVE ASSURANCE ......................................................................................................... 23
3.2 FOR TENDERING ............................................................................................................................. 23
3.3 FOR PLANNING ............................................................................................................................... 24
3.4 FOR PROJECT MONITORING AND CONTROL ............................................................................. 24
3.4.1 ENGINEERING MANAGEMENT STRUCTURE ....................................................................... 26
3.5 ENGINEERING INTERFACE MANAGEMENT ................................................................................. 26
3.6 SUPPLIER MATURITY ..................................................................................................................... 28
3.7 SECTION SUMMARY ....................................................................................................................... 28
3.8 ROLES, RESPONSIBILITIES AND ACCOUNTABILITIES ............................................................. 29
3.9 RAILWAY SYSTEMS INTEGRATION PARTNER (RSIP) ............................................................... 29
3.10 TECHNICAL INTEGRATOR ............................................................................................................. 32
3.11 SECTION SUMMARY ....................................................................................................................... 33
4 TECHNOLOGY SOLUTION .................................................................... 35
4
4.1 INTRODUCTION ............................................................................................................................... 35
4.2 INPUTS REQUIRED FOR ETCS DATA CREATION ....................................................................... 36
4.3 NRT .................................................................................................................................................... 37
5 FORM OF CONTRACT ........................................................................... 39
5.1 PROPOSED FORM OF CONTRACT ............................................................................................... 39
5.2 CONTRACT CLAUSES .................................................................................................................... 39
5.2.1 GENERAL .................................................................................................................................. 39
5.2.2 CONTRACTOR’S MAIN RESPONSIBILITIES .......................................................................... 40
5.2.3 TIME .......................................................................................................................................... 40
5.2.4 QUALITY MANAGEMENT ......................................................................................................... 40
5.2.5 PAYMENT .................................................................................................................................. 41
5.2.6 COMPENSATION EVENTS ...................................................................................................... 41
5.2.7 USE OF EQUIPMENT, PLANT AND MATERIALS ................................................................... 41
5.2.8 LIABILITIES AND INSURANCE ................................................................................................ 41
5.2.9 TERMINATION .......................................................................................................................... 41
5.2.10 OPTION CLAUSES ................................................................................................................... 41
5.3 COST COMPONENTS ...................................................................................................................... 42
5.4 NEC4 VS NR12 TERMS AND PROPOSED ADDITIONAL TERMS ................................................ 42
5.5 SUPPLIERS APPROACH TO CONTRACT RISK ............................................................................ 43
6 MAINTENANCE CONTRACTING ........................................................... 44
6.1 BACKGROUND ................................................................................................................................ 44
6.2 MANAGING CHANGE ...................................................................................................................... 44
6.3 MAINTENANCE SCOPE ................................................................................................................... 44
6.4 SPARES AND REPAIRS .................................................................................................................. 45
6.5 CONSIDERATIONS FOR THE SPARES SCOPE ............................................................................ 45
6.6 TECHNICAL SUPPORT .................................................................................................................... 46
6.7 TECHNICAL INVESTIGATION ......................................................................................................... 46
6.8 TESTING EQUIPMENT, SPECIAL TOOLS AND TRAINING EQUIPMENT .................................... 46
6.9 MANAGING OBSOLESCENCE........................................................................................................ 46
6.10 NETWORK AND CYBER SECURITY MANAGEMENT ................................................................... 47
6.11 KEY PERFORMANCE INDICATORS ............................................................................................... 47
6.12 RELIABILITY TARGETS AND PERFORMANCE ............................................................................ 47
6.13 MAINTENANCE REPORTING .......................................................................................................... 47
6.14 TENDER FORMAT ............................................................................................................................ 48
7 RISKS AND CHALLENGES .................................................................... 50
5
7.1 CULTURAL CHANGES .................................................................................................................... 50
7.2 SYSTEM OF SYSTEMS .................................................................................................................... 50
7.3 SYSTEMS AUTHORITY .................................................................................................................... 50
7.4 TECHNICAL CHANGES REQUIRED ............................................................................................... 51
8 CASE STUDY: MOORGATE – NORTHERN CITY LINE RENEWAL ...... 52
8.1 BACKGROUND ................................................................................................................................ 52
8.2 CONOPS ........................................................................................................................................... 52
8.3 CLIENT DELIVERY TEAM ................................................................................................................ 53
8.4 ENGINEERING STRUCTURE .......................................................................................................... 54
APPENDIX 1 ................................................................................................. 56
6
EXECUTIVE SUMMARY
The Interim Joint Development Group (IJDG) Moorgate Project Team has analysed the problem statement to
determine whether using an Outcome Based Specification approach can facilitate a different project delivery
model. The IJDG Project Team used the proposed Moorgate: Northern City Line Renewal as a case study for
the deployment.
To realise the Digital Railway vision requires the complex integration of technology, processes and people and
focus needs to be given equally to each to ensure success. The need for the delivery team to manage across
the business (i.e. train operators, maintainers, TOCs, etc.) as well as manage the technology supplier requires
a different approach.
The key issues include:
• Digital Rail technology requires integration between the technology and the people and process that is
significantly greater than for traditional railways.
• Introduction of new technology means that there is a shift in knowledge base to the suppliers and their
products.
• Over specifying complex integrated solutions would restrict the supplier’s ability to apply products and
to innovate.
• A systematic rather than a prescriptive approach to project delivery is required.
Outcome Based Specifications enables focus on what is important to the success of the project which can be
lost during the project lifecycle. The requirements set should be as well defined as possible to allow innovation.
However, the constraints within the contract must also be carefully considered. With the supplier taking on more
responsibility, they must be cognisant of being able to demonstrate that the requirements have been met in a
complex regulatory environment.
The IJDG Project Team supports a new thin client organisation that is responsible for the system integration
with the System of Systems and the stakeholders. Responsibility for technical integration will be transferred to
the supplier.
During the transition there will be significant risk resulting from managing new technology deployment within a
new organisation structure. New processes will need to be introduced which would require practical application
rather than strict adherence. Resistance to change can also be expected.
A review of the technical issues arising from the deployment of ETCS is considered in the report including the
need to have accurate site data and the interface with NRT who will be required to provide GSM-R technology
to the project.
The NEC4 contract is considered to be an appropriate vehicle for the new delivery strategy and with the
recommended amendments can be used to manage the risks of the new structure whilst providing incentives
to the suppliers in key areas. This includes arrangements for the long-term management of the system.
The Moorgate Northern City Line ETCS Renewal is a good opportunity to assess the performance of a new
contracting model. The project is over a small geographic location but includes the complexity of an integrated
solution including ETCS trackside and onboard as well as a transition point and tunnel operations.
7
The Panel recommends that for Moorgate, an Outcome Based Specification (OBS) is considered with a suitable
project delivery team model. Several recommendations made in this report should be considered for further
assessment to enable this strategy to be successful.
Key Recommendations
Recommendation Document Reference
OBS is a suitable project delivery model for the Moorgate Northern City Line Project
Section 8
NEC4 Contract with amendments is a suitable vehicle for contracting OBS Section 5
Progressive Assurance with Audits and Gateways to be deployed for Moorgate Section 3.1
Business Change Management Team for initial projects Section 7.1
New Job Titles in the new organisation to enable cultural change Section 7.1
Physical Railway Configuration Data needs to be improved Section 7.4
NRT collaboration with the Technical Integrator (TI) Section 7.4
8
1 Introduction
1.1 Joint Development Group (JDG)
Building on the lessons learned from the previous Early Contractor Involvement (ECI) work streams combined with an industry specific benchmarking exercise, the Digital Railway Programme (DRP) developed the concept of a Joint Development Group (JDG). The JDG seeks to leverage the breadth and depth of technical competencies that exist in the supply chain to inform a diverse industry opinion and respond to novel and ambiguous problem statements that emerge within the Digital Railway Programme. The core concept behind the JDG is to bring together a community of suppliers with a wide range of skills and capabilities, each able to be called upon/invited to support the DRP’s development activities. This new way of working allows the DRP to utilise the diversity of thinking from the supply chain on a variety of problem statements. For the remainder of CP5, the JDG will be in its interim phase (IJDG) during which the concept and operating model will be validated prior to a solution being locked in CP6.
1.1.1. THE COMMISSIONING PROCEDURE
The diagram below shows each step with descriptions.
Figure 1: JDG commissioning process
1.2 Project Background and Problem Statement The London North Eastern Route (LNE) and the Franchise Govia Thameslink Railway (GTR), in conjunction
with Digital Railway (DR) are considering the roll out of a European Train Control System Level 2 Baseline 3.4.0
(ETCS L2). This rollout will be without lineside signals, on the Northern City Line between Drayton Park and
Moorgate stations (route hereafter referred to as ‘Moorgate Branch’). The implementation scope also includes
the necessary sub-systems to operate ETCS L2, such as Radio Block Centres (RBC), Global System for Mobile
Communications – Railway (GSM-R), balises etc.
Customer will approach JDG core management team with a problem statement. The JDG work with the customer to convert the problem statement into a capability request.
The core management team will issue the capability request, evaluation criteria, submission form and NR03 construction services agreement via email
Instructions regarding the submission process will be included in the capability request email. Suppliers will be asked to populate a submission form
JDG core management team use a simplified process whereby only submission forms are evaluated. There will be no interview component
All competing suppliers will be notified of the evaluation outcome and awarded suppliers will be issued an NR03 construction services agreement for execution. A kick off meeting is convened to capture deliverables and assign responsibilities.
9
Through this commissioned piece of work DR wants to continue exploring the ‘thin client’ approach, whereby
the DR organisation itself operates leanly, relying on its partners and suppliers for delivery support. One way of
achieving this is through Outcome Specification based procurement, and more specifically, Outcome
Specifications when developing a future Invitation To Tender for the Moorgate Branch ETCS L2 rollout
described above.
Based on collective experience of suppliers and the information to be delivered, working on this project, DR had
the aim of understand what procedures suppliers envisage may need to change within, to support an Outcome
Specification document. This includes identification of inputs and level of data quality required along with a
methodology for change, to create a robust suite of Outcome Specification documents for the Moorgate Branch.
This suite of documents will support the LNE/GTR/DR plan to roll out ETCS Level 2 across the East Coast Main
Line.
1.3 The IJDG Project Team The IJDG Project Team working on the Moorgate problem statement included Subject Matter Experts from
around the industry, working collaboratively alongside the Digital Railway Programme customer to develop a
solution. The Moorgate organogram and key are below.
Figure 2: Organisation
Digital Rail Team
Supplier Community Team
Core Management Team Graham Lawrence
Project Manager
Ben Lane
Regional Commercial Manager, Siemens
Andrew Woods
Senior Systems Engineer, Siemens
Simon D’Cruz
Chief Engineer, Atkins
Keith Atwood
Professional Head of Signalling, Alstom
Dan Holder
Problem Statement Owner, Programme Engineer Manager
Pareisse Wilson
Project Manager, IJDG
Bernard Yeo
Project Engineer
Christos Panou
Senior Project Engineer
10
1.4 Key milestones
Figure 3: Key Milestones
1.5 Expected outputs The original brief included 9 expected outputs.
No Expected Output Output 1 What would an Outcome Specification look like and how should
this be presented in the tendering process for a DR Scheme of
this size?
The Outcome Specification is described in two key documents – the Concept of Operations and the Application High Level Specification (CRD). In Section 2, there is a description of how the Outcome Specifications will be managed through the V-Lifecycle. Specific consideration of the Moorgate project is given in Section 8.
2 How would current DR Practices and processes need to change?
.
The Engineering Practice and process would need to change to reflect the new contracting arrangements. Section 3 considers the implication of these changes
3 Given the shift to Outcome Specifications based procurement, how are the roles of DR and a Supplier impacted? Do new roles need to be defined? If so, what does this look like?
Sections 2 and 3 consider the implications on the roles of those involved in the development of these technologies. Newly defined roles of Railway Systems Integration Partner (RSIP) and Technical Integrator help to define the new responsibilities of the Client and Supplier and try to set out their respective involvements in the deployment process. Section 7 considers the risks and challenges of this new arrangement.
4 What is the role of DR and the Supplier in the delivery of outcomes and what would the assurance regime be?
Section 2 proposes a new regime of gateways and audits to replace the current assurance model.
5 Define the roles of System Integrator and Technical Integrator, how do they inform a deployment strategy given the shift to
Outcome Specifications based procurement?
Section 3 describes the roles of the RSIP and the Technical Integrator.
23 April, Kick Off Meeting
4 May, identified areas of expertise
for Problem Statement
22 May, finalisedoutcomes
8 June, final report submitted
11
No Expected Output Output 6 What are the asset and data requirements for a scheme this
size? What need to be included as part of the above?
The implication for the asset and the data requirements are considered in Section 4. Specific issues for the Moorgate Project are considered in the Case Study
7 How could performance be measured and compensated?
Section 2 considers potential methods of measuring the Supplier which could be developed into a payment structure
8 A view to whether the existing asset data need the quality
requirements of an Outcome Specification based procurement?
In Section 4 there is a description of the quality of data requirements for ETCS systems and how this can be applied to an Outcome Based Specification
9 What lessons learnt from previous tenders can be shared with DR?
The team has drawn from its experience and knowledge of other technology deployments to build this strategy for a thin client organisation using Outcome Based Specifications
1.6 Findings The JDG report concentrated on four key areas:
• How to develop and use Outcome Based Specifications through the project lifecycle
• The impact on the current engineering practices and the roles and responsibilities of the engineers
• The impact on the engineering specifically around the handling of data and the technical interface with
others
• The commercial and contractual implications of using Outcome Based Specifications
The Moorgate Northern City Line project has been considered as a case study and the specific findings have
been addressed separately.
12
2 Outcome Specifications
2.1 Introduction
In the Digital Railway, the stakeholders are predominantly the same as they are for conventional projects. There
will still be physical infrastructure; track, traction power, signalling, control centres, stations, passenger
information systems, performance monitoring/recording systems, all using a backbone communication network.
These systems will still need the supporting organisational structures for the day to day running of the railway
infrastructure operations department, Railway undertakings (TOC, FOC), Rolling Stock Operating Company
(ROSCO), infrastructure maintainer, rolling stock maintainer, route controllers, rostering clerks, timetabling
clerks. The conventional railway system allows each of these organisational structures to focus inwards towards
their own elements of physical infrastructure and procedures. The railway system operating as multiple discrete
sub systems, many of which have minimal interactions with the other sub systems around them, managed
through compliance with historically proven standards. Where sub systems are ‘connected’ information is
generally transferred as an information dump at predefined intervals to allow the other sub systems to extract
what they require and discard the rest. These interactions with others are out of necessity and generally for the
personal gain of the individual organisation. So, for example a train operator will liaise closely with a route
controller to recover their train pattern following perturbation because it minimises their customer (passenger)
discontent and places their rolling stock and train crews into the required locations to minimise onward delays
caused by rostering issues such as rest periods, competency, route knowledge, train maintenance schedules
etc. Whilst the route controller’s interests are to minimise financial penalties associated with attributable delays.
In the Digital Railway the core disciplines to control the railway will remain the same; the change will be upon
how these disciplines interact. The core sub systems being used to perform the day to day utilising available
and new technology will require a higher level of integration into the railway system.
This integration at the digital level will aid the railway in meeting the demands of the current and future population
demographic who have become reliant upon technology to provide anything and everything they ask. In the
railway system of systems this translates into the vital and non-vital systems required to operate the railway of
the future. But even here the boundaries will change, what is vital? The train control sub systems that ensure
the safe movement of trains (interlocking) or the traffic management sub system that plans train movements to
minimise conflicts at junctions and maintains a smooth throughput to meet the timetable?
In simplistic terms the needs of the railway users can be met by identifying the required functions and assigning
to the appropriate subsystem. The digital information transfer between these subsystems becoming critical for
day to day operations also creates a necessity for clear definitions as to what is required. As these system
interfaces become more complex and reliant upon on each other, the raw standard compliance approach
becomes untenable. The System of Systems must therefore be represented as explicit requirements,
characterised and assigned to sub systems and / or interfaces. The traditional engineering structure applied to
project delivery following standards compliance approach fails to meet the future needs and the engineering
structure and roles need to be manipulated in the system of systems.
Requirements Management are the activities that ensure requirements are identified, documented, maintained,
communicated and traced throughout the life cycle of a system, product, or service.
13
The result of requirements engineering is a hierarchy of requirements that:
• enables an agreed understanding between stakeholders (e.g., acquirers, users, customers, operators,
suppliers)
• is validated against real-world needs,
• can be implemented provides a basis of verifying designs and accepting solutions
For a contracting strategy, that is based on Outcome Based Specifications where the responsibility for the
detailed design relies on the supplier to assure their works there is a need for a requirements management
driven strategy.
Furthermore, the client team can also focus on assuring the outcomes of the project are satisfied and
demonstrating those outcomes to the client and the stakeholders. This change in focus removes them from
obligation of checking the suppliers’ works as they are assured that works is being satisfied through the reporting
generated by the requirements management systems.
A robust requirements management system that is integrated into the project delivery, technical assurance and
reporting systems should provide the degree of satisfaction required to assure clients, stakeholders and
designers alike that the right products are being delivered.
2.2 Thin Client Engineering Model
The traditional supplier project delivery assurance model as depicted in
Figure 4 predominantly focuses effort towards the supplier. Engineering assurance is achieved at project level
through the client organisation conducting detailed analysis of design deliverables required by the supplier to
construct and verify the build status of the end solution. The acceptance reviews are based on confirming
compliance with standards and procedures, clients’ needs being considered satisfied if the installed end product
is compliant.
Figure 4: Current NR Signalling Engineering Model
In the Digital Rail environment, the system interactions will only provide the required benefits if they are clearly
defined. To be clearly defined they must first be identified and captured. With clearly defined and measurable
system performance criteria and interactions, engineering assurance of suppliers can be tailored to utilise
different and more appropriate assessment techniques. The aim being to assure the delivery of the end solution
is progressing to plan and meets all achievable stakeholder requirements.
14
The Digital Railway engineering model therefore needs to place greater emphasis on identifying and engaging
with stakeholders to understand their needs and interactions, enabling them to be translated into clearly defined
requirements that can be developed into technical solutions. This in turn will allow for the transition from the
standards compliance engineering assurance process, to an outcome-based assurance technique. This
engineering management model requires greater effort in the direction of the stakeholder and relatively less
effort in the direction of the supplier, creating the ‘thin client’ model depicted within Figure 5.
Figure 5: Future Engineering ‘Thin Client’ Model
The ‘thin client’ model follows the consideration that the client’s effort would be better placed in managing the
higher-level interfaces and stakeholders to ensure that expectations are managed, and outcomes achieved
through ensuring whole system integration or System of Systems integration. The client therefore takes on the
role of ‘Railway System Integrator Partner (RSIP)’.
2.3 Defining Requirements The Digital Railway programme will affect the entire industry and there are several different stakeholders that
will be impacted by the new technology; each one
will have their expectations and perceived
overcomes. It is almost evitable that, whilst they
might all share the same overall ambitions for the
Programme, their specific needs may well be
contradictory or overambitious.
The Application Business Requirements (ABR)
will be developed to consolidate all the
stakeholder’s needs into a single common set.
Potential stakeholders in the ABR could include
DfT, RDG/FOCs, Supply Chain, TfL, RSSB, etc.
as depicted in Figure 6. The ABR describes the
outcomes that will be met by any given
programme or project.
The ABR can be generated using several different sources including; Client /Sponsor Brief, regulatory
requirements, stakeholder engagement workshops, standards, etc.
It is inevitable that the form of the input will come in different formats; maybe narrative, or, standards,
diagrammatic or a specific set of outcomes. These will be interpreted into the Concept of Operations (ConOps)
and the Application High-Level Outcomes (CRD). These documents transform the stakeholder requirements
into the application specific operational, functional and non-functional requirements. Once this process is
underway it will be necessary to conduct a series of workshops with the various users to ensure that the system
is being developed with their needs in hand.
ABRDfT
Trade unions
RDG/ RFG
Supply Chain
TfLRSSB
Maintainer
Operator
ORR
Figure 6: Stakeholders input into the ABR
RSIPStakeholder Supplier
EffortEffort
15
The requirements will also include for any assumptions or constraints that are ascertained as a part of the
stakeholder engagement processes.
2.4 The V-Life cycle The V-Life cycle (
Figure 7) is a model that is used to describe the process steps required to deliver Digital Rail project or
programme. The V-Life cycle provides us guidance on how we can execute projects in a sequential manner
whilst providing the framework for verification and validation to assure that the supplier produces the expected
outcomes. For the proposed contracting strategy, the V-Life cycle also provides the depth to which the client
organisation needs to step to undertake his verification and validation activities. This allows the client to focus
on the outcomes and demonstrates satisfaction of those outcomes to the client and stakeholders.
The Digital Railway Programme V-Lifecycle describes the process and reflects their delivery strategy.
Supplier s System Requirements Specification
(SRS)
Generic Source Information
DR Customer
Requirements Suite
Application
Concept of
Operations
(ConOps)
Application
Customer
Requirements
(CRS)
Application-
Specific
Engineering
Rules &
Standards
Route
Commissioned
and Track
Handed Back
Integrated
Route System
Installed
Components
Detailed Design and Production
Factory
Acceptance Tests
Integrated
System of
Systems
Application
Business
Requirements
Generic
Concept of
Operations
DR System of
Systems &
System
Requirements
Engineering Rules &
Standards
Final
Acceptance
Lin
ked
Compliance
Integration Tests
(RIDC Laboratory)
Integration Tests
(RIDC Test Track)
Integration Tests
(Route)
System
Maintained
and in
Operation
System
Decommissioned
Filtered Subset
Existing Level B & C
Requirements
(Initial Applications only)
Validation
Final Validation
Application
High Level
Outcomes
(CRD)
Application
System
Requirements
(RRD)
Application
Sub-system
Requirements
(DRRD)
Filtered Subset
Filtered Subset
Application
Operational
Test
Scenarios
Figure 7: ‘V’ Life cycle for Digital Rail projects
Due to the nature of the technology, the introduction of a DR solution cannot be considered in isolation. Generic
Concept of Operations and System and Subsystem Requirements Specification set out the overall requirements
and these will be considered as inputs to the requirements capture process too.
The supplier will be expected to work with the client to develop System Requirements Specification (SRS)
derived from the Application Customer Requirements Definition (CRS) and the Application System
Requirements (RRD) that addresses the Application Concept of Operations and ABR whilst adopting the
technical requirements as specified in the generic documents.
16
This allows for tailored solutions to be realised that are based on the specific project demands, the supplier’s
technology and the contracting strategy. The requirements for these solutions are captured and the variances
to the Generic are understood and managed under configuration control processes. This allows the Network
Rail team to;
• implement the best solution for the given application,
• understand where projects have varied from the generic, and,
• adopt best practice from projects and improve the generic.
To ensure that the overall DR solution can be integrated as a “System of Systems”, it will be essential to ensure
that the mandatory or common integration requirements are well defined and controlled to ensure that different
projects can be interoperable.
Assurance has traditionally been undertaken by continual design checking, reviews and approvals. However,
this is more difficult to do where the technology and the tools that develop the technology are automated and
software based. Furthermore, Digital Rail technology is a fast-developing forum where solutions are complex
and integrated in data. The solutions are driven by the supplier’s technology and that is where the expertise
resides.
It is, therefore, natural for the quality assurance to revert to the supply chain as they retain the expertise and
knowledge of their products. The client still needs to assure themselves of the solution, but need to look at
different approaches.
Figure 8: Relationship between the RSIP and the Technical Integrator
The adoption of a ‘thin’ system integration team requires the assurance paradigm to change. Both the Railway
System Integration Partner (RSIP) and the Technical Integrator must have confidence in the requirements
management process and in each other to perform the tasks that exist within their domain. The RSIP can choose
17
to check certain key deliverables to ensure the quality of the outputs are assured. The level and depth of
checking should be set out at the beginning of the arrangement, but be assessed on a periodic basis (i.e. at the
gateways) to determine if the right level of surveillance is suitable. However, the Technical Integrator will retain
the primary responsibility for the design process. The use of audits to assess the overall quality of the outputs
can be conducted to retain the ability to assess the work being undertaken at the bottom of the ‘V’, but these
audits should be focussed on enabling the project to proceed rather than a mechanism to ‘check-up’ on the
detail.
During the detailed design and development stages, the supplier will be expected to demonstrate that they are
conducting verification and validation exercises to the client. The client team will not be actively involved in these
processes.
The RSIP can use several techniques during the project to assure themselves, including verification tests that
can be conducted at each stage – i.e. do all the parent requirements have child requirements? Are there
orphaned requirements? Has the parent been reasonably defined?
The requirements management tool provides the ability to connect parent requirements to children
requirements. It is reasonable to assume that the relationship between a parent and their children is a one to
many one.
2.5 System of Systems The development of application specific solutions will need to be carefully managed to ensure interoperability
with other DR projects. The generic specifications provide both the architecture and the requirements needed
to ensure the various projects can be effectively integrated into the System of Systems (SoS).
Some of the objectives of the DR SoS generic design are to:
• Successfully deploy an integrated and repeatable train command, control and safety system on GB rail
network including
o Traffic Management System;
o Connected-Driver Advisory System;
o ETCS Trackside, incorporating equipment trackside for Level 2 (no signals), modern interlocking
technologies, and trackside equipment necessary for fitted trains running elsewhere on the GB rail
network
o ETCS Onboard
• Provide the framework to ensure that all DR delivery activities are aligned against a common understanding
and baseline architecture (i.e. maintenance, operations, engineering, people and process etc.);
• Provide a foundation for enabling the systems to be configured;
• Automated control of train paths derived from a planned time-table, and
• Increased service reliability and the potential for increased capacity and performance (subject to the
specifics of the deployment)
18
Business Systems
IXLSCWS
Central (STW)
SCWS Portable
(STW)
Trackside Objects
TM
GSM-R Data
FTN(X) EULYNX
SCADA
DRACAS
Digital Railway Programme
TM Protection (Portable)
CA
Trackside objects include level crossing control, train detection, lineside signals where fitted, remote monitoring, TPWS, trackside train monitoring systems etc.
Business systems include operational and business
systems e.g. TRUST, TOPS, Stock & Crew, TD Data etc.
Voice comms includes GSM-R
Voice system and lineside telephony
CCTV
Onboard systems
Voice Comms
CTI
Infrastructure and Onboard
Data Hub#
Trackside Maintainer
Onboard Maintainer
Trackside Operator
Onboard Operator
KMC
TM CCTV inputs include for level crossings, tail lamp
detection, sidings capacityETCS
TracksideETCS
Onboard
COMPASS Central
COMPASS Trackside
COMPASS Onboard
C-DAS Trackside
IM
C-DAS Onboard
C-DAS Trackside
RU
ATOOnboard
LINX
ATOTrackside
Figure 9: System Architecture
Figure 9 is the system architecture for the digital technology solution and demonstrates how the systems will be
integrated to ensure interoperability of systems.
As each project develops their Customer Requirements Definitions that are based on the Generic Requirements
and then tailored to the specific application, careful consideration needs to be given to preserve the generic
requirements such that the interoperability and integration of the project solution into the wider System of
Systems can be achieved.
This is a major challenge and should not be underestimated.
The need to meet challenging project delivery programmes will require the RSIP to make decisions on how to
achieve certain generic requirements that might not be aligned with the System of Systems approach. For
transformational programmes where the end state is not fully defined or understood the risk of deviation in
requirements is potentially high without careful management. This issue is further complicated by parallel
deployments of the Digital Rail solution all “learning” how to apply the requirements to their solution. Lessons
learned and good practice will need to be shared across the industry to ensure that the System of Systems is
realised.
2.6 Safety Management The hazard records that are generated from the safety assurance process are key deliverables for any project.
It is important to be able to demonstrate the Control Measures that need to be applied to satisfy the safety
19
argument for the project was proven. The control measures can be considered as emerging requirements and
should be considered equal to any input requirements.
If the control measures are to be considered as
requirements, and, therefore subject to
attention, in our management process then the
source, the hazard log, could also be considered
as part of the requirements management
process. A robust Requirements Management
Tool can allow for the management of the
hazard log too. Traditionally the hazard log is
maintained in an excel spreadsheet which is
quite restrictive. By considering the Hazard Log
as an element of a database, the hazard data
becomes more usable.
Like the process for requirements capture, the
CRS can consider the control measures from
two sources; the applicable items from the generic
hazard log and the application hazard log. The hazards and the control measures can be decomposed into the
CRS and attributed so that they are marked as Safety Requirements. This effectively builds the Safety
Requirements Specification within the CRS document.
This process embeds the safety assurance work within the requirements management process. The control
measures will be treated the same as all requirements and follow the V-Life cycle process being traced through
the detailed design, implementation and testing regimes. The Application Operational Test Scenario will be
prepared to include tests that demonstrate the safety requirements so that team can witness and be assured
that these are satisfied.
2.7 Verification and Validation Requirements management provides a technique of tracing requirements through the life of the project. This
provides the ability to verify that the children requirements are satisfying their parents. The verification activity
requires expert attention to ensure that the requirements are being satisfied correctly. This is especially
important where the requirements are complex with one to many relationships.
Where the traceability is being undertaken by the suppliers, the client organisation is reliant on their work being
undertaken correctly. The client organisation needs the supplier to assure that the requirements are being
satisfied during the detailed design and development phase.
2.8 Gateways and Audits There will be a need to ensure that the project is progressing according to plan and that the requirements are
being well defined and assured in the design and development phases. The use of audits and gateway controls
are the best approach.
Audits will be used to assure the requirements process is being conducted in an appropriate manner. The audit
should be seen as an opportunity to evaluate the evidence within the requirements database. The objective will
be to demonstrate that the supplier is developing the solution correctly. Where deficiencies may be found the
audit team and the supplier will agree corrective actions that can be enabled as part of the next phase of works.
Applicaton Hazard Control
Measures
Generic Control
Measures
Safety Requirements
Figure 10: Managing control measures as requirements
20
Audits will be conducted during the lower part of the ‘V’ Lifecycle where the supplier is wholly responsible for
the process.
Gateways shall be conducted at key points in the project where the client needs to ensure that the technology
is being deployed correctly, i.e. critically when the systems are being brought in to trial service or into operation.
Gateways will be used by the supplier to demonstrate to the client and stakeholders that the solution meets the
requirements. To ensure that these Gateways operate in a pragmatic and progressive way, the prioritisation of
requirements needs to be made at an early stage in the project. The Gateways will be led by Gateway Managers
whose role will be to focus on the key requirements that affect that gateway.
The client needs to be assured that the supplier has completed the works and that is satisfactory to pass to the
next phase of the project subject to agreement on action/mitigation plans that need to be implemented to
address any open issues that are identified.
Gateways are conducted to ensure the project is sufficiently developed / mature to move to the next delivery
phase. The gate process should commence during the initial phases of the project development through to final
handover and closeout. Early gates should be used to identify the gate stages applicable to a project and identify
the key deliverables and maturity level of the deliverable required at each phase to ensure the project risks and
expectations are managed. The gateway review should be conducted by a person independent of the direct
delivery of project but with sufficient understanding and knowledge of the project to ensure potential issues are
identified. The independent person should also be empowered to agree targets and mitigations against any
deficiencies identified during the gate review process.
Requirements Assurance Lifecycle – the following diagram sets out a possible path through the project
lifecycle and where gateways and audits could be inserted to assure the input requirements are being satisfied.
For the Digital Railway programme this diagram will be multi-layered as the deployment will include multiple
strands that need to be met for a brown-field implementation.
Figure 11: Proposed Assurance Lifecycle
The proposed Requirements Assurance Lifecycle includes 6 steps. It will be important to consider alternative
gateways depending on the application, i.e. additional gateways for system modelling, test track running, etc.
G1 – Tender: The client and sponsor agree the ABR, Application ConOps and the Application High Level
Outcomes. Depending on the nature of the project, this Gateway could include other stakeholders such as the
DfT, RDG, TOC, etc. This is a Gateway for the client to demonstrate to the sponsor and stakeholders that their
requirements as defined in the ABR have been properly defined and understood. By including the Stakeholders
21
in this stage, we are ensuring their engagement with the high-level requirements. This is a Go/No-Go Gateway
that happens before the supplier is engaged.
G2 – Preliminary Design Gateway: with the finalisation of the supplier’s System Requirements Specification,
the client and supplier agree the exact requirements to be implemented by the project. It is also possible to
finalise other project matters, i.e. programmes, costs, etc. The Gateway is undertaken with the supplier and is
for the supplier to demonstrate that the requirements have been properly defined and understood. This Go/No-
Go Gateway allows the supplier to progress into the Design and Development phase.
G3 (s) – Supplier Design Audit (s): this is an audit of the progress being made during the detailed design and
development phase. The number and frequency of audits will depend on several factors, i.e. the duration of the
design and development phase, the sensitivity of the project and the maturity of the supplier.
G4 (s) – Pre-Deployment Audit (s): This audit is an overview of the solution prior to the system being
manufactured or installed on site. The number and frequency of audits will depend on several factors, i.e. the
duration of the design and development phase, the sensitivity of the project and the maturity of the supplier.
G5 – Approval for Train Running: This is a key Gateway where the supplier will demonstrate their system is
ready for dynamic train running. The supplier will need to demonstrate that the verification and validation of
requirements has been met including the client’s relevant testing requirements as defined in the Application
Operational Test Scenarios. This is a Go/No-Go Gateway that empowers the supplier to undertake dynamic
test running.
G6 – Completion: This is a key Gateway where the supplier will demonstrate that all the requirements have
been satisfied including all the requirements in the Application Operational Test Scenarios. This is a Go/No-Go
Gateway that allows for the final handover of the system. It should be noted that this will happen after the
operational handover which will be achieved by the normal handover/handback processes.
2.9 Configuration Control and Change Management Audits and Gateways also provide an opportunity to baseline the requirements. Baselining the requirements at
key points in the project enable multi-disciplined activities to work from a source of the truth with confidence that
they are working from the same condition. It also provides the client a baseline for reference.
Projects mature across time and new emerging requirements are to be expected and managed. New
requirements may come from the design and development process, from the safety assurance process and
other sources including change of stakeholder expectations.
Using requirements management to assess changes provides a systematic approach that can provide a holistic
view of how the change impacts the entire system. The change can be analysed by tracing both up and down
the requirements path and across the affected areas to ensure that the impact of the change is fully understood
before it is implemented. Both the client and the stakeholder can have an agreed understanding of the impact
through this process.
As changes emerge throughout the project life it is important to re-consolidate the changes – this can be done
at the next baseline.
22
3 Requirement Management Process and Tools This proposal is based on integrating a solution that acknowledges the current working practice with tools that
have been used on mega projects to deliver a progressive assurance process that enables project owners to
take a holistic and pragmatic stance in the management of complex railway programmes.
The processes and tools described below have been successfully deployed on multiple overseas projects where
the client has a “thin organisation” which have relied upon using outcome-based specifications and minimal
national standards.
The ability to integrate the Requirements Management Database with the Electronic Document Management
System and the Progressive Assurance Tool is extremely powerful
Requirements Management Database: Traditionally in the UK, the DOORS database has been the “go to”
application for managing requirements. The database is a collation of requirements that can be linked together
to demonstrate that the design, implementation, verification and validation are aligned.
For complex and multi-layered projects, the need to understand how
requirements are being interpreted as the design matures through the
project lifecycle is both challenging and complicated. It is also essential
to understand to ensure the outputs realise the intended outcomes.
However, technical submissions remain a document driven process
meaning the Requirements Management is subservient to the
demands of a programme driven document submittal register.
Documentation that is not coordinated with the Requirements
Management database can contain many orphaned and unrealised
requirements.
Electronic Document Management Systems: Projects, invariably, are driven by documents. These
documents are registered in an Electronic Document Management System such as Enterprise Bridge (eB). This
system provides an electronic record of the deliverables, their versions and their history. However, these
documents tend to be isolated without practical links with other documents. Embedded requirements in these
documents can be lost, mis-acquired or deviate the results incorrectly.
Progressive Assurance Tool: The Progressive Assurance provides the ability to manage the requirements
assurance process. It can be used to capture assurance checking comments on the decomposition of
requirements and on documents. It provides clear traceability paths both upwards and downwards. Reporting
can be managed better, providing stakeholders clarity on their specific requirements, as well as providing project
delivery teams focus on the issues.
The combination of the three systems (system suppliers can provide more than one product within their system)
provides a framework for requirements to managed in a proactive and controlled manner.
By having a model that connects the three systems together we can ensure that the requirements in the
documentation are aligned with the requirements in the database. Changes in the documents or in the database
can be flagged in the progressive assurance tool for attendance and assessment. This approach provides the
ability to manage the configuration in a dynamic and proactive manner.
Using a web-based requirements management system provides suppliers (and their supply chains) the ability
to use the “live” database to undertake their requirements management activities. The client can observe the
Requirements Database
Progressive Assurance Tool
Document Control
Figure 12: RM Tool arrangement
23
progress remotely without the need for intrusive design review and checking regimes. There is still a need for
audits to be conducted but these can be planned at key stages in the project timeline.
3.1 Progressive Assurance As the ABR is outcome based it will be benefit driven in terms that can relate to the
various stakeholders. Using progressive assurance techniques, it is possible to take
the stakeholders on the same journey with full visibility of how their benefits are being
translated into design requirements through to delivered products.
By using the input documents as a baseline, the supplier shall develop the System
Requirement Specifications and then trace the relationship with the performance requirements. The relationship
can be one to one or one to many depending on the nature of the requirements.
By using a progressive assurance technique, the client can then monitor the development of the design and the
evolution of the client requirements in real time online. The client can be satisfied that the design of their
requirements is maturing through the design process without undertaking intrusive and time-consuming review
processes. Gateways can be established (as set out above) throughout the design process that checks the
maturity of the requirements rather than on the completion of design documents
Progressive Assurance has been proven to provide the client the ability to monitor the supplier’s work by
measuring compliance to the requirements rather than on the ability to submit documents. Focus can be given
to requirements that are not evolving allowing the client and supplier to trouble shoot better.
By giving the supplier the freedom to operate in the design domain it can improve the client-supplier relationship.
Governance becomes more than a simple measure of compliance adherence and thus removing some of the
unnecessary and irrelevant constraints that a compliance approach introduces.
3.2 For Tendering Traditionally tendering has been a process of reviewing tender submissions that
are provided in paper or electronic format. Even having a compliance matrix can
be difficult to follow or trace the requirements and therefore be assured that the
supplier has demonstrated that can achieve the requirements.
With a Requirements Management Tool (RMT), the system can be used as the
key tendering submission. The client organisation will prepare the tendering
specification requirements within a subset of the database which is issued to the
tendering parties.
The tenderers are then required to respond using the database demonstrating
how they will comply with the tender requirements.
The tender review panel then use the progressive assurance tool to evaluate the
tenderers responses, confirm compliance, comment and, where necessary,
raise Technical Queries.
Tender Queries can be issued in the database formatted format and responses can be received in the same
manner.
In this way, the tendering process can be well managed, configuration control can be maintained, and progress
can be easily demonstrated.
Tender Specification
Tender Response
Tender Review
Tender Queries
Figure 13: Tendering process managed by the RMT
24
3.3 For Planning Every requirement must be analysed to determine its prioritisation, its lifecycle and its verification and validation
(test) conditions.
The process of requirements analysis also provides a method of planning the requirements life.
Requirement prioritisation is the process of assessing the need; most projects consider whether the
requirement is mandatory (i.e. safety/operation critical), preferred, or optional. Prioritisation allows the delivery
teams to focus on the key requirements to ensure that the project can be successfully handed over to operations.
This is important on complex projects where there are 10s of thousands of requirements to be analysed, traced
and assured.
Every requirement has its
own timeline. That is to
mean that requirements
can be assured at different
times in a project lifecycle.
Predominately,
requirements tend to be
validated during the
testing phase, but some
could be assured in the
design phase,
manufacture or the
installation.
Overall, we can generate
a Requirements Lifecycle
Model that describes the
completion of all the requirements. This model describes when the requirements are completed and does not
reflect the actual effort conducted in the requirements management exercise. It is therefore sensible, to weight
effort for all the requirements (i.e. weighting for requirements could be based on the current DR model design
of 50%, 95% and then at completion of the testing).
We can now monitor the project using two ‘S’ Curves; Requirements Lifecycle Model and Requirement Effort
Model in mapping requirements. The first provides a measure of the progress to actual completion and the
second provides a measure of the value of the work undertaken.
These requirements management techniques provides another tool to the project in planning the works being
undertaken.
3.4 For Project Monitoring and Control Progressive Assurance is designed to enable the engineers in both the client and supplier’s organisation to
focus on the system engineering solution. The system provides the tools for tracing the requirements through
the project life cycle. It also provides the ability to review and comment in a controlled place.
Design Reviews: Projects will continue to deliver requirements in document formats for the foreseeable future.
These documents can be uploaded into the progressive assurance tool and compared to the requirements
management database. Compliance can be assessed and where comments required they are generated within
Manufacture/Install
System Test
Dynamic TestDesign
Progress %
Effort weighted progress S Curve
Requirement Lifecycle
Completion
Project Lifecycle
Figure 14: Requirements driven 'S' Curves
25
the tool. Reviews are therefore linked to requirements and are contained with the Progressive Assurance Tool
providing a permanent and traceable record of the assurance process.
A requirements traceability record can be a particularly powerful tool when demonstrating the safety assurance
process to others such as the ISA or the regulator.
New versions of the documents can be reviewed in the same system and updates that have resulted from
review can be assessed in the system.
Progress: using requirements management to monitor the progress can be a useful project management tool
that can be used alongside the more traditional progress matrices. The ‘S’ Curves are just some of the reports
that a progressive assurance tool can generate. As the system is “live” it can provide daily, weekly or monthly
reports that can be optimised for the audience, i.e. stakeholder specific progress reports that focuses on the
specific stakeholder and their needs.
Benefits Driven Programmes: with technology projects there is an opportunity to manage the delivery
programme based on delivering benefits rather than delivering products. By understanding what functionality
provides what benefits we can judge what value can be had from providing them early. This type of programme
strategy can only be considered in specific projects such as traffic management systems where the functionality
can be achieved in a more staged manner rather than ETCS where the requirements requires all products to
be realised at the same time.
Managing Innovation: Digital Rail takes advantage of new and emerging technology to deliver solutions. The
delivery strategy needs to be open to the continued innovation in new technology to ensure the most appropriate
solutions are realised.
Managing requirements progressively allows the delivery team to “innovate” by defining those requirements that
are mandatory and those that can be innovated. Programmes can then be developed so that the innovation
requirements follow different timelines to the mandatory ones. Separating mandatory and innovative
requirements means the delivery of the core functionality can be focussed on and assured to achieve the
schedule whilst allowing the design teams more time to innovate and create solutions that meet the emerging
requirements.
26
3.4.1 Engineering Management Structure
The Digital Railway introduces a need for greater interaction between track and train. To realise the railway
system benefits required for the future, these systems need to be highly integrated.
The current Network Rail signalling project delivery structure focuses heavily upon re-assessing the finite detail
of the supplier’s deliverables, in particular the application design. The complexity of the system interfaces using
software and application data makes this traditional approval process (design/check/review/approve) ineffective
in assuring the sponsor that the high-level safety, functional and operating requirements are being fulfilled.
The engineering assurance model required for corporate governance must therefore change to ensure that
suppliers are providing a solution that meets the client’s needs. This model will need to apply different
techniques to provide this assurance with focus on moving towards measuring the supplier through
outcomes/outputs rather than through the constraints of standard compliance. The modified assurance model
will create a different engineering management structure focusing on the interactions between the project and
other stakeholders. This model is being referred to as the ‘Thin Client’.
3.5 Engineering Interface Management
The thin client model presents a single supplier interface to the client. In practice this model would be extremely
limiting and contrary to the client procurement policy. The key elements of the Digital Railway (TMS, ETCS
Trackside, ETCS Onboard, Communication network) may be procured from multiple suppliers. This creates a
further consideration as to how the engineering interactions between multiple suppliers can be managed. The
solution must ensure that the technical skills within each supplier organisation work effectively together to
achieve the final integrated Digital solution.
Network Rail’s Engineering Management for Projects process (NR/L2/INI/02009 Issue 6) provides three
engineering interface management structure models (options 1-3). The three models are based around the
responsibility for design integration. Recent IP signalling renewals projects have applied a hub and spoke
contracting model with Network Rail managing the interfaces and acting as the design integrator, this is
represented as option 2 within the standard.
Option 1 [Figure 15] and Option 3 [Figure 16] align with the ‘thin client’ approach where the supplier Contractors
Engineering Manager (CEM) takes responsibility for the integration of the multi discipline designs. The two
options allow for different contracting arrangements, with option 1 covering the single source option whereby
the supplier is contracted to undertake all discipline activities, while option 2 permits Network Rail to contract
individual disciplines directly but appoints one supplier as the design integrator. Using the existing management
models within the thin client structure the traditional CEM role will be a ‘Technical Integrator’ for the activities
within their work scope. The Technical Integrator (supplier) will become responsible for conducting assurance
activities in line with their Quality Management System, allowing the RSIP to satisfy themselves that assurance
is being actively controlled/managed by receipt of supplier declarations and reports.
27
Figure 15 - Design Integration Model (extract NR/L2/INI/02009 Option 1)
Figure 16 - Design Integration Model (extract NR/L2/INI/02009 Option 3)
28
3.6 Supplier Maturity
The supplier maturity will dictate how closely Network Rail will need to monitor and interface with the supplier
in the discharge of their duties for corporate governance, legislation and regulation compliance. The engineering
model applied needs to ensure that Network Rail is executing its duty to adequately manage safety and business
risk.
A justifiable method to support Network Rail’s decision to discharge some of these duties to the supplier under
the thin client model could be based on a predetermined supplier maturity level scoring or ranking. The ranking
system could be based on external body supplier qualification schemes such as Railway Industry Supplier
Qualification Scheme (RISQS) and Capability Maturity Model Integration (CMMI). Network Rail would use this
pre-assessed ranking to supplement a maturity level verification process at tender pre-qualification or during
the formal tendering process. This will allow Network Rail to execute an appropriate level of control, scaling its
engineering delivery team commensurate with the risk, complexity and novelty, as appropriate and forming part
of Network Rails Assurance process for level 2 – Corporate Oversight.
The application of a maturity model-based approach to engineering assurance, taking cognisance of the
maturity and experience of the supplier / suppliers within the GB mainline railway and Digital Railway
frameworks, allows for a scaling of the client team based on the supplier’s experience. The use of a supplier
maturity assessment also provides Network Rail with a mechanism to introduce new suppliers into the GB
railway market to ensure competition is maintained through the procurement chain. The new supplier having a
potentially lower maturity rating requires an increased level of effort for monitoring/review to achieve client
confidence in the supplier’s assurance process.
Figure 17 – Immature Supplier Engineering Assurance Model
The Project Engineering Management plan should be used to record the supplier maturity level and define an
appropriate Network Rail Engineering structure to manage the corporate risk.
3.7 Section Summary
The use of NR/L2/INI/02009 Issue 6 options 1 or 3 appears to provide potential models to implement the thin
client / supplier engineering interface. A supplier maturity assessment should be considered as this will provide
an indicator as to the level at which Network Rail can discharge its duties to the supplier whilst maintaining its
legislative obligations and satisfying corporate governance requirements.
Further consideration, whilst NR/L2/INI/02009 Issue 6 provides options that can be applied, the use of an
existing process may lead individuals to follow previous behaviour and overly focus on assuring the supplier’s
deliverables. For this reason alone, the production of a new or revised standard may be appropriate as this is
likely to create the desired new behaviour. Alternatively, the Project Engineering Management plan could be
subject to high level senior review to ensure the engineering assurance process is clearly defined and satisfies
Network Rails corporate governance requirements.
RSIPStakeholder Supplier
EffortEffort
29
3.8 Roles, Responsibilities and Accountabilities
The Digital Railway thin client engineering management structure will evolve around two key defined roles:
➢ Railway System Integration Partner (RSIP)
➢ Technical Integrator
These roles will take the lead in ensuring the technical solution fulfils the requirements for the system of systems,
meeting the safety and functional requirements. They will also retain responsibility for executing engineering
assurance activities to comply with legislation and corporate governance.
3.9 Railway Systems Integration Partner (RSIP)
The RSIP will be a role within the refined engineering structure with a focus on the greater railway system
(System of Systems). Responsible for ensuring the technical requirements of stakeholders are clearly defined,
captured and satisfied. The specific duties of the RSIP will align with the contracting model and supplier maturity
to ensure that Network Rail’s duties and obligations as required by legislation and governance polices are
adequately executed. However, the RSIP’s focus will be on ensuring that stakeholder interfaces are defined
and managed to ensure whole system
integration.
The stakeholder interactions and interface to
the sponsor shall be detailed within the
project engineering management plan.
The RSIP may need to execute some or all
of the duties of the DPE role as defined
within NR/L2/INI/02009, where these have
not been discharged to the Technical
Integrator. This shall be detailed within the
Project Engineering Management plan.
The RSIP should contain a Lead Engineering competence and be appointed.
The RSIPs key technical duties could include:
➢ Act on behalf of DRs Systems Authority as the system authority for the System of Systems
o Owner of project engineering management plan
o Define the NR engineering structure based on the maturity of the supplier & baseline solution.
o Act as registration entity - updating of each European Union Member State’s National Vehicle
Register (NVR)
o European Railway Agency (ERA) project register (one stop shop)
Figure 18 –RSIP’s Interactions
Stakeholder
System
Integrator
Independent
Assessor
Regulatory
Body
Route
Sponsor
Technical
Integrator
(Supplier)
Others
Railway
Undertaking
30
o Act as Sponsor for Product Acceptance
o Manage the Asset Management Plan
o Develop IM and RU compatibility tests
o Production of Technical file
o Appoint lead Technical Integrator
o Technical Change Control Management
o Manage System Baseline
o Infrastructure data management
o Manage open points and deviations with combined SRS
o Key contact between projects with responsibility for ensuring integration
o Identify performance indicators in conjunction with the project manager
o GB ERTMS National Identities project co-ordinator
o GB ERTMS KMC key co-ordinator
o Lessons Learned are feedback in to the DR team
o Certify the System Solution
➢ Legislative Compliance - Network Rails duties under the regulations are satisfied.
o CDM compliance
o ROGS compliance
o TSI compliance
o NTR compliance
o CSM compliance
o HSE – ensure suitable and sufficient risk assessments are completed
➢ Corporate Governance
o Maintain a level of technical governance, although reduced to fit thin client model based on the
supplier maturity.
o Define Engineering Verification Plan NR/L2/RSE/070 Issue 2 – the verification plan shall specify
the split between supplier self-assurance and Network Rail engineering assurance activities.
o Conducting supplier Assurance activities. Based on NR/L2/ASR/036 Issue 5 Network Rail
Assurance Framework Level 1 and NR/L2/SIG/10027 Issue 4 for Surveillance of Signal
Engineering Activities. Note this should be based on the supplier maturity model and limited to
performing spot tests on the supplier rather detailed deep dives. Activities such as site
surveillance may be satisfied through review of supplier’s own records.
o Identify / define whole system level integration requirements
o Define system level integration points. This should be commenced during specification phase
to ensure all stakeholders are identified, consulted and requirements captured.
o Support Project Manager for technical gate reviews
o Support Project Manager in defining a regime for monitoring key project integration milestones
o Manage technical approval process for elements identified within the Project Engineering
Management plan.
➢ Stakeholder Technical Interface
o Identify / define stakeholder interfaces with sponsor
o Identify / classify technical interfaces between stakeholders
o Act as technical contact for sponsor stakeholder interactions
o Assist client in defining and specifying technical elements of the CRD
31
o Ensure stakeholders are advised of/aware of training requirements
➢ Tender Support
o Current pre-contract award DPE duties as defined in NR/L2/INI/02009 Issue 6 will need to be
retained by the RSIP
o Endorse contract technical work scope
➢ Requirements Capture / Management
o Manage requirements outside of the supplier’s remit.
o Selection and gap analysis of Generic source information (concept of operations, System of
systems requirements, Engineering rules & Standards)
o Prepare relevant technical requirements for inclusion in contract
o Capture stakeholder requirements and ensure clearly defined (Customer Requirements
Specification)
o Assist in production of RRD
o Compile DRRD
o Identify and define expected supplier outcomes and measurement criteria from combined SRS
o Align stakeholder CRS with Digital Railway RS and Route RS
➢ Change Control
o Manage changes to stakeholder requirements
o Facilitate the resolution of issues within the defined requirements, deviations and non-
compliances with the requirements.
➢ Safety Assurance
o Appoint Safety Assessor
o Agree safety assurance process and CSM models to be applied.
o Accept Safety-Related Application Conditions (SRACs) exported by supplier
o NoBo / DeBo interface
o Confirm that adequate assurance has been undertaken to take the system into use.
➢ Pre-supplier appointment
o Act as Technical Integrator
➢ Project RSIP Handover to Route Asset Manager (RAM)
o Transfer system performance requirements to RAM
o Verify outcome criteria satisfied / identify deviations
o Lesson learned outputs
o Authorisation to operate
o Warranty
The need for a Maintenance RSIP to manage the maintenance contract has not been considered in this
remit, but it may be of consideration in the future.
32
3.10 Technical integrator
The technical integrator
role may be performed by
an individual or a group of
closely interacting
individuals with a
nominated lead. The
technical integrator shall
be responsible for the
interactions between the
signalling sub systems and
this may be extended to
incorporate both the
trackside and on-board
sub systems dependent
upon on the contracting
strategy.
This role is likely to
execute the duties of a
design integrator and
CEM.
The technical integrator
organisation structure and
interfaces shall be detailed
within the Project
Engineering Management
Plan. It is expected that
each supplier / technical
integrator will develop their
own sub-system
Engineering Management
Plans which will act as
child documents to the
Project Engineering
Management Plan.
The lead technical
integrator shall be
responsible for ensuring
the functional interfaces
between signalling
subsystems are clearly
defined and functionally
correct. The role may include activities to
support the V&V process.
Figure 19 –System Integrator Interactions
Lead
Technical
Integrator
(Supplier)
CEM
CRE
Disciplin
e 1
CRE
Disciplin
e 2
CRE
Disciplin
e 3
Engineer
ing
Manager
CRE
Disciplin
e 1
CRE
NRT
Stoke
Tech
CORE
Control
System
ARS
TMS
Time
table
processo
r
C-DAS
Access
Node
Gauge
Engineer
Traction
System
Signallin
g
System
Depot
Maintain
er
Safety
Assuran
ce
Indepen
dent
Assessor
Product
Assuran
ce
Trackside
Technical
Integrator
Onboard
Technical
Integrator
Control
System
Technical
Integrator
Assessor
Maintain
er 2nd
Line
33
The Technical Integrator shall be nominated by the lead supplier and appointed by the RSIP.
Technical Integrator key responsibilities:
➢ Principal Contractor
➢ Subsystem Interface Act as subsystem design authority
➢ Subsystem integration
o Act as CEM including managing the self-assurance of all technical documents. The CEM, under
the NEC4 contract, would need to satisfy the Service Manager that the correct approvals have
been obtained to enter the system into service.
o Identify functional interfaces between physical sub systems i.e. CCS trackside, On board,
Control system / TMS and communication network.
o Ensure functional interface requirements are clearly defined and allocated to the relevant sub-
system
o Ensure sub system interfaces are subject to configuration management as required by the
engineering management plan.
o Lead Interdisciplinary checks and reviews (IDC/IDR) ensuring functional interface designs are
aligned, integrated and meet the defined requirements.
o Ensure tests are defined for testable functional interface requirements
➢ Ensure open points within sub systems / interfaces are managed
➢ Competence
o Appoint competent people to key roles identified within the Technical Integrators organisation
structure.
o Ensure key personnel within the technical integrator framework are formally appointed.
➢ Manage technical change.
➢ Put forward product acceptance
➢ Compile SRS
➢ Audit / surveillance checks
➢ Technical KPI reporting in line with supplier QMS
➢ Technical Query Management between Technical Integrators
➢ Technical Query escalation to RSIP
➢ Generating Engineering Compliance Certificate
➢ Manage and resolve construction issues
➢ Manage handover process to maintainer
➢ Define sub system training programmes
Further consideration will need to be given to defining these roles so that the contractual boundaries and
responsibilities are well understood. Contractual consideration needs to be given to the delegation of duties by
each party and how the technical authority can execute his works whilst engaging with suppliers that they may
have no contractual relationship with (i.e. train manufacturers). This has not been considered in this remit.
3.11 Section Summary
The RSIP and Technical Integrator will be the leading responsible engineers within the thin client model. The
RSIP role being held by the client organisation, whilst the Technical Integrator role is contained within the
supplier organisation. The detail of the responsibilities split will be based upon the level of devolution for
engineering assurance from the client to the supplier, which should reflect the maturity of the supplier within the
GB mainline railway environment. The project engineering management plan should be used as the vehicle to
34
define and record the engineering management structure applied to the project, thus ensuring that the detail of
the roles and boundaries are clearly recorded.
35
4 Technology solution
4.1 Introduction The use of ETCS Level 2 effectively mandates a specific solution architecture for the signalling system. An
ETCS level 2 system will consist of an Interlocking Safety Processor which is in close communication with the
Radio Block Centre. The Radio Block Centre generates Movement Authorities which are based upon the
geography of the railway and the availability of routes from the Interlocking. The Interlocking communicates to
the trackside assets (points machines and train detection) via the communication network (FTN) and the RBC
communicates to the ETCS onboard units via the fixed communications network (FTN) and the radio network
(GSM-R). This is shown in Figure 20.
.
ETCS OnboardETCS Onboard
InterlockingRadio Block
Centre
Control Centre
Trackside Assets
ETCS Onboard
Units
FTN/GSMR
Trackside Assets
Trackside
Assets
Figure 20 Signalling System Architecture
Figure 20 highlights the importance of the integrated communication system (FTN<>GSM-R) for the
communication between the Interlocking and Trackside Assets and between the RBC and ETCS Onboard Units.
Without reliable and timely access to the Network, the delivery of the ETCS system can be put in jeopardy.
As stated earlier the RBC generates the movement authority based upon route availability and geography of
the railway. The purpose of the movement authority is to provide information to the onboard unit to allow it to
calculate a safe movement and braking profile to ensure the safety of the train. Previously under traditional
signalling the location of the point at which the driver would begin braking was based upon the performance of
the worst braking train which could run on the line. With ETCS this braking position is calculated dynamically
36
for each train. This provides the opportunity for trains to be operated closer together (subject to optimising the
existing fixed block lengths for Level 2 systems) providing greater capacity over traditional signalling.
Extra capacity can be provided by increasing speed through sections as a result of reduced braking curves.
Block section length may also be reduced by using the characteristics of the worst braking train. Variations in
rolling stock will still be a constraint as the trackside design is only a facilitator to increasing capacity. A holistic
approach which considers the trains and the trackside is required to maximise the capacity gains that ETCS
can provide and to prevent safety events. Poor input data can cause the design tolerances to be so great that
any benefit is lost to compensating for those tolerances.
4.2 Inputs Required for ETCS Data Creation To deliver ETCS data of suitable quality and veracity the Infrastructure Manager needs to provide an accurate
3D geographical model of the physical railway (or allow for suppliers to generate their own).
This input includes media that enables the designer to determine the location of assets. It will include the location
of all physical assets in a form that is both human readable and electronically readable. Ideally, it will be available
in a visual form that enables the designer to check for logical inconsistencies. Ideally, it will identify the location
of assets in a datum plus offset format.
The geographical model will identify the location of:
• signals;
• track detection sections IBJ / Axle Counter Heads;
• point tips;
• gradients/spot heights;
• static(line) speed restrictions;
• buffer stops;
• platforms;
• balises;
• marker boards
The geographical model may also identify the location of:
• Low adhesion areas (LAAs);
• ESAs/ Signal Group Replacement Controls (SGRCs);
• Interlocking boundaries;
• RBC boundaries;
• Tunnel emergency exits This input forms the primary geographical input into the process. Hence, its correctness and control is vital. It
must contain geographical information covering all physical assets on the railway to a high resolution, potentially
in the order of 0.1m and to an accuracy of +/-0.5m for dense high capacity sections of the Railway. This level
of accuracy is required to ensure high performance ETCS operation. Lower accuracy data can be used but the
additional tolerance may reduce the performance of the ETCS system. Modelling of the performance required
and therefore the survey accuracy required may be undertaken prior to the survey beginning.
Surveying of gradient is important as an incorrect gradient measure could cause an overrun of an MA by a
protected train. Attention should be paid to accurate measurement of the gradient.
A secondary data source for verification of logic, completeness and correctness is also required. This needs to
be a diverse survey and must be entirely independent of the geographical 3D model. The required accuracy of
37
the secondary survey information is less than onerous than the primary geographical survey information. It shall
be accurate to +/-5m. However, its completeness and correctness is critical. This could be other documentation
such as Signalling Plans, Verification Surveys for other engineering domains such as Permanent Way or Civil
Engineering or drone surveys.
Following completion of the surveys it is vital that the railway configuration is managed. This is especially
important where other works are undertaken alongside ETCS implementation. Any changes need to be
identified and supplied to the ETCS supplier in order to keep the data model accurate.
As implementation of the scheme continues a feedback loop between design and implementation also needs
to be closed to ensure the ETCS data reflects the actual implementation of the system and to the above
accuracy. An example of this is siting of ETCS balises as per the design. This may be prevented due to other
equipment in the siting location. Any change in this location (even by a few metres) must be fed back to the
ETCS data design team to keep the data correct. This could be done using an ETCS test train running over the
area to ensure they are within the design window.
4.3 NRT As part of the Digital Railway thin client approach
it is proposed that changes are made to the
mechanism of contracting Network Rail –
Telecoms (NRT). Currently NRT is contracted to
Network Rail IP Signalling. This can create issues
in communication as all design work needs to be
passed via the IP Signalling team. These issues
can reduce the ability of the contractors and NRT
to collaborate efficiently and deliver the best
solution.
As part of the Digital railway proposals there is the
concept of the Technical Integrator. This role would be
undertaken by a major contractor. It is proposed
that Network Rail Telecoms would have a direct
relationship with the Technical Integrator. This
would allow direct communication between the
Technical Integrator and NRT. It is expected that
this would enable greater collaboration between the
two organisations, as well as communication to
ensure issues are resolved quickly and efficiently.
An issue may be around encouraging collaborative
behaviour in the relationship. The provision of a
service level agreement to formalise this
relationship may be a useful device.
A service level agreement could include the
following areas:
• Timescales for design work and reviews
this may include an agreed baseline programme
NRT
Technical System
Integrator
Railway System
Integrator
Figure 22: Proposed Project relationship
IP Signalling
Signalling Contractor
NR-T
Figure 21: Current NRT Project Relationships
38
• Attendance at Interdisciplinary Design Checks/Reviews
• Agreed inputs and deliverables.
• Availability of the provided FTNx services
• Integrity of the provided FTNx services
Previous collaborations between suppliers have shown that for it to be truly effective then collaboration needs
to be more than skin deep. A deep commitment between organisations is required to break down borders and
ensure team members engage with each other. It must be a true relationship with common goals and a desire
to meet those goals. Co-location of key staff to allow the building of relationships and to create a dynamic
problem-solving environment can help with this. Whilst a service level agreement can attempt to force
behaviours; true collaboration requires active engagement from all and can lead to a more successful outcome.
There may be scope for NRT to “sub-contract” design work for the FTNx solution to suppliers chosen by the
Technical Integrator. NRT would still be responsible for setting the constraints around the design such as
equipment used to ensure maintainability. The Technical Integrator may be able to use suppliers already in their
supply chain and to maximise that relationship to improve delivery quality.
As a national system the FTNx may also be subject to multiple simultaneous changes which can impact one
another. As the Infrastructure Manager NRT needs to be able to manage these changes in parallel and ensure
that conflicts do not occur. They would need to place requirements on the Technical Integrator as part of the
whole system integration piece.
39
5 Form of Contract
5.1 Proposed Form of contract
Digital Railway (DR) has proposed using the Design, Build and
Operate NEC4 contract for the Moorgate line and other DR works
on the ECML South. This contract shall be performed as a Design,
Build and Maintain contract with the current NR maintenance staff
maintaining as employees of NR. The current maintenance staff
may however be working under the instruction of the Contractor.
The following sections provide a supplier commentary on
questions and concerns that would have to be addressed during
or ideally before a tender was issued.
To ensure that an effective tender process is completed, it may
be of significant benefit to workshop some of the questions raised
below with the suppliers to reduce the number of TQ’s during the
tender phase, which could disrupt the tender process, before the
OJEU notice for the works is issued.
5.2 Contract clauses This section shall comment on the core clauses by category set out within the contract. This section should be
read cross referencing the NEC 4 contract.
5.2.1 General
Clause Commentary
11.2 (2) Affected property – given the nature of working on the railway the “property” is handed over and back on a regular basis. Similarly, other parties shall be working on the network; the impact of this scenario may have to be considered.
11.2 (5) Defect – depending upon any contract incentive or penalties a defect will have to be clearly defined within the service, there will need to be consideration to a defect within the build phase verses the maintain phase of the works.
11.2. (6) Defined Cost – discussed within the Schedule of Cost Components.
11.2 (9) Equipment – When will the transfer of ownership take place? What obligations will be on the Contractor at the end of the maintenance period? The required state of the equipment at the end of the maintenance phase.
11.2 (17) Price Adjustment Factor - What price adjustment factor would be most relevant to this type of works?
11.2 (20) The Price for Services Provided to Date – What measurement within the price list shall be used to assess the payments? The client or contractor could propose this, for the build phase. It is more likely to be defined for the maintain phase e.g. periodic payments.
11.2 (22) Scope:
Describes the Service: This is obviously a key document and traditionally be the contract requirements technical.
Figure 23: NEC4 Contract
40
Clause Commentary
Constraints on how the Contractor Provides the Service – Given the move to an outcome specification approach this section is key to setting the parameters within which the contractors can work.
13.2 Communication system: Which system would be used EB?
5.2.2 Contractor’s main responsibilities
Clause Commentary
20.2 The Contractor minimises the interference caused to the affected property – Traditionally it is the Client’s responsibility to provide access to the railway, however would typically provide an access schedule within the CRT. This clause may need to be amended to reflect how access would be treated within the project.
21.2 The Service Manager accepts the design – Who within the Project acts as the Service Manager, what stakeholders would be involved within the process, or would this be an independent activity for example and ISA? Approvals such as ORR approvals would have to be defined within the scope.
21.5 Record of the contractor’s design – What records would be required to be retained and for what period? Drawings are typically handed over however IP is retained by the Contractor.
23.1 What “Key People” would be required to be provided by the Contractor? Typically, frameworks contracts often also have further management requirements such as management boards.
24.1 The Contractor co-operates with others – Others would need to be defined within the contract, this should state the responsibilities of who manages which stakeholders. The list of others could be significant if the Contractor takes on the Principal Contractor role.
5.2.3 Time
Clause Commentary
30.3 At the end of the Service Period the contractor returns the …property in the condition stated within the scope. Currently the property is handed over to the client after the build stage, i.e. the property is new. Works may need to be undertaken to define in what condition this property is in at the end of a 10+ year maintenance period.
33.1 Access – Access is provided by the Client in accordance with the Accepted Plan. This clause may need to be modified depending on how the access is to be estimated for and provided.
5.2.4 Quality Management
Clause Commentary
40.1 The Contractor operates a quality management system which complies with the scope – Under existing contracts this is not defined as the Client takes an active involvement of the checking of designs, there are only usually references to materials and workmanship.
41 Tests and Inspections – currently there is an obligation on NR to provide the track time and potentially a train from the TOC’s to facilitate any testing this may need to be accounted for with in the clause.
41
5.2.5 Payment
Clause Commentary
52. Defined Cost shall be reviewed within cost components.
53 Performance measures – The performance measurement criteria need to be set out within the contract data, the mechanism of the any adjustments needs to be reflected within this clause. This is a key factor when assessing the risk which is to be designed out or priced.
54 Price Adjustment – needs to be decided as previously stated in the definitions, 11.2 (17).
55 Price List – The format of the price list needs to be defined for both the build and maintain phase. In addition to a rate card what form would the pricing exercise take for a given tender.
5.2.6 Compensation Events No specific comments within the process set out for compensation events; there is a section to add additional
compensation events within Contract Data Part 1.
5.2.7 Use of equipment, Plant and Materials
Clause Commentary
73.1 Title to Materials – The contractor has no title to materials within the Affected Property … Whilst the title of materials passes to the Client the clause does not deal with any provision of IPR, licences or third-party guarantees. These are likely to need to be addressed somewhere within the contract.
5.2.8 Liabilities and Insurance The levels / limits of insurance and liabilities are to be completed as an option in X18. The level of risk around
schedule 4/8 railway costs is typically defined and capped within the contract. Similarly, the risk around liability
during the maintain phase needs to be defined as it could have a significant impact on the solutions or pricing
of the works. Consequential losses are usually also defined in more specific detail for the protection of both
parties.
NR usually provides an insurance manual for each project, there is an expectation this would continue for future
projects.
5.2.9 Termination Digital Railway has already stated that their governance dictates that they have a termination at will clause
within the contract. The clause will need to be amended to reflect this.
5.2.10 Option clauses Dispute resolution – would need to be agreed between the parties, but given the on-going, established
relationships with the supply chain, a governance board type approach may be more applicable as a form of
mediation initially.
Ultimate Holding Company Guarantee – Many suppliers have different parent company relationships. Given
the scale of the majority of the suppliers in the market the implementation of this clause may provide DR with
additional cost for a negligible level of additional security.
42
Undertakings to others – Given the complex structure of the UK rail industry it is likely over a long-term period,
in a digital environment, that information or services may be supplied to other parties, such as TOC’s. There
may not be any benefit to precluding it from an OJEU notification however initially there may not be a
requirement.
Transfer of rights – Similar to IPR this section would likely need to be expanded given that hardware and
software will form part of the scope.
Information Modelling – The use of BIM is unlikely to add value to the project however information systems
are likely to add value. What information these systems hold and how it is used form part of the potential of a
digital solution.
Performance bond – the risk of the supplier’s performance would have to be assessed by the client, would the
cost of a bond offer value over a long-term agreement?
Advanced Payment – Not common in NR contracts unless an initial outlay is required.
Limitation of Liability – to be defined in accordance with the values in the Contract Data.
Extension of the service period – The conditions, timing and value of the extension would have to be defined.
Housing Grants Act and the Contract Act are likely to apply for UK contracts.
Z - Clauses would need to be defined relevant to the project.
5.3 Cost Components Many of the supply chain work in a mature target cost environment and have an agreed position on the elements
that constitute the Actual Cost and the elements that make up the fee. Often a schedule of labour rates is used
instead of individuals actual cost to ensure that administering the contract is timelier and cost effective. All costs
are made available for NR to audit centrally. Given that suppliers and NR have worked to these standards and
they are agreed across much of the supply chain in may be worth looking to use the cost components within
the ICE framework agreements instead of the NEC definition.
Aligning the schedule of cost components to the contract which is to be used for any new CP6 framework
agreements will also bring savings to the suppliers and DR.
The makeup of the project is likely to include significant amounts of internal labour and therefore it may be
beneficial to have set labour rates or a rate card instead of auditing the make-up of 10’individual’s costs.
5.4 NEC4 vs NR12 terms and proposed additional terms When using a standard form of contract there will inevitably be changes required to ensure that the contract is
workable given its specific requirements, environment and constraints. A review has been undertaken
comparing the base NEC4 Design Build and Operate terms to those of a NR12 S&T contract. Appendix 1
proposes wording for terms that the suppliers believe would need to be amended or added in order to make the
contract workable. The appendix covers:
• Insurance
• Liabilities
• Client Options
43
• Care of the works and handback
• Railway Costs
• Intellectual property rights
• CDM regulations
• Prohibitive Materials
• Construction Industry Scheme
• Confidentiality
• Track access
The appendix also references the clause number within an NR12 contract to demonstrate the current wording
agreed with Network Rail. The NR12 contract has evolved over a number of years and been refined as a result
of the delivery of a significant number of schemes. It would make sense to use this learning and to continue
with the agreed wording where applicable for the Moorgate contract.
5.5 Suppliers approach to contract risk When creating a payment model within the NEC4 framework there is opportunity to create an incentive model
to ensure that the outcome based specification remains the contractual focus. One proposed model is that the
Supplier puts all or part of their fee at risk until an outcome milestone is met. The costs are paid throughout the
duration of the project, subject to the pain/gain mechanism, to provide cash flow to the supply chain and
confidence that the fair payment charter is being upheld. Having the Fee withheld until outcome based criteria
are met ensures that the focus remains on delivering the specific outcome. For differing projects the goals may
be different, for some it may be timely delivery for example to meet other stakeholders delivery dates, for
instance new rolling stock. Another might be reliability performance given the high impact nature of certain parts
of the network should they fail. The Suppliers are accepting to put the fee at risk on an outcome however also
expect to be rewarded if they can provide additional benefits which are agreed with the customer.
When creating an incentive model an outcome based specification should set out the main goals of the customer
and the contracting mechanism must align these with those of the contractor. A framework model allows an
environment where closer working and understanding can be achieved. For example if a section or Railway,
like the Moorgate line, has life expired maintenance issues then the supplier could be rewarded for delivering a
solution faster, saving the customer money on delay costs and improving the end user experience. If the goals
of the customer are not aligned with those of the contract, then a misalignment can cause friction between the
parties who will focus their efforts on different priorities.
44
6 Maintenance Contracting
6.1 Background The majority of the mainline signalling installations within Great Britain are currently maintained by Network Rail
staff. Suppliers are typically asked to provide 3rd line technical support for the technologies that they have
installed and legacy equipment that is still in use on the railway. Suppliers also provide repairs and spares
service and often manage obsolescence of the systems within their working lifetime, and often beyond their
original design life.
As the maintenance activities are undertaken by NR, the supply chain have little involvement in the undertaking
or the decision making process when it comes to developing maintenance strategies.
Typical warranty periods for signalling equipment installed on current schemes are 2 years, however the design
life is significantly longer.
The risks attributed with the maintenance of the equipment is almost entirely with NR including the risk of
Schedule 4 & Schedule 8 payments for when the railway is closed for maintenance or is not available because
of equipment faults. Within the supply chain there is not currently an understanding of the costs involved, or the
process of how costs are attributed, between stakeholders because of preventative or reactive maintenance.
The supply chain has, however, acknowledged that to remain competitive and best serve its clients it needs to
provide products that not only reduce the capital costs but help to reduce the operational cost including
maintenance. As technology continues to develop more products have diagnostics that can notify the maintainer
of their performance, or of any failures. As more data is gathered to understand the performance of products
artificial intelligence can be introduced to predict failures before they occur. This forms part of the benefits of a
Digital Railway.
Outside of Great Britain, it is common for suppliers to take on the operation and maintenance of the railway
infrastructure. This is however usually based on deploying staff directly from within their organisation. The
transition of responsibilities for the maintenance of GB infrastructure will need to be carefully managed.
6.2 Managing Change Changing supplier – client roles, responsibilities and processes is extremely complicated operation and one that
this section will not try to address. It would be worth acknowledging however that a framework arrangement that
allows for flexibility would assist in facilitating the transition. Suppliers could be incentivised to provide
continuous improvement in supporting maintenance activities. Targets may not be able to be set at the tender
stage however mechanisms could be agreed to periodically reassess and reset these targets. Within other
industries where long term maintenance agreements are in place contract extensions are often based upon,
innovation, engagement and KPI’s that are not necessarily defined at the tender phase.
The suppliers may not be able to move to a position where they take liability for the operation of the railway but
suppliers are willing to put “skin in the game” and start to move in that direction.
6.3 Maintenance Scope This section looks to provide DR with some potential maintenance options that the supply chain could provide.
The diagram below provides some of the headings that make up the total lifecycle management of a product.
45
Figure 24: Life Cycle model
6.4 Spares and Repairs Data on spares, repairs usage and requirements can be harvested and used to profile future requirements and
influence ordering as well as stockholding.
Efficiencies may be achieved in central holding/remote warehousing of strategic spares for National
requirements.
Product modifications/upgrades may be developed or realised when new applications are required for other
projects. These can be incorporated into maintenance/enhancement programmes for existing installations.
6.5 Considerations for the spares scope The supplier should define as part of their technical solution the required spares for the scheme in order to
maintain the railway to the required availability specification. The cost of spares should be factored into the
overall scope and whole life cost of the project.
Once the responsibilities of the maintenance teams are defined then the location of the spares holdings could
be defined within the tender. The spares store could be maintained by the maintainer or the supplier.
As part of the tender the supplier should include RAMS targets, FMECA reports and other substantiation that
demonstrates the level of maintenance required including the spares holding required. This can be factored into
determining the cost and the arrangements to repair or replace any spares within a time frame.
46
6.6 Technical Support 1st Line site support: Enhanced site support could be provided 24 hours a day, 7 days a week after the initial
entry into service. It is common for the maintainer to often request this cover post a major commissioning in
case any initial faults occur. The supplier will often provide commissioning spares to avoid failures affecting the
railway during this infant mortality phase.
2nd Line support: During the period of enhanced site support a competent ETCS supplier could be required to
attend site within 24 hours of receiving the request. This option could be implemented for an initial period until
the maintainer is fully confident in managing the new equipment. The duration of this period could be flexible
and may be a function of the quality of the training that has been provided.
3rd Line Support: Telephone support could be provided by the supplier to answer all technical queries. The
telephone support could be available during office hours on working days or 24/7 depending on the railway
regime. When the telephone support is not available the supplier could provide an answering service such that
a message can be left and the supplier shall return the call when the telephone support is next available.
The telephone support will typically provide:
• Over the phone assistance with problems with repaired items;
• Over the phone assistance with the diagnostics on faults;
• Over the phone assistance with component history; and
• Discussion regarding second No Fault Founds (NFF) and next steps.
The traditional 3rd line technical support can be enhanced by remote monitoring of anything from individual
components to mock ups of complete systems. Any faulting issues arising can be quickly understood and
performance diagnostics can be run remotely with solutions being devised in a controlled environment.
By more long-term data gathering and sharing, the life of components can be modelled. This has the potential
to assist in the understanding of reactive maintenance and the planning of preventative maintenance. The
further into the life cycle and the more projects that exist with a supplier, the greater the data and the more
accurate the model. Contracts could be extended based upon the value that the supplier continues to offer, this
feedback loop would also benefit future products where any weaknesses or sub optimisation of the system
could quickly be addresses.
6.7 Technical Investigation In addition to the supplier providing reports on defect analysis and trends, they shall also, on request, undertake
specific investigations into failures, incidents and any other unexpected behaviour of the ETCS system.
Technical investigations are often required where different systems interface with each other to understand the
reasons for failures.
6.8 Testing Equipment, Special Tools and Training Equipment The supplier shall maintain all testing equipment, special tools, maintenance training rigs, and additional
software updates associated with the ETCS system in service for the duration of the project.
6.9 Managing obsolescence The supplier would have to monitor the availability of parts such that the installed equipment remained
maintainable. Where such parts could not be obtained, the supplier would have to provide alternative solutions
to ensure the system remains operable.
47
If a maintenance agreement were to last 30 years at some point there may need to be an update to the
equipment. Certain components or software may no longer be supported and therefore updating equipment
may continue to keep the system operable and extend the life of the system.
When selecting a supplier, the client would need to consider the supplier’s historic record of managing
obsolescence as an important indicator of how well they intend to maintain their current products.
6.10 Network and Cyber Security Management As the railway advances into an ever more digital environment the supplier would need to ensure that the
systems controlling the railway maintain secure.
Where information transfers from the project network on to the national network the protocols and security would
need to be agreed with NRT to ensure the systems remain safe and operational. Careful consideration will need
to be given where remote access to systems is required by the supplier to provide 3rd line support which would
invariably mean remote access to safety related and safety critical systems from a point external to the NR
telecommunications infrastructure.
The supplier should provide a maintenance strategy and process to ensure that networks remain protected
during the maintenance phase.
6.11 Key Performance Indicators Common performance indicators for the maintenance period could include:
• Maintenance of the reliability targets
• Achievement of the lead times for provision of new spares
• Achievement of the lead times for repaired spares
• Response to queries to the telephone service within the required times
• Inputting data concerning the occurrence and rectification of defects into DRACAS
KPI’s could be used as an incentive for the supplier to perform throughout the life of the contract. Monthly
maintenance payments could be awarded based upon the performance against the KPI performance, with a
reduced payment should the supplier not meet the required targets.
6.12 Reliability Targets and performance The ETCS system would initially have a reliability target to be achieved. During the maintenance phase and
during subsequent deployments along a route, the supplier could be rewarded for improving upon the reliability
target. This would incentivise the supplier to continuously develop the reliability of their products. Products could
be systematically upgraded in future years to increase reliability, creating a win-win situation for both the
maintainer and the supplier.
Should the reliability target not be met then the supplier would be penalised. This could be a function of the
periodic maintenance payment based upon the number of failures within the period. Should the supplier not
meet the minimum maintenance requirement then no maintenance payment would be received.
6.13 Maintenance reporting A periodic maintenance report could include the following:
• any failure to maintain a reliability target;
• any incentive payments of deductions
48
• any failure to meet a lead time for new spares with the reasons for the delay and steps being taken
to prevent delay from occurring again;
• any deductions to be made in respect of failure to deliver new spares by the relevant lead time
• any failure to meet a lead time for repaired spares with the reasons for the delay and steps being
taken to prevent delay from occurring again;
• any deductions to be made as a result of failure to deliver repaired spares by the lead time;
• any failure to return calls within the response time or, where such calls were returned in the
Response Time it was not by an appropriately qualified engineer;
• any failure to input defects into a DRACAS as required.
• any draft remedial performance improvement plans;
• any other service failures together with the information required;
• whether a persistent service failure has occurred or is likely to occur; and
• any other information which is related to the performance of the Service, maintenance of the
reliability target and the achievement (or otherwise) of the KPIs or as may be requested by the
Employer.
6.14 Tender Format The format of the tender documentation will need to reflect the use of an Outcome Based Specification. The
proposed arrangement as shown in Figure 25 provides a structured approach.
Figure 25: Proposed Tender Document Structure
The Core Document contains the overview documentation associated with the project including an overview,
the geographical boundaries and the ABR.
49
The Infrastructure Data contains the documents and data that describe the infrastructure that the project will
be implemented upon including the existing asset data, constraints and possession planning information.
The Functional, Process and Non-Functional Requirements are consolidated into the Application High Level
Outcomes (CRD) that describes all the requirements as either functional, non-functional or as process
requirements.
The Preliminary Schedule provides the programme and phases of work including the key milestones and
interfaces with associated and adjacent projects. For a Design, Build and Maintain project, this will include the
period of the maintenance period including renewals and obsolescence matters.
The O&M section provides information regarding the current operating documentation including training issues
and the asset management regime for the route.
The Commercial section sets out the commercial and contractual arrangements for the project.
50
7 Risks and challenges
7.1 Cultural Changes Adopting a “thin” client organisation may introduce culture shock to the project delivery and technical assurance
teams. Whilst it is understood that the current arrangements are no longer fit for purpose, the transition to a new
“thin organisation” will introduce several challenges.
It should be expected that the transition will be jarring with each organisation trying to understand their new
roles. There is a risk that as each organisation flexes into their new roles as RSIP and Technical Integrator that
critical tasks are duplicated or omitted. This would cause confusion and conflict between the teams and
resistance to the new process.
This risk could be mitigated by deploying a “business change management team” that
would be independent and oversee that the process to ensure that the works are
being conducted in accordance with the strategy. They would provide guidance to the
teams and ensure “fair play” was maintained during the transition period.
Whilst this report, retains the current job titles (i.e. DPE) this
is to provide understanding. To provide a clear differential from the existing
organisation to the new one, it is recommended that job titles are revised and aligned
with the new responsibilities. This would provide a clear delineation from the current
and allow new attitudes and behaviours to be established.
7.2 System of Systems The V-Life cycle provides the opportunity to the supplier to provide a bespoke and tailored solution that makes
best use of the generic specifications, the application requirements and their products.
However, their solution will reside in a wider system (the System of Systems (SoS)) that it will need to reside
within to ensure that it can provide interoperability.
Now, the generic specifications provide the requirements for achieving the M9 state and these requirements
need to be preserved in each application to ensure the systems will be interoperable.
There is a risk that the generic specifications could constrain the application requirements and the supplier. It is
understood that the generic specifications have been designed to be flexible and supplier agnostic but this has
not been tested.
7.3 Systems Authority The ability to tailor requirements to specific applications will require assurance that the tailoring does not affect
the System of Systems approach required to assure the interoperability of the systems provided by individual
projects.
This report supports Digital Rail’s intent to have a Systems Authority that will preside over the Specifications to
ensure that the interoperability of systems is persevered.
The ability to provide guidance in the production of requirements throughout the project lifecycle by using
templates and guidance notes would also help to mitigate deviations and manage the assurance of the generic
requirements.
51
This report recommends further consideration of templates for the project management plans (both delivery and
engineering), assurance and V&V plans, and testing reporting.
7.4 Technical Changes Required Following completion of the surveys it is vital that the railway configuration is
managed. The functionality of an ETCS system is defined in the configuration data.
This data has to match that of the actual railway. Divergence between the data and
the actual railway can result in expensive re-work cycles.
Further collaboration between the Technical Integrator
and Network Rail Telecoms is required as the FTNx and
GSM-R systems are now core to the delivery of the signalling system. This will require
a culture change in NRT as they will no longer be integrating with the IP signalling
team but with a System Integrator as IP signalling operate as a Railway Systems
Integrator in the Thin Client Model.
52
8 Case Study: Moorgate – Northern City Line Renewal
8.1 Background For the Moorgate – Northern City Line Renewal the strategy is to
roll out ETCS Level 2 without signals on the Moorgate Branch
between Drayton Park and Moorgate Stations. This is
approximately 3miles in length with a large section in a tunnel.
The renewal requires the deployment of the ETCS Level 2 system
(e.g. RBC with GSM-R) with the renewal of points, interlockings,
train detection and signalling power.
The TOC is providing stock with ETCS equipment fitted on board
so the focus of this project is the technical integration and the
trackside deployment.
There is no requirement to provide a Traffic Management System
or C-DAS which means this is not aligned with the System of
Systems architecture.
8.2 ConOps The Generic Concept of Operations document consider the operation for an integrated system including ETCS
(trackside and on-board), TM and C-DAS. The Moorgate – Northern City Line Renewal is only considering the
provision of one element of that in the ETCS Level 2 System.
In principle, the Concept of Operations
for the Northern City Line between
Drayton Park and Moorgate using
ERTMS Technology (Issue V2) should be
filtered from the Generic. The application
document should document the
difference, especially around where the
operational principles to be applied
where the other systems (C-DAS and
TM) are not being provided. It would be expected that alternative arrangements would be described in the
application Concept of Operations document that provided functionality that the generic system expects from
the missing systems.
This report recommends that further assessment is undertaken of the Generic
Concept of Operations document to ensure that the Application is configured
correctly.
Generic ConOps
Filtered Requirements
Application ConOps
Figure 27: Filtered ConOps
Figure 26: Route Map of the Northern Line Renewal
53
8.3 Client Delivery Team The client’s delivery organisation includes the following roles:
Figure 28: Proposed Thin Client Organisation Chart
Project Manager – will be responsible for the overall delivery of the project this will include stakeholder
management with the sponsor, the RAMs and the System Authorities.
Project Controller – will be responsible for the monitoring, control and reporting of the project. Detailed project
planning tasks will be transferred to the Technical Integrator whom will be responsible for the planning exercise.
Commercial Manager – will administer the project including managing the contractual and commercial issues.
Systems Integrator DPE – the lead engineering role responsible for ensuring the stakeholders are engaged
and ready for the delivery of the new technology. The SI DPE will need to manage the relationship with the
Route’s RAM Organisation and the Sponsor amongst other stakeholders and interested parties.
The DPE will also work with the DR System Authority to ensure the System of Systems requirements are
assured. The SI DPE will provide support to the Technical Integrator in the development of the system solution
and liaise with stakeholders on his behalf on matters of interest.
The DPE will also be responsible for the verification and validation of requirements by conducting assessments
of the requirements that have been traced to the CRD. This will include requesting specialist expertise to review
technical issues that could be outside of his expertise.
The DPE will organise and lead the gateway and audits that need to be conducted during the project lifecycle.
Requirements Manager/Configuration Manager - the owner of the requirements management process
including the tools. The Requirements Manager will provide support and guidance to the Technical Integrator in
the development of their requirements database including ensuring that the traceability to the CRD is correctly
undertaken.
The Requirements Manager could also be responsible for ensuring that configuration control is retained
including leading the Configuration Change Board.
Project Manager
Project Controller
Commerical Manager
DPE
Requirements Manager
System Assurance Manager
Operations Rep Site Manager
54
ETCS Operations Representative – is the operation facing team member and will be responsible for ensuring
the ETCS system is ready for operations including working with the TOCs. He/she will provide guidance to the
team and the Technical Integrator regarding Concept of Operation matters.
Site Manager – will be involved during the implementation phase and be responsible for assuring that the CDM
obligations are being met by the Technical Integrator. The Site Manager will undertake inspection and test
witnessing activities as required.
Safety Assurance Manager – will manage the Safety Assurance process in accordance with CSM principles.
The SAM will manage the relationship with the Regulator, ISA and other safety bodies that would be required
by the project.
The SAM will provide direction to the Technical Integrator in the development of their safety argument and
ensure that the various Safety Cases are correctly integrated.
8.4 Engineering Structure Figure 29 provides a proposed engineering structure for the Moorgate Project.
The arrangement places the Client engineering team in the centre of the project acting as the RSIP between
the technical activities being conducted by the supplier and the Sponsors, the Users (RAMs/TOC/etc.) and the
Authorities (Digital Rail, ISA, Regulator, etc.).
The RSIP role will require a dynamic team that are prepared to work in a co-operative and pragmatic way to
ensure that the new model is given the chance to evolve and develop into a working solution.
The Technical Integrator role will manage the delivery of critical activities integrating together the various
disciplines into a cohesive solution. Under this structure, key tasks such as Design Assurance, Quality
Assurance and Safety Management will now have to be conducted by the Technical Integrator with little
oversight from the RSIP. Whilst the Supply Chain has considerable experience of undertaking this role on many
overseas mainline and metro projects, this project will be novel in many respects not least because it affects
the established standards and procedures for project delivery on the GB network. Like the RSIP’s team, the
Technical Integrator will need to deploy practical and pragmatic engineers to work in an emerging and evolving
project delivery environment.
55
Requirements
Manager
Configuration
Manager
Sys Int /DPE
GTR
ETCS Operation
s Rep
Safety Assurance Manager
Siemens Class 717
Alstom Class 313
CEM
CRE IXL/
Trackside
CREETCS
CRETrack
Safety Assurance
Assessor
Product Assurance
Technical Integrator
Maintainer 2nd Line
CRECivils
CRETraction
CREPway
Test
CRE Control Centre
Safety Assurance Manager
V&V Lead
NoBo (TSI)
ISA
DeBo (NTR)
AsBo
Train Dispatch
CRE Telecoms
CREPower
RAMTrack
RAMCivils
RAMTraction
RAMPway
RAM Telecoms
RAMPower
Local Mtce
Site Manager
ORR (safety
authority)
ERA(tech
pillar 4th Railway
package)
Test Manager
Trainers
Signal Sighting
Chair
Sponsor
NRT
Passenger flow control
Evacuation plans
Rostering
Possession
Planning
Figure 29: Proposed Organisational Relationships for Moorgate Project
56
Appendix 1 Proposal for Signalling & Telecoms specific amendments to NEC 4 Design, Build and Operate Contract (June 2017)
Clause Proposal Comment Comparison NR12 (S&T) Clause
Proposed Optional Clauses
X15 X15.1 The Contractor is not liable for a Defect which arose from its design unless it failed to carry out that design using the skill and care normally used by professionals designing works similar to the works.
X15.2 The Contractor corrects a Defect for which it is not liable under the contract as a compensation event. X15.3 The Contractor may use the material provided by it under the contract for other work unless
• ownership of the material has been given to the Client
• it is stated otherwise in the Scope X15.4 The Contractor retains copies of drawings, specifications, reports and other documents which record the
Contractor’s design for the period of retention. The copies are retained in the form stated in the Scope.
▪ This is the standard NEC 4 Option X15 clause, with the exception of X15.5. X15.5 has been omitted on the understanding that required insurance will be set-out in a single location, in the insurance table within Core Clause 83.3.
▪ Set-out the general duty for reasonable skill and care for design. ▪ Only X15.1 and X15.2 would be required to maintain the existing principles, but
X15.3 and X15.4 are proposed as potentially helpful clarifications.
Clause 8(2)
X18 X18.1 Each of the limits to the Contractor’s liability in this clause apply if a limit is stated in the Contract Data. X18.2 The liability of each party to the other for any loss of profit, loss of use (including without limitation loss of use
of infrastructure or railway vehicles), loss of production, financial loss, loss of contracts, loss of data or information or for any indirect or consequential loss is limited to the amount stated in the Contract Data.
X18.3 For any one event the liability of the Contractor to the Client for loss or damage to the Client’s property is limited to the amount stated in the Contract Data.
X18.4 The Contractor’s liability to the Client for Defects due to its design is limited to the amount in the Contract Data. X18.5 The Contactor’s total liability to the Client for all matters arising under or in connection with the contract, other
than the excluded matters, is limited to the amount state in the Contract Data. The excluded matters are amounts payable by the Contractor for:
• any liability in respect of death or personal injury resulting from a negligent act or omission or breach of statutory duty by the Contractor or any person for whom the Contractor is responsible;
• any losses directly caused by the fraud of the Contractor. X18.6 The Contractor is not liable to the Client for any matter unless it is notified to the Contractor before the end of
liability date. X18.7 The limitations and exclusions of liability in the contract apply to any breach of contract or statutory duty, tort
(including but not limited to negligence), delict, by way of indemnity or otherwise to the extent allowed under the law of the contract.
▪ Proposes an amended Clause X18 to capture the currently agreed S&T position regarding limitations and exclusions of liability.
▪ X18.2 captures current exclusion of liability provisions within the S&T conditions.
It is assumed that the liability value in the Contract Data would be “£0”. Given the nature of the ETCS works an expansion of the language is proposed. For transparency the operative additional words are underlined in blue for NR’s consideration. As with the existing S&T provisions it is proposed that this clause also applies for the benefit of NR.
▪ X18.5 under the equivalent clause of the NR12(S&T) conditions [clause 88],
insured design liability would also be covered by a separate cap of £10 million. For transparency, this statement has not been proposed here, as it is understood that the design liability cap would be covered by X18.4.
Clause 88 and Clause 8(2)(c)
New X24 Client’s Options
X.24.1 Client’s options are those elements of service stated in the Contract Data which, if requested by the Client on or before the relevant date stated in the Contract Data, shall be undertaken by the Contractor in accordance with this clause.
X.24.2 The Client gives an instruction for perform any or all of the Client’s Options on or before the relevant date stated in the Contract Data. The Client’s instruction to perform a Client’s option is a compensation event.
X24.3 Compensation events instructed under this clause shall be assessed as follows:
• The addition to the Prices is the itemised sum against each Client’s option unless any changes to the services in the relevant Client’s option have been made.
• Any changes to the services in the relevant Client’s option shall be assessed as compensation events and the relevant Price(s) established shall be adjusted either up, or down accordingly.
X24.4 No extension of time shall be allowable as a result of any Client’s option instructed under this clause. For the avoidance of doubt, any subsequent alteration to the services to be delivered pursuant to and following the instruction a Client’s option shall be assessed as a compensation event.
▪ Creates the ability for the contract to include priced options within the scope; which NR has the right to exercise up to the, programme driven, date for exercise of that option.
Clauses 1(1) and 89.
57
New X25 Additional Responsibility for Care of the Works
X25.1 The Client issues a draft hand-over certificate (“the Hand-Over Certificate”) when any part of the Works or other work package contractor’s works (“the Hand-Over Works”) are completed to a standard which is sufficient for it to be capable of being handed over to an Other or the Contractor or the Employer.
X25.2 The Hand-over Certificate shall detail the relevant Hand-Over Works and shall be valid and effective once it is signed by the Contractor, the Service Manager and the relevant Other.
X25.3 Where the Contractor is handing over Works it shall be relieved of its liability for loss of or damage to the Works, Plant or Materials handed over from the date of the Hand-Over Certificate and responsibility for the care of the Hand-Over Works shall pass to the following Other or the Client. The Contractor’s liability for the remaining Works shall not be affected by this clause.
X25.4 The passing of responsibility for the care of the Hand-over Works shall not constitute Works Completion.
▪ The mechanism was introduced by NR to grant clarity for hand-over of parts of the works to either another NR contractor (e.g. from signalling to electrification) or to NR itself. Similarly, it enables hand-over of specific parts of the works from NR or its other contractors to the Signalling contractor.
▪ This provision creates a documented process for recording responsibility for the risk of theft, vandalism or damage for different parts of the works when different contractor disciplines are working on the same project, or if works are required to be installed significantly in advance of commissioning.
▪ The terminology used for these provisions within NR12(S&T) does not translate
naturally in the NEC 4 DBO contract. Therefore, attention is brought to the attempt to align language particularly in respect of X25.2 (language aligned to Cl.81.1 BP 2 of the DBO conditions).
Clause 87
New X26 Liability for Railway Costs
X26.1 Notwithstanding any other provision of the contract, the Client and the Contractor agree that the liability of the Contractor to compensate the Client in respect of any sums payable by the Client pursuant to Schedules 4 and 8 of the Track Access Agreement or the equivalent provisions of any Freight Access Agreement (together “Railway Costs”) are as set out in this clause and the Contactor shall have no further liability for any sums paid by the Client for Railway Costs.
X.26.2 The Contractor pays liquidated damages to the Client where a track possession or speed restriction has gone beyond the times stated in the contract as a result of a matter which is the Contractor’s liability.
X.26.3 The liquidated damages shall apply to the period extending beyond the expiry time of the track possession or speed restriction, detailed in the contract as a result of the Contractor having failed to complete work in accordance with the contract or some matter which is a Contractor liability and will be applied at the rates detailed in the Contract Data.
X.26.4 The Contractor’s liability for liquidated damages in respect of railway costs is limited to the amount stated in the Contract Data.
X.26.5 Without prejudice to the Contractor’s insurance obligations under the contract and save as expressly set out in this clause the Contractor shall have no further liability for any track possession or speed restriction extending beyond the expiry time of the track possession/speed restriction detailed in the contract
▪ Sets-out the Contractor’s liability for Schedule 4 and 8 costs.
▪ Liquidated damages would apply for overrun of granted track possessions and speed restrictions.
▪ Typically, these performance LDs have been limited to 15% of contract price.
▪ Under the current S&T conditions LDs also apply where the systems falls short of the guaranteed MTBF target (subject to the same 15% limit). For transparency, this provision has not been imported across as it is assumed that for a service contract NR will wish to set out specific performance criteria.
Clause 34
New X27 Works Performed under previous contracts
X.27.1 The Contractor has carried out preliminary Works for the contract under the purchase orders listed in the Contract Data and therefore:
• all and any obligations on the part of the Client to make payment under such purchase orders shall determine; and
• any payments made under such purchase orders shall be treated as payments on account of the contract; and
• everything done by the Contractor or on behalf of the Contractor under such purchase orders shall be deemed to have been done pursuant to the contract and any outstanding payments, variations or claims under such purchase orders shall be valued and managed in accordance with the terms and conditions of the contract.
▪ Allows NR to nominate early works contracts to be subsumed into this contract. Where used the price of the early works contract should also be subsumed into the Defined Cost of the current contract.
▪ If used, the Contract Data needs to include a list of the early works orders subsumed into the contract.
Proposed Additional Conditions of Contract
58
Z1 IPR Z1.1 Intellectual Property supplied by the Contractor for the purpose of the contract shall remain vested in the Contractor.
Z1.2 The Contractor grants the Client an irrevocable, royalty free non-exclusive licence to use all [designs and drawings produced/ Intellectual Property supplied] by the Contractor for any purpose in connection with carrying out of the Works.
Z1.3 The Contractor:
• waives in favour of the Client any and all moral rights in the Contractor’s designs and drawings
• agrees that upon completion of the Works the Client may grant sub-licences to other persons to use and to reproduce the Contractor’s designs and drawings for any purposes of operating, maintaining, dismantling, re-assembling, repairing or adjusting the Works
• procures from copyright holders a licence with a full title guarantee to the Client in the same terms as set out in this clause.
Z1.4 The Client shall have no right to decompile any computer software which forms part of the Intellectual Property licensed to the Client nor shall the Client attempt to derive any algorithms, techniques or other features of the software or modify or attempt to create any derivative works from the software and any sub-licence granted by the Client shall similarly apply these prohibitions to the sub-licensee of that computer software.
Z1.5 Notwithstanding the above provisions no licence is granted to the Client under this Contract to reproduce or have reproduced the Plant and Materials in part or whole; and no licence is granted to the Client to make or have made components or spare parts for the Works which are protected by intellectual property rights vested in the Contractor or any of its Subcontractors for any other purposes other than the maintenance, running or repair of the Works.
▪ Add in a licence to use designs and drawings which is currently missing from the baseline NEC conditions.
▪ In respect of Z.2.2, the current suite of S&T conditions refer only to licences in
‘designs and drawings’. Given the greater involvement of software within ETCS applications, NR may consider it beneficial to expand the scope of the licence to include all Intellectual Property supplied by the Contractor.
▪ As neither the current S&T conditions or the NEC 4 conditions define intellectual
property, if the wider licence is chosen by NR, we would also propose inclusion of the following new definition of ‘Intellectual Property’. This is the standard definition within Network Rail’s NR3 v3.11 conditions:
“Intellectual Property is all intellectual and industrial property and all rights therein in any part of the world including any patent, patent application, trade mark, trade mark application, registered design, registered design application, trade name, trade secret, business name, discovery, invention, process, formula, know-how, specification, improvement, technique, copyright, unregistered design right, technical information or drawing including rights in computer software, database rights, topography rights”
▪ Item’s Z2.4 and Z2.5 are important from a signalling perspective as NR has
included these provisions within its S&T terms for many years. Therefore, these provisions are a common feature in third party licence agreements.
Clause 6(2), (3) and (4)
Z2 CDM Regulations
Z2.1 The Contractor complies with the Client’s health and safety requirements as set-out in the Contract Requirements HSQE.
Z2.2 The Contractor procures that the Contractor’s employees, Subcontractors and other persons engaged by the Contractor receive safety and skills training in accordance with the requirements of the Contract Requirements HSQE and the Employer may instruct the immediate replacement, at the Contractor’s cost, of any person on the site who is not so trained.
Z2.3 The “Principal Contractor” is the entity specified in the Pre-Construction Information Packs included in the Contract Requirements - HSQE.
Z2.4 If the Contractor is the “Principal Contractor” it warrants that it is competent to accept this appointment and will properly perform all the duties required of a Principal Contractor under the Construction (Design and Management) Regulations including, without limitation, liaising with the CDM Co-ordinator named in the Contract Data.
Z2.5 If the Contractor is not the “Principal Contractor” the Contractor will fully support the Principal Contractor to properly perform all the duties required of the Principal Contractor under the Construction (Design and Management Regulations.
▪ Aims to incorporate NR’s standard CDM provisions into the NEC contract.
▪ If adopted, would require a new Contract Data Part One entry specifying the name of the CDM Co-ordinator.
Clause 71
59
Z3 Prohibitive Materials
Z3.1 A material is prohibited if, in the context of its use in the Works (whether alone or in combination with other materials):
• it poses a hazard to the health and safety of any person who may come into contact with the Works (whether during their construction or after their completion)
• either by itself or as a result of its use in a particular situation or in combination with other materials it would or is likely to have the effect of reducing the normal life expectancy of any other material or structure in which the material is incorporated or to which it is affixed
• it poses a threat to the structural stability or performance of the physical integrity of the Works or any part or component of the Works.
Z3.2 The Contractor does not specify, authorise for use or permit to be used any materials which at the time the Works are being carried out are generally accepted or reasonably suspected of:
• being prohibited in themselves
• becoming prohibited when used in a particular situation or in combination with other materials
• becoming prohibited with the passage of time
• becoming prohibited without a level of maintenance which is higher than that which would normally be expected of a structure of the type under construction
• being damaged by or causing damage to the Affected Property and the Contractor, when requested, issues to the Client a certificate that no such materials have been specified for use or permitted for use.
Z3.3 The Contractor warrants that it shall specify materials for use in the Works in accordance with the guidelines contained in publication “Good Practice in Selection of Construction Materials” (1997: Over Arup & Partners and/ or that materials used in accordance with the construction of the Works shall be in accordance with such guidelines.”
▪ Incorporates NR’s standard requirements for use and control of hazard materials; and in respect of Z4.3 for control of hazardous materials generally.
Clause 8(3)
Z4 Construction Industry Scheme
Z4.1 For the purpose of this clause “Scheme” shall mean the Construction Industry Scheme, as provided for Chapter 3 of the Finance Act 2004 and the Income Tax (Construction Industry Scheme) Regulations 2005.
Z4.2 The Contractor provides to the Client the information specified in regulation 6(2)(b)(iii) of the Income Tax (Construction Industry Scheme) Regulations 2005.
Z4.3 The Contractor ensures that at all times it is registered for gross payment under the Scheme. Z4.4 If the Contractor fails to completion with this clause the Client shall not be obliged to make any further payments
to the Contractor until such time as the failure is remedied.
▪ Provides NR with a mechanism to ensure Contractor’s compliance with the Construction Industry Scheme.
▪ Proposal will require validating by tax specialists.
Clause 60(12)
Z5 Confidentiality Z5.1 The Contractor and the Client treat all information obtained from the other in the course or conduct of the contract as confidential and do not divulge it save as necessary to effect the execution of the contract or maintenance, operation or repair of the Works and then only on the basis that the receipt of such information shall be bound by similar confidentiality obligations to those in this clause.
Z5.2 The obligation in this clause shall not apply to information which:
• is or shall become in the public domain otherwise than in consequence of a breach by the Contractor or the Client of its obligations under this clause
• was in the receiving party’s possession prior to award of the contract and which the disclosing party did not notify as confidential or which would not reasonably be regarded as confidential by its nature
• was received from third parties having to the best of the recipient’s knowledge the right to disclose such information
• is require to be disclosed pursuant to a court order or statutory requirement provided that the recipient shall to the extent permitted by the relevant legal or statutory requirement (a) provide the disclosing party with prompt written notice of any such requirement before such disclosure
is made; and (b) take all reasonable action to avoid and limit such disclosure as may be requested by the disclosing
party Z5.3 The Contractor does not make any announcement in relation to the contract or its subject matter without the prior
written approval of the Client except as required by law or by any legal or regulatory authority.
▪ Standard confidentiality clause.
▪ Z6.3 adds requirements not to make press releases relating to the contract without NR’s approval.
Clause 74
60
Z6 Track Access Z6.1 The Contractor submits written notice to the Client confirming any speed restrictions, track possession or isolation requirements in accordance with the Client’s current planning procedures (or as otherwise laid down in the contract) in advance of the proposed commencement of work on or near railway lines.
Z6.2 The Client reserves the right to cancel or alter the dates and times of the agreed speed restrictions, track possessions or isolations at short notice if this proves necessary because of any emergency affecting the safe or uninterrupted running of rail traffic, but in such event the Client makes alternative arrangements as soon as the Client’s programme permits. Such cancellation or change in circumstance shall be a compensation event.
Z6.3 Where any part of the Works has to be carried out during an agreed period of a speed restriction, track possession or isolation, the Contractor shall make adequate arrangements to ensure that such part can commence in accordance with the Accepted Plan, and can be completed as early as possible, and in any case within that period. The arrangements shall include the provision of sufficient and suitable Contractor’s Equipment (including where practicable, standby equipment) and sufficient labour.
Z6.4 Prior to commencement of any speed restriction, track possession or isolation, the Service Manager is of the opinion that the Contractor has failed to comply with the requirements of clause [Z6.3], he may at his discretion cancel the speed restriction, track possession or isolation, or reduce the extent of the work that the Contractor may carry out during such speed restriction, track possession or isolation and the Client notifies the Contractor accordingly.
Z6.5 If, during a speed restriction, track possession or isolation, the Service Manager is of the opinion that the Contractor will be unable to complete the planned work (or any revision proposed by the Contractor) to his satisfaction so as to permit the termination of the speed restriction, track possession or isolation at the time agreed, then the Service Manager may instruct the Contractor to reduce the extent or vary the dates and times of the work to be carried out during such speed restriction, track possession or isolation. Such reduction or variation shall not entitle the Contractor to a compensation event if and to the extent that the Contractor’s inability to complete the planned work was due to a breach by the Contractor of the requirements of the contract.
▪ Establishes NR’s right to amend possessions to the extent this is necessary to ensure uninterrupted operation of the railway.
▪ Actual liability for overruns is set out in clause 34 of NR12(S&T) [see proposed X26 above].
Clause 75; also to be read in conjunction with amended clause 34.
Proposed Bespoke Amendments to Core Clauses
21.2 The Contractor’s design
Add the end of the first sentence add “The Service Manager accepts or rejects the design within the time period set out in the Accepted Plan. If the design is not accepted the Service Manager sets out the reasons for non-acceptance and the changes that in the Service Manager’s opinion are to be made to allow acceptance.”
▪ Confirms that the time scales for acceptance or rejection of designs will be set-out in the Accepted Plan; and that, in order to allow the programme to be maintained, the reasons for any nor acceptance will be stated.
Clause 7
24.2 Working with the Client and Others
Delete the second sentence beginning “Any cost incurred…”. ▪ Typically, LDs would apply for delay, as it will not normally be possible for the Contractor to manage Others. Incentivisation provisions and integration meetings would typically be implemented to ensure collaborative working practices and mitigation of costs.
Clause 47
27 Assignment Add a new 27.2 to read: “27.2 The Client shall be entitled to assign, charge or transfer the contract with the Contractor’s prior written agreement (which shall not be unreasonably withheld or delayed).”
▪ Adds in an additional right for NR to assign or transfer the contract, subject to the agreement of the contract which cannot be unreasonably withheld or delayed.
Clause 3(1)
30.3 Starting and the Service Period
Delete Clause 30.3. ▪ This standard NEC clause appears designed around building/ property management. Management and operation of the Affected Property would be outside of the scope of these works.
60.1(15) Compensation Events
Propose that Cl.60.1(15) is amended to read: (15) A change in the law of the country in which the Affected Property is located or a change in Rail Group Standards,
Network Rail Standards or other equivalent standards which occurs after the Contract Date.
▪ Provides a mechanism for early warning and assessment of changes in applicable railway standards; which can be expected to change many time through the life of the project.
Clause 8(1)
60.1(21) Compensation Events
Add a new Para (21) to read: (21) The Contractor encounters physical conditions which
• are within the Site
• are not weather conditions, and
• an experienced contractor would have judged at the Contract Date to have such a small chance of occurring that it would have been unreasonable to allow for them.
Only the difference between the physical conditions encountered and those for which it would have been reasonable to have allowed for is taken into account in assessing a compensation event.
▪ The comparative clause within NR12(S&T) is clause 12. However, to keep to NEC principles the proposed clause is the standard NEC 4 Clause 60.1(12) wording.
▪ Given the nature and duration of the services it is proposed that this would be a practical level of test process for assessing the impact of unforeseen site conditions.
Clause 12
60.1(22) Compensation Events
Add a new Para (21) to read: (22) A weather measurement is recorded before the Completion Date for the whole of the works which would make it impracticable or unsafe to Provide the Services in accordance with the Accepted Plan.
▪ The comparative NR12(S&T) clause entitles a change in respect ‘exceptional adverse weather conditions’.
▪ We recommend clarifying this to refer to weather conditions which would make it impracticable or unsafe for the works to be provided in accordance with the Accepted Plan.
▪ Given the nature and duration of the services it is proposed that such
circumstances should trigger an assessment of safety and programme mitigation measures.
Clause 44(1)(c)
61
81.3 Insurance Table
Amend the third box to read: “Loss or damages to the Works, Plant and Materials and Equipment (until Works Completion [or transfer of liability under [X.25]]).”
▪ Consequential adjustment if new X.25 (please see above) is introduced. If parts of the work are handed-over under X.25 then responsibility for insurance remains with whomever has responsibility for the works when they are damaged.
Clause 21(3)
90.2/ 91.9 Termination
Propose adding a new right for the Client to terminate at will: “91.9 The Client may terminate by giving two weeks written notice to the Contractor for any other reason (R23)”. With termination Procedures P1 and P4 applying and the Amount Due being A1, A2 and A4.
▪ A termination for convenience provision has been proposed, as NR have identified this as a key requirement in their supplier briefings.
62
Proposed Adjustments to the Contract Data Part One
The following additions to the Contract Data Part One are proposed where the corresponding draft clause mentioned above is adopted. In each instance the information provided is the same a currently specified in the NR12(S&T) conditions.
X24: Client’s Options
The Client’s Options are: Option to be exercised no later than:
1. [Option 1] [Date 1]
2. [Option 2] [Date 2]
3. [Option 3] [Date 3]
X25: Additional Responsibility for Care of the Works
The works for which X25 applies are:
1. [Insert Item Definition]
2. [Insert Item Definition]
3. [Insert Item Definition]
4. [Insert Item Definition]
X26: Liability for Railway Costs
For the first 60 minutes or part thereof £[Insert] per minute
For the next 15 minutes or part thereof £[Insert] per minute
For the next 15 minutes or part thereof £[Insert] per minute
For the next 15 minutes or part thereof £[Insert] per minute
For the next 15 minutes or part thereof £[Insert] per minute
For subsequent delay £[Insert] per minute
The Contractor’s total liability for Railway Costs is limited to [£based of 15% of the Prices]
X27: Works performed under previous purchase orders
The purchase orders to which X27 applies are:
1. [Insert PO Number] dated [Insert date]
2. [Insert PO Number] dated [Insert date]
Z2 CDM Regulations
The CDM Co-ordinator is:
Name: [Network Rail Infrastructure Limited]
Address: [Insert Address]
top related