Introduction

The Project Development Agreement (PDA) states that CRL shall manage and deliver the Crossrail Project in a manner that will oblige the operators to accept handover of assets and systems. Demonstrating this had been met involved the successful handover of information structured to the level required for the operation and maintenance of that “Element” by the IM. This paper discusses information requirements capture, strategy, planning, resources, execution and reporting activities. The outputs of all these activities helped ensure handover of information required by London Underground Limited (LUL) and Rail for London (RfL), the Infrastructure Managers (IMs) of the Central Operating Section of Crossrail, and TfL as the guardian of the project archive. The scale and complexity of ensuring information handover can be illustrated by the volume of Crossrail Information generated by a project valued in excess of £16bn. It incorporated work from over 60 major contractors and their sub contractors. This produced over 650,000 asset tags with an average of 10 key attributes per asset which generated roughly 10 million documents including As Built Drawings. Crossrail information was associated to virtual system structures and in some cases assigned with IM system metadata to guarantee its traceability in the IM and TfL business systems. It was also vital to ensure this occurred at the appropriate stage of final delivery to enable acceptance of each Element of the railway, as defined in the Project Development Agreement (PDA).

Common Data Environment

The methods for management of information in the Crossrail Common Data Environment (CDE) were in line with British industry standards BS 1192:2007 “Collaborative Production of Architectural, Engineering and Construction Information” [1] , as well as its associated PAS 1192-2 [2] which facilitated handover to an operational Asset Information Model (AIM) (PAS 1192-3) [3].

Crossrail also developed a set of principles within the information model which aligned to the Building Information Modelling (BIM) method. Multiple information formats such as records, CAD and asset data were intelligently related and available to stakeholders at each stage of the project lifecycle in the CDE. Crossrail also developed a strategy for handover which aligned with TfL Pathway [4] a Project Management methodology comprising of deliverables or “Products” which demonstrate a project had been managed in line with TfL policy for information management towards handover.

Figure 1 – Crossrail PIM model demonstrates relationships between different information types

Crossrail System Architecture and Data Model

Crossrail’s CDE held information required for handover which was managed by the following systems:

• Bentley Enterprise Bridge (eB)

The Electronic Document Management System (EDMS) which managed production, review cycle, change control compliance and quality reporting of all project documents (records). It also enabled linking of related documents which would ensure schedules for example could be linked systematically to all the individual records contained in them.

• Bentley ProjectWise

The CAD models used for managing design of all permanent works. All Tier 1 and Design Contractors were required to deliver 3D model design for clash detection and spatial referencing purposes. The final as-built drawings were then 2D “sliced” views of the 3D models.

• Bentley AssetWise

The Crossrail Asset Management System for contractors to deliver their asset inventory. The Crossrail Information Handover model was aligned to the Asset Breakdown Structure so key information in the CDE relating to operation and maintenance of the assets (O&M) could be intelligently linked to the asset data in the CDE.

• ESRI

The Crossrail Geographical Information System (GIS) linked data from all the other CDE systems with publicly available geographical reference data. It provided context to engineers, asset maintainers and operators by laying asset data and links to key records into a spatial model of the railway providing cutting edge up to date mapping of the progress of the railway delivery. It delivered a truly digital railway model which mapped to and facilitated the delivery and operation of the actual Crossrail railway.

Infrastructure Manager (IM) Systems Architecture

The two IMs receiving information from Crossrail in the Central Operating Section were Rail For London (RfL) and London Underground Limited (LUL). NR were delivering key assets on the rest of the Crossrail route.

The system architecture of the Infrastructure Managers (IMs), as well as the final archive database for continued stewardship by TfL of CRL information, was managed in the TfL OneLondon domain (the network of databases that support TfL’s business systems). The process of understanding the target system’s data requirements and structure should leave time for the following:

• Testing data load capabilities
• Scheduelling progressive transfer without impacting the users of the systems from other projects
• Configuring the integration between the various business systems using the core handover information
• Making available the information needed to demonstrate operational and maintenance readiness such as training and O&M information
• Demonstrate systems readiness as part of the Safety Management System (SMS)

Figure 2 –  Indicative IM systems architecture into the first quarter 2016

Crossrail Delivery Contractor Breakdown

Crossrail Delivery contractors fell into 3 broad categories

Design

• Overall Facility design (systems, stations, portals, tunnels and shafts)
• Civils Structural Asset Design
• Architectural Design

Construction

• Civils construction
• Architectural
• Mechanical, Electrical and Public Safety (MEP) Design and Construction

Systemwide

• Linear systems Design and Construction
• Common MEP systems located in multiple facilities

The different Contractor Types were required to deliver information against a set of deliverable types agreed with Crossrail called a Master Deliverables List (MDL) which covered all information deemed necessary for asset management, technical assurance, health and safety and compliance with regulations and standards. Each Contract type was provided with a list which matched their scope of work.

• Design – Design Master Deliverables List (DMDL)
• Construction – Construction Master Deliverables List (CMDL)
• Systemwide – Systemwide Master Deliverables List (SMDL)

Figure 3  – Generic Station HMDL matrix of information sources

Handover team Strategy and Tools

The strategy for successful handover began with identifying at the highest level the purpose or function of information needed for IM acceptance of a facility and all the systems within it.  There were four possible functions:

1. Operation and Maintenance of systems and assets being handed over
2. Technical Assurance relating to those systems and assets
3. Health & Safety and environmental information relating to the facilities, systems and assets.
4. Legal, Commercial and Financial.

This allowed the contractor MDLs as well as assurance evidence and information outputs from CRL to be classed as fulfilling one of more of these higher level functions. It also drove the mechanisms for reporting progress of information readiness for handover.

The first 3 of these functions could be classed as asset or facility related and predominantly comprised of contractor information deliverables, though some higher level assurance, H&S and O&M information came from Crossrail Technical while the final function were outputs from Crossrail corporate activities. Figure 3 reflects this with the shaded regions demonstrating the type of contract deliverable information and the sources that information that all made up a standard HMDL.

IM Information Requirements Capture

Method for Identifying Handover Information Requirements in Project Information Model (PIM)

The method utilised generic Deliverable codes assigned on most contracts as part of the Works Information which allowed Crossrail to provide uniformity and track progress as a means to control information delivered by Crossrail contractors.

Figure 4 –  Crossrail Limited and Contractor MDL inputs to HMDL requirements

The Handover Information Team first identified the IM bodies within RfL and LUL who would be tasked with accepting the information at Handover in the IM operation and maintenance bodies. It was vitally important that for asset types being handed over to both IMs the same set of information requirements were agreed. The Handover Information Team first worked on gaining an agreement with both IMs on the Station assets HMDL requirements. These groupings of assets and systems also comprised the groups delivered in the Portals and Shafts. These assets mostly fell under the Crossrail definitions of Mechanical, Electrical, Public Safety and Architectural (MEPA).

Geographical Facilities MEPA Asset Information Requirements

• Station
• Portal
• Shaft
• Running Tunnel

The Handover Information Team ran a series of workshops targeted at each MEPA asset discipline group in both RfL and LU. The objective was to present:

• The process of identifying and providing a uniform structure to all  information required for handover
• The method in which the structured information would be made available to the IM business systems automatically

Linear Facilities – Linear Asset Information Requirements

The Handover Information Team also ran workshops with RfL who agreed information requirements for the remaining linear system and facility classes the CRL project was delivering:

• Communications and Controls
• Tunnels
• Track
• Signalling & Train Control
• Power
• Sidings

Different facility types delivered as part of Crossrail contained different groups of assets and systems. Therefore, smaller generic sub-HMDL templates were then developed against which facility-specific HMDLs could be measured for progress and completeness.

Figure 5: Indicative breakdown of contractor and system type per facility type and IM receiving the asset information.

Higher Level Information Functions

Operation and Maintenance Information

Crossrail were faced with a challenge in delivering O&M information which would allow RfL, in particular, to develop their maintenance regime and prepare their Maintenance Management System (Maximo) for operations in the short space of time it took for the work to be completed by Crossrail contractors, verified by Crossrail, and handed over to the target IM systems to develop their operational and maintenance readiness programmes to gain industry regulator authorisation.

Traditionally operation and maintenance manuals come in large free text documents which contain the information required to maintain an asset spread out over multiple sections. In addition every contractor delivering assets would have their own information requirements set, templates,  terminology and reference material. On a project the size of Crossrail this would take months or years to extract and restructure for upload to an IM’s maintenance management system.

Crossrail was therefore required to capture uniform structured data that could be extracted from documents relating to maintenance activities and uploaded into the IM maintenance management systems directly once verified. In addition it was seen as best practice to collect O&M referential documents to a standard set of requirements in a standard template format across all contracts.

This method of collecting information to a uniform structure enabled Crossrail to begin building a fully connected asset model of all information types and formats required by the IMs to accept assets and systems under the conditions of the PDA. It would also deliver O&M information which was future proofed, enabling the IMs to extract information from the uniform templates into a schema for data driven O&M in the operation phase of the railway.

 

Figure 6  – Key asset information associated with the system at the appropriate level for use during the whole life of the asset

O&M information from contractors was associated to the appropriate level of the Asset Breakdown Structure (ABS) as can be seen in Figure 5. However the majority of information which was needed for frequent reference by IMs was related to the Primary Functional Unit (PFU) or system. Each requirement in the O&M process could potentially necessitate supporting documents which would need to be associated to the assets in the CDE.

In order to be able to differentiate information types without an understanding of the CRL project document numbering convention, relationship types were created which would allow a project reviewer and eventually maintainers to understand the purpose of documents related to assets. The relationship types were then applied to each O&M information requirement a contractor was required to fulfil.

These then came to constitute information sets in the IM systems once handed over. LUL for example used this method for distinguishing documents in their asset document library, the Core Asset Inventory (CAI). Each relationship created during delivery was mapped to an information set in the CAI to facilitate automated handover of O&M documents.

 Figure 7 – CRL Asset Breakdown Structure with intelligently related associated documents supporting the O&M

Crossrail Technical Assurance Deliverables

Assurance was grouped into 8 separate evidence sets which delivered assurance for all Crossrail activities in delivering the railway:

1. Design
2. Construction/Installation
3. Testing & Commissioning
4. Safety & Safety Justifications
5. Trial Running
6. Trial Operations
7. IM Products
8. CRL Products

Documents providing evidence of technical assurance were collected and assigned to assurance evidence sets defined under the Technical Assurance Process (TAP). These drove the reporting mechanism for measuring progress of assurance developed by Crossrail as part of the CARE (Crossrail Assurance Reporting Environment) system.

Each evidence group was subdivided into assurance codes. The codes were then created in the CDE under CARE Virtual Item Groups. These were virtual structures of nested objects which carried metadata and the status about the documents related to them as they were evaluated under the TAP criteria. In order for a CARE evidence document to be identified and ensure it was available as assurance evidence for handover, extensive mapping exercises were carried out to map contractor MDL codes with an equivalent technical assurance deliverable (CARE) code. Each CARE code was also mapped to an equivalent IM Asset Deliverable requirement.

The assurance information was then also associated to the appropriate asset in eB to form part of the overall Asset Information Model for the whole life of the asset.

Execution

The basic process for populating an HMDL followed this method:

1. CRL review and accept
2. MDL codes verified as appropriate
3. Documents associated to the correct level of the ABS in the CDE
4. Assign IM system attributes to document in HMDL spreadsheet report
5. Progressive handover of information to IM systems once fully verified and assured by all stakeholders

Figure 8 – Example of Execution Model for handover of records to LU Livelink

For much of the asset information the Handover Information team mapped CRL contractor and assurance deliverables to Mandatory Asset Information Deliverables (MAID). This is a TfL Pathway product similar to the Crossrail contractor Deliverables Lists but driven by asset discipline rather than contract. CRL also captured additional RfL information deliverable requirements for line wide systems. By mapping contractor MDL deliverables to these requirements classifications Crossrail was able to demonstrate how it would to measure progress and completeness of the information required for acceptance of each element as well as the entire railway system.

With the collaboration of the Delivery and Information Compliance teams the Handover Information team communicated the extra significance or those contractor MDL codes which had been identified as forming part of the HMDL. Delivery and Information Compliance monitored the use of these codes for suitability.

Information Handover to Sponsors

TfL was one of two principal Sponsors along with the Department for Transport (DfT).

TfL were steward of the final project information archive, retained in the project Common Data Environment and associated to virtual structures which had been mapped to the equivalent TfL information governance schedule. The TfL Information and Records Disposal Schedules were used as the source structure against which CRL business information was mapped. The Handover Information team worked with the Crossrail IT Directorate to develop virtual structures in the CDE which mapped to TfL Disposal Schedule requirements providing structure to the business handover information.

All information which could be mapped to an applicable TfL schedule item was identified. This process involved the Handover Information team assisting each Crossrail business group in the development of a Departmental Handover Information Plan (DHIP). The plans detailed the following:

• Stakeholders who required the information the function held, for handover
• Development of the schedule for handover
• Identifying information required for handover which was not managed in the CDE and how it would be ensured it was uploaded to the CDE prior to programme completion or the phasing out or transitioning to TfL of the function.
• Creating a relationship between each business record and the appropriate virtual TfL Record group structure in the CDE. This was key to ensure any items required for a specific Element handover could be identified by its associated Corporate HMDL (CHMDL) code and tracked through the element HMDL process.

An example of this was the Commercial Directorate’s DHIP which identified all the various sources of key handover information per contract which would need to be passed on to TfL. Some of this would also be required for an element HMDL. The commercial team developed a virtual hierarchy in eB to manage the information needed for handover similar to a contractor’s MDL. This meant the key information could be tracked through to completion and the overall progress of the key information deliverables per contract tracked to contract completion.

 Figure 9 – Commercial Directorate Landscape

Programme-wide collaboration

A key part of ensuring the methods and processes developed by the Handover Information team was the collaborative approach developed with nearly every Crossrail function.

• Project Delivery Information Management team educated the CRL Document Controllers on the appropriate processes and educated all contractors involved with information management on the importance of correct metadata assignment
• Project Delivery Engineering team ensured that the generic HDML could be tailored per Element (facility) of the railway to ensure the correct information was collected at each location
• Information Compliance Team ensured the contractor MDLs were correctly change controlled and contractors complied with the requirements which affected the generation of the HMDL structure and the application of documents to those structures
• The Asset Information team worked on providing the asset structure against which documents would be associated to ensure every single asset handed over had all necessary records associated to them in the CDE system to demonstrate traceability of key information assigned to the appropriate level of the Asset Breakdown Structure
• Contract Administration provided justification for programme wide publication of the Operation and Maintenance Information Requirements which allowed Crossrail to collect all key information for operation and maintenance and assign it to the correct asset(s)

Conclusion

This is a technical paper to demonstrate the importance of proper management of data contained in Crossrail core systems and activities which will be needed to ensure successful handover of the information to IM systems. This needs to be done on schedule and with the quality, traceability and usability of information sufficiently demonstrated to enable its acceptance. This will be done so key information can be used by the IMs prior to final handover for developing their operation and maintenance readiness plans and developing or updating their Safety Management System (SMS) to gain regulatory authority to operate. It is also vital for aiding the RfL in configuring their systems to provide useable information for Crossrail assets during their full lifecycle.

Lessons Learned

1.  Contractor Master Deliverables List (MDL) should be clearly defined with clear description of what that deliverable represents. While CRL MDL deliverables were described in the Works Information documents which formed part of each Crossrail contract there was not always a clear definition of the deliverable, or the criteria for determining if a deliverable code had been correctly assigned and delivered
2.  Contractor MDLs should be defined to incorporate the view of those who will receive information at handover. Due to the long duration of large infrastructure projects and therefore the likelihood that the information architecture used by stakeholders, this will inevitably need to be refreshed. However mapping the MDL deliverables to a requirement from the operator/maintainer business processes means changes to those processes can be change controlled and highlighted if mapping to a new requirement is necessary

This technical paper is relevant to client organisations on a major project considering their information handover strategy as well as BIM and Information Management SMEs. This paper can also be of use to the following:

• Any project or organisation which is handing over information that is managed within multiple systems and integrated using BIM principles

• Handing over to a recipient who is configuring or upgrading systems over the course of a project lifecycle into which information has to be transferred before and during project handover.

References

1 BS 1192:2007 “Collaborative Production of Architectural, Engineering and Construction Information”

2 PAS 1192-2 http://shop.bsigroup.com/Navigate-by/PAS/PAS-1192-22013/

3 PAS 1192-3 http://shop.bsigroup.com/forms/PASs/PAS-1192-3-2014/

4 Transport for London (2013) TfL Pathway:  http://www.content.tfl.gov.uk/Item04-TfL-Pathway-PPP-May-2013.pdf