A Review of Human and Electronic Systems for the Safe Delivery of Tunnel Projects.

Dr Angus Maxwell Maxwell Geosystems Ltd.

ABSTRACT
The objective of all tunnel projects is to deliver the completed tunnel in time and in budget within acceptable environmental impact guidelines. This requires a complex interaction between a large number of people and between people and machines. Systems make all this work. Good systems can lead a project to its objective whilst poor systems can hinder. Important characteristics of all systems are their cost and capabilities, time for implementation, available inputs and outputs, user friendliness and ease of communication. Robust systems require built in redundancy and disaster recovery measures to account for whatever fate throws your way. Really useful systems integrate across multi-disciplines to bind the team together and focus resources. The paper will review human and computer systems from various points of view and look at the options for integrating these into various types of projects. 1 INTRODUCTION One of the often ignored characteristics of construction is that in many cases each project starts from scratch and once finally delivered loses almost all of its assets to other projects and companies. This is unavoidable since no company can afford to keep the workforce if no follow up project exists. As a result, systems that have evolved on one project are not always transferred to other projects. Even when successive projects occur the same teams are seldom involved or are not in place when systems are set up. 2 SYSTEM CHARACTERISTICS Systems are essential parts of modern construction. They provide the communications and the checks and balances. They introduce rigor into daily activities and control day to day risk. If set up effectively, systems provide efficiencies which translate into time and cost savings. In his 2009 Terzhagi lecture Alan Powderham stressed the importance of observational engineering in driving both innovation and safety. All systems can be divided into components of procedure and feedback. Procedure is the series of systematic steps required to undertake a task and the feedback deals with the way results are reported back to enable the procedure to be assessed and modified. Human systems work well on the procedural level provided that sufficient training is given but fail in the feedback where they are often limited by a number of factors: the speed at which information can be delivered the ability to provide the information in forms suitable for the various levels of the organization consistency of the data collected consistency in processing and analysis consistency in the formatting of reports to allow end users to compare and contrast data.

The application of standards for data and reporting can go some way to deal with the issues of consistency but then these must be controlled adding an additional overhead to the system. Machine based systems can provide improvement in each of these areas.

3 KEY FACTORS AFFECTING HUMAN SYSTEMS

Table 3.1 shows the typical contractual and organisational hierarchy of a project and the locations where systems will exist. Even in this simple Owner Engineer Contractor matrix the number of potential systems in place is large, and often in excess of a hundred systems can co-exist. Those shaded in grey in Table 3.1 are transferable in that they are corporate systems which are part of an entitys quality assurance documentation and in many cases part of a software system built into the core of the company management. At the discipline and task level, systems are largely brought to the project by individuals and are commonly based on that individuals experience of a particular type of construction. Whilst this experience is valuable it may also be somewhat prejudiced to a certain set of conditions which may not apply in the new role. Such new systems will require some effort to initiate and maintain especially with teams unfamiliar with the methods. Often the architect of the systems does not get the required quality of input because of this initial unfamiliarity. If the team subsequently transfers en-masse from one job to another the system will evolve but unfortunately this is seldom the case. Table 3.1 Systems on Construction Project by Management Stratum and Contract

Company Office

Project Group

Discipline Group

Task Group Individual

Filing Report to executive Commercial Corporate Filing Reporting Commercial project Risk management Project Tracking Geology Geotechnical Environmental Programme Construction QS Purchasing Survey Instrumentation and Monitoring Safety Methods Monitoring Filing Daily working methods Information analysis methods Reporting methods

Consider the systems in place along each stage of a Project Delivery Cycle. In addition to the variety introduced by the various corporate boundaries rigid contractual boundaries also ensure that a wide variety of different systems are used at various stages of construction

Owner

Types of systems

Subcontractor

Contractor

Engineer

projects. Very little live factual data is transferred across the contract boundaries. In most cases deliverables are PDF reports and CAD files and the ownership of the data remains with the party undertaking the contract. 4 MACHINE BASED SYSTEMS Table 4.1 shows a listing of the various systems which may be utilised during the lifetime of a project. Many of these are based on IT systems but there is an array of forms and formats used. Typically systems are initiated at the construction stage and can vary from document management to instrumentation management systems to full data management systems. 4.1 Instrumentation Systems The main driver of instrumentation systems is the sheer quantity of information which puts it beyond the capability of conventional spreadsheet management. Real time monitoring and alarms also require systems.

Figure 4.1 Instrumentation System The key requirements of instrumentation management systems: All measurement data is taken in absolute raw format and processed on the fly. Automatic processing corrections for revisions, reference level settlement, benchmark settlement, water density changes (saline vs freshwater = 2%), tidal fluctuations Built in audit reporting Mapping is project specific eg: air photos, construction drawings, geology maps Multiple alignments including heading, bench and side slash All features cross referenced by 3D distance real time

 Automatic alarms with built in filters on magnitude and rate (spike removal) Quarantine and filtering of implausible/impossible data from public domain. Fast and capable 15000 instruments >40 million records graph 5000 points in <5 seconds Secure and robust. Built in disaster recovery. Reporting to PDF with batch processing capability and to Excel for analysis by users Built in weblog to communicate with users. AAA weblog to track alerts and responses 4.2 Tunnel Data Management Systems Whilst the instrumentation systems contain information about progress and instrumentation it does not contain the technical or job specific data collected as the job is progressed. Full TDMS systems have been implemented on seven tunnel contracts over the last 15 fifteen years for the Hong Kong Government

Figure 4.2 Tunnel Data Management System The TDMS systems expand on the instrumentation systems through the addition of: Real time monitoring of TBMs, Jumbos Geotechnical records Blasting details Tunnel construction records (ring building and cutter changes) Drilling and probing Ground investigation data Environmental monitoring Water inflow records Asset information (eg. sensitive structures and utilities)

Table 4.1 Systems engaged during the Project Delivery Cycle

CONTRACT STAGE Inception Project Management Planning KEY TASKS Business modeling Programming Alignment evaluation Resource evaluation Legal evaluation Engineering Scoping Desk Study Engineering and Environmental feasibility Field study Initial Site Investigation Risk assessment Project information systems Design SI Tender Supervise Schedule Interpret Manage data Interpretation of SI data Parameters for design Geostatistics and Quantitative Risk Assessment Geotechnical design (to pile cap) Hydrogeological assessment Geotechnical interpretation Alternative designs Quantitative Risk assessment and pricing strategies for ground engineering works Works sequencing Re-interpretation of SI data with new information Value engineering Observational method Temporary works design Instrumentation installation and monitoring Observational engineering Search & condition survey Monitoring Systems Telemetry Site management systems Site supervision Geological and geotechnical services Environmental monitoring and audit Claims analysis Cost analysis Programme analysis Environmental and structural conformance Instrumentation installation and monitoring Long term performance monitoring Control systems and alarm systems Analytical services SYSTEMS None Programming CAD or Terrain Modelling GIS Spreadsheet based tools CAD CAD/GIS Geotechnical Database Spreadsheet based tools Environmental data base

NONE

Feasibility FEASIBILITY

INVESTIGATION

Investigate

Geotechnical database Environmental data base CAD/GIS

Design

Spreadsheet based analyses FE and FD analyses Limit state analyses 3D modelling tools

DESIGN

Tender

PDF reports CAD Little transfer of digital data

Engineer

Spreadsheet based

CONSTRUCTION

Contract delivery

Commercial cost control systems Programming Spreadsheet based systems Document management systems Instrumentation systems Tunnelling systems Various web sites

Commercial resolution Monitor MONITOR

Cost control systems Spreadsheet based systems Programming software Instrumentation systems often high tech

5 INFORMATION MANAGEMENT AND PROCUREMENT STRATEGY

It is clear that in most projects there is no strategy for live information transfer across contract or organizational boundaries other than in the form of reports and drawings. This is a considerable limitation if the information is to be used effectively in later stages. A possible reason for non transfer across contract boundaries is the perception that non paper data results in questionable liability. Those who define deliverables within the project delivery cycle may consider only reviewed and properly signed off reports and drawings to be worthy of handing to downstream service providers. This approach is not always applied. In the case of the Channel Tunnel Rail Link a database of over 3000 boreholes and trial pits was made available to Contractors during the bidding process to facilitate access to information. It can be argued that by making available the factual data on which interpretations are based improves the knowledge base of future project contributors. The organizational barriers are a function of the project procurement method adopted. These are summarised in Table 4.1 below. Table 4.1 Effectiveness of Systems by Procurement Model
Project Procurement Method The Private Project The Project Delivery Partner The Public Private Partnership The BOOT or BOT Scheme The Engineers Design The Design and Construct Partnering

Effectiveness of Systems Clearly defined separate roles and responsibilities systems unlikely to be unified Ultimate owner my require systems for his own monitoring but otherwise as with Engineers design Teams joined by financial shareholding in the scheme. Information systems may be shared until things go wrong As with PPP joint financial commitment may engender information sharing. Clear contractual demarcations mean information systems are only shared if specified Designer and contractor united and there is a high possibility of combined systems. Unless specified there may be no obligation to provide information to the Owner True partnering requires certain system to be shared eg. risk and progress/performance monitoring. However if the partnering has little financial incentive attached it is rare for parties to unify systems. One party delivering the project with high reliance on independent verifiers for safety. The optimum environment for unified systems.

Alliancing

Most systems are implemented at construction stage and since construction projects do not have the time to engage in systems development the systems have to be in place almost immediately. This is especially true when the need for systems only becomes apparent later in a project when the existing human systems are unable to cope and the lack of information becomes a significant risk. Whilst the systems need not be the complete the architecture must be defined such that they can be augmented later. System implementation has been driven by subcontractor, contractor, designer/consultant and owner within a variety of contractual settings. Observations on the different levels of success are documented below. Subcontractor Generally the subcontractors scope is limited and the subcontractor is interested only in parts of the system which are critical to his scope. Focus is applied because the systems are mission critical.

Contractor

If the systems are implemented by the contractor for his immediate benefit then focus will be applied. If data is to be published widely then the data entered to the system will be limited only to what the Contractor is contractually obligated to provide. If the Contractor has other systems then he is normally reluctant to integrate these into one environment if significant additional up front expense is incurred. The designer/consultant faces the most design risk on the project and therefore requires the feedback on project performance particularly for instrumentation. In this respect the focus is most acute when systems are implemented by the designer. In Engineers design contracts the resident site staff are tasked with tracking the progress and technical details of the project to ensure the job is built in accordance with the specification and contract terms. Systems implemented through the engineers site staff will be of high quality but will be limited if contractual provision is not made to require the Contractor to pass information.

Designer/Consultant

Owner

Since the owner can specify anything of the contractor and designer he is in the best position to implement the systems on the project. Since he is not the designer or contractor it is often difficult for him to define the requirements of the various parties and provide a useful environment for all.

5 ALTERNATIVE MODELS
The previous review has indicated that none of the existing forms of application of systems is entirely satisfactory. Information does not remain live across a projects lifespan and cannot pass organizational or contract boundaries except as dead PDF reports. Information provision is limited by contract obligation and in many cases information is deemed to have market value to the various organizations and is guarded. The designers who really need the information often do not get it and project wide systems are normally only put in place at construction stage. The following extracts from the Nicol Highway Joint Committee of Enquiry interim report 2004 reflect how important breaking down these barriers is to safe completion of the project. The committee state that:

There is a need to integrate information from the various instruments and to relate the crucial information to what is happening on the worksite, as well as the quality of each of the elements in the construction. These two requirements must be present in all relevant projects.
A consistent supply and collation of up-to-date and accurate monitoring information is essential. There is a need to ensure this. Its correct and timely interpretation, including comparisons between predicted and actual values, is crucial for safety. Monitoring at critical locations as construction progresses is important. This will allow adverse trends to be detected early.

It is clear from these two statements that construction control systems require the integration of all data including construction information, instrumentation results, ground conditions both assumed and encountered, design assumptions, method and prediction. Owners have the power to implement such systems across a project but not necessarily the skills since this will require a balance of IT capability and engineering knowledge. Design consultants have the understanding but will normally consider this to detract from services they would historically provide themselves.

5.1 The Independent Monitoring Consultant

The management of information flow across these boundaries is clearly in the hands of the owner. By implementing management systems for the project at implementation stage, the Owner can streamline the many processes of investigation, design and construction and manage risk and increase safety. To do this the Owner must be prepared to publish data in forms other than PDF reports and drawings. One example of an owner led initiative is the implementation of an independent monitoring consultant role by the Mass Transit Railway Corporation for its Regional Express Line Project (XRL). The XRL comprises a signature 8 hectare station with platforms underground and 26km of high speed underground alignment up to mainland China. This project is subvented to the Mass Transit Railway Corporation by the Hong Kong Government and as part of the subvention a number of independent consultants are put in place to check on the technical and financial details of the subvention.

Figure 5.1 Project Structure for Delivery of the MTRC Express Rail Link One of these is the Independent Monitoring Consultant or IMC. The IMCs role is to provide a review of the adequacy of geotechnical monitoring for the project, to independently measure

a proportion of instruments and to set up systems for the collection and processing of data from all parties. The IMC is required to report on alarms and abnormal trends and to check that movements are in line with those expected. The systems provided by the IMC are intended for the use of all parties.

5.2 The Independent Information Consultant and the MissionOS

An extension of the Independent Monitoring Consultancy successfully applied for MTR is the Independent Information Consultant. The IIC is a company spanning both engineering and information technology and able to define the requirements of the information system for the project lifetime at the outset. Early and independent implementation of systems by engineers with knowledge of all stages enables the owner to dismantle the contract and organizational boundaries which are a hindrance to effective management of the project. Only the owner can do this. The system is The MissionOS and acts as the single repository for published data on a project. In such a content and context rich environment data is displayed as designed ie: maps are displayed as maps, geographical data is displayed and accessible as live data for graphing and analysis, documents which cross reference to data and geographical objects are available through the map and data links. Normalization of all the data via a single structure and interface enables engineers to explore relationships and even to define rules which can be implemented programmatically to extract information or highlight anomalies. The IIC spans all the stages of a project and is initiated as soon as the project feasibility is to be investigated. A key part of the IIC concept is that all consultancy and construction contracts include a clause defining an interface between the consultant/contractor and the IIC, a description of the data to be published and the form in which it is to be provided. The IIC role does not negate the Contractor or Consultants ability to utilize their own systems to undertake their work. It actually facilitates this by making all historical information available. Their only obligation is to publish data and results back to the IIC. The backbone of this expert system is the project programme and the project risk register both of which should be live documents (BTS 2003, GEO 2009). Each separate job on the programme is linked via its spatial coordinates to the map. The programme determines the expected progress for that job and the system tracks the progress and any commentary. Key events eg. stoppages etc can be added to the programme at any time and the programme can be updated easily from any standard programming software. The risk register is also linked to the system by jobtype, location and jobtitle and rules are set within the register to define where and when risk profiles may change. For example: Table 5.1 Risk profile for cutter head intervention and weak ground
Risk Element The Statistic. The Monitoring. The Hazard. Susceptibility. The consequence. The Risk. Mitigation. Description Cutter change interventions are running at a frequency of 1 per 40m within ground of the current type and cutters have not been changed for 30m. The TBM is approaching a change from Grade V residual soil to colluvium. The ground type is not self supporting and cannot take compressed air Cutterhead interventions are highly susceptible to the hazard Collapse during cutterhead intervention and potential settlement of overlying utilities. High Pre-emptive interventions

As the probability of a required cutterhead intervention rises along with probability of the ground hazard the increase in overall risk of instability during cutterhead intervention triggers an alarm. The mitigation measure for this alarm will be shown. On a project with many headings it is potentially difficult for a risk manager to have all of the details all of the time. Risk registers may be many thousands of records long and contain the combined experience and expertise of many engineers and geologists. The risk engineer may not be expert in all of the areas that are covered by the register. Having increasing risks highlighted by such a system is of benefit to all parties and for greatest impact the warnings can be directed at the risk owners for immediate action. Such warnings are also published to the weblog such that action and follow up is tracked. 6. CONCLUSIONS Current systems for tunnel information management and communication seldom satisfy the requirements of all parties. Contractual and organisational barriers to information flow increase project risk, cause frustration and waste time. A kaleidoscope of high powered technical systems are in use but despite this PDF is the common data standard. This is not acceptable. Insurers, lawyers and international institutions have agreed that data from all stages of a project must be integrated, shared and communicated rapidly in order to effectively manage risk. The paper has described features of systems which are available to do this. The paper has reviewed the delivery mechanism and has concluded that the systems are best delivered by the owner using an independent specialised body combining geotechnical and tunnel engineering and IT.

REFERENCES The Incident at the MRT Circle Line worksite that ted to the collapse of the Nicoll Highway on 20 April 2004. (2004) Committee of Inquiry, Ministry of Manpower, Singapore The Observational Method - Using Safety As A Driver For Innovation. (2009) Vienna Terzaghi Lecture GEO Technical Guidance Note No. 25 (2009) Geotechnical Risk Management for Tunnel Works. Geotechnical Engineering Office, Civil Engineering and Development Department The Government of the Hong Kong Special Administrative Region The Joint Code of Practice For Risk Management of Tunnel Works (2003) The British Tunnelling Society