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.
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.
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 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.
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 entity’s 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 individual’s 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.
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 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.
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.
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.
The key requirements of instrumentation 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
The TDMS systems expand on the instrumentation systems through the addition of:
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.
|Project Procurement Method||Effectiveness of Systems|
|The Private Project||Clearly defined separate roles and responsibilities – systems unlikely to be unified|
|The Project Delivery Partner||Ultimate owner my require systems for his own monitoring but otherwise as with engineer’s design|
|The Public Private Partnership||Teams joined by financial shareholding in the scheme. Information systems may be shared until things go wrong|
|The BOOT or BOT Scheme||As with PPP joint financial commitment may engender information sharing.|
|The Engineer’s Design||Clear contractual demarcations mean information systems are only shared if specified|
|The Design and Construct||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|
|Partnering||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.|
|Alliancing||One party delivering the project with high reliance on independent verifiers for safety. The optimum environment for unified systems.|
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.
Generally the subcontractor’s 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.
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 Engineer’s 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.
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.
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 project’s 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.
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.
One of these is the Independent Monitoring Consultant or IMC. The IMC’s 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.
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 Consultant’s 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:
|The Statistic||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 Monitoring||The TBM is approaching a change from Grade V residual soil to colluvium.|
|The Hazard||The ground type is not self supporting and cannot take compressed air|
|Susceptibility||Cutterhead interventions are highly susceptible to the hazard|
|The consequence||Collapse during cutterhead intervention and potential settlement of overlying utilities.|
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.
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.