1. Background 

Crossrail is the project created to deliver the Elizabeth Line, a new railway for London. The Elizabeth line will stretch more than 60 miles from Reading and Heathrow in the west through central tunnels across to Shenfield and Abbey Wood in the east.

The new railway – currently being built by Crossrail Ltd and Industry Partners e.g. Network Rail (NR) and London Underground (LU) – will stop at 41 accessible stations (see Figure 1), 10 newly built, and is expected to serve around 200 million people each year.

It will add 10% capacity to central London’s rail network, bringing an extra 1.5 million people to within 45 minutes of central London.

Crossrail is acknowledged to be one of the most significant and complex capital infrastructure projects of the 21st Century.

Key project characteristics:

• 42km new tunnels through central London
• 10 new central London stations
• Multiple station upgrades at existing NR stations
• Over 15,000 people have worked on the project and over 120 million working hours have been completed since construction begun in 2009.
• New fleet of 70 trains, 200m long, 1,500 passengers capacity
• Trains operating through four signalling systems (one in the new tunnelled central section, and three on the existing NR infrastructure)
• The Elizabeth Line trains share NR infrastructure with other services outside of the tunnels as well as providing a new underground metro service through the centre of London
• New Infrastructure Manager (IM) organisation
• One of the most advanced digital railways in the world

Figure 1. The Elizabeth Line route

2. Introduction

On programmes as large and complex as Crossrail, system integration is essential. It is central to managing risk; risk that systems won’t work together, risk that systems are unreliable / inoperable, risk that the works are not logically sequenced and ultimately risk of schedule delays and associated budget increases.

Successful system integration (SI) on Crossrail means delivering a railway that is safe, operable, maintainable, reliable and performs to the required levels of capability. It also considers:

• Technical integration – achieving acceptable, compliant, compatible technical outcomes
• Operational integration – making it work for the railway operators and passengers
• Organisational integration – bringing organisations and teams together to enable above

Ideally SI should be client led commencing at the inception of a project and continuing throughout the project lifecycle. This is important to ensure that common goals are established as early as possible from which requirements can be developed and a contract breakdown structure created. “The Railway Integration Approach at Crossrail” (J Bates and J Morris, 2018, Crossrail Learning Legacy) paper provides important context regards the approach taken to integration on Crossrail. Key artefacts used by Crossrail include:

• System Integration Management Plan
• System Architecture diagrams from various viewpoints: physical, geographic and functional as examples
• Migration plans – see Section 3.3
• Configuration Management plan
• Railway Integration Authority
• Testing and Commissioning Strategy

3. Systems Integration on Crossrail

Following a substantial review in early 2019, a new strategy was required to open the railway as soon as practicable and to minimise programme delays. This approach was embodied in an Earliest Opening Programme (EOP), led by Crossrail Ltd and utilising a Systems Integration approach, which has proved critical in providing clarity and focus on the key steps to getting the railway into passenger service.

The original Crossrail plan called for the completion of the Central Operating Section (COS) in its entirety (Paddington to Abbey Wood stations), before handing it over to the operators and maintainers. The EOP changed the focus to a staged completion process that would allow the railway to migrate through a series of Configuration Stages acceptable to all key stakeholders.

3.1 Defining the Stages

Outer Areas

Various routes west of Paddington and east of Whitechapel (from Figure 1):

Central Operating Section

The EOP defined several key stages for Passenger Service recognising that the railway would still be in a state of change throughout. These were:

 

Stage 1:	Crossrail 7 car train services Liverpool Street High Level to Shenfield
Stage 2a:	Crossrail takes over Heathrow Connect services using Class 360 trains
Stage 2b:	Crossrail Services (Class 345) Paddington High Level to Heathrow Airport
Stage 5a:	Crossrail Services Reading & Maidenhead to Paddington High Level
Stage 3a:	Passenger Service through the Central Operating Section (COS) from Abbey Wood to Paddington but not with all the central stations in service.
Stage 3R:	Passenger Service through the COS from Abbey Wood to Paddington with all the central stations in service.
Stage 4a:	9 car  train services Shenfield to Liverpool Street (High Level)
Stage 5a+:	Part 1 – Additional Peak services Reading & Maidenhead to Paddington High Level Part 2 – Additional Off-Peak services Reading & Maidenhead to Paddington High Level
Stage 5b:	Crossrail services Shenfield to Paddington (Low Level) and Abbey Wood to Reading
Stage 5c:	The final configuration with services running from Shenfield and Abbey Wood through the COS to Paddington, Heathrow, Maidenhead and Reading.

 

3.2 Exit / Entry Criteria per stage in the COS

It was important to set the conditions that had to be met to progress from one stage to the next. These conditions comprised both the required functionality that had to be available and the performance levels that needed to be achieved. These set the boundaries from which the key milestones for the Migration Plan could be established and were developed in collaboration with the Infrastructure Managers and the Operators.

3.3 Migration Plan

The Migration Plan is a crucial artefact in creating the common goals as it shows the key milestones of each of the contracts and, importantly, the interdependencies between them. It brings together, at a high-level, multiple levels of integration: Technical; Operational and Organisational. The Migration Plan becomes more important if there are to be a number of completion stages as part of the project delivery strategy, see Figure 2.

Figure 2. Crossrail Overall Migration Plan – v3.0

3.4 System Descriptions

The introduction of the EOP meant that clear descriptions of the scope and functionality required for the key Configuration Stages of Trial Running and Trial Operations needed to be developed.

Trial Running System Description

The initial System Description for Entry into Trial Running was developed to describe the minimum configuration and functionality required to start Trial Running as set out in the Dynamic Testing Exit and Trial Running Entry Criteria. However, to safely take on the railway the IM needed to know the exact configuration and functionality that would be available at the start of Trial Running.

Therefore, an approach to managing the difference between the minimum and actual was put in place. The Trial Running Configuration Deltas Description was produced to capture both the positive and negative deltas to the minimum functionality. Each of the proposed deltas was reviewed by the stakeholders so that impacts were fully understood. The actual delivered functionality was then the sum of the minimum functionality and the deltas.

For each system, the configuration and functionality were described in terms of being:

• Fully available
• Partially available
• Not available

For those functions that were not fully available guidance was provided to the end users through Structured Engineering Judgement (SteJ) and Operational Restrictions processes. These look at the effects of the functionality not being available from a technical assurance, operational and maintenance perspective and consider the acceptable workarounds that would be required.

The actual functionality combined with agreed Operational Restrictions then provides a simplified picture of the operational capability available.

A similar process is to be followed for Entry into Trial Operations.

3.5 Configuration State Maps

Each System Description document was supported by a set of Configuration State Maps, which provided a graphical representation of the content that were useful aids for wider programme engagement.

See Figure 3 for an example Configuration State Map.

Figure 3. Example Configuration State Map

3.6 Programme Integration, Alignment and Managing Interfaces

The ability to achieve the desired outcomes is dependent on strategic alignment and effective management of interface across the key functions within the Crossrail Programme; notably those below:

• Delivery – including Safety, Health, Environment and Quality (SHEQ)
• Supply Chain (Tier 1, 2 and 3 Contractors)
• Field Engineering / Engineering Management
• Chief Engineers Group (CEG)
• Engineering Assurance
• Engineering Safety Management
• Infrastructure Manager (LU / RfLI / NR)
• Operators (MTR / RfLI)

Various examples are included in Section 0 regarding organisational evolution and specific organisational choices made to facilitate reduction of integration risk.

3.7 Testing & Commissioning strategy

An important component of defining how the railway comes together is the Crossrail Testing & Commissioning Strategy. This lays out a phased process for testing and commissioning to demonstrate that the assets and integrated systems perform in accordance with Crossrail’s programme functional and sponsors requirements. The process involves:

• Integration of each sub-system to work with its interfacing sub-systems
• Testing of each sub-system and then the integrated system to demonstrate that they meet their requirements; and
• Commissioning of each system to bring it into operation.

The process follows the below stages, illustrated in Figure 4.

• Phase 1 – Off-site tests
• Phase 2 – On-site standalone static testing
• Phase 3 – On-site static integration testing
• Phase 4 – Dynamic testing
• Phase 5 – Trial Running

Figure 4. Crossrail’s approach to Testing and Commissioning overlaid to industry standard Systems ‘V’ diagram

The five-phase testing and commissioning process was embedded in the programme contractual scope, known as the Works Information, for all of the Tier 1 Contracts for Stations, Shafts and Portals, and for the Systemwide Contracts.

The Works Information required Contractors to produce plans and reports for testing and commissioning with the resulting outputs feeding:

• Satisfaction of requirements
• Closure of hazards
• Certification to support handover (i.e. Acceptance certificates)

To complement the Tier 1 / contractor activity, and considering integration at a railway level across the sub systems, Crossrail undertook additional integration testing split into:

• Stations integration
• Routeway integration (all of the systems that form the route connecting the stations)

Both the Stations and Routeway integration activities had an associated set of requirements to be met through a number of scenarios. These were determined through a risk-based assessment and focussed on critical functions/systems and end-to-end integration.

Crossrail is accountable for integration of the railway, therefore the satisfaction of these requirements is a Crossrail led activity which included 100’s of dedicated multi-system tests supported by the contractors.

This end to end system integration is being evidenced via the satisfaction of 32 scenarios relating to the Routeway and 13 scenarios relating to the Stations, each involving multiple tests. Each scenario is proven via the gathering of significant volumes of test evidence across multiple subcontracts and in some cases additional bespoke and Crossrail led complex multi-interface testing. This serves to complement and supplement the test evidence supplied by the Crossrail programme suppliers, which is constrained in the extent to which it can demonstrate true system integration.

Figure 5 and Figure 6 below depict an illustrative integration hierarchy and the elements and main systems which make up the Central Operating Section Railway System respectively.

Figure 5. Illustrative integration hierarchy

Figure 6. Central Operating Section elements and systems

Example Routeway Integration test scenario

An example of an important routeway integration test was a safe de-trainment and evacuation of passengers from a train in the event of an emergency (train fire) in the tunnel. It is simple to describe; train stops in the tunnel, passengers evacuate onto the tunnel walkway, walk to the station platform to egress through the station. However, this involves a multitude of systems working together including; signalling, train, communications (GSM-R for voice and SCADA for alarms), tunnel ventilation, tunnel lighting, door force compliance and CCTV. Expected performance of notable test components explained:

• Tunnel ventilation: to be requested to start operating and provide incident airflow in the requisite direction (extracting smoke). Request to be made by the driver to the Route Control Centre via in-cab GSM-R.
• Tunnel lighting: to switch on automatically in the relevant tunnel sections when tunnel ventilation fans start. This enables passengers departing the train on to the tunnel walkway, to see clearly and provides guidance through the safe exit route.
• Cross passage and platform end doors: doors routing passengers between tunnels (which may be required depending on the specifics of the emergency) and doors at the end of the tunnel walkway leading onto the station passenger platform.
  • Doors being opened are to trigger relevant system alarms to the Route Control Centre and local Station Operations Room, and CCTV images are to be present.
  • Forces required to open the doors are to be compliant to various legislation

Example Station Integration test scenario

An example of a complex integration test involved Civils, Architecture, Tunnel Systems, Train, Mechanical Smoke Ventilation Control Systems and Fire Safety System. For this specific test, there is a requirement to demonstrate that in the event of a train or platform fire, passengers and station staff can safely evacuate the station without being trapped by smoke or evacuation doors. This also involved ensuring a sufficient level of air flow to control smoke and also ensuring the air flow wasn’t so excessive to create a hazard or risk to passengers or staff.

This required coordination and integration with technical, operational and maintenance teams. The early phase results of this test were unexpected which led to further design reviews and changes to the system response in order to achieve the expected outcome in line with industry standards and safety / operational regulations.

Further practical examples of Crossrail led integration testing are referenced later in this document, and Figure 7 illustrates the logic from a stations perspective.

Figure 7. Testing and Commissioning logic for stations

4. Best practice examples

The below section gives best practice and practical examples of Crossrail’s work in systems integration.

4.1 Evolving organisational capability and structure

As with all major programmes that span multiple years, there is a need to evolve the organisation and associated governance to be right for the programme at that time and the road ahead.

Strategic considerations exist, including:

• What do we mean by integration, and are programme and systems integration the same / managed through the same vehicle?
• Who integrates? And what organisational design, capability and resource type / level is required to facilitate?
• When is the right time for the Integration organisation to take the lead from the Construction / Installation organisation?
• How is integration managed commercially?

Two good examples of evolutions made are:

Fully complete to staged completion

Per Section 0 Crossrail undertook a change of completion strategy for the programme in early 2019. This required the definition of what needed to be completed to enter each of the subsequent programme stages in the COS; ensuring that the overall capability available upon entry to the next stage would be acceptable to all, including meeting the assurance needs related to safety, operability, maintainability and performance.

Once this scope was set, the delivery organisations were then tweaked to ensure schedules were prioritised accordingly.

Integration organisation taking the lead from construction

Crossrail has recognised its role as integrator from early on in the programme, building integration capability that is placed into various parts of the overall organisation structure.

As the programme was approaching the end of the Dynamic Test phase and entry into the Trial Running phase, an organisational evolution brought key integration capability into the same part of the organisational structure, with Programme Integration sat directly beneath the Programme Director, and included:

• System Integration
• Trials, Testing and Commissioning

These two sub-parts of the organisation effectively house the focus of integration capability on the programme and facilitate the collaboration of others to achieve the integration goals.

Integrated Delivery Teams (IDTs)

To achieve improved integration during the latter part of the Dynamic Test programme phase, and particularly to cultivate collaborative working and to ensure alignment of delivery and technical teams, Crossrail introduced IDTs.

IDTs were put in place for each contract (whether that be a station contract or system-wide contract) and included representation from seven key functions as a minimum – see Figure 8 for the breakdown of the functions.

Figure 8. IDT concept illustration

This change was very effective on multiple contracts, most notably where assigned resources had the required capacity to undertake their role in the IDT alongside their wider functional role and with the associated decision-making authority to operate as an effective team.

The use of IDTs is a good example of Organisational integration.

4.2 Key Integration Areas

The below section describes selected examples of key integration areas established based on risk.

Train and signalling

The challenge of integrating the Train and Signalling systems is driven by the complex requirement to integrate four signalling systems on board the Train (AWS/TPWS/ETCS/CBTC) and display the outputs to the driver on a single display. This was to be done in the context of a number of key external interfaces (Platform Screen Doors, Automatic Route Setting, Timetable systems, Customer Information Systems, GSM-R etc.).  This required coordination at the functional level as well as the operational level and drove the need to bring together the delivery of the Train and Signalling functionality.

To address this an integrated ‘Plateau’ team was formed. Plateau provided the Systems Integration environment for the train and signalling contracts to collaborate and resolve issues together. This enabled better solutions to be developed and for the configurations of each of the systems to be aligned to deliver the required functionality when needed and ensuring the associated Assurance to be in place. Plateau includes representation from the project, contractors, COS infrastructure manager, the operators and also NR, ensuring operational integration is part of the discussion alongside technical and schedule considerations.

Plateau have created joint schedules, clear functional baselines for software that addresses each migration point and clarity on Operational arrangements to support the interim delivery states. Figure 9 provides an extract from the train and signalling functionality baseline configuration map. An example of a jointly created and owned deliverable of Plateau.

Figure 9. Extract sample from train and signalling functional baseline configuration map

Plateau is a good example of Technical, Operational and Organisational integration.

Stations

Station integration for one of the world’s most advanced digital railways is complex. Further, Crossrail is building ten new Central London stations with different Tier 1 contractors, which will be handed over to one of two Operators; LU or Mass Transit Railway (MTR) on behalf of Rail for London (RfL), and one of two Infrastructure Managers; LU or RfL. Given the sheer breadth of stakeholders alone, a co-ordinated approach to how stations would be integrated individually and with consistency across them all was important.

Building on the success of Plateau (referenced above), a Plateau 2 team was created specifically to focus on commissioning stations for operational use. It is also a good example of Technical, Operational and Organisational integration.

Plateau 2 comprises Crossrail, the system wide Tier 1 supplier for communications, Infrastructure Manager, Operator and stations Tier 1, 2 and 3 contractors.

It provided a central hub for deciding changes in strategy and plan for bringing stations into use operationally, and the basis for a weekly planning and monitoring review.

Plateau 2 developed a seven-step phased approach to achieve operational integration that complements, see Figure 10.

• Steps 1 – 4 – Baselining and locking down the configuration
• Step 6a – 6b – Cutting over systems and Bringing in to Use
• Step 7 – Operator takeover

Figure 10. Plateau 2 phased approach to testing and commissioning

Railway integration de-risking

During the Trial Running phase, a key focus is sustained timetable running. Trial Running commenced with operating 4 trains per hour (TPH), building to 8 TPH then 12 TPH. The Trial Running phase objective is to demonstrate railway system level performance, operational capability requirements and reliability growth.

Prior to Trial Running, opportunities for running sustained timetable running were initially limited, with the focus of the Dynamic Test phase being to prove system level functions delivered by each contractor. With Crossrail operating under a Railway and Other Guided Transport Systems (Safety) Regulations (ROGS) exemption, the volume of test trains in operation on the infrastructure was limited in the Dynamic Test phase initially to 4 maximum.

In order to de-risk the transition into Trial Running, to enable earlier defect discovery and to obtain the maximum value from the completed railway infrastructure in the period of preparedness for entry into Trial Running, an activity known as System Integration Dynamic Testing (SIDT) was undertaken. SIDT operated under a revised ROGS exemption, introducing sustained timetable running of up to 8 trains in the COS to better emulate revenue service requirements and to flush out issues not seen by discrete sub-system focussed tests with fewer trains.

SIDT had an additional significant benefit of enabling earlier exercising of operational processes that would be introduced in the Trial Running phase, and of building Operator familiarity with the railway assets, functionality and restrictions.

It was a deliberately executed technical, operational and organisational integration de-risking activity that delivered significant learning to Crossrail, the IM and Operators ahead of entering the Trial Running phase.

5. The practicalities

This section describes some of the key practical challenges and decisions to be made when integrating a railway, using real examples from Crossrail.

5.1 When to start integration testing

Building on Section 3.7, there is a natural sequence to Testing and Commissioning of each system. However, each system doesn’t require the same amount of effort, make the same progress or start at the same time. This creates a dilemma as to when you start to integrate systems together.

To minimise schedule risk, there is a desire to undertake integration testing as soon as possible as part of planned ‘defect discovery’, noting that the lead time for fixes, especially in software systems, can be significant and threaten the critical path. This is to try and find the issues seen only when you exercise the end to end integrated systems, as opposed to testing in isolation. However, test too soon in the knowledge that multiple configuration changes are still pending increases the risk for tests to be repeated (possible duplication of effort) or results to be misleading.

There is no one size fits all approach. The answer is a judgement based on risk, considering the specifics of:

• Interface priority – is the interface critical to safety / performance, or non-vital? Is the interface an enabler to other dependent systems or activities?
• Interface complexity – is the interface complex? New novel technology?
• Interface readiness / maturity – where is each system in its own testing and commissioning process?
• Schedule impact – what is the impact of finding defects at this stage vs a later stage? If defects are found between two systems, what is the typical lead time to resolve? If a long lead time, it may drive earlier testing.

Crossrail led Stations and Routeway Integration testing was started approximately two thirds through the project Dynamic Testing phase, with testing planned into Trial Running.

An example of an integration test performed early was of the Transparent Link function. This is a communications link between the train and Route Control Centre that provides live train status information centrally from the fleet. This was prioritised as it was a complex interface that could have relatively lengthy lead times associated with any issues found. It was therefore planned deliberately early as part of defect discovery to mitigate schedule risk.

In another example, during the Phase 3 testing, Crossrail experienced several integration issues across multiple station Mechanical, Electrical, Public Health (MEP) assets. Some of these issues required decisions from the engineering directorate including reassessment of systems design.

Based on the design issues experienced and the time required to resolve, other station integration tests were brought forward even though some of the sites weren’t practically complete to support this fully. To enable this approach, alternative arrangements were required to simulate the required end state test environment. This allowed the early identification of further design issues, reducing risk to the overall schedule.

5.2 How to prioritise

Further to Section 5.1, additional considerations for how to prioritise the sequence of integration testing included:

• Volume of testing required – two test shifts vs twenty test shifts for example
• Practicalities / logistics of test execution – not all tests are equal. Some are straightforward to perform, others require specialist instrumentation / equipment, or pose logistical challenges that have associated lead-times.
• Successor activities – notably assurance evidence deliverables; including whether evidence is required for safety justification, regulatory requirements or for performance predictions as examples.

5.3 Integration collaboration

The main objective of testing and commissioning is to exercise and evidence the safety, operability, reliability and maintainability of the railway and that it performs to the required levels of capability.

However, that is always set in context of achieving schedule within the allocated budget, so a lot of challenges exist to deliver integrated system testing efficiently, particularly the commercial arrangements at individual contract level. Numerous examples exist on Crossrail where projects from both sides of an interface have met their contractual requirements and everything is compliant to specification (including interface specifications between the two), only to find issues exist to achieving a functional or reliable end to end system.

Crossrail, as integrator, then needed to facilitate on multiple fronts; through project, technical and commercial leadership. Crossrail sit central to multi-contract outcomes.

The key to effective collaboration and breaking silos has been the importance of communicating context and clarity of programme milestones. Showing the necessity of achieving the collective goal, the route to get there, the associated dependencies to successor activities have all been used as powerful tools to drive motivated collaborative behaviour.

See Section 3.3: Migration plan for a tool that has been used to assist this.

An example worthy of note here is Platform Screen Door and Tunnel Ventilation System integration.

Platform Screen Doors (PSDs) are doors that line the platform edge that open and close with the train present.

An unexpected issue was found during early routeway integration testing where the PSDs would not reliably close with a train at a platform in a congested railway environment with tunnel ventilation active. For background, when delays occur and trains are congested (stopped in tunnels) awaiting their next move the tunnel ventilation system is activated automatically to provide a level of cooling into the tunnels and over the trains.

The operational impact of the platform screen doors being unable to close is that the train is not permitted to depart₁. This would provide a significant impact.

Through engineering investigation, it was concluded that both the tunnel ventilation system and platform screen door systems met their contractual requirements. Note, there is a functional and operational interface between the systems but no architectural link (no electrical or mechanical connection).

Crossrail subsequently facilitated multiple supplier inputs and led on the associated solution option evaluation, selection, implementation and testing.

5.4 Operational and organisational integration

Crossrail’s governance has periodically been evolved to suit the needs of the programme at the time. At programme level; forums exist with all parties represented reviewing readiness of each to achieve key milestones. An example of this was the Trial Running Mobilisation Board (TRMB), chaired independently, with senior representation from all stakeholders, tracking shared deliverables across organisations to achieve the common goal.

Section 0 Railway integration de-risking describes an activity undertaken prior to the Crossrail project moving from the Construction environment (using construction legislation / rules) to entering the ROGS environment. This was undertaken to make the transition from the Dynamic Test phase to the Trial Running phase easier, and to try and find process issues, human factors issues and training gaps (as examples) sooner rather than later.

5.5 The acid test question: how do you estimate the time required to test and commission a new railway?

These projects are large, complex and likely to be unique. The most similar to Crossrail is the Jubilee Line Extension, twenty years prior. For now, there isn’t an off the shelf answer of “x months / years” based on budget, number of stations, km of tunnels etc. It takes judgement based on:

1. Experience from comparable projects; noting carefully the degree of similarity – every project is different.
2. Expert judgement of the anticipated challenges. Experience can point to systems / scopes of work that are problematic vs those that may need fine tuning vs those that are relatively trouble free.
3. Consideration of the unknown / unexpected issues. You cannot foresee everything. Judgement is needed to assess how much effort and time should be allowed in the schedule to deal with things not yet in scope but will need to happen.
4. Performing a “backward pass” of the schedule; i.e. working backwards from key milestones of the steps needed, to then compare to an assessment of readiness to achieve the steps by the dates and to drive the delivery of construction.
5. Regularly updating the Quantitative Schedule Risk Analysis (QSRA) to validate the range of durations/dates.

6. Suggested lessons for future projects

6.1 System Integration starts at the top

Have clear leadership and accountability for SI at the top. This has enabled the success of Plateau and Plateau 2 teams, centred around key integration risk areas. CRL also used a Railway Integration Authority (for ‘joining it all up’ at programme level) and the Railway Integration review points as part of the governance. SI should be centralised and controlled.

6.2 Recognise the accountable integrator and incentivise

If the client doesn’t appoint an integrator, then the client is the integrator. Crossrail is accountable for integration. It has had to build capability accordingly and lead hard and soft the incentivisation of suppliers to collaborate and resolve multi-contract issues.

Consider gain / pain share type arrangements for alliances of partners that need to collectively achieve particular milestones. This drives efficiency based on the gains made due to good integration.

6.3 Create a Minimum Viable Product and staging of Operations

Give attention to creating a Minimum Viable Product as a start and build from there. Crossrail changed its opening strategy in early 2019 to deliver the COS in a staged manner (see Section 0). This promotes the evolution and maturing of both the railway systems and the operational processes and familiarity over time.

Consideration should also be given on future projects to staged operational services within the tunnelled route. Opening a service between Abbey Wood to Canary Wharf for example in the COS as a preliminary stage to full COS revenue service.

6.4 Shifting to “owning the whole”

Recognise and plan for when the Integration organisation should take the lead from Construction. System Integration should start at the inception of the project and carry on throughout the lifecycle. However, the focus needs to shift at the right time of delivery. This will vary programme to programme, and will likely be best aligned to the movement through the test and commissioning phase.

This move should coincide with the mindset and behavioural shift of moving from collaboration to ‘owning the whole’, where everyone’s success is interdependent on each other.

6.5 Don’t underestimate the power of context and clarity  

Simple, but used to great effect on Crossrail. Continually providing clarity on programme context; where everything fits, what dependencies each contract / activity has is a very powerful tool across the programme and with each of the supporting contractors.

This has been used significantly for driving multi-contract outcomes.

6.6 Create collaborative teams based on critical integration risks

The use of specific collaborative teams around critical integration risks has proven very effective on Crossrail (see Section 0.2 for detail).

The success here has been driven by:

• Focussing only those areas of critical integration risk, not all integration risk.
• Executive leadership team commitment. These teams have active participation from the top; with members of the Executive Team at Crossrail and from each of the suppliers participating.
• Long term commitment and positive mid-set. The teams have not been allowed to drift and fade away as members of the various organisations have changed over time. The overarching objective has remained, with commitment of all to achieve it.

6.7 Get ahead with defect discovery

In Section 5.1 considerations are outlined for the timing of when to start integration testing. The overriding experience on Crossrail has been that finding defects early so that fixes can be found with systems that are not fully through their respective testing and commissioning programmes outweighs waiting for ‘finished’ individual systems before testing them together.

In addition, use of simulation environments – using real connected hardware and systems wherever possible – can significantly de-risk and provide confidence in integration. Crossrail used the Crossrail Integration Facility (CIF) for this purpose.

6.8 Seek out opportunities for early operational and organisational integration

Go further than the more obvious technical integration and seek out opportunities for early insight into how things will operate and be maintained and stressing the system in different ways. Crossrail took great advantage of sustained running of up to 8 trains to better emulate revenue service in the Dynamic Test phase ahead of formally running to a timetable in the Trial Running phase. This activity delivered significant learning to Crossrail, the IM and Operators ahead of entering the Trial Running phase.

Footnotes

1. Specific overrides exist should these be required, but are not typical operations

Acknowledgements

Catherine Latham, Head of Trials, Testing and Commissioning, Crossrail

Rory Mitchell, Manager Engineering, Trials, Testing and Commissioning, Crossrail

Steve Massey, Senior Systems Integration Engineer (ex-Crossrail)

Jon Arrowsmith, Commissioning Tester in Charge (CTiC) Stations, Crossrail

Pradeep Vasudev, Head of Systems Integration, Crossrail

References

[1]        Bates J, Morris J. (2018). The Railway Integration Approach at Crossrail – Crossrail Learning Legacy