Introduction and Industry Context

The Central Operating Section of the Elizabeth line is the first large scale railway project in UK to be built and assessed under the Railway Interoperability and Safety Regulations.  The Authorisation for Entry into Passenger Service (APIS) by the Office of Rail and Road (ORR) involved the assessment of more than 6000 evidence submissions from 450 projects over different stages of the design, testing and trial operation until completion.

This paper explains how this process was managed and provides learnings which will be of use to future schemes following the APIS authorisation process.

The Opening Strategy

The all-encompassing strategy for Elizabeth Line Authorisation for Entry into Passenger Service was first developed in 2016 and provided a successful framework for scoping the safety assurance to Network Rail (NR) as the adjacent Infrastructure Manager and the Elizabeth line train operator MTR-EL, see Figure 1.

Figure 1 – Crossrail route

The opening strategy was defined in stages from early in the delivery phase. The stages were revised post August 2018 to bring Stages 5A and 4A forward in the sequence – See Figure 2. This was a result not just of the delays to the project, but in response to TfL’s priorities in managing and recovering from the COVID19 pandemic. There was an opportunity to use the new trains as they became available to put them into service and maximise revenue.

Figure 2 – Opening Strategy

Stage 2A was delivered as planned in May 2018 before the delay arose. This provided 2 tph between Paddington (High Level) and Hayes and Harlington and 2tph between Paddington and Heathrow using reduced length (7-car) units (RLU). This was during the period that the services were branded TfL Rail.

The Authorisation Strategy had to be flexible and modular to allow for the associated assurance. The first and most unique scope for Authorisation was identified for Stage 4A. Stage 4A was delivered in May 2021 and provided a 12tph peak service from Shenfield to Liverpool St (High Level) using full length (9-car) Class 345 trains (FLU). This required platform modification at Liverpool St (delivered by Network Rail and sponsored by Crossrail/RfL) and modifications to the ETCS lineside equipment controlling the transitions to the Central Operating Section of Crossrail. Crossrail applied for Authorisation of the ETCS transitions to both East and West, while only the East was to be put into service at the time.

The central section was eventually opened in May 2022 with a 12tph peak service, and the service was rebranded the Elizabeth line.

High level lessons learned

Crossrail’s CEO Mark Wild has identified a set of high level lessons from the delivery of the Crossrail programme:

• Solid management systems to control data – provides baseline to control change
• Own the Whole – Output based approach. Client must own the problem and provide context of overall plan
• Transparency – trust and transparency to enable collaborative working
• Co-ordinate complexity – find focal points of progress to provide context for programme, operational and technical integration
• Don’t try to manage everything – Identify what matters and focus, staging is key to progress
• Cross the line together – involve all the players, jointly build objectives, plans and drive to completion

The first and second lessons from the above list – Own the Whole, are important in the context of Interoperability and Authorisation, and covered more extensively in this paper.

The Authorisation process

Figure 3 shows in simplified terms the process of how interoperability works in terms of deliverables specified in legislation and what is required to obtain APIS from ORR. Crossrail was the project entity for the central section, and had to produce safety justifications under the common safety method legislation, technical compliance evidence and a Summary of Compatibility. Affected parties were required to endorse or issue a non-objection. This included NR, DLR, LU, National Grid, all forming part of Crossrail’s Declaration of Control of Risk.

Figure 3 – Authorisation flow

The bodies required by the process are:

Approved Body (ApBo)

Assessment Body (AsBo)

Notified Body (NoBo) – replaced by ApBO in UK

Designated Body (DeBo)

In the process of finalising Crossrail’s documentation post the UK exiting the European Union, the National Safety Authority requested that Crossrail, as the project entity, produce their own technical file for each subsystem in the scope of Authorisation, which consolidated the files of the Approved Body and the Safety Assessment Report. This request was unexpected as none of the examples from NR’s domain and shared by ORR contained a Technical File created by NR as the project entity. The question remains whether the benchmark will be set a little bit higher for future projects.

The hierarchy for authorisation is depicted in the multi-layered pyramid in Figure 4:

Figure 4 – Authorisation Hierarchy

Crossrail followed the principles of Engineering Safety Management, in accordance with the Transport for London processes and procedures for safety assurance.

There was a further complication for Crossrail in that a new Infrastructure Manager (IM), Rail for London Infrastructure, was created to maintain the routeway assets in the central section. This was a separate safety authorisation process. The IM’s Safety Management System was an essential building block for the overall Authorisation of Crossrail.

Figure 5 shows the building blocks from the Technical Specifications for Interoperability (TSIs) which constitute the railway as a whole and identifies what parts are Crossrail’s scope for authorisation. Crossrail was responsible for the fixed infrastructure in the scope for Infrastructure TSI, the Command, Control and Signalling TSI, the PRM (Persons with Restricted Mobility) TSI and the Safety in Railway Tunnels TSI.

Figure 5 – Scope for Crossrail Authorisation

The project authorisation strategy summarised the boundary and the modular structure for the submissions. The original position was that APIS for the Class 345 trains to run on the conventional network would be obtained prior to Stage 3 authorisation, first with no ETCS, then with lines fitted with ETCS, all outside the Crossrail COS. Authorisation for ETCS on GWML was with NR and outside CRL scope.

As a knock-on effect of the delays to installing ETCS from Paddington to mile post 12, Crossrail had to instruct the installation of additional balises at the entrance/exit to Old Oak Common depot to mitigate potential loss of ETCS on the Wales and West route in the case of a hard reset following maintenance.  These were agreed to be outside the scope for Authorisation but on the National Eurobalise database.

The next phase, roll out of ETCS between Airport Junction and Paddington, required further work by Crossrail and a project has been set up working in the spirit of co-operation and in accordance with the principles of GE/RT8270 and Reg.22 of ROGS between NR, RfLI and MTR-EL.

Lesson 1

The Project Authorisation Strategy should clearly define the scope, including the interface with all duty holders.

The Approved Body Technical File references the authorisation strategy which also sets out the baseline of applicable standards. Keeping this up to date enables the project to be in the driving seat and ensures the Approved Body and Acceptance Body stay within the boundaries set by the strategy when reviewing evidence.

In the scope of the Project Authorisation Strategy, the project can state what is to be authorised and what is coming at a later stage. This approach was used for the two-stage authorisation of Bond Street station. The first stage was a mini-authorisation of the station’s evacuation route, to be used when the central section went into revenue service without Bond Street station being open for passengers. This still required the full suite of the documentation as in Figure 3.

Lesson 2

The deliverables of the Independent Assessors are not perfect at Issue 1.

Assessors can also make mistakes! There can still be a misunderstanding between ApBo and AsBo even if they are the same company!

For Crossrail, the Technical File Structure was based on the number of subsystems in the scope of authorisation, with a further split of requirements down to individual projects. The list of assets as defined in the Crossrail Programme Functional Requirements was used to compile the overall system definition. Due to the chequered history of the programme, some linear assets were effectively delivered by Network Rail (e.g. track transition to Great Eastern Main Line), others were delivered by Crossrail and handed over to NR, together with the associated evidence for compliance with the Interoperability requirements, to be included in the scope of Authorisation of NR. For GSM-R, which is the standardised radio network for railway use, the boundary for authorisation was beyond the new coverage delivered by Crossrail and matched the operational boundary required for Crossrail train services. The effective authorisation of the newly built line was only achieved by Crossrail ‘owning the whole’, as the Chief Executive Mark Wild stated, and not simply relying on projects delivering the Engineering Safety Justification for their own scope.

Figure 6 – Integrating the Contracts

Because Crossrail operates a Quality Management System, most of the assessments were done at the design stage, with only certain requirements checked at as-built stage (FDO) in Figure 6.

As a new railway, with a new IM, the Authorising body ORR would not allow Crossrail to operate with an interim statement of verification, which was previously commonly the case for projects on the national network.

Crossrail’s contracts were organised by geographical scope. Using the famous V-curve there were various points at which reviews brought evidence from all the projects into a final design overview and then marking completion and compliance in reviews for readiness, testing and commissioning and entry into passenger service.

Crossrail also created two review panels to oversee integration; the systems integration review panel and maintenance integration review panel.

Figure 7 – Safe integration under Interoperability and CSM

For Authorisation for Entry in Passenger Service, two separate work streams are clearly visible in Figure 7. While the technical files are based on the applicable clauses from the TSIs, the high level hazards for the railway are important to demonstrate safe integration. It is a known fact that the high level hazards to the railway are somewhat subjective and open to further interpretation, so the TSI requirements provided the objective and definitive additional boundary setting. A statement of verification was issued to each project for each of the stages going up the right hand side of the Verification curve in Figure 6. The consolidated and final statement of verification was not at a contract level, not at an element level but at railway level, accompanied by the declaration of control of risk under CSM.

Lesson 3

The TSI (now NTSN post UK exit from the European Union) requirements are important to be followed explicitly. Any non-compliances, however trivial are listed in the authorisation letter, together with a deadline for putting them right. Any remedial works are very expensive as they require access to the open railway.

Lesson 4

It is important to maintain an open dialogue with ORR and DfT as the Competent Authority under Interoperability.  It is worth noting that ORR does not provide an opinion either way until the formal submission. While DfT’s agreement to any deviation is mandatory to be obtained and involves a separate safety justification for each deviation. For example, to justify slightly lower platform end door frame height, Crossrail built a risk assessment argument based on the average height of people now then projected it into the future and concluded how many tall people would be likely to be on the train in case of a random unplanned evacuation exercise from the tunnel. No-one is prepared to go outside the compliance.

A high performing digital railway demands a highly integrated technical, operational and management approach.

The high level critical integration risks tracked by Crossrail and relevant to Authorisation for Entry into Service were:

• Configuration Management (systems and software)
• Platform Screen Doors
• Scada integration
• Signalling Integration and Transition between different systems
• Train Integration – e.g. platform train interface
• Tunnel Ventilation

As an example of assumptions that didn’t materialise for Authorisation, Crossrail used the maintenance vehicle to survey the as-built railway and plot the clearances because the as-built drawings produced by the contractors did not show these parameters.

Authorisation RACI

The RACI may be different depending on the leading entity responsible for Authorisation. Crossrail, as the Integrator was also the owner of the risk and there was no active sponsor’s role to independently verify the scope, see Figure 8.

Figure 8 – Scope of activities for Stage 4A

The Authorisation scope for stage 4A emerged when Crossrail looked at opportunities to maximise revenue based on what was available and operable. Crossrail followed RfLI’s change process under their existing Safety Management System as authorised under ROGS. The Interoperability Authorisation of the Signalling transition was accelerated from the original schedule and obtained ahead of the stage 3 authorisation.

A major milestone was the agreement with ORR that no or limited authorisation of CBTC was required provided that the change was demonstrated as safe by a combination of Safety Arguments. Obtaining a limited APIS for Stage 4A gave the Train Operator MTR the confidence to take on the interface and put the train into passenger service. MTR still had to do the final argument on human factors, dispatch without CBTC, door opening and closing, through their own safety panel, for Empty Coaching Stock Operation first and then for Passenger Service.

Progress charts – format

It is very important to maintain regular progress reports, to monitor the situation and de-risk the program should a concern be flagged by the assessors as design evidence emerges from the design contractors. Each period the % complete was reported and given a RAG status. Although this was a reasonably sensible measure, it wasn’t providing the project with enough granularity.  Also, some requirements from the TSIs needed evidence from multiple contractors.

When the opening date for Crossrail was set, the focus lifted to a 4 week look ahead for Approved Body File and Safety Assessment Report.  As Crossrail entered the ‘production phase’ for the Technical File ORR’s stance also ‘softened’ and the assessors commenced their reviews on draft Technical Files so they could familiarise with the scope and any open requirements.

For the last two months of preparation and progressive submissions of authorisation evidence, the flowchart below Figure 9 was issued every week.

Figure 9 – Exec summary of progress for APIS

The heat and project anxiety were excruciating at times. The Microsoft Viva function counted 139 collaborators, all contributing to deliver APIS for Crossrail in the last 2 weeks prior to the agreed submission deadline.

Link between authorisation and commencement of test activities

The flowchart in Figure 10 shows the flow of evidence.

Figure 10 – Programme Assurance phases for APIS

Until Trial Running Crossrail was a construction project and therefore exempt from the requirements of ROGS by agreement with the ORR.  At the point of completion of the Final Design Overview process as a condition to enter Dynamic Testing, Crossrail requested that the AsBo and NoBo produce intermediate Statements of Verification (by the NoBo) and Intermediate Safety Assessment Reports (by the AsBo), as part of the Progressive Assurance processes. They were not used for Entry into Service as the Railway was still exempt.

For Trial Running, Crossrail as the integrator collated evidence from all stakeholders – CRL, RfL, LU, NR and MTR, which was submitted to ORR to allow Trial Running Operation under the SMS of the Infrastructure Manager RfLI.

Crossrail Limited is the purpose-built vehicle set up to deliver Elizabeth Line. Although it was the Client organisation for the construction subcontractors, it was the delivery organisation responsible for achieving Authorisation to Place into Service. It was only possible to achieve this by capturing and cascading the requirements for Authorisation to the individual contractors by including them in the Project Work Instructions.

Conclusions

The lessons for future programmes which need to obtain APIS are:

• Project Authorisation Strategy should clearly define the scope for Authorisation including the interface to all Duty Holders
• The deliverables of the Independent Assessors are not perfect at Issue 1. There may be a conflict and misunderstanding between the ApBo and AsBo even if part of the same company!
• The TSI (now NTSN) requirements must be followed explicitly
• Share your approach with the regulator and take them on the journey
• The Delivery Organisation should be responsible for compliance while the Project Managers’ responsibility is to deliver a compliant solution rather than argue why the solution is as good as possibly achievable.

Crossrail achieved successful handover of assets to the Owners and mobilised the Operators and Maintainers for the successful opening in May 2022. It is the first rail project in UK to achieve full authorisation under the Interoperability Regulations.  The Service is performing above 95% on-time (100% most days) which is a testament to the great work of so many people on the project but also to the rigidity of the Assurance Regime under CSM and Interoperability and the ‘own the whole’ principle.