Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Hierarchical representation of information for construction methods selection Udaipurwala, Asad H 1997

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1997-0607.pdf [ 8.15MB ]
Metadata
JSON: 831-1.0050316.json
JSON-LD: 831-1.0050316-ld.json
RDF/XML (Pretty): 831-1.0050316-rdf.xml
RDF/JSON: 831-1.0050316-rdf.json
Turtle: 831-1.0050316-turtle.txt
N-Triples: 831-1.0050316-rdf-ntriples.txt
Original Record: 831-1.0050316-source.json
Full Text
831-1.0050316-fulltext.txt
Citation
831-1.0050316.ris

Full Text

HIERARCHICAL REPRESENTATION OF INFORMATION FOR C O N S T R U C T I O N METHODS SELECTION by ASAD H. UDAIPURWALA B.E. (Construction), The University of Bombay, 1993 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF T H E REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES Department of Civil Engineering W e accept this thesis as conforming to the reauired s t a n d a r d - ^ THE UIVERSITY OF BRITISH COLUMBIA October 1997 © A s a d H. Udaipurwala, 1997 In presenting this thesis in. partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department; or by his or L her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of C i v \ \ l ^ c ^ i Q & £ Y V P ) C ^ The University of British Columbia Vancouver, Canada Date \ & ^ ' O c - b p b ^ y DE-6 (2/88) ABSTRACT Selection of appropriate construction methods is key to a successful project. However, the mult i tude of available methods alternatives, and the variety of resources available to execute these methods, make the task of selecting an appropriate method very cumbersome. This is aggravated by the constant introduction of new technologies and the increasingly complex nature of modern facilities. With computing capabil it ies now becoming widely available, it would be advantageous to automate, at least in part, the task of storing information about conventional as well as new construction methods, and reasoning about their applicability to a particular project. To achieve this goal we need to develop a vocabulary for referring to construction methods and the constructed product, which is rich enough to represent the wide spectrum of available construct ion methods and projects, at the same time being simple enough for easy manipulat ion by a computer. In this thesis, we develop a standard vocabulary for referring to construction methods for use in a computerized environment to enable the user to store information on construction methods, reason about their feasibility for use on a particular project and develop a preliminary project schedule for the methods selected. The major focus is on understanding how construction professionals decide on the use of certain methods in particular project situations, and how this can be incorporated in the design of the methods selection system. This system design is discussed in detail, and parts of the system implemented to date are presented using an example for underground utility construct ion. TABLE OF CONTENTS Abstract ii Table of contents iii List of tables v List of f igures vi Acknowledgement viii 1. INTRODUCTION 1 1.1 P R O B L E M IDENTIFICATION 1 1.2 R E S E A R C H METHODOLOGY 2 1.3 T H E S I S O R G A N I Z A T I O N 3 2. P R O B L E M DEFINITION 4 2.1 L I T E R A T U R E REVIEW 4 2.1.1 Construction related literature 5 2.1.2 Literature related to other industries 14 2.2 T H E C O N S T R U C T I O N INDUSTRY 15 2.3 D E F I N I N G T H E PROBLEM SCOPE 16 3. P R O B L E M ANALYSIS 18 3.1 IDENTIFYING T H E MAJOR FACTORS 20 3.2 INTERPLAY BETWEEN T H E MAJOR FACTORS 25 3.3 ISOLATING T H E REQUIREMENTS FOR EFFECTIVE METHOD SELECTION 28 4 THE P R O P O S E D SOLUTION 30 4.1 CONCEPTUALIZAT ION 33 4.1.1 Methods and Resource Breakdown Structure (M&RBS) 37 4.1.2 Physical Component Breakdown Structure (PCBS) 56 4.1.3 Feasibility Rules 69 4.1.3.1 Modes of Operation 69 4.1.3.2 Option 2: Semi-Automated Project Setup 73 4.1.3.3 Option 3: Project Setup with access to STANDARDS 78 but with no system help 4.1.3.4 Option 4: Independent Project Setup 81 4.1.3.5 Option 1: Automated Setup 81 4.2 IMPLEMENTATION 108 4.2.1 General Comments 109 4.2.2 Methods and Resource Breakdown Structure (M&RBS) 110 4.2.3 Physical Component Breakdown Structure (PCBS) 131 iii 4 . 2 . 4 Standard Fragnets 1 3 4 4 . 3 V A L I D A T I O N 1 3 6 4 . 3 . 1 Validity of the initial idea 1 3 6 4 . 3 . 2 Validity of the implemented model 1 3 9 5 . R E C O M M E N D A T I O N S FOR FUTURE W O R K 1 4 5 5 . 1 I T E M S REQUIRING MAJOR F O C U S 1 4 5 5 . 2 W R I N K L E S THAT NEED IRONING O U T 1 4 8 5 . 3 P E R F O R M A N C E A N D USABILITY IMPROVEMENT FEATURES 1 4 9 Bibliography 1 5 1 Appendix I - E-R Diagram 1 5 7 Appendix II - Command listing 1 5 9 A p p e n d i x III- S a m p l e r e p o r t 1 6 3 LIST OF TABLES 3.1.1 Soil profile along the Yellow Brick Road 19 4.1.3.5.1 Naming convention 86 4.1.3.5.2 Sections of a structured rule file 92 4.3.1.1 Evaluation of our conceptual model against the stated aim 137 and design principles v LIST OF FIGURES 2.1.1 Schematic representation of factors affecting technology 9 transfer and diffusion decisions 3.1.1 Factors affecting the choice of a construction alternative.. 24 4.1.3.5.1 Sample Project PCBS for illustrating the addressing of 87 PCBS and M&RBS components 4.1.3.5.2 Sample Project M&RBS for illustrating the addressing for 89 a parameter of a PCBS or M&RBS component 4.1.3.5.3 Sample M&RBS for illustrating the syntax and structure 95 of a rule file 4.1.3.5.4 Sample PCBS for illustrating the syntax and structure of.... 96 a rule file 4.1.3.5.5 Schematic representation of the proposed methods selection 106 system 4.1.3.5.6 Schematic representation of the Standard level in the proposed 107 Method selection system 4.2.2.1 Template listing in Standard M&RBS 111 4.2.2.2 Window showing the contents of a newly defined 112 Method Statement 4.2.2.3 Defining Operations in a Method Statement 113 4.2.2.4 Defining a method in a Method Statement 114 4.2.2.5 Completed Method Statement for constructing a sewer 115 using microtunneling 4.2.2.6 Defining a Condition for a Standard M&RBS component 116 4.2.2.7 Parameter/Condit ion listing for a Standard M&RBS 117 component. 4.2.2.8 Form for assigning/defining a fragnet for a method in the 119 Standard M&RBS vi 4.2.2.9 Defining a Fragnet for a method in the Standard M&RBS 120 4.2.2.10 Form for defining a multi-media records for a Standard 122 M&RBS component 4.2.2.11 Associat ing a multi-media file with a Standard M&RBS 123 component 4.2.2.12 Defining the contents of a report in the Standard M&RBS 124 4.2.2.13 Resource Class definition showing the CIB-W75 classification 125 for construction equipment 4.2.2.14 Fragnet Listing under the Standard Fragnets 126 4.2.2.15 Defining the constituent tasks of a fragnet 127 4.2.2.16 Defining a Complex Fragnet 129 4.2.2.17 Project M&RBS for a Sewer Project assembled from two 130 Standard Method Statements 4.2.3.1 Template Listing for Standard PCBS 132 4.2.3.2 Standard Physical Breakdown Structure for a Sewer Project 133 4.2.3.3 Parameter definition for Standard PCBS Component 134 4.2.4.1 Copying Standard Fragnets to Project Level 135 vii ACKNOWLEDGEMENT I would like to appreciate the constant guidance and support of my supervisor Dr. Alan Russell. His keen sense of direction and thorough grasp of the realities of the construct ion industry have been invaluable in this research effort. I would also like to appreciate the insights provided by Dr. Thomas Froese into the various aspects of designing computer systems. Wil l iam Wong, the senior programmer in the Construct ion Management lab is responsible for the computerised implementat ion of the system. I would like to sincerely acknowledge his patience during the design development and his appreciation for the nuances of the design. I would like to acknowledge the financial support of The National Research Council Canada - Industrial Research Assistance Program, and the Natural Sciences and Engineering Research Council of Canada. I would like to make a special mention of my friend and col league Anoop Sharma. In an effort to come up with a complete and rigorous methods representation structure, w e decided to explore two widely divergent problem domains for methods selection, namely that of underground sewer construction and high-rise construction. Anoop 's thesis focuses on high-rise construction whereas mine focuses on underground sewer construction. The long hours we spent in discussing the requirements of our individual problem domains have influenced to a large degree the design of the system as discussed in the thesis. viii Finally, I would like to extend a word of thanks to my friends and family for their encouragement and support. ix 1. INTRODUCTION 1.1 Problem Identification It is now generally accepted by all parties concerned that planning and schedul ing is critical to the success of any construction project. What therefore is planning and schedul ing? The commonly held view is that it is breaking down the work into activities and calculating their duration and sequence. Let us look at the steps involved in planning and scheduling a typical construct ion project. They are: 1. Estimating the quantit ies. 2. Defining the activities to be performed. 3. Calculating their duration and sequence. 4. Resource allocation. They may not necessarily take place in the order specif ied. However, implied in all the above is the choice of method(s) used for constructing the structure. For example, if for constructing a concrete high-rise, the method used is installing precast elements, then the quantities and cost est imated will be those for precasting as against if the choice of method was cast-in place concrete. Therefore, method 1 selection is not only an integral but also a most essential part of planning and schedul ing. Both academicians and practitioners are aware of this and have tried to approach the problem in different ways. In practice, for example, the method selection exercise involves one or more brainstorming sessions before bidding for a job. From the academic point of view, little research has been done on what is involved in the process of method selection per se, but people have tried to break the problem down into smaller manageable chunks (e.g., crew selection, equipment selection) and come up with a solution to these. This approach, however, has the serious limitation of being too focused on the particular application domain selected and/or not being very easily implementable in practice. The object of this thesis is therefore to approach the method selection problem as a whole, investigating the requirements for effective method selection and coming up with a solution which is readily implementable in practice. 1.2 Research methodology Having identified the need for a method selection system, we now have to come up with a research strategy that would help us to satisfy this need. W e first refer to the available literature on the subject. Combining these with our own (limited) practical exper ience and advice from a few seasoned construction professionals, we seek to 2 design a method selection system. W e then try to devise a structure which would meet most (if not all) of our requirements and test this for conformance. 1.3 Thesis Organization In the second chapter we define the problem more precisely and identify its scope and limits. The third chapter analyzes the problem in depth and identifies the major factors which affect method selection. In the fourth chapter, w e present the conceptual design of a method selection environment and some selected aspects of it that have been implemented to date. The fifth chapter is our wish list of what can be done to enhance the system to make it more adaptive, responsive and usable. 3 2. Problem Definition In this chapter, we will attempt to come up with a precise scope definit ion for the method selection problem. Note that this is not the scope definition for our system, but a scope definition of the method selection problem domain. The chapter starts off with a review of related studies in both the construction and other domains. Next, we identify the various phases of a construction project and how the method selection decision may affect them. W e integrate our f indings f rom this with those f rom the literature review to come up with a robust scope definition of the method selection problem. 2.1 Literature review Not a lot of work has been done in the areas of method selection as related to construction work. However, there is a large body of research work focusing on related subjects such as construction modeling, physical representation of projects and selection systems, in the construction and other domains. W e review these studies under two sub-headings. One, details works which we have found to be of interest in the construction literature, while the other focuses on all the other industries. 4 2.1.1 Construction related literature Literature related to construction methods selection Halpin & Woodhead (1976), in their work on CYCLONE - a system for simulating construct ion operations, came up with a constituent structure for a construct ion operat ion, while defining each of its constituents. According to the authors, a construction operation has a construction method focus. It results in the placement of a def inable piece of construction, and encompasses several distinct construction processes, each having its own work technology and work task sequences. A construction process has a basic technological sequence focus and is def ined as a unique collection of work tasks related to each other through a technological structure or sequence. A work task corresponds to a fundamental field action and work unit. Ta tum (1987), in his classic paper, highlighted the importance of classifying and tracking construction technologies. He further developed the ideas laid out by Halpin & Woodhead to come up with fairly generic definitions of construction technology, resources and processes, as well as project requirements. These are: "Construct ion technology is defined as the combination of resources, processes, and condit ions that produce a constructed product." "A resource can be either materials and permanent equipment, or construction applied." "Construction processes are the methods and the tasks needed to build a constructed product." "Project 5 requirements and site characteristics are the major condit ions of construct ion technology." Zozaya-Gorostr iza, Hendrickson and Rehak (1989), in their expert system on planning construction processes, have emphasized the importance of selecting the right method of construction. However, they adopt a very narrow definit ion of a construct ion method. They define construction method as the combinat ion of resources, i.e. crews, required to perform an activity. They accordingly use a database of rules to enable the user to select the appropriate crews. They have used the CSI Masterformat to classify the crews. An interesting question is whether construct ion processes determine the activities to be performed or whether activities lead to construction processes. The authors are of the first opinion. This view is also shared by Fischer and Aalami (1996), who, in their research on the development of a computer- interpretable construction methods model, treat the need to answer the two basic quest ions asked of construction managers - "how much will it cost" and "how long will it take?" Their system proposes the use of a template to capture the information of applicability of methods to activities. Their model first determines the activities needed for a project and then assigns applicable methods to it. It starts with a seed activity and assigns the applicable methods to this. It then goes on breaking down this activity into lower level assigning applicable methods and so on. Trinh and Sharif (1996) conducted a study to assess the technological complexity of construction projects. They planned to use this analysis to determine the 6 technological capability required by local contractors to bid on projects. They used the Analyt ic Hierarchy Process developed by Saaty to assign weight ings to process and product complexity attributes, and then combined the two to come up with an overall technological complexity value for a particular project. They are of the opinion that both product (i.e., physical) and process (i.e., method) attr ibutes should be considered in assessing the technological requirements of a project. Skibniewski and Chao (1992) have also used the A H P technique in the evaluat ion of technologies. Their proposed model is a hierarchy of evaluation elements. They use the evaluation hierarchy to determine the cost and benefit factors for each of the technology alternatives by doing a pairwise comparison for each element. The two factors are then combined to determine a priority setting for each alternative. They then perform a sensitivity analysis to evaluate the change in the overall priority setting if the weighting of the evaluation elements is changed. In Skibniewski and Chao (1995), the authors extended the above process. They now obtain the weighting for each of the evaluation elements by interviewing experts. The experts are asked to give their judgment as to their acceptabil i ty of new technologies against a base (conventional) technology by giving weights to the evaluation elements. These weights are then used to train a neural network. The trained neural network then can be used for evaluating the acceptabil i ty of a new technology. 7 Adbul-Malak, Mezher and Murphree (1995) have used a new approach to construct ion method selection (an approach which we prefer). In their work, they have identified a number of potential barriers to the acceptance of a technology by the contractor as shown in Figure 2 .1 .1 . They have used these to develop a rule-based system, which the contractor can use to assist him in evaluating applicable methods. The set of barriers he wants assistance on, however, is his choice. Alternatively, the contractor can use an AHP-based expert system. In this, the contractor is provided with a hierarchy in which all the relevant factors are organized in a logical and systematic way from the goal to the factors and sub-factors, and down to the alternatives of the technology choice. The system then leads the contractor through each element in the hierarchy asking him to judge their relative importance with respect to a higher level criterion or property, i.e. perform a pairwise compar ison. These comparisons are then analyzed using A H P to rank the alternatives f rom which the user can make a choice. 8 IMPEDIMENTS Project-Imposed Constraints: • Interdependences between operations. • Site Conditions Contractor's Financial Constraints: • Sources of Funds • Assurance of Performance Owner-Imposed Constraints: • Budget • Specifications Governmental Constraints Human Resource Constraints CONSTRUCTION MARKET CONDITION Level of Competition Market Share NEEDS-BASED THRUSTS r Competitive Advantage • cost • schedule • quality r Problem Solution r Vanishing Skills Figure 2.1.1: Schematic representation of factors affecting technology transfer and diffusion decisions (Adbul-Malak, Mezher and Murphree (1995)). Further work related to construction methods was done by Leu Sou-Sen (1992) in his thesis in which he proposed the use of a semantic data model for the representation of knowledge of identification or selection of construction methods. In his research, he implemented this using a Hypertext database. The system, however, left the feasibility entirely to the discretion of the contractor. Further, once the method was selected, not much help was provided to the contractor as to the related activities and their sequencing. A l -Hammad (1991) in his thesis proposes a knowledge-based approach to the selection of construction methods. He uses a two-tiered screening approach to accomplish this. He first narrows his range of applicable methods by screening out 9 the infeasible methods using broad-brush rules. These methods are then further analyzed for their level of conformance to the project at hand. His final model , however, tends to focus more on the latter. Also, his system has one important limitation, that of keeping the knowledge completely inaccessible to the user of the system - i.e. the user cannot readily modify the rules within the system. Syal (1992) in his thesis has presented a conceptual method selection model for both the design and construction phases of a project. Syal defines a construction method as a combination of construction option and the resources needed to perform the option. His approach assumes that all projects are made up of standard work items such as those indicated in the CSI Masterformat. Associated with each work item are a number of alternatives for construction of the item. The alternative adopted for use on a project is called the construction option. Associated with each construct ion option is a defined set of resources required to perform it. In cases where a work item consists of subsection items belonging to more than one work division, for example, a concrete column which encases a steel sect ion, the work item is broken down into subsection items and a construction option is selected for each subsect ion item. loannou and Martinez (1996) have proposed the use of matched simulation to compare two alternative methods, although no formal definition of what they mean by a method is given. Their method tries to eliminate the inherent defects of individual simulation runs for each method by assigning a single random number 10 seed to each uncertain variable (in this case they have defined the uncertain variables as activities) and then comparing the results of the simulation. All the above works, however, have a few common shortcomings, which w e have summar ized below: 1. The foregoing systems have the serious limitation of being very difficult to implement in practice. All of the techniques suggested so far, al though intellectually challenging (they all seek to model the methods selection problem so as to achieve minimum user involvement in the choice of a construct ion method), cannot be used to advantage in regular construction practice. It is obvious that if the construction industry does not readily accept new technologies for carrying out their day-to-day construction work, they are still more unlikely to accept such computationally intensive techniques as proposed above. 2 . A second major shortcoming that we found in a number of these systems is the very broad and often vague scope definition. A majority of these systems try to develop a single model that can be used for selecting construction methods for a project, that is, both for the design and construction of a project. These systems thus tend to fail because they try to achieve too many things with a single model . 11 3. A relatively minor shortcoming that we found with the above is that they tend to focus on a few areas such as high-rise construction or road construct ion. Other construction domains such as underground construction tend to remain relatively unexplored. Some of these present many unexpected design and construct ion chal lenges such as varying underground conditions. Other Construction related literature loannou and Yiu (1988) developed a database for storing, tracking, and retrieving new construction technologies in a readily usable manner as a part of an initiative by the Construct ion Industry Institute. They used the CSI Masterformat for grouping the construction technologies. This database has been used by Syal (1992) and Abdu l -Malak et al. (1992) as a source for construction methods. A somewhat related body of research is that focusing on the design of selection systems for other than methods selection. A few that we looked into are the formwork selection system for construction of regular structures such as high-rises developed by Sal iman (1989), a system for crane selection for high-rise construct ion by Gray and Little (1985), the earth-moving equipment selection system by Alkass et al (1988), and a knowledge-based system for selecting excavation equipment developed by Hadjigeorgiou (1988) for the National Research Council of Canada. These works tend to focus more on the selection amongst a particular class of equipment rather then the selection of equipment for a class of works. For example, 12 although a hydraulic excavator can also be used for lifting, the system limits its selection of hydraulic excavator only for excavation operations. An except ion is the work by Lin and Haas (1996) on developing an interactive environment for the design of critical operations involving the use of large semi-stationary equipment. Another area of research that reflects more on the thought process that construct ion planners engage in while planning a project is that of selection and sequencing of activities. Echeverry, Ibbs and Kim (1991) have identified the factors affecting sequencing of activities, which include physical factors as well as factors related to the method selected. Reda and Carr (1989), in their paper on t ime-cost tradeoff, identified the conflicts raised by the use of various resources and methods when determining construction duration. Rule-based or knowledge based systems for automatic activity generat ion and sequencing have also received considerable research attention. Prominent among these are PLANEX by Hendrickson et al. (1989), HISCHED by Shaked and Warzawski (1995), and OARPLAN by Winstanley, Chacon and Levitt (1993). A related work has been the development of building product and process models which seek to give a context independent structure for representing information related to the construction product or process. The Building Construct ion Core Model by ISO, which seeks to give a detailed breakdown of all the processes, actors and resources involved on the construction of high-rises, has been examined. This 13 model proposes that a construction process be expressed in terms of a series of work tasks. A final area of research is that related to the storage and retrieval of construct ion exper ience and using this to advantage on future projects. The thesis by Lim (1989) provides an example of this type of work. 2.1.2 Literature related to other industries A lot of work has been done in the manufacturing industries for the effective selection of production methods. The shortening of product cycles and increasing customer awareness are prompting these industries to make the most out of their production units. One work that we explored because of its similarity to the construction process is the knowledge-based system for selection of the best mining method, developed by Mutagwaba and Terezopoulos (1994). This system fol lows a two step approach: first eliminate the obviously infeasible methods, and then use a rule value interrogation mechanism to arrive at a decision with some level of conf idence. Another very interesting work is the manuscript on the development of an expert system for the selection of material for structural design by the National Materials Advisory Board (1995). Software engineering also involves a choice decision regarding the best development environment for an application. One approach suggested by Liggesmeyer (1996), is the use of fuzzy logic. 14 2.2 The Construction Industry The construct ion of any project involves at least two distinct phases: 1. Design 2 . Construct ion Generally, design and construction are carried out by separate special ized companies which themselves sub-contract part of the work out to other more special ized parties. Method selection takes place in both these phases, however, the context varies significantly. In the design phase, method selection covers a very broad context. That is, given a set of requirements, a structure has to be designed taking the construction method into account. Method selection in the construct ion phase is much more focused. That is, given a structure that is to be constructed in a fixed t ime and budget, and given the general guidelines as to the method(s) to be fol lowed, formulate a detailed strategy for a plan of action identifying the major operat ions involved and the method(s) for performing these operat ions. This includes consideration of physical parameters such as site and weather condit ions, contract condit ions and the structure itself. To a large extent, the factors to be considered while making design decisions are formalized. For example, if in the design phase a decision has to be made regarding the choice of a shoring system, then the factors to be considered are the depth of excavation, lateral load on the 15 shoring, etc. The actual construction decisions are based in large part on heuristics and past experience, not much of which is documented, or the documentat ion is not in an easily usable form. For example, if in the construction phase a decision has to be made regarding the choice of a shoring system, then factors such as space availability for storage, availability of sub-trades, etc. need to be considered. Further, the construction of a structure is influenced to a large degree by the regional condit ions, trade practices and the prevailing regulations and code requirements. For example, in Vancouver the generally fol lowed Ground Wall Support System (GWSS) is Shotcreting while in Toronto it is Timber Piles and Lagging leading to different choices for the same problem in different jurisdictions. A final aspect to keep in mind is that a contractor's investment is typically greater than that of a designer, and so the degree of risk exposure is larger. 2.3 Defining the problem scope Method selection is a very fundamental aspect of the construction of every project. The decision of the method to be fol lowed is taken at different stages during construction, and it may also happen that the choice of a method at one stage affects the choice of a method at a subsequent stage, or a subsequent method decision results in a review of some assumptions previously made. 16 The scope of the method selection problem domain is, however, limited to the choice of a method to perform the key or strategic project operations. The other decisions can be categorized more as operational or tactical decisions. W e belong to the school that thinks that construction activities are a result of the choice of which processes will be used and, therefore, for us, method selection is a key to the successful planning of a project. Conventional planning and budget ing techniques, the results of which are the main decision making tools used by the industry today, rely heavily on the activity structure for a project. Thus, whi le solving the problem of method selection, we will have to develop a solution which lays out the results of our methods selection process in the form of the conventional activity structure used by existing tools for modeling a project. 17 3. PROBLEM ANALYSIS In this chapter we explore a hypothetical project scenario, that of the construct ion of a trunk sewer in a busy downtown area, in order to explore the range of issues to be considered while making a decision to adopt one or a particular set of methods on a project, and the thought process that goes into it. The scenario has been modeled loosely on the Clark Drive Sanitary Sewer project in downtown Vancouver, as well as another minor project on the outer edges of the city which the author had a chance to visit. Al though the context is a sewer project, we will try and identify as many aspects relevant to the general methods selection problem as possible. Scenario You are a senior manager responsible for planning in a construction f irm contracting for sewer construction in the Greater Oz regional district. The City of Oz has just issued a tender for the construction of a 750mm (internal diameter) concrete trunk sewer in downtown Oz on their main arterial road, the Yel low Brick Road (YBR), extending f rom the north end of Munchkin Street to the north side of O. N. (Ozland National) rail yard to tie in with an existing GORD sewer line. The entire length of the proposed sewer installation is approximately 300m. The concrete trunk sewer is to be installed at depths from 3.5 m to 6m (invert) below the existing ground surface. 18 The fol lowing table summarizes the soil conditions at the proposed pipe elevations along the length of the proposed sewer. Table 3.1: Soil Profile along the Yellow Brick Road Location Soil Condit ions O. N. Rail yard to Palace Street Invert depth 4.5 m Moist to wet, very loose to compact, SAND containing trace to some gravel variable amounts of organics including wood waste and topsoil as well as construction debris (FILL) Palace street to Fairy Street Invert level 4.5 to 6.25 m Very dense, dry, S A N D S T O N E or CONGLOMERATE, containing gravel and cobbles. Fairy Street to Munchkin Street Invert depth 3.5 to 6 m Very dense, moist, SILT and SAND, some gravel, cobbles and boulders (TILL LIKE). Contaminated groundwater is expected only in the loose materials between O. N. Rail Yard and Palace Street at depths of 2 to 5 m. The City of Oz requires you to prepare and submit a lump sum bid for the project in two weeks ' t ime. As a part of the bid submittal you are also required to submit a project plan to complete the work within a one month t ime f rame and a statement of the methods you will use to execute the project (a Method Statement), with special attention directed at the steps to be fol lowed to ensure the continued f low of traffic. 19 You also have a bid submittal for a sewer pipeline for the city of Munchkin in three days t ime. Traditionally you would call a meeting of the senior technical and site personnel and thrash out a project plan. Being a person with foresight though, you decide that this t ime when you call the meeting you will ask the members to stay around for a discussion to formulate the design of a system to aid the planners to perform method selection and initial project plan preparation, a system which could hopefully have basic knowledge of construction methods and their applicability as well as capitalize on the years of experience gained by the company. You inform the concerned senior persons and your boss of your intentions. Your boss thinks this is an excellent idea. The first meeting sets out an initial schedule of three meet ings to isolate the major factors involved in methods selection. These then would be considered in the next round of meetings to discuss actual system design. Described in the next section are the summaries of the discussions in the three meetings. 3.1 Identifying the major factors Project-related discussion l . You say that the company has done similar work in Oz a year ago. If we can dig out the project records, then we can probably use the same methods we did on that project. 20 2. The technical team suggests that we can use a phased construction technique to keep the traffic f low unhindered, but some congestion cannot be avoided. Use of a phased approach all depends on the product (sewer line) and the site characteristics, both of which need to be studied in more detail. They agree to provide the planning department with the major operations involved in using this approach. 3. To achieve the time target the planning and technical teams agree to look into the use of overtime. However, local by-laws would have to be consulted to ensure feasibility. The acceptance of local sub-trades will also be required. 4. The technical and planning departments also agree to look into the use of increased resources and crewing. This all depends on previous production f igures. 5. A senior person f rom the technical department suggests that he has heard about the use of new trenchless technologies for constructing underground utilities. This technology can be used to advantage in urban condit ions. 6. The product development team informs the group that they have been approached by several companies engaged in the trenchless installation of utilities, and they are actively researching a few interesting ones. 7. You need to know if there are any local contractors that adopt this technique. You also would like to know the approximate unit cost of the work so that you 21 can compare it with the traditional approach. The product development team agrees to find out. Method selection related discussion 1. The company has been using the open-cut technique for sewer installation successful ly for a number of years now and maintains records for all the projects it has executed. These records contain some valuable information on project chal lenges and how these were met. However, they need to be systematical ly analyzed and maintained. 2. The company has in its cadre a number of personnel, expert in various areas of sewer construction. The company seeks to leverage their expert ise by regularly providing them with training and sending them to trade shows and conferences. This long-term investment will, however, be lost to the company if the employee decides to leave or retires. 3. The company subscribes to a number of trade magazines to keep abreast of the latest construction trends. It encourages all employees to read these and other related magazines. A few employees take an active interest and collect cl ippings or references for future use. The information is, however, limited to these few individuals and does not percolate down or up through the organizat ion. 4. The company maintains an ever-increasing collection of manufacturer 's handbooks and specifications for the machines (their sizes, production rates, modes of use, etc.) that it owns and also information about any product 22 promotions sent to its office. The company even has a product development department, which investigates new products, and trends, which may provide a competi t ive advantage to the company. To refer to this data for the relevant details is, however, a very tedious and often unrewarding experience. 5. The company endeavors to keep track of the latest changes in rules and regulations and standards related to work methods, personnel safety and local by-laws. 6. The company is also heavily investing in information technology and comput ing to keep pace with the new computer-based tools. However, the company has not been able to develop the means for organizing, storing, and analyzing these discordant sources of information, resulting in these not being used to full potential. A process for method selection needs to draw from these sources of information and mold the knowledge in these sources to productive use. The company should therefore try to develop a single database capable of storing information from such a wide spectrum of sources. One of the newer employees also presents a diagram for the factors affecting construction method selection f rom a paper by Abdul-Malak et al (1995). This d iagram is shown in figure 3.1.1. 23 IMPEDIMENTS Project-Imposed Constraints: • Interdependences between operations. • Site Conditions Contractor's Financial Constraints: • Sources of Funds • Assurance of Performance Owner-Imposed Constraints: • Budget • Specifications Governmental Constraints Human Resource Constraints Contractor's Attitude Toward Risk Level of Risk Exposure CONSTRUCTION MARKET CONDITION r Level of Competition r Market Share r Expected Future Volume of Work NEEDS-BASED THRUSTS r Competitive Advantage • cost • schedule • quality r Problem Solution r Vanishing Skills Figure 3.1.1: Factors affecting the choice of a construction alternative (Adbul-Malak, Mezher and Murphree (1995))1. It is decided that you will identify a list of important factors that are needed for designing a methods selection environment and put it forth for considerat ion and finalization at the next meeting. After studying the two discussions you come up with the fol lowing list: 1. Project requirements. 2 . Product and site characteristics. 3. Previous works of a similar nature. 4. Major operations involved. 5. Process characteristics. 24 6. Resource capabilit ies and limitations. 7. Local by-laws and regulations. 8. Availabil i ty of resources and/or expertise. 9. Company Policy. 10. Market Condit ions. 3.2 Interplay between the major factors At the second meeting you present your summary but the conversat ion drifts first into the discussion of the Y B R Sanitary Sewer Project. Project related discussion 1. You inform the meeting that the records for the previous project were found and that a preliminary duration estimate was prepared based on them. However, based on the methods fol lowed previously, it does not seem possible for the project to be completed in a month's time. Resourcing up or crewing up would not help due to the space restrictions on the site which would lead to conflict. 2. The technical team informs the group that they have studied the preliminary plan based on the previous project. The previous project also used a phased approach to construction. However, a few things will need to be altered. The 1 For the sake of convenience, we have reproduced this figure from chapter 2. 25 previous project involved the use of t imber shoring throughout and there was minimal ground water seepage. This project, however, has a certain section with very loose sand and organic till with considerable groundwater seepage. This would necessitate the use of a Trench Shield support system at the location. Also, the invert level along the trench was more then the acceptable value of 6 m for t imber shoring. A luminum hydraulic shoring could be used instead. Also, considerable dewatering will need to be carried out. The possibility of using some system such as well-point or freezing to stop the seepage seems unlikely considering the congested site conditions. This means that one of the side sewers would need to be tapped to dispose off the pumped water. 3. Your team also points to the fact that the phased approach would lead to the blocking of at least one of the cross streets all the t ime due to the need for storage. 4. The liaison personnel inform the meeting of the local by-laws that prohibit work after 7 p.m. Due to the cold conditions at this t ime of the year, starting the work before 7 a.m. would not be possible. This leaves us with a t ime window of 10 hours per day excluding non-working hours. 5. The product development team inform the group that they have talked to a number of trenchless technology companies regarding this project. The response has been most encouraging. They finally decided to choose Iseki Microtunnel ing for detailed discussions as they have a local subsidiary. Based on the design of the sewer line, Iseki suggests that we can achieve the installation with a 26 minimum of trenching. The company suggests that for installing the 2.4m long pipe sections, the jack shaft dimensions need to be 3.65 m wide x 5.8 m long and the receiving shaft 2.4 m wide x 4.3 m long. This would fit in the proposed site width and provide the necessary clearance for operation of the equipment. The pits can be used for both jacking and receiving, thus serving a dual purpose. The pits will only be needed at the intersections. Tunnell ing in the soil condit ions and at the grades required can be achieved using their D ISCMOLE microtunneling head. The shafts can only be constructed using convent ional means. The achievable production rate is of the order of 1 to 1.5 m of pipe installation per hour. The microtunneling company is prepared to either sell, lease or rent the machinery and train the personnel, or take the job as a sub-contract. Considering the competit ive edge this would yield, it is better to buy the machinery. There is only one catch. The pipe has not been designed to withstand the axial jacking loads. Our company will therefore have to pursue a design change. Iseki has agreed to give a draft plan and schedule by the end of the week. 6. You say that we will prepare a draft plan and budget for the two methods and present the two to the senior management for approval. It all depends on their acceptance of the risks associated with investment in a new technology. Method Selection Related Discussion 27 The ten factors identified by you are approved at the meeting. The fol lowing points came out in the discussion on the interplay of the factors: 1. The project requirements were very important in the selection of a method as they helped in narrowing the choices quickly. For example, the requirement for maintaining the traffic f low virtually eliminated the use of the spread technique. 2 . The product and process complexit ies as well as the major operat ions and resource capabilit ies are very highly interrelated and it would be very hard to characterize one without the other. For example, the production rate for an excavator for pipe-laying is very much dependent on the weight and location of the pipe. 3. The local by-laws could be more readily interpreted as limitations on the use of certain methods as opposed to factors for their selection. 4. A l though the last three conditions, i.e. availability of resources and/or expertise, company policy and market conditions, are not actively considered while selecting the method, they are always at the back of one's mind, and therefore their effect is very intangible. 3.3 Isolating the requirements for effective method selection The third and final meeting was a short one and consisted of the fol lowing discussion: 28 Project-related discussion 1. You inform the meeting that two draft schedules and budgets were prepared and submitted for perusal by senior management. Management has decided to bid using the second method, i.e. the trenchless technology opt ion, and are reasonably confident of winning the bid, considering the advantages of the method. Discussions with City Engineers seem to indicate that if the method is accepted the design change will not be very hard to get. Method Selection related discussion 1. Considering all the discussions in the previous meetings, it was felt that for an effective method selection environment all the stated factors played major roles. However, it was found that the details for the last three factors, i.e. availability of resources and/or expertise, company policy and market condit ions, were either not easily achievable or not well documented. Also these three factors were more a judgmental decision rather then a conformance decision. 2 . In the interest of getting the system design underway, these three factors were dropped f rom the list. 29 4. THE PROPOSED SOLUTION The first step in the design of any system is to determine or bound the scope of the system, i.e. to lay down what we expect the system to perform. In the case of our system it is as follows. Aim W e are endeavoring to provide the user with a toolkit to enable him to encode his knowledge of construction methods in a readily usable form for use, as appropriate, to automate or facilitate the methods selection process for selected aspects of future projects. The final product of the system is a preliminary project plan for the particular method chosen. However, construction professionals are already engaged in the methods selection process. What, therefore, would be the benefit of using our system as against the traditional brainstorming method? Answering this question leads us to the second important step, which is to lay down the design principles, i.e. what are the benchmarks against which we will evaluate the performance of the final product? In the case of our system, these design principles are as fol lows. 30 Design Principles 1 The system structure should be as simple as possible to use, and to the extent possible we should keep the workings of the system transparent to the user. 2 The data structure should be such as to allow ease in maintaining and updating the data. W e will evaluate this using the fol lowing criteria: a. the system should be so designed as to take the burden of maintaining data consistency away from the user as much as possible. b. the system should be so designed as to allow easy updating of the data in order to keep pace with technological advancements. 3 Recently there have been t remendous advancements in the computer industry, especially in the area of information technology, and there is still a huge potential for additional development. Our system design should keep in mind these inevitable changes and be prepared to take full advantage of them as they arrive. This entails a modular system design. In case of future improvements in information technology, we can then easily incorporate them without disturbing other unrelated parts that are already implemented. 4 The system should be flexible to allow for different modes of use, keeping in mind the varying needs of different construction projects. 5 Not all people like to work at the same level of detail. Some prefer to work at very fine levels of detail while for others, coarser levels of detail are good 31 enough. The system design should recognize these varying views of users, and should cater to both. 6 Users may wish to use the system as a database of available construction methods. The system design should cater to the user's need to retrieve data irrespective of whether he needs to prepare the preliminary plan for a project. 7 The learning curve for using the system should be kept as short as possible. One of the ways this can be effectively achieved is to make use of as many industry terms as possible. Another way is to provide on-line help and wizards. The third step is to conceptual ize the problem domain and the system structure. The fourth step involves the actual system development, including refining and redefining some of the assumptions made during the third step. The final step involves evaluation of the system against the benchmarks we have set, determination of successes and failures in meeting these benchmarks, and modif ications to correct mistakes. Steps three, four and five are generally iterative and influence each other to a large extent. Al though to make the thesis more readable, we have presented these separately, the reader should keep this iterative process in mind. 32 4.1 Conceptualization Let us start by asking ourselves the most fundamental quest ion. Since we are designing a methods selection system, what exactly is a method? To answer this and other related questions let us look at a few definitions of a method: • Method: a procedure or process to obtain an object. (Webster 's Dictionary). • Technology: a technical method of achieving a practical purpose. (Webster 's Dictionary). • A construction method can be defined as a combination of construct ion option selected for the execution of the work item and the associated resources to perform the construction option. (Syal et al (1993)). • Construct ion technology is defined as the combinat ion of resources, processes and condit ions that produce a constructed product. (Tatum (1987)). • Construct ion technology or method is a combination of resources (labor and equipment) required to perform a certain activity. (Hendrickson et al (1989)). • Construct ion technology is a combination of resources, methods and environmental requirements and constraints that produce a construction product, ( loannou e t a l (1993)). • Methods elaborate higher level activity into appropriate lower level activities to link schedules at various levels of detail. (Fischer et al (1996)). 33 A statement relating to the selection of appropriate technology for a project f rom Trinh and Sharif(1996) is also worth considering in our effort to find the definit ion of a construction method: • Both product and process complexit ies need to be considered for assessing the technological requirement for a project. (Trinh et al (1996)). Two very important points that are evident f rom all of the above definit ions are: 1. Most authors agree that a method represents a process and that resources are an important element in describing it. 2 . The terms technology and method signify the same things. Al though we initially gave thought to the issue of differentiating between a construction technology and a construction method, we later dropped the idea for the same reason. For purpose of this study, therefore, we define a construction method as fol lows: A construction method is a series of ordered tasks performed by one or more resources resulting in the construction of a designed product or a part thereof. Having defined a construction method let us now define what we mean by methods selection: 34 Selecting a method involves making an informed decision about the applicability of one or more set(s) of construction methods for the construction of a designed product while satisfying all or a majority of the associated constraints. where w e define a set of construction methods as: A set of construction methods is any meaningful combination of construction methods that can be used for constructing a physical product. For example, the following can be valid elements of a set of construction methods for constructing a trench: Excavation using hydraulic backhoe and t imber shoring On the other hand, a combination of the following does not constitute a valid set of construct ion methods for constructing a trench: Blasting, Excavation using hydraulic backhoe and t imber shoring as blasting and shoring are incompatible. This definition now identifies all the information that we need to perform effective methods selection. This information and the components which provide it are as follows: 35 1. W e need to describe a method, its range of applicability and attributes. W e also need information about the set(s) of construction methods that can be used to construct a product. This information is stored in the "Methods and Resource Breakdown Structure" (M&RBS). 2 . W e need information about the designed product to be constructed. In this research we are only worrying about methods selection f rom the contractor 's point of view in a typical three step (Design - Bid - Build) construct ion contract. W e are aware that the selection of some methods may affect the design of a component . For example, if a designer has designed a sewer pipeline for installation by conventional open-cut method, the use of microtunneling and pipe-jacking as a construction method will require the pipe thickness to be increased. However, we are not treating this as a part of the research because: a . In most cases if the designer has assumed a construction method during design, he explicitly states it as a part of the construction tender. b. A majority of the decisions related to construction method selection are taken by the contractor in a conventional contract as opposed to the designer. The designer is primarily concerned about the constructibil ity of his design whereas the contractor is concerned with the detai led specif ics of how to construct the designed product. W e think it is in the latter decisions that methods selection is more important. The only facility we have provided in the system that links design and construct ion is that the user is provided with a message that makes him aware of the design 36 changes warranted by the choice of a particular construction method. Such information about the designed product and any other physical constraints that may impact the method(s) selected is provided by the "Physical Component Breakdown Structure" (PCBS). 3. Finally, we need a mechanism to reason about the applicability of methods for particular products subject to certain constraints. This is provided in the system through "Feasibility Rules". W e will now systematically develop each of the above parts of our system and then present what has been implemented to date. 4.1.1 Methods and Resource Breakdown Structure (M&RBS) W e considered a number of different data models for representing construction methods. W e found several characteristics of hierarchical and object-oriented models to be of interest to our application. Advantages of hierarchical database models include the fol lowing: 1. The ability for the user to breakdown his thoughts into progressively f iner levels of detail as he moves down the hierarchy. 37 2. A hierarchical database model is very intuitive to civil engineers who have been exposed to hierarchical classification structures during their educat ion. 3. Most of the indexes for classifying information available on the internet are hierarchically arranged and therefore we could eventually take full advantage of information available in them. Object-Oriented Database Models have the following advantages: 1. The ability to arrange methods into classes according to their common attributes. For example, excavation using backhoe and blasting can be classified as excavat ion methods. 2. The ability to inherit attributes f rom a higher level object or class. This proves very advantageous to the user if he classifies his methods by funct ion, e.g., excavat ion methods. He then only has to specify attributes, e.g., production rate for this function class and it is inherited by all the method objects in the class. W e found that the foregoing models as well as other true database models failed to provide us with the flexibility that we wanted, as stated in one of the primary design principles. Therefore we decided to implement a quasi-hierarchical, quasi-object-oriented database model which would allow us to take advantage of all the above characteristics. However, we then faced a serious problem. Most of the true database models have been developed after considerable thought and deliberation by experts to attain two 38 primary objectives, i.e., to maintain data integrity (for example, to avoid replication) and to allow for ease of maintenance (insertion and deletion). Our decision not to adopt a true database model meant that we now had to do a considerable amount of checking in our programming to ensure these objectives are met. Since we did not use any of the formal data models, our design development also did not fol low any formal design methodology. We, however, found it useful to identify all the entities in the system and the relationships among them using an entity-relationship diagram. This diagram is presented in Appendix I. In general we can say that every construction project has a single goal, for example, a pipeline installation project has a goal of laying the pipeline. This goal (primary objective) can be called the project's statement of purpose or the reason for undertaking the project. Similarly a set of methods that can be used to attain this goal or primary objective can be said to be the project's Method Statement. W e have chosen to name the root of our hierarchical tree structure as Method Statement for the same reason. Another reason to choose this name was that Method Statements is a term quite commonly used in the construction industry. It has now become common to submit a Method Statement (a statement of methods the contractor proposes to use) for major construction projects. Please note that we have not defined (and do not plan to define) the scope of a construct ion project so as not to restrict the user. Al though we discourage the user 39 f rom defining a very narrow scope for a construction project and, therefore, a Method Statement, we do not restrict him from doing so. For example, the user may choose to have a Method Statement for constructing a round column. Also, as per a true hierarchical data model, we have chosen to allow the user to define the root only once which cannot be repeated anywhere else in the hierarchy; al though a case could be made for the use of multiple roots, i.e. two or more Method Statements having a common set of methods. For example, construct t rench and construct excavation as two roots can have the same set of methods under them. The primary reason for avoiding this is that it would lead to a case of multiple inheritance and therefore additional checks. A Method Statement has the following attributes: 1. A name which has to be unique (unique, that is, among Method Statements). However, a Method can have the same name as a Method Statements. How a name is used will be made clear in the section on feasibility rules. 2. A set of Parameters and Condit ions. 3. A memo. Al though we could have allowed insertion of all methods to achieve the scope of the Method Statement directly under it, we found that mechanism to allow a Method 40 Statement to cover either a broad or narrow scope of work it is useful to insert an intermediate level. W e have termed this intermediate level as Operat ion. An Operat ion is defined as follows: An Operation is the application of resources to perform a method or set of methods resulting in the construction of a designed product or part thereof An Operat ion is also significant for creating a preliminary project plan. W e define a preliminary project plan as follows: A Preliminary Project Plan can be defined as a coarse estimation of the schedule for constructing a project. This schedule is composed of key activities required to construct a project and the relationship between these. The activities should be such that their completion marks milestones in the life of a project. If w e al lowed Methods to be included as a direct part of Method Statement, then to create the activities for the preliminary project plan we would have to map each Method as an activity. Further, we would have to forge precedence relationships between Methods. This would have been difficult for the user as the presence or absence of processes is contingent on the project condit ions and constraints. However, the presence of physical locations is guaranteed based on the Method Statement as is their precedence relationships. Since an Operat ion always operates on a physical object, for example, construct trench (construct is the operat ion and trench is the physical object) and an operation can be performed by a set of 41 methods (note that a set can be null), it can now be mapped onto an activity in the preliminary project plan and precedence relationships can be formed among them. This does away with the problem of presence or absence of methods. For example, consider the Method Statement for conventional sewer pipe installation using an open-cut technique. The presence or absence of a method of shoring is cont ingent on the soil condit ions i.e. if the trench is in stable rock there is no need for shoring and, therefore, no need for a method for it. However, physically there needs to be a trench and then only we can lay a pipeline. The operation, construct trench therefore, precedes the operation, lay pipeline. Constructing a trench may or may not involve shoring the trench. Note that the user is now working at a much coarser level of detail, that of constructing a trench as opposed to excavating trench and shoring trench. Since an operation now maps one on one to activities we now have to impose a constraint that it is an indivisible piece of work as we do not have the means to predict the number of interruptions and their effect on other operations. In our example, this, therefore, means that once construction of a trench for a pipe-run has been started, it has to be finished for a given location. Work can be interrupted between locations, however. An operat ion has the following attributes: 42 1. A name which has to be unique (unique, that is, among Operations). However, a Method can have the same name as a Operat ion. How this name is used will be made clear in the section on feasibility rules. 2 . A set of Parameters and Condit ions. 3 . A memo. A n Operat ion is performed by using one or more set of methods, depending on the project condit ions and the requirements. The next level in the hierarchy after operat ions is therefore a method. Since we are preparing our preliminary project plan at the Operat ions level, we need to perform a check that all Methods under an Operat ion are compatible. For example, the user should not specify two methods such as blasting for excavating the trench and shoring under an operat ion called construct t rench. How do we check for this? Well , in this case we do not perform a check. W e leave this check to the discretion of the user specifying the breakdown. Consider again the operation "construct t rench" for laying a sewer pipeline. The project soil condit ions indicate stable rock, implying an operation that will involve blasting as a method of excavation. However, if the contract specifically states that no blasting should be carried out, then another method for breaking the rock, e.g., using jack hammering, may have to be adopted. In some cases, especial ly for highly mechanized processes, such as microtunneling, a method signifies nothing more then the use of a piece of equipment, (e.g. Iseki's uncle mole). In such cases, 43 instead of having an intermediate method level in our hierarchy, we can allow for resources to be attached directly under an operation (this is where we diverge f rom the true hierarchical structure). W e need to check that if a resource is specif ied directly under an operation, it is compatible with any other methods specif ied. For example, putting a method called laying pipeline by pipe-layers under an operat ion Lay Pipeline is incompatible with specifying a pipe-laying machine as a resource under that operation. W e leave it to the discretion of the user. A final check which we again leave to the discretion of the user for the present is incompatibil i ty between an operation and any methods or resources directly under it. For example, an Operat ion, construct jacking shaft, cannot have a resource, microtunneling head, under it. A Method has the following attributes, not all of which need to be specif ied: 1. A name which has to be unique among Methods. On the other hand, an operat ion can have the same name as a Method. The use of a Method name will be elaborated upon in the section on feasibility rules. 2 . A set of Parameters and Condit ions. 3. A memo. A method can be performed by one or more resources. Resources, therefore, are al lowed as the next hierarchical element in our breakdown. Al though the user can specify resources for a method in great detail, ( for example, pipe-laying by pipe-44 layers requires pipe-layer, helper, hydraulic excavator, excavator operator, chain, hook, winch, rope etc.) we discourage this. It is most beneficial to specify only the key resources for a method. Resources such as chains and hooks do not help in reasoning about the feasibility of a method and are therefore unnecessary to track. Again a check of compatibil ity between the resource and the method and among the resources themselves is needed. User discretion in this aspect is warranted. A resource has the following attributes: 1. A name which has to be unique. The use of this name is elaborated upon in the section on feasibility rules. 2 . A set of Parameters and Condit ions. 3. A memo. Now consider the design of the second most important feature of a method - its procedural nature, i.e., a method is a series of ordered tasks. W e now need to allow the user to define this series of ordered tasks, which we refer to as a fragnet. A fragnet is a series of ordered tasks. A work task corresponds to a fundamental field action and work unit (Halpin & Woodhead(1976)) . Since it is a fundamental field action, its duration is dependent to a large extent on prevailing field condit ions. In some cases, however, (e.g., setting up a microtunneling machine) the duration is relatively constant over a wide range of field conditions. In this case the user must be able to specify a standard value for the duration. In all other cases w e need a 45 mechanism to deduce the duration of the tasks depending on the project condit ions. W e discuss this in more detail when we treat the actual operation of the system. A task is performed by resources. W e therefore need a way of specifying which resources are required to perform that task. Now we begin to realize the benefits of our quasi-hierarchical breakdown. Since we have resources as a sub-level to the methods and the methods are a series of tasks, we can simply assign all the resources under a method to every task for that method. The quantity of resource assignment, however, needs to be decided. This again depends on the project condit ions and has to be decided while preparing the preliminary project plan. Addit ional information required for a task is the cost of performing it. W e have not considered this particular aspect as a part of this research effort. A fragnet, therefore, consists of tasks each having duration and resource assignment (indirectly). W e now need to specify the sequencing of tasks. W e use the traditional C P M precedence relationships for this purpose. In addit ion, we now need to allow for the repetition of this set of ordered tasks over multiple locations. W e also need to make the traditional checks for loops and dangling activities. Coming back to our Methods and Resource Breakdown structure, we can now associate a fragnet as a complete object with a method to complete the definit ion of a method. 46 However, we have previously mentioned that in the preparation of the preliminary project plan, operations are mapped one-to-one to activities. Since an operat ion can be performed by one or more methods (or resources), we need a mechanism to combine method fragnets into an operation fragnet. W e can do this simply by treating each method fragnet as an object. W e can then define an operat ion fragnet as a complex object made up of several methods fragnets plus addit ional tasks, if required, to link them together. W e can now provide precedence relationships between method fragnets and also between method fragnets and any linking tasks. For example, if Task A has a precedence relationship with Fragnet B, and Fragnet B is composed of Tasks one, two and three, then in effect Task A has a precedence relationship with all three tasks. Since Tasks one, two and three also have a precedence relationship between themselves, two of the three relationships between Task A and Tasks one, two and three are unnecessary. This may seem wasteful but it is quite acceptable considering the reduction in the amount of user input and thereby maintenance of data integrity and ease of use for the user. This operat ion fragnet can now be copied as one complete entity into an activity. Indeed what would be the most desirable solution would be to provide a hierarchical planning structure at the project level, consisting of activities which themselves consist of tasks for the project so that the user can work at multiple levels of detail. If he wishes he can only work with activities, or for detailed day-to-day planning he may choose to work with the tasks. In that case then the entire operat ion fragnet would appear as a tree in the project with the fragnet name as the activity root and 47 the tasks as the branches under it. Such a planning structure is left to future work. Its development constitutes the work of an entire thesis in itself. What has been described so far enables the user to encode his knowledge of the application of various sets of methods to accomplish the construction of all or part of a project. This knowledge can come from trade journals, product literature, conference papers or indeed from colleagues. However, the strength of a human expert is derived not only from his knowledge about how to construct projects, but also f rom his knowledge of current and upcoming technologies about methods and resources. He can then use this knowledge, as appropriate, for the construct ion of new projects. Therefore, our system should be able to store such knowledge. What information should be stored to achieve maximum benefit to the user? W e keep in mind that while it is theoretically possible to store all construct ion related information, practically it should be avoided because: 1. All stored information needs to be in a form usable by the system. Information for information sake requires unnecessary computer storage which is a lways at a shortage for the average construction user. 2 . The larger the amount of data stored, the greater the effort required to maintain and update it. 48 In our Methods and Resource Breakdown structure, methods and resources are our major building blocks (Operations are context-sensit ive). It would therefore be most advantageous to store knowledge about methods and resources. W e accompl ish this by means of a classification structure. W e have introduced the concept of a method class and a resource class. A method may be classified according to function (e.g. pipe-laying methods), availability (e.g. sub-contracted methods), etc. Since w e provide no restriction for the user to use one particular classification system, it means that one method can belong to multiple classes. W e therefore should check to ensure the consistency of data for the same method listed under different classes. Such a check has not been implemented. A method under a method class can also have resources under it as in the Method Statement and have a set of ordered task (fragnet) associated with it. The attribute set also remains the same. Al though it may be advantageous to have a multi-level method classification structure, w e have avoided this because: 1. The number of methods at a construction company's disposal are not that many; and 2 . This el iminates at least one check, that of ensuring the integrity of data for the same method listed in two sub-classes under the same class or different classes. A resource class is similar to a method class with the only difference being that here we do allow for multi-level classification. Specifically, it is possible to define a 4 9 resource sub-class under a class, and then define resources under the sub-class. Again, resources have the same attribute set as in the Method Statement. Having classified methods and resources, we now need to be able to use them to build new or innovative Method Statements. Therefore, when defining new Method Statements, we need to have an ability to pick a method f rom a method class and insert it at the appropriate level in the Method Statement. W e also need to be able to access resources in a resource class (or sub-class) while defining new methods under a method class, or while inserting it directly under an operation in a Method Statement. To ensure that all methods used in any Method Statement are available for future use, we require the user to first define the method under a method class before trying to associate it with a Method Statement. W e also need to ensure that all sel f-owned as well as inherited attributes from the method class are available to a method in a Method Statement, and that any conflicts between them are resolved. A similar check needs to be done for resources. W e now address the issue of data maintenance and currency. In this day and age where information technology is becoming ever more accessible and easy to use, we should develop our system take advantage of it. Specif ication sheets for commonly used construction equipment are now available online. In addit ion, a number of developers of proprietary methods have developed checklists to aid supervisors and inspectors. This information availability is expected to increase in the future in the form of searchable databases and readily downloadable 50 specif ication sheets 2 . Therefore, we should provide the user with an interface to connect to this wealth of information. Further, if he finds that due to some reason(s) the use of particular method(s) has been prohibited by regulatory agencies, he should be able to modify his existing Method Statements easily. Addit ional ly the user should be provided with the capability to develop a local database of multi-media records. These can take the form of scanned-in articles f rom trade journals or specif ications f rom manuals, handbooks and other sources. The user should be able to readily access these records while formulat ing project plans. A n ability to search through these records is essential. For example, consider the scenario in which the user is looking for trenchless pipe installation techniques which are steerable. A quick look through all his records will enable him to quickly narrow down to steerable methods. This can be achieved by allowing the user to associate records with appropriate components in the M&RBS 3 . Parameters and Conditions: Our system design has now reached the stage where we can store information about methods and resources and use this stored information to develop effective Method Statements. However, we need to facilitate the reasoning about the 2 Most of the current information is in HTML format which is not very user friendly in terms of downloading, because of the various embeddings and other techniques used. Readily downloadable formats include PDF (Portable Document Format), Postscript, text etc. 3 Some interesting storage and retrieval techniques such as data banking could also allow users to catalog and retrieve information about multi-media records. 51 applicability of methods to suit project conditions and requirements. This help could range f rom complete and rigorous automation of the reasoning process, to just providing all the information related to a method to the user, allowing him to do the reasoning independently. To facilitate reasoning we require the knowledge of what makes one method different f rom another, and information as to a method's applicability. Every method has some inherent qualities which makes it different f rom other methods. W e call these parameters. They can be tangible items such as max imum achievable production rate, or intangibles such as disturbance of traffic (example value = minimal). Also a method requires certain conditions to be fulfilled for it to be feasible for use on a project. Condit ions deal with tangible values that need to be satisfied for a method to be feasible. For example, to use soil displacement methods, all pipe runs should be less than sixty meters in length. One might argue that a method's parameters can also refer to feasibility condit ions. For example, consider the parameter(s) for use of soil d isplacement methods. W e can have a parameter that says that maximum pipe length that can be installed in a single run is equal to sixty meters. Interpreted differently, it can be said that one of the condit ions for the use of soil displacement methods is that all pipe-runs should be less than or equal to sixty meters. What then, in our opinion, is the advantage of differentiating between parameters and conditions. Two main reasons justify this differentiation: 52 1. Parameters refer to qualities inherent to the methods. These qualit ies might not always be limiting condit ions for judging a method's feasibility. However, these may be important items for general project planning work. For example, consider the parameter of power requirement of an electrically driven pipe-jacking machine, e.g., 35 kW/hr. The knowledge of this requirement is not important for judging its feasibility, but is important when renting a generator for the project. 2. Condit ions refer to things expected from the project. They may or may not map to parameters of methods. For example, the feasibility condit ion for placing exposed cast-in-place concrete is that the precipitation should not be high Let us now look at the kinds of values that parameters and condit ions can assume and how to represent them. Some of them are obvious, such as (1) quantitative, for example, max imum production rate = 20 ft/day, or, (2) a range of quantitat ive variables, for example, operating height of CAT E70B (one piece boom, 1.39m) = -3.78 m to +6.505 m. In addition we also need to give the user with the ability to use commonly employed construction and civil engineering terms. Some examples of these would be (1) soil class names (e.g. sand), (2) group names (e.g. Gravelly sand) and (3) material names (e.g. pipe materials can be steel, reinforced cement concrete or prestressed concrete). These terms are more linguistic then quantitat ive. Addit ionally, the need exists to represent items such as permit requirements. The availability of Boolean variables ((Yes, No), (True, False)) facilitates this. 53 A similar case can be made for the need for parameters and condit ions for resources. As a next step, we need to understand how experts think about feasible methods. In general , it can be said that humans think from whole to part (Fenly and Harris (1988)), i.e. in laying a sewer pipeline, an expert would look at the project condit ions and requirements and eliminate some choices straight away. For example, consider the case where he has to reason about a project for laying a pipeline in a busy urban area. The work corridor available to him is very narrow, e.g., 5 m. The soil condit ion is such that it needs to be supported immediately. He has to lay a 1200 mm diameter sewer main. He will immediately look for alternatives to the convent ional open-cut technique, i.e. trenchless methods. He will then further narrow down the trenchless methods according to their space requirements, max imum installable pipe diameter, etc. What this means for us is that we should allow for the screening out of obviously infeasible methods before proceeding to more detailed reasoning. W e can readily achieve this by having Condit ions assigned to the Method statement which el iminates the use of that particular combination of methods, given the presence or absence of certain conditions. W e can also have parameters for Method Statement as also Method class and Resource class which reflect one general parameter of all methods and/ or resources under that particular Method Statement (or Method Class or Resource Class). This will help the user by reducing his data-entry 54 requirements and potential for mistakes. As operations are context sensit ive to the Method Statements, they do not have any parameters or condit ions assigned, but they can inherit parameters f rom a Method Statement to allow for further inheritance by methods or resources. As conditions refer to the feasibility of one specif ic set of methods (Method Statement) or an individual Method or Resource, their inheritance is not al lowed. Further, although the parameters may be common to several methods and/or resources, their values need not be the same and may actually depend on a number of variables. W e therefore allow inheritance of parameter definit ions but not their values. In our previous discussion on M&RBS, we have described a system for the user to encode his knowledge of construction methods and resources and their applicability. The user can then tailor this knowledge for use on a specific project either himself or automatical ly by using help provided by the system. To achieve this goal, we have used a two-tier system architecture. The first layer is referred to as S T A N D A R D S . A user can use STANDARDS to encode his knowledge of methods as described above. He can then use selected parts of STANDARDS on the second layer called PROJECT as applicable. This layer refers to the project at hand, with all its attendant design and site conditions. On the PROJECT layer we have provided a similar structure as for S T A N D A R D S with a few differences as follows: 55 1. W e provide the user with the ability to build only one Method Statement for a project. This Method Statement may, however, be composed of several Standard Method Statements for different facets of the project. 2 . W e do not have Method or Resource classes on a PROJECT level. 3. A l though a user can insert new operations and methods in a Project Method Statement, we do not allow him to change any of the components that he has copied over f rom STANDARDS. 4. In a Project Method Statement, for the items copied over f rom S T A N D A R D S we do not allow the user to modify any standard values for the parameters. However, we provide the user with additional fields to enter new values adjusted for the project at hand. For example, a company data sheet may provide production rates for equipment under ideal condit ions with adjustment factors for deviat ions f rom this ideal. The user may apply the appropriate adjustment factors for the project at hand in this additional field in order to generate relevant project values. 4.1.2 Physical Component Breakdown Structure (PCBS) W e have already determined that we need information about the product to be constructed. W e provide this information through the Physical Component Breakdown Structure (PCBS). 56 To design the structure of our PCBS, we need to know the information required to represent for the designed product, and/or the site context. This information includes but is not limited to: 1. The physical description of the project in terms of the components that need to be constructed to complete the project and their description. For example, in the case of a pipeline project, these are the actual pipe-runs, the manholes, the lateral service connections and any other appurtenances such as f lushing systems. W e also need to know the length of each pipe-run, the depth of installation (invert level), grade of installation, number of pipe-runs, pipe materials and sizes, number of manholes, size of manholes, manhole materials, their locations, size of lateral connections their location and number, design of appurtenances, joining techniques between the different elements, existence of bends and/or corners and their design etc. 2. The details of the construction site such as length and width of work corridor, soil condit ions such as soil type, water-table and toxicity, overhead condit ions such as overhead cables and structures, surface condit ions such as existence of pavement, its type and traffic conditions and cl imatic/weather condit ions such as average temperature, precipitation and humidity. 3. Project constraints such as t ime constraints, cost constraints, noise constraints and contract condit ions stipulating use of certain techniques. 57 4. The need for temporary structures to be constructed for use of a particular set of methods. For example, if we are using microtunneling, we need information on the location and size of jacking and receiving shafts. Consider now how one might describe the physical components of a project for purposes of method selection and evaluation. A number of authors have suggested a hierarchical structure for the physical representation of projects (Winstanley et al. (1993), Syal (1992), Hendrickson et al. (1989)) This structure we found is most suitable for t iered structures such as residential or commercial high-rises where the project can be successively broken down into lower and lower levels of detail, for example, a high-rise project consists of superstructure and substructure. The superstructure consists of typical floors. A typical floor consists of horizontal e lements (slabs) and vertical elements (columns and walls) and so on. A similar breakdown for linear construction projects such as pipelines and roads, and block structures such as dams is very difficult though not impossible. In our at tempt to develop a universal methods selection environment, we decided to use a quasi-hierarchical quasi-object-oriented structure for the physical breakdown. This structure can be adapted to the project at hand by using a deep hierarchical breakdown for tiered projects or a flat tree structure for linear projects. This structure also provides us with an easy mapping onto our M&RBS which is also similarly structured. 58 Here we describe the tree structure from the top down. At the root of the tree is the project itself i.e. the entire product, site and temporary structure combinat ion. The advantage of using this as our root will be apparent later on. W e now divide our project into one or more sub-projects, for example, a pipeline project may have one sub-project to lay a main line and another to lay a lateral service line. If there is only one sub-project, it means that the sub-project is equivalent to the project and therefore one can avoid using it. A sub-project (or project) can have one or more systems under it (this is not a very useful concept for pipeline projects). For example, a high-rise project could be decomposed into two sub-projects -superstructure and substructure. The superstructure can be further descr ibed in terms of a mechanical system, a structural system and an electrical system. Naturally a system can itself have many subsystems, e.g. a mechanical system can have a HVAC subsystem and a sprinkler subsystem; an electrical system can have a communicat ions subsystem and a power-supply subsystem; a structural system can have a horizontal subsystem of slabs and a vertical subsystem of columns and walls. Every system or subsystem is composed of elements. For example, a vertical structural subsystem is composed of elements columns and element walls, an electrical subsystem is composed of element panels and element cables. A n element can also represent temporary structures to be constructed for complet ing the system. An element can further consist of sub-elements; e.g., e lement columns can consist of the sub-element, round columns and the sub-element, rectangular columns. 59 However, what happens in the case of a pipeline project which does not have clearly divided systems or, for that matter, subsystems? W e therefore need to allow for the insertion of elements directly under a sub-project. But what happens if the project has only one sub-project? Thus we need the ability to insert e lements directly under project. Of course, the sub-elements go under the elements. Similarly, consider the scenario of a contractor who only takes electrical contracts for high-rises, and does not need to divide the project into sub-projects deal ing with substructure and superstructure. His concern is limited to a single system. However, this system has subsystems which have elements and so on. Therefore, we need to allow direct insertion of system under the project level. This obviously leads to another scenario where a system may not have sub-systems e.g. a contractor for foundat ion work for an embankment may have a drainage system of sand piles and pump and a pre-load system. However, the pre-load has no subsystem. W e therefore need the ability to insert elements directly under the system level. However, to successfully develop a system to represent the designed product, we need more than the above components. W e need to know the location at which an element or sub-element occurs. This we achieve by introducing a new component in our breakdown structure called location. A location can now represent an element or sub-element or system or sub-system, and can be duplicated as many t imes as needed, for example, for a pipeline we can have locations representing jacking shafts, receiving shafts and pipe-runs for using the microtunneling method and then we can replicate these locations the appropriate number of t imes for the project at 60 hand. For a high-rise we could have a location representing a typical f loor which gets repeated, for example, twenty-five t imes for a twenty-f ive storey project. A typical f loor can be a system component in our Physical breakdown. The important advantage that we get f rom using locations is the ability to perform spatial reasoning easily. Though we could have done the reasoning without using a location component, it would have been a lot more cumbersome. Consider, an example which involves developing a PCBS for a pipeline project which is to be constructed using microtunneling and pipe-jacking with precast concrete manholes. In terms of spatial information, we need to know the location of the jacking shaft, receiving shaft and manholes. For microtunneling, the contractor tries to position jacking shafts at the final manhole location. This saves excavat ion and related activities all the way to restoration of the surface. By using a location component , we can simply say that this component represents the location of both the jacking shaft or receiving shaft and manhole. This saves us the trouble of looking up the parameters (explained later) of the three components to determine their coordinates and an additional reasoning construct to instruct the inference engine that three components with the same coordinates have the same location and therefore only one pit needs to be dug. W e now only have to reason in the t ime domain to determine when each component is constructed. A similar case can be made for the use of the same pit as a receiving shaft and then a jacking shaft for subsequent pipe-runs. The system now only has to be instructed when the addit ional 61 installations to use a pit (formerly being used as a receiving shaft) as a jacking shaft need to be made. Another example from an unrelated construction domain is that of a typical high-rise building. A typical floor has one slab and many columns and a building has many typical f loors. In this case, we represent each typical floor by a location, and then have the appropriate components of slab and columns under it. This saves us the trouble of defining the number of typical f loors and their components as well as precedence relationships between typical f loors and among components more than once. Once defined for one system component we can replicate it the required number of t imes. The above discussion also points to the fact that locations are a means to represent the spatial positioning of one or a group of project components. Therefore we allow insertion of locations only under the project or sub-project components. W e now need to know two things: 1. Which component of the PCBS is at which location? How we achieve this is explained in detail in the section on feasibility rules. 2 . W e need to know the number of components to be constructed at each physical location. For example, if a location represents a typical f loor then we need to 62 know the number of columns per typical floor. To answer this quest ion w e need to discuss the parameters and conditions associated with a component . It is important to note that there is a difference between parameters and condit ions as they relate to the M&RBS and the PCBS. In the case of the P C B S , we define parameters as the attributes which are expected of the final constructed product (as opposed to M&RBS where a parameter is a quality inherent to a component) . Condit ions in a PCBS are the constraints placed on the project. In this case we are using a very broad definition of constraints to use items such as: 1. Contractual condit ions of t ime, cost, etc. 2 . Spatial constraints such as lack of adequate storage area, insufficient headroom, etc. 3. Unknown factors such as weather, undetected underground utilities resulting in risk exposure, etc. 4. General site condit ions such as site dimensions, surface, subsurface and overhead condit ions. Parameters by definition are localized to certain components in the PCBS whereas, condit ions are global attributes of the project as a whole (or a sub-project as a whole, if sub-projects are in varying conditions such as substructure and superstructure). It therefore appears that parameters cannot be downward inherited but condit ions can be downward inherited. For example, what is a constraint on the 63 project (or sub-project) is also a constraint for all e lements under it. However, there are except ions. As an example, a pipeline installation project consists of a number of pipe-runs each of varying length. When we reason about the applicability of a set of methods (Method Statement), it would be fairly simple to adopt a reasoning process such as: 1. Determine the total length of pipeline to be installed. 2 . Determine the t ime frame in which the project is to be executed. 3. Divide the total length of the pipeline by the t ime frame to determine the average production rate required to be achieved. 4. Compare this production rate with the achievable production rate indicated as a parameter to the Method Statement. If the production rate required/ production rate achievable is greater than or equal to one, then the Method Statement is likely to be feasible. To adopt this approach, we would need to go to each pipe-run, find its length and sum up all the lengths. This is very inefficient if a number of Method Statements are to be compared. In such cases, it would be more efficient to aggregate all pipe lengths and store them as a project parameter for easy access. W e therefore need an aggregat ion mechanism to sum up individual lower component parameter values to higher level component parameter values. To achieve this therefore we need to define the same parameters at both the higher and the lower levels in the hierarchy. To avoid this and all the associated errors, we allow for downward inheritance of 64 parameters but not their values. Parameters and condit ions can have either quantitative values, e.g. t ime frame for project completion equals 100 days, number of components of this type per location equals 3; linguistic vales, e.g. soil type is Lean Clay; or Boolean values e.g. line required to remain in service equals Y E S . Another important point to note is the case of temporary structures. Al though these structures are subject to the same conditions as the project, their parameters are dependent on the methods used. For example, Iseki microtunneling Inc. does not require the same jacking shaft diameter as Soltau microtunnel ing. Inc. Their parameter values are therefore derived from the methods used and their condit ions are all inherited f rom higher level components. In addit ion to the parameters and conditions described above, all of the PCBS components have the following properties: 1. A name which is unique to that particular level which is used for referencing this component; and 2 . A memo. As in the case of M&RBS, we provide a two tiered system architecture. Accordingly, there is a Standard PCBS and a Project PCBS. The differences between a Standard and a Project PCBS are as follows: 65 1. A l though in the Standard PCBS we can define parameters and condit ions for a PCBS component, they assume values only when they are used in the Project PCBS. How they are used is explained in the section on Feasibility Rules. Again how do we inform the user of a valid set of values for a parameter or condit ion when a Standard PCBS is used on a project. This is explained below as multi-media records. 2 . The location specification in the standard PCBS is only a template. W h e n used in the Project PCBS, this template must be replicated the requisite number of t imes for the project at hand. 3. If the user employs one of the Standard PCBSs for the project at hand, we do not allow him to modify or delete any of the components copied f rom the Standard PCBS. He can however add new components. W e ment ioned the difficulty of conveying to the user valid values for parameters in a Project PCBS. W e can solve this problem using mult i-media records which we can associate with Standard PCBS components. These mult i-media records can be notes on commonly used classification systems, government regulations, scanned in specif ication sheets for temporary structures, clips f rom training v ideos or company promotion videos, or even sound clips recorded by the person designing the Standard PCBS 4 . The possibilities are limitless. 4 Some interesting work on automated content recognition systems by Photios et al. (1995) could be used to advantage. 66 Although we have designed a viable system for representing information about the physical structure to be constructed, we immediately realize that the structure will tend to be tailored for use with a single Method Statement. This is in part due to the need to treat temporary structures. For every variation of the Method Statement a new PCBS has to be def ined. This can be a daunting and often t imes wasteful task which could prevent the adoption of our system or ones like it by construct ion planners. As an example, consider a Method Statement for installation of a sewer line using microtunneling. At present we have to dig and expose all lateral and service connect ions to the sewer. W e therefore have an element such as excavat ion for lateral in our Standard PCBS. In the near future if a system is developed which allows connect ion of laterals or service connections remotely without excavat ion as is the case with PVC pipe lining techniques, the user will have an alternative to either construct the sewer by exposing all the laterals or using this new technology. He will therefore have two Method Statements, one with the new technology and the other without. He will accordingly need two PCBSs, one with the element excavat ion for laterals and one without. The only difference between these PCBSs is the absence of this element. However, if the user has to define the entire PCBS tree again for this it will be a waste of his productive t ime. W e overcome this by al lowing the user to define individual components of the PCBS independently of the Standard PCBS tree and then use them as necessary in formulating new PCBS trees. These we refer to as Templates. For example, the user can define templates such as pipe-run element, jacking shaft element, receiving shaft element and excavat ion for 67 lateral element, and then use them as necessary to make a PCBS. He can also formulate templates for entire systems, sub-systems or sub-projects composed of lower level element and sub-element templates and then use these to formulate his PCBS tree. However, since a location is just a representation of the spatial posit ioning of a PCBS component with no individuality we do not allow the user to have a Location template. Since while defining templates we allow the user to specify parameter and conditions for the components in the templates, w e now have to perform a check to avoid conflict between these parameters and condit ions and any that are inherited f rom a higher level PCBS component. For example, consider a sewer pipeline PCBS composed of two sub-projects - main line and pump house. If w e have defined the main line sub-project as a template with its own condit ions such as soil condit ions etc. and we are defining a condit ion called soil condit ion for the project component (Root) which is to be inherited downwards, then there is a conflict between the two soil conditions. W e have to resolve this. If we had adopted a true object-oriented data representation structure, this could readily be done. For the t ime being, we require the user to check for any conflicts. W e now have robust structures to represent the physical information that we need to know about the structure to be constructed as well as our knowledge of construct ion methods. W e now have to bind the two together with a reasoning schema to complete our methods selection system. This is explained in the next sect ion. 68 4.1.3 Feasibility Rules Our feasibility rules are the mechanism we use for automated feasibility checking of methods and subsequent preliminary plan generat ion. Unlike other expert systems, however, these rules are meant to be dynamically specified by the user (expert) and are not hard-coded into the system. However, our stated aim is to automate or facilitate the user's method selection process for the selected aspects of future projects. W e therefore clarify the various ways that we intend to facilitate the user's method selection process. 4.1.3.1 Modes of Operation Construct ion projects by their very nature are unique ventures. Every project has to deal with new and varying site and design challenges. Still, there are some characterist ics of certain projects which make them similar and thus help in classifying them, e.g. residential projects, pipeline projects, road projects, etc. The grouping and classification of projects, though interesting, are outside the scope of this thesis. For companies doing the same work repeatedly, like residential high-rise contractors, it would be advantageous to automate the reasoning about the feasibility of construction methods for use on a specific project and preliminary plan generat ion. For companies who specialize in only one or two areas of construct ion but concentrate on a lot of design variations and/or geographic locations, encoding 69 their previous knowledge in a computer-interpretable form and using it to advantage on future projects with or without automation would be good enough. For large multi-national companies who tend to bid for large unique projects with a number of convent ional components as well as some unique ones, it would be most useful to piece together knowledge of the conventional components f rom previous experience, freeing up time to focus on the unique aspects. Companies should in this case be able to formulate a Project M&RBS and PCBS without reference to any STANDARDS. W e therefore end up allowing the user four modes of use. 1. Automated setup of Project M&RBS and PCBS from the S T A N D A R D S along with initial project plan generation and feasibility reasoning. 2 . Use of one or more Standard Method Statements without system help with the use of the associated PCBS for project setup, 3. Use of one or more Standard PCBS templates along with independent use of one or more Standard Method Statements for project setup. 4. Formulat ion of the project Method Statement and PCBS without any reference to STANDARDS. W e will eventually be able to provide complete and thorough system support only for the first option, but with significant constraints on the user. For the remaining three options, the additional flexibility offered places greater burdens on the user to ensure data integrity and compatibility. 70 To use the first and second options, associations between components in the M&RBS and appropriate components in the PCBS have to be made. W e start with the second option. There are two important differences between the first and the second options: 1. The first option has a very rigid definition of project scope as compared to the second option. The first option assumes a project scope involving construct ion of the entire facility and not its parts. The second option does not restrict the user to this definit ion. 2. The first option uses encoded expert knowledge with expert discretion for the reasoning and the user only performs the task of supplying the facts which form the basis of this reasoning. The second option on the other hand uses expert knowledge with user discretion. The user in this case performs the dual tasks of collecting the facts and analyzing them. The expert knowledge in this case only helps the user by providing him with a checklist of all the issues that are important for the methods selection and planning exercise to ensure that the user does not overlook an important item. Reasons for choosing the second mode of operation over the first include: 1. The first option is an all or nothing option which is most useful for a narrow range of construction projects with very little design variation. If the user wants to use expert knowledge on a major variant of the same theme, he will have to use his own discretion in doing so. There is a fundamental limit as to the reasoning 71 capabil i ty of any expert system. This arises f rom the fact that humans tend to use an adaptive reasoning process which allows them to collate task specific information, past experience, available alternatives and common sense to arrive at a solution as opposed to machines which are designed to use prescriptive reasoning. Prescriptive reasoning is the process of f inding a solution to problems from a known set of solutions (knowledge base) to best fit the facts. This means that to have a machine reason about a broader subject, more knowledge needs to be coded in the knowledge base. This is restricted both by the amount of effort required and also the difficulty of encoding certain forms of knowledge (such as common sense). In order to make a system usable, therefore, a trade-off has to be made between the amount of user effort and the viability of providing a more intelligent system. This is especially true in the construction domain where variations in the design of projects is more the rule rather than the except ion, requiring different judgements to be made about the applicability of specific methods. 2 . Al though a project is similar to one for which knowledge is encoded both in design and scale, it might just be that the project environment dictates the use of a certain approach which is beyond the capability of the system. For example, consider a local Vancouver contractor who wants to diversify into other regions such as Alberta. Construction of a pipeline in Alberta needs preparation for winter work whereas the same work in Vancouver would not require it. The 72 encoded knowledge would not reflect Alberta's location and climate, and could therefore give erroneous results. 3. A less significant but still relevant reason would be the lack of conf idence in the machine's reasoning capability. It should be noted that the author knows of no knowledge-based methods selection system which is currently in use by practit ioners on actual projects - i.e. there is still a long way to go before knowledge-based systems will be used in everyday practice. 4.1.3.2 Option 2: Semi-Automated Project Setup User interface designers tell us that computer users want help at their f ingertips but out of the way. Psychologists tell us that people have very short attention spans. Construct ion planners tell us that site superintendents never follow a construction plan to the letter, but will most certainly complain if no plan exists. Extending these three observations to the association of M&RBS components with PCBS components, we conclude that our design should allow: 1. The user to access expert knowledge easily while setting up the Project M & R B S and PCBS. 2 . The expert knowledge should be in the form of suggestions and not conclusions. 73 3. The expert knowledge should not be descriptive but to the point, i.e. it should be organized so as to provide the user with information that he is seeking without reference to unrelated subjects. To achieve these goals, we allow the user (expert) to associate a Standard Method Statement with any level in a Standard PCBS except location, because it is project dependent. The association should, of course, be comparable with the scope of the Method Statement. For example, if we have a Method Statement for construct ion of a pump house for a sewer pipeline, it is expected that the user will associate this Method Statement with the system component, pump house. Associat ion with a subsystem such as sub-structure or with physical elements such as columns or slab would be fruitless. This, however, cannot be automatically checked, as w e do not know the structure of the Standard PCBS or Standard M&RBS a priori. User care is therefore warranted. Once the proper association has been done, however, additional help can be provided. For example, we provide the ability to associate each lower level component in the Method Statement i.e. Operations, Methods and Resources with one or more components in the Standard PCBS template which are a part of the hierarchy of the component associated with the Method Statement. For example, if the user has associated a Method Statement with the system pump house, he can associate an operation, e.g., construct substructure, with the substructure sub-system as well as with the Element, strip footing. Further, he can associate a method for excavating a trench for the footing with the substructure sub-74 system as well as with the Element strip footing. The following two checks are automated to help the user avoid mistakes: 1. W e check that the Sub-system, substructure, and Element, strip foot ing, are a part of the system pump house; and, 2 . W e check that the associated Sub-system and Element are f rom the same Standard PCBS template as that associated with the Method Statement. This is because, as discussed earlier, a Standard PCBS template can also be used as a part of another template. So if this system template is used as a part of an oil pipeline project as well as a sewer pipeline project, we need to ensure that our Method Statement is referring to parameters for sewer pipeline components as against oil pipeline components. An association is basically a reference to the PCBS component (it is comparable to a spreadsheet being embedded in a word processing application and being referenced from there). Using the second option involves the following steps: Step 1: To start, the user adds a new project and selects the second option for setup. Step 2 : The setup routine then prompts the user as to which Standard Method Statement Template he would like to use to plan the project and presents him with a list of previously defined Templates to choose f rom. 75 Step 3: Once he selects a particular template is selected, the system copies over that Method Statement to the Project M&RBS. Step 4: The system then creates a Project PCBS with Project as the root. The next step involves the copying over of the associated Standard PCBS template (or template part) to the Project PCBS. Step 5: The setup algorithm then determines if any locations were defined for the copied Standard PCBS template (if association is made only with a part of a Standard PCBS template, the system copies the inherited locations). It then cycles through each and every location and asks the user how many locations of that particular type he would like created. Step 6: On completing the generation of all locations, the system assigns the entire location range (e.g. Location 1 - Location 10, i.e., it indicates ten locations 1, 2, 3, 4, 5, 6, 7, 8, 9, 10) as a default to every parameter and condit ion defined for that PCBS tree. Step 7: The user is informed that the setup has been successfully completed and is presented with an option to prepare the initial project plan, to copy over another Method Statement or to exit. If the user chooses to add another Method Statement, then steps 2-7 are repeated. If the user, on the other hand, chooses to prepare the initial project plan, the setup algori thm searches the Project M&RBS for any Operat ions and sends them over as activities to the scheduling algorithm which numbers them sequential ly and assigns the first PCBS location as default to each activity. It then assigns 76 the resources under that operation to the corresponding activity. On complet ing this, the setup algorithm terminates. Note that when the user specifies multiple Method Statements the system does not check their compatibil ity. The setup algorithm should, however, be intelligent enough to detect any conflicts in the location specification. Locations belong to the entire-project and critically affect the development of the initial project plan. Accordingly, if the user defines the same name for a location during setup, the algorithm gives him the alternative to either rename it or keep only one copy of the location by overwrit ing the previous one. The setup algorithm is not concerned with the PCBS structure. For example, during setup when the user copies over the first Method Statement, if the associated Standard PCBS template (or part of a Standard template) is a system, it inserts it directly under the project. If the Standard PCBS template (or part of a Standard template) associated with the second Method Statement is an Element, it again puts it directly under the project component. The only exception is a Subsystem or Sub-element, in which case the setup algorithm puts it under the first System or Element in the Project PCBS tree. The only check we do is to ensure that two components at the same level are not named the same to ensure referential integrity. Once the setup process is complete, the user has to determine the duration of each task in the Method fragnet, and then roll it up to determine the duration of the 77 Operat ion. These durations will then be copied over to the respective activities as activity duration per location. The user can choose not to do this and assign durat ions directly to activities. If the user does decide to compute operation durat ions he will have to know the physical characteristics of the project. Here is where our associations come to the aid of the user. The user can go to each and every task of a method and access in a window the associated PCBS components and their parameters. He can enter the appropriate values and variables for the parameters and sum up the quantities by aggregating them all for one component . As he knows the number of components he therefore knows the total quantity. Referring to the parameters of the Method itself he can find the production rate and so determine the duration of the task. Having determined the duration of each task, the duration of the Operation fragnet (and so the activity) can be computed using critical path method. Work can then proceed on the project level planning and schedul ing. The user can take this approach a step further. For the Project PCBS, he can define the condit ion and parameter values for all of the components. He can then compare the listed feasibility conditions for each Method Statement and see if they are satisfied. If they are not, he can then take appropriate corrective action by either changing some Methods and/or Operations and/or resources under it. For this we need to provide the ability to access individual Methods and Resources in the Standard M&RBS from the Project M&RBS. Changing the Operat ions will however not change the activities. If the Method Statements are feasible he can check the 78 feasibility of the underlying Methods and Resources and again take corrective action if necessary. Unlike for the case of automated setup, we do allow the user to modify the Project M&RBS and PCBS while using this second option. W e now describe briefly the working of the third and fourth options before moving on to a thorough discussion of the automated setup (opt ion l ) . 4.1.3.3 Option 3: Project Setup with access to STANDARDS but with no system help. If the user chooses to use the third option, he will be able to copy over the Standard PCBS templates and M&RBS Method Statement templates independently and use these to set up his project. What we mean by independent is that the associat ions between a Standard Method Statement template and Standard PCBS. template(s) no longer hold. The process involves the following steps: S t e p l : To start, the user needs to add a new project. He will be presented with an option screen listing the four setup options above. Step2 : If he chooses the third option he is presented with a further choice to copy a Standard Method Statement template or Standard PCBS template or quit adding the new project. Step3a : l f he chooses to copy a Standard PCBS template he is presented with a list of defined templates to select f rom. He can choose a template to copy. The 7 9 system then uses a similar setup algorithm to the one detai led above (without the part dealing with the M&RBS) to define project locations and assign location ranges to component parameters and condit ions. The algorithm then goes to step 4. Step3b : l f he chooses to copy a Standard Method Statement template then again he is presented with a list of defined templates to choose from. Once he selects a template it is copied over and the underlying Operat ions are sent to the scheduling algorithm as activities. Now, however, he has no access to the PCBS as we do not have any associations. The burden of how to determine the task durations rests entirely on the user. The algorithm then moves to step 4. Step4 : The user is again prompted with the same screen as in step 2 above. Depending on his response, the algorithm either executes step 3a, step3b or exits. For option 3, we do no additional checks except maintain referential and directional integrity. 80 4.1.3.4 Option 4: Independent Project Setup On adding a new project, if the user decides to use option 4, then the system just generates an empty project PCBS with only one location, that of GPRJ (General Project -modif iable by the user) and an empty M&RBS tree. 4.1.3.5 Option 1-Automated Setup W e now discuss in detail the automated setup of a Project PCBS, M&RBS, and generat ion of a preliminary project plan using feasibility rules and our setup engine. To do this the user first needs to define feasibility rules. The next section details our implementat ion schema for feasibility rules. The following section then discussed the setup engine and its operation. Feasibility Rules: W e looked at a number of possible configurations that could be used to define the feasibility rules: 1 . W e thought of using a single coherent file for defining the feasibility rules for an entire Method Statement template. The rule file would contain all the rules for determining the feasibility of the Method Statement as well as the underlying methods and resources (we do not test the feasibility of Operat ions). The following are the advantages and disadvantages of this approach: 81 Advantages: a . Since all the rules are in a single coherent file, we do not need to have external addressing to call the rules for methods and resources. b. Debugging the rule file would be a lot simpler. Disadvantage: The rule file is contrary to our modular design approach. Specifying all the rules in a single file would mean that the rules for the feasibility of a method (or resource) would have to be defined in each rule file. This will most certainly lead to incoherent rules and difficult system maintenance. 2. Another possible approach is a totally modular one. This approach would mean that the rules for feasibility of a component reside with the component and the setup engine is responsible for chaining them. The advantage of this approach is modularity and ease of maintenance. The disadvantage is the extensive external addressing that we would have to implement. W e finally decided to implement a hybrid approach which collects the rule file tr iggering in one file, but the rules themselves reside with the respective components. This means the use of a structured rule file. W e found an excellent prototype in the Microsoft® Initialization (.ini) files which are used in Windows® 3.xx to define the user preferences at the launch of an application. This file is clearly divided into distinct sections. Each section then has specific commands which the 82 program recognizes and executes at startup. W e decided to adopt a variant of this approach to reduce the user effort in specifying the rules. To start determining the final structure of our rule file, we first need to formulate a good range of possible feasibility rules Let us look at a few examples: 1 . Method Statement - Construction of sewer pipeline using microtunneling R u l e l : If required production rate is greater than the achievable production rate then the Method Statement is infeasible Rule2: If the pipeline al ignment is irregular or if the number and location of underground utilities is unavailable, then the Method Statement is infeasible. 2. Method Statement - Laying of sewer pipeline using spread technique. Rule: If the project setting is urban or the site condition is congested or the pipe material is not welded steel, then the Method Statement is infeasible. 3. Method - Timber Shoring. Rule: If the excavation depth is greater than 20 ft, then the Method is infeasible. 4. Method - Skip Shoring Rule: If soil type is not Type A (OSHA Classification) or if the soil condit ion is submerged, then the Method is infeasible. 83 5. Method - Soil Displacement Method of Microtunneling Rule: If the grain shape is angular or if the soil condition is submerged or if the pipe al ignment is irregular or if the pipe diameter is greater than 200mm or if pipe-run is greater than 60 m, then the Method is infeasible. 6. Resource - Hydraulic Excavator (CAT E70B) Rule: If the maximum weight of pipe is greater than 1000 kgs, then the Resource is infeasible. 7. Resource - Soltau Microtunneling Head (RVS 250A) R u l e l : If the pipe's minimum internal diameter is less than 18 in, or if the pipe outer diameter is greater than 60 in, then the Resource is infeasible Rule2: If the pipe length equals 10ft then the jacking shaft width equals (10ft). If the jacking shaft width > width of the project corridor, then the Resource is infeasible. Two points are apparent as we analyze the sample rules: 1. All of the rules are basically elimination rules, i.e. we are trying to determine the least possible combination of conditions which would make the use of a component infeasible. 2. All our rules can be represented by the following general statement: 84 Check if "argument" satisfies "condition". If not then component is infeasible. One additional point not highlighted in the above stated rules is that the feasibility of the higher level component in a Method Statement (e.g. Method) is contingent on all the lower level components (e.g. Resources) being feasible. If any of the lower level components are infeasible, the higher level component also becomes infeasible. Consider the second point listed above. W e have to know what condit ion needs to be satisfied and what are the arguments for it. W e have already solved the problem of the condit ions by allowing specification of feasibility condit ions as one of the attributes of all M&RBS components. Arguments in our case then refer to the parameter and condition values of the appropriate Project PCBS components. For example, in the rule for hydraulic excavator, the maximum weight of the pipe is a parameter of the Project PCBS component Sub-element - Pipe-length . In the case of the rule for Skip Shoring, the soil condition refers to the condit ion - soil condit ion which is one of attributes of the Project PCBS Component - Project. W e therefore have all the ingredients to analyze feasibility rules. However, we need to reference them and incorporate them in our rules. So we need a referencing schema. W e have used the following schema: 85 1 . Since we are referencing different parts of the system we need to have a naming convent ion. This is given in Table 4.1.3.5.1 below: Table 4.1.3.5.1: Naming Convention Name System part referred to SPCBS Standard Physical Component Breakdown Structure SMRBS Standard Method and Resource Breakdown Structure PPCBS Project Physical Component Breakdown Structure PMRBS Project Method and Resource Breakdown Structure 2. As previously explained, under STANDARDS we allow the user to have the ability to have a number of templates both in the Standard PCBS and M&RBS. W e therefore need a way to specify which templates we are referring to. W e have already mentioned that we have a unique name for each template of a particular component type. Since we are using a wholistic approach for the automated setup, i.e. we allow the user to only deal with the entire project, we can use this unique template name to refer to it. For example, a Standard Project Template called Sewer pipeline will be referred to as "SPCBS.Sewer pipeline". This obviously constrains the user from using a period (.) in the template name. In the case of a Project PCBS or M&RBS, we do not need this template name. 3. W e now have to tell the system which component in the template w e are referring to or in the case of Project PCBS or M&RBS, the component in the tree. 86 Tree structures are very commonly used in computer software, and a standard convent ion has been developed for referring to a particular level in a tree. This convent ion separates successive levels in a tree called branches by their name separated by a period. For example, if we have a Project template called Sewer System with a breakdown as shown in figure 4.1.3.5.1 below, then If we want to refer to the element, Jacking shaft, we indicate its address as : Sewer System.Main Line.Jacking Shaft To integrate this addressing with our general referencing structure, we enclose it within square brackets. So the complete address for the element pipe-run would be: SPCBS.Sewer System[Sewer System.Main Line.Jacking Shaft] Sewer System - Project M a i n Line - S u b - p r o j e c t La tera l - S u b - p r o j e c t Receiving Shaft - Element Pipe-run - Element Jacking shaft - Element Figure 4.1.3.5.1: Sample Project PCBS for illustrating the addressing of PCBS and M&RBS components. 87 However, if no restriction is placed on the length of a component name then the address would soon become unmanageable. W e therefore restrict a user to a ten character reference name for each component which has to be unique to a particular branch level in the tree structure. The root is named ROOT by default but can be changed by the user. 4. Our final step would be to reference a parameter or condit ion. This can be done by entering an '* ' after the component whose parameter we are referring to fol lowed by the parameter name and an'! ' fol lowed by the condit ion name. So to refer to a parameter, e.g., diameter of pipe for Element pipe-run, the address would be: SPCBS.Sewer System[Sewersys.Main l ine.Piperun*diameter of pipe] To refer to a feasibility condit ion, e.g., soil type, in the Project M & R B S shown figure 4.1.3.5.2, the following address will be used: PMRBS[Sewerlnst .Trench.Skipshore!Soi l type] 88 Sewerlnst - Method Statement ( O p e n - c u t S e w e r Instal lat ion) T rench - O p e r a t i o n (Cons t ruc t Trench) Lay Pipe - O p e r a t i o n (Lay Pipel ine) Exctrnch - M e t h o d (Excavate Trench) Skipshore - M e t h o d (Shore Trench using Skip Shoring) Condit ions: Soil Type = Type A Figure 4.1.3.5.2: Sample Project M&RBS for illustrating the addressing for a parameter of a PCBS or M&RBS component. To incorporate condit ions and parameters in our rules, we need to make a few changes to our condition and parameter structures. Referring back to our rules, the reader will find that we have used a number of and/or operators to link condit ions together. Whi le specifying conditions it would be advantageous if the user is able to specify them as multiple statements using and/or operators. However, we cannot reason about a parameter (or Project PCBS conditions) as an argument to a condit ion if the parameter has more than one value i.e. if we allow use of the and/or operators in the parameters as well. W e will then not know which parameter value is serving as an argument to which condition statement. Thus we do not allow parameters to have multiple statements linked by and/or operators. 89 The next step is to incorporate a level reasoning capability in our feasibility condit ions. Level reasoning refers to the need for reasoning about the feasibility of lower components in a Method Statement, once we find that the overall statement is feasible. This we can achieve by treating the feasibility condit ion as a funct ion, which returns a value of true or false when supplied with the appropriate arguments. For example, consider the feasibility condition Soil Type = Type A. If we treat this as a function and supply it with an argument of a project soil condit ion of Type B, it will perform the following steps to arrive at a result. 1 . Accept the value of the project condition as an argument, in this case Type B. 2. Compare this with the expected value, in this case Type A. 3. If the argument matches the expected value, then return true, else return false. For this case, the result will be false. By doing this we can call the feasibility condition as a function with arguments. In our example this would be: Soil type(PPCBS[SewerSys!Soi l Condition]) where PPCBS[SewerSys!Soi l Condition] is the address of the argument. 9 0 W e can also deal with multiple statement conditions by just providing the condit ion function with two arguments. For example, consider the condit ion called Underground: Soil type = Type A and Soil condi t ion<>Submerged. W e can now call this function as follows: Underground(PPCBS[SewerSys!Soi l Type], PPCBS[SewerSys!Soi l condit ion]) The steps for arriving at a value of true or false are exactly the same except that now two values are compared. There is one final convention we need to develop to complete the development of our rule file. This convention is because of the fact that al though we are aware of the feasibility conditions as an attribute of a M&RBS component, the arguments for testing this condit ion are an attribute of a Project PCBS component. Therefore they are project dependent, and the feasibility of an M&RBS component can therefore only be tested when copied onto the project side. W e need a way to supply these arguments to the condition functions to evaluate a component 's feasibility. This we can achieve by again using a variant of our previous strategy, that of using a condit ion function. W e can similarly define a component function. W h e n evaluating the feasibility of a component on the project side we supply the arguments for the condit ions of the component by enclosing them in curly braces. Then the arguments to the condit ions of a method, e.g., Excavation, are specified as follows: Excavat ion{arg1, arg2, arg3} 91 How these arguments are used internal to a method is examined later. Rule file W e have decided to use a structured rule file divided into sections. W e have defined four sections as indicated in Table 4.1.3.5.2: Table 4.1.3.5.2: Sections of a structured rule file Section name Possible members Arguments Project PCBS conditions or parameters Components Lower level components Condit ions Condit ions of the particular component to which the rule belongs Routines The actual reasoning End Stops processing of a rule file To begin defining a rule file, we need to associate the highest level component in our Method Statement template with the highest level component in a Standard PCBS template i.e. a Project. No other associations are necessary though if the user wants, he can associate lower level components in the Standard PCBS template to lower level components in the Standard Method Statement template. Step 1 : What the system does next is copy all the parameters and condit ions of all components in the Standard PCBS template into the arguments section of the rule file as project parameters or conditions, and numbering them sequential ly starting from arg1 , . . . . The only difference is for parameters or 92 condit ions of locations which are copied as a rg i l 1 and so on, as the number of locations are not known a priori. When a rule encounters an argument of the form, a rg i l 1, it looks for all locations of the type 11 and then tests the validity of the feasibility conditions for the first condit ion of all these locations. This points to a programming problem, that of keeping track of all locations of a particular type. This we solve by internally tracking the locations as 11, 12,... although externally we allow naming them differently. On replication we provide each location of the same type with a letter sequential ly such as 11a, 11b,... to keep track of them. Step 2: The system then copies all the methods and resources under the Methods and Resources under the Method Statement in the components section of the rule file as project M&RBS components, again numbering them sequential ly as component1,component2, . . . . Note that only resources directly under an operation are copies and not any Methods. Step 3: This step copies all the conditions defined directly for the Method Statement in the condit ions section of the rule file, again numbering them sequential ly as cond i t ion l , condit ion2,... . Steps 2 and 3 cascade down and are repeated for all underlying Methods and Resources. For the resources, there are no underlying components and therefore the components section remains empty. The arguments section also remains empty to be defined by the user. 93 What the user has to do next is to call all the conditions in turn specifying the arguments as per the calling convention discussed above (Excavat ion{arg1, arg2, arg3}). After this the user calls each and every component in order giving it the appropriate arguments. He then goes down to each component 's rule file and repeat the same procedure for them. The values of the arguments for a component (listed in the arguments section) are supplied by the calling routine. To illustrate the foregoing consider the following Standard M&RBS and Standard PCBS. 94 Sewerlnst - Method Statement (Open-cut technique for Sewer Installation) Conditions: project setting <> congested Parameters: max. production rate = 12 m/day Trench - Opera t ion Laypipe - O p e r a t i o n (Construct t rench) (Lay Pipeline) Conditions: Conditions: Parameters: Parameters: , CAT325 - Resource (Caterpillar Hydraulic Excavator) Conditions: min. clear site width = 5 m Parameters: max. production rate = 0.9 yd 3 /hr SkipShore - Method (Trench Support using Skip Shoring) Conditions'. Underground Conditions -soil type = Type A and soil condition <> submerged Parameters: Pavrem - Method ( Pavement Removal) Conditions: Parameters: Labor - Resource Timber - Resource (Labor) (Timber for Shores) Conditions Conditions: soil toxicity = none soil grain <> angular Parameters: Pavcut - Resource (Pavement Cutter) Conditions: Parameters: CATE70B - Resource (Caterpillar Hydraulic Excavator) Conditions: Parameters: Figure 4.1.3.5.3: Sample M&RBS for illustrating the syntax and structure of a rule file. 95 SswerSys- Project (Typical Breakdown for a Sewer Installation Project) Conditions weather = setting = Parameters: Pipe-run - Location (Typical Location for Pipe-run) Conditions site width = site clear height = soil type = soil condition = Parameters Figure 4.1.3.5.4: Sample PCBS for illustrating the syntax and structure of a rule file. Rule file for Method Statement Sewerlnst: [Arguments] R E M 5 Defining arguments ( corresponds to Step 1 in the formulation of a rule file) arg1 = PPCBS[SewerSys!weather ] arg2= PPCBS[SewerSys [setting] arg3= PPCBS[SewerSys.p ipe*pipe material] arg4= PPCBSfSewerSys.p ipe* pipe diameter] arg5= PPCBS[SewerSys.p ipe* lnver t level] arg6= PPCBS[SewerSys.excvn*width] arg7= PPCBS[SewerSys.excvn*depth] Rpe - Hement (The pipe to be laid) Conditions Parameters pipe diameter = invert level = excvn - Element ( hole to lay the pipe) Conditions Parameters width of excavation = depth of excavation = 5 REM indicates that the statement following it is a remark. It is not a part of the rule file syntax and is included here for clarifying the intent of the following text. 96 \ a r g i l 1= PPCBS[SewerSys.pipe-run!si te width] a r g i l 2 = PPCBS[SewerSys.pipe-run!clear height] a r g i l 3= PPCBS[SewerSys.pipe-run!soi l type] a r g i l 4 = PPCBS[SewerSys.pipe-run!soi l condition] a r g i l 5= PPCBS[SewerSys.pipe-run!toxici ty] [Components] REM Defining Components (corresponds to Step 2 in the formulation of a rule file) componen t l =PMRBS[Sewer lnst .Trench.CAT325] component2=PMRBS[Sewer lnst .Trench.Skipshore] component3=PMRBS[Sewer lnst .Trench.Pavrem] [Condit ions] REM Defining Condit ions (corresponds to Step 4 in the formulation of a rule file) condi t ion l =PMRBS[Sewerlnst !project setting] [Routines] REM Calling condit ions and other components as functions If condi t ion l (arg2)=True then (return code =1 condit ion =condit ion1 9 7 break) else cont inue If componen t l {argM 1-arg6}<>0 then (return code = returned return code condit ion = returned condition component = returned component break) else continue If component2{argl13,argl14,argl16,argl16}<>0 then (return code = returned return code condit ion = returned condition component = returned component break) else continue return code = 0 [End] Rule file for Method Skipshore: [Arguments] REM Defining arguments ( corresponds to Step 1 in the formulation of a rule file) 98 arg1={argl13} arg2={argl14} arg3={argl15} arg4={argl16} [Components] REM Defining Components (corresponds to Step 2 in the formulation of a rule file) componen t l = PMRBS[Sewerlnst .Trench.Skipshore.Labour] component.2 = PMRBS[Sewerlnst .Trench.Skipshore.Timber] [Condit ions] REM Defining Condit ions (corresponds to Step 4 in the formulation of a rule file) condit ion 1 = PMRBS[Sewerlnst .Trench.Skipshbre!underground condit ions] [Routines] REM Calling condit ions and other components as functions If condit ion 1(arg1, arg2) = True then (return code =2 condit ion =condit ion1 break) else continue If componen t l {arg3}<>0 then (return code = returned return code 99 condit ion = returned condition component = returned component break) else continue If component2{arg4}<>0 then (return code = returned return code condit ion = returned condition component = returned component break) else continue return code = 0 [End] Rule file for Resource Labor: [Arguments] REM Defining arguments ( corresponds to Step 1 in the formulation of a rule file) arg1={arg3} [Components] REM Defining Components (corresponds to Step 2 in the formulation of a rule file) 100 [Condit ions] REM Defining Condit ions (corresponds to Step 3 in the formulation of a rule file) condi t ion l = PMRBS[Sewrlnst.Trench.Skipshore.Labor! toxicty] [Routines] REM Calling condit ions and other components as functions If c o n d t i o n l ( a r g l ) = True then (return code = 3 condit ion = condi t ionl break) else continue return code = 0 [End] The final aspect of our conceptual design is the development of the setup engine. The steps involved are: Step 1 : The user starts by adding a new project. He is then presented with a dialog box listing the four setup options or the option to exit. Step 2: If he chooses option 1 - Automated setup he is presented with a list of M&RBS templates to copy over to the PROJECT layer. 101 S t e p 3: W h e n he chooses one of the displayed templates, the setup algori thm copies over the Standard Method Statement template as well as the associated Standard Project template. If no project template is associated or if the associated template is not a Project template, the algori thm brings this to the users attention and asks him to select another template. S t e p 4: The setup algorithm then cycles through each location asking the user for the number of each of these that he would like to create. Step 5: The algorithm then assigns the entire location range to each parameter and condit ion of all the components. Step 6: The algorithm next cycles the user through the parameters and condit ions of each component so that he can specify the locations at which they occur, if any, and specify their parameter values for these locations. Step 7: The algorithm next calls the rule file of the Method Statement and transfers control over to it. Step 8: If all the rules are satisfied then a return code of zero is sent back to the setup engine. The algorithm then proceeds to step 10. If, however, any of the rules fail, then the appropriate return code, condit ion name, and component name are returned to the setup engine. The setup engine then informs the user which condition of which particular component has fai led, and presents the user with an option to either continue regardless of the failure or to find another component of a similar type fol lowed by cont inued 102 processing of the component. However, if it is a Method Statement, then in this case he cannot choose another one and so must exit. Step 9 a : If the user opts to continue, then control is transferred back to the rule file where it stopped processing. Step 9 b : If the user opts to choose another component of a similar type, the user is prompted that he will have to do so manually. The only assistance the machine provides him with is that it will look at the return code which specif ies which type of component failed. If it was a Method or a Resource the algorithm finds the class that the component belongs to and presents a list of available Methods/ Resources in that class. The algori thm then pauses in order to let the user study the list as well as the component attributes and select one that he thinks is suitable. The algori thm then moves control back to the rule file to continue f rom where it was interrupted, and repeats steps 7 and 8. Step 9 c : If the user decides to use the option to exit processing the Method Statement, then the computer moves to step 13. Step 10: If processing of the Method Statement is completed successfully, the setup algorithm then informs the user that the Method Statement is feasible. It 103 then sends the Operations to the scheduling algorithm as activities and the Resources under the Operation as their assigned resources. It also sends the entire location range to the scheduling algorithm. The schedul ing algorithm gives each activity a unique activity ID, assigns it resources and assigns the first location in the range as the default for each activity. It then shifts control back to the setup algorithm. S t e p 11 : Next, the setup algorithm prompts the user to assign a duration to each task in the fragnet. It then cycles him through every task. At each task, it waits for the user to study PCBS as well as M&RBS parameters as an aid in assigning the task a duration. Step 12: Once this is complete, control is transferred to the scheduling algorithm which computes the duration of each Operation and copies it to the activities. Control then shifts back to the setup algorithm. Step 13: Once this is complete, the setup algorithm asks the user if he would like to add another Method Statement template to the project or would he like to exit. Step 14a: If the user decides to add another Method Statement template, the setup algorithm backs up and stores a copy of the Project PCBS, Project 104 M&RBS and activity spreadsheet and then moves back to step 1 (without options 2,3 and 4). Step 14b: If the user decides to exit, the setup algorithm terminates. The user can now inspect all the stored feasible project plans and decide which one to adopt. This completes the discussion of our conceptual design. Figure 4.1.3.5.5 gives a complete schematic design of the system and figure 4.1.3.5.6 gives the details of the standards level of the method selection system. 105 OUTSIDE WORLD COMPUTERIZED ENVIRONMENT C h a n g i n g : Technology u New Technologies • New Construction Equipment • New Construction Methods • New Materials & Related Products • More powerful computer and software technology • New modes of information capture (e.g digital photography) • New modes of information dissemination (e g. Internet) Regulatory Environment • Safety regulations • Environmental regulations (noise, waste disposal. . .) Industry u Competitiveness, both domestic and international • Computer Literacy • Sources of information - trade literature, sales personnel other jobs, post-project analysis, .. Constraints • Stakeholder Involvement • Financial Resources Project Level 3 PHYSICAL VIEVt OF Fl'OJECT Project PCBS - Representation o' Phys.cal Project • Parameterized descrjption'of project'require • ParaiTieteir£ed'(le^ptiori'of plfty£k»)!c«rnj: • 1 Parameterized description of anticipated site | M n 3 i t i p n s l ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ B | | Multi-med'a description of project & site "•; M >&j S i 4. PROCESS VIEW OF PROJECT Project M&RBS.; Methods S Resource Representation • Method Statements) • Opera! ons • Methods • Resources Interactive Cycle Design Environment Project Planning & Scheduling Environment 5. PERFORMANCE EVALUATION • Cost • Time • Safety • Risk • Environmental Impact 1 < 6. OUTPUT Method Statement(5 G|c |§DeJg^ l^^^pP|^^B Plan & Schedule "i; Cost Evaluation Explanation ofTesults frar • 1 • Figure 4.1.3.5 Schematic Representation of the Proposed Methods Selection System LEGEND Associated Multi-media records Association between PCBS and M&RBS components Indicates use of smaller predefined components or blocks of components to build new larger ones. The lighter side Indicates the smaller components being used while the darker side indicates the components they are contributing to. In M&RBS shows associated Fragnets from Standard Fragnets Operations Fragnets composed of Methods Fragnets and Linking Tasks. Indicates a M&RBS or PCBS component with its associated parameters and conditions. Parameters and Conditions can have Quantitative, Linguistic or Boolean values. Indicates that this fragnet is available for use only with one method as an associated fragnet. O STANDARD METHODS & RESOURCE BREAKDOWN STRUCTURE STANDARD FRAGNETS Figure 4.1.3.5.6: SCHEMATIC REPRESENTATION OF THE STANDARDS LEVEL IN THE PROPOSED METHODS SELECTION SYSTEM 4.2 Implementation Since our aim was to produce a preliminary project plan, including Method Statements, we elected to implement our methods selection system within an existing project planning environment. W e chose to use REPCON™ (REPresent ing CONstruct ion), a research system developed at the University of British Columbia. Al though some of the actual implementation and conceptualization of the methods selection environment has been influenced to some extent by this choice, we have tried to keep it as generic a possible. REPCON™ is a repetitive construction modeling environment. It operates under MS-DOS® or in protected mode under Windows®. It has been written in C and C++, and data storage and manipulation are provided by Btrieve's Microkernel Database Engine®. For model ing repetitive construction, REPCON™ uses the concepts of locations and typical relationships. Once a typical precedence relationship between activities has been defined it gets repeated from location to location, unless superseded by a non-typical precedence relationship. This makes the job of planning simpler for the user. Other features such as use of multiple calendars, resource loading, cost al location, date and float computat ions, etc. which are generic to almost all modern project schedul ing software systems are also supported. 6 Programming of the concepts discussed herein was done by William Wong of the Construction Management Laboratory. 108 Implementat ion of the conceptual design previously described involves a massive programming effort. To get the maximum amount implemented in the relatively short t ime span available, we developed the following strategy 7 . First, we decided to focus on getting the major components of our system up and running before adding various checks, user interface (Ul) features and other subtle performance improvements. The implementation assumes a user knowledgeable in construct ion. The discussion of the implementation has been arranged to follow roughly the same pattern as that for the conceptual design. 4.2.1 General Comments The system uses a graphical user interface similar to the traditional W I M P (Windows, Icons, Menus, Pointer) interface standard, without the icons, i.e. in effect we use a W M P interface. All data is presented to the user in one of three formats - a list format, a graphical tree representation, and reports. All user querying is achieved through the use of forms. 7 This was essential for our operating environment. For implementation under Windows® several SDKs (Software Development kits) are available which provide standard code for help with the Windowing etc. For DOS development, however, no such help is available. 109 As we have a consistent set of screens, we also have a very small set of commands that the user needs to be familiar with. A context-sensit ive help facility is also available. The table in Appendix II lists the command set and their functionality. The commands have been grouped according to the format. Some commands are common to multiple formats. 4.2.2 Methods and Resource Breakdown Structure (M&RBS) The M&RBS aspect has been the primary focus of the implementat ion. The discussion of the implementation has been kept quite short, as the applications' screen shots convey most of the information. Implementat ion of the M&RBS can best be explained by leading the reader through the setup of a simple Method Statement. The example selected corresponds to a Method Statement to install a sewer using microtunneling. The steps follow: Step 1: W e start by adding a new Method Statement as shown in f igure 4 .2.2.1. The template list has been sorted for easy reference ( A future implementat ion consideration would be to group the list to allow ease of access). 110 STflMIfflBD/M&BBS i . jEEB~DeTete Edit . Mofue Contents JfecurfTTst Report. eXTf" D:SBEPC0M4 1&BBS Templates S Tree S t r u c t u r e s type onu Seuer Replacement-Main L i n e (Concrete p ipe) Methods Statement Conu Seuer Replacement-Latera ls (Concrete p ipe) Methods Statement Conu Seuer Replacement-Manholes (Concrete P ipe) Methods Statement Conu' Seuer ,Beplacement-Bends&Cornrs(ConcretePipe) Methods Statement Conu Sewer Replacement-Main L i n e , (Stee l p ipe) Methods"Statement Conu Seuer Replacement-Latera ls (Stee l p ipe) Methods Statement Conu Seuer Replacement-ManholeS: (Stee l p ipe) Methods Statement Conu Seuer Replacement-Bends&Corners (Stee l p ipe) Methods Statement Conu Seuer Replacement-Main L i n e (U Clay p ipe) Methods Statement Conu Seuer Replacement-Latera ls (U Clay p ipe) Methods Statement Conu Seuer Replacement-Manholes (U Clay p ipe) Methods Statement Conu Seuer Replacement-Bends&Corners(D-Clay p ipe) Methods Statement Conu Seuer I n s t a l l a t i o n - M a i n L i n e (Concrete P ipe) Methods Statement Conu Seuer I n s t a l l a t i o n - L a t e r a l s (Concrete P ipe) Methods Statement M&RBS Template Type: g Trenthie&s ( I "• imp &^.-.jmii.j ethods^StS-tene'n t «J 1 j I I . - : < i i n " : ' ' . . , . ! . i n i i ' : . .it I rV:Lo.j fll t - P ' : P r i n 1 Figure 4.2.2.1 Template listing in Standard M&RBS Step 2: Next, we want to view the contents of the new template. This is done by selecting contents on the bar menu. A window opens showing the Method Statement that we have created as the root of a tree as shown in f igure 4.2.2.2. This ensures that the names of the Method Statement in the template listing as well as the tree structure are the same. To ensure referential integrity, we do not allow modification of the root. The user then selects the first item from Window in the bar menu, i.e. Define/Edit Parameters and Condit ions. 111 S TANDARD/M&RBSIDEFIHE/EDIT M8RBS PflRflME TERS/COHDITIONS KEcard L i s t Report. e X i t D:\REPC0N4 «V&'M Contents 18RBS Templates 8 Tree S t r u c t u r e s - Type ^onuSeuer .Replacement -Mam L i n e (Concrete -p ipe) Methods Statement Trench l ess (Microtunnel l i n g ) Seuer I n s t a l l a t i o n Type": Methods Statement -ROOT Methods Statement Trenchless ( M i c r o t u n n e l l i n g ) Sewer I n s t a l F l : H e l p U - » « - : S c r o I l Enter :Select" E s c : Ex i t Figure 4.2.2.2: Window showing the contents of a newly defined Method Statement. Step 3: W e insert the first Operation as a sub-tree. In this case, the Operat ion is the construction of a jacking shaft. The form for this purpose is shown in f igure 4.2.2.3. To ensure that the user selects the right component, we have a scrollable list box which limits his choice to components which may come directly under the level above. W e should check that the Operat ion is indeed a sub-tree and not a leaf, but at present we do not check this. 112 STANDABD/M8RBSiDEFINE/EDIT M&RBS PARAMETERS^COMDITIONS Add . I D:\REFC0N4 Contents Bi:cord List Report eKTF" 18BBS Templates 8 Tree S t r u c t u r e s Type 2oriu Seuer Bep lacement-Main L i n e (Concrete p ipe) Methods Statement on Trenchless ( M i c r o t u n n e l l i n g ) Seuer I n s t a l l a t i o n Type: Methods Statement; DEFINE/EDIT M8BBS FABAMETEBS/CONDITIONS M&RBS P A T H : H«h"T .Descript ion;: -to. .Uiitffl" Type: 5frfflai«I-jL [X] I n h e r i t parameter / cond i t i on d e f i n i t i o n from aboue l e u e l pffiTl^lniFPa^ 1 al i 1 l i , I , f ' : i • l r i f ' . . . i t n n I | F7 :Log A l t - P : P r i n t Figure 4.2.2.3: Defining Operations in a Method Statement. Step 4: W e now have two options. One is to continue defining the operat ion sub-tree, or define all the operations at once and then define their components. W e will continue with the definition of the Operation sub-tree. Step 5: W e insert the next lower level component, in this case a Resource, in the form of CAT E70B Hydraulic Excavator. W e continue at the same level and insert a Method for Shoring which involves the use of A luminum Hydraulic Shores. Note in figure 4.2.2.4 that the screen form requires the user to define a Method in a Method Class. In theory, we could do this by simply 113 copying the method directly f rom the Method class; however, this feature has not yet been implemented. Also, if this were possible, we could use it to define various crew combinations as a Resource Sub-Class and import them into the Method Statement. This would mean that, al though while copying we indicate a Sub-Class, what actually gets copied over are the Resources. STANDARD/M8RBS!DEFINE/EDIT M8RBS PARAMETERS/CONDITIONS D:\REPC0N4 Contents 1SRBS Templates 8 Tree S t r u c t u r e s Type Zonv Seuer .Replacement-Maih L i n e (Concrete- p ipe) Methods Statement on Trench les s (Microtunne11ing) Seuer Construct ion; Type: Methods Statement: DEFINE/EDIT M8RBS PARAMETERS/CONDITIONS M8RBS PATH: R O O T . J a c k S h a f t . p g ^ i " D e s c r i p t i o n : ^ ;tVm ff&^tU-U' >ikiiv,-ji 3 Type: " . . Template: •?!;-yy; flfrMTgg;".' . ; '}•'*>? ' ^SfrTiH;?-Path : T ^ a K a ^ ^ i B ^ , 1 _ J • l [ 1 I n h e r i t p a r a m e t e r / c o n d i t i o n d e f i n i t i o n from above l e v e l F3:Def ine Parameter /Condi t ion t r 33 Se II H. i ' M . i . l - i u i I M M - i i | F7TLog"ftrt^PTPfint Figure 4.2.2.4: Defining a method in a Method Statement. 114 Step 6: W e insert a Resource - Shoring Labor under the shoring Method. W e continue defining the tree to complete the entire Method Statement as shown in figure 4.2.2.5. STANDABD/M8RBS i DEFIME/EDIT M&RBS PARAMETERS/CONDITIONS D:\BEPC0N4 <l< »* t<~*;> i/taB t„»,vr»i contents RSSIS 1&BBS Templates; & Tree S t r u c t u r e s Type Cbhu Seuer Replacement-Main L i n e (Concrete p ipe) Methods; Statement Trench les s ( M i c r o t u n n e l l i n g ) Seuer C o n s t r u c t i o n type: Methods Statement; E d i t f P ' . - •-• ' • BOOT Methods; Statement Trenchless ( M i c r o t u n n e l l i n g ) Seuer Cons tr CAT-E70B Besource 0-AlumShore Method I—ShoreLahor -Besource L-ShoreSets Besource Deuater Method g-1nst1Equi p Method •RecuShaft Operat ion/ PipeInsta1 Operat i on •Testpipe Operat ion CAT-E7QB (Caterp i11ar Hydrau1ic Excau Shoring us ing Aluminum H y d r a u l i c Shor Labor f o r Shor ing Modular A1urn inum : Hydrau1ic Shore Se Deuatering the J a c k i n g Shaf t I nsta11 P i p e j a c k i n g Equipment and S o i Construct Bece iu ing Shaft I n s t a l l the P ipe Uater t e s t the p ipe as; spec i f ied by des OOT.JackShaft .'J.D.itct Uiiif'.uu I ' I I ! ! i Ins I.i n|ili>fi- lit M I M I . U I l ' tt I V) I n . , ( T ..m- !t:ui-l i I i'- t< '.'..,< • ! .. • i» t' . ' i I I ft Di.-li'li' r*<: I n .1:1 I. ill. : i :U i -Figure 4.2.2.5: Completed Method Statement for constructing a sewer using microtunneling. Step 7: W e next define the parameters and conditions for each component in the Method Statement. W e demonstrate the parameter/condit ion definit ion of two components. Method - Microtunneling has got a feasibility condit ion for use in cohesive soils with cobbles. The definition of this condit ion is shown in figure 4.2.2.6. W e then move down to the resource - Iseki UNCLEMOLE. 115 This resource also has the same feasibility condition and therefore inherits it f rom the Method. Further, it has parameter definitions such as Max imum grain size of cobbles and Average production rates in various soils. The definition of these is shown in figure 4.2.2.7. The abbreviat ions 'P' and ' C in the P/C column stand for parameter and condit ion respectively. The abbreviat ions 'Q' and 'L' in the B/Q/L column stand for quanti tat ive and linguistic values respectively. These indicate the type of values that a particular parameter or condition can accept. If we had any parameters or condit ions accepting Boolean variables it would be indicated by a 'B' in the last column. STANDARD/MftRBS!DEFIHE/EDIT M&RBS PARAMETERS/CONDITIONS b F r ~ s c i " c . .-v. <j-.,<> . Contents D:SREPC0N4 1&RBS Tenplates & Tree S t r u c t u r e s Type Doriu Seiier Replacement-Main L i n e (Concrete p ipe) Methods Stateneht Def ine Parameter /Condi t ion Add Delete! M8RBS: t r e n c h l e s s ( M i c r o t u n n e l l i n g ) Seuer C o n s t r u c t i o n C o n d i t i o n D e s c r i p t i o n : • C l a s s F T " Cond Std Ualue 1 Ualue Type: L i n g u i s t i c Std Ualue 2 B / Q / L - i 11 ii. . . . ' I i- t I HI i 1 .•• I - i r | F7:Log flit P'l'r m l Figure 4.2.2.6: Defining a Condition for a Standard M&RBS component. 116 STAMDARD/'M&RBS!DEFINE/EDIT M&RBS PARAMETERS/CONDIHONS D:\REPC0N4l f i v ; . •* * t . >>;£. •> Contents 1&RBS Temp 1ates & Tree S t r u c t u r e s Conu Seuer Replacement-Main L i n e (Concrete p ipe) Methods Statement Type; Def ine Parameter/Cond i t i on M&RBS: Trenchless ( M i c r o t u n n e l l i n g ) Seuer C o n s t r u c t i o n D e s c r i p t i o n ; Maximum. G r a i n S ize /Diameter of S h i e l d Aug Product ion Rate f o r S o i l s u i t h Sands Aug P r o d u c t i o n Rate in C l a y s Aug Product ion Rate in S o i l s u i t h Grauel Aug Product ion Rate u i t h Crushed Rock " F e a s i b i l i t y • o f u s e - S o i l Type P /C C l a s s P T e c h n i c a l Inher i t ed Parameter /Condi t ion P / C : Parameter /Condi t iun I ' l :Hc lp U « - : S c r o l l E n t e r i S u l u c t E i » c : E x i t Figure 4.2.2.7: Parameter/Condition listing for a Standard M&RBS component. Step 8: To demonstrate the use of fragnets, we temporari ly move out of the Method Statement Template we are in and go to a Method Class Template, e.g., that of Excavation Support Techniques, and select the appropriate method, e.g., installation of Aluminum Shores. To install the shores we have to perform a series of tasks. W e go into the Contents of the Method Class Template, move down the tree to the method of interest, and then bring up the Window listing (by pressing F3) to bring up the form for the fragnet 117 definition as shown if f igure 4.2.2.8. Since we do not already have a fragnet defined for this, we press F3 again to bring up the fragnet definition window. In this we start by adding a new fragnet, e.g., A luminum Shoring. This is shown in figure 4.2.2.9. W e will discuss more on fragnet definit ion shortly. For now, assume that we have completed defining the tasks for this method fragnet. W e exit the definition screen, go back to the associated fragnet field and add the fragnet we just defined from a pop-up list. As soon as we have done this, the application marks this fragnet as used by a method and prohibits its use by another method. By doing this we can prevent the user f rom performing the mistake of making a wrong association of this fragnet with another method. If he does wish to reuse the fragnet, he can make a copy of it, and associate the copy with another method ( t h i s feature has not yet been implemented). Having defined fragnets for all of the remaining methods, we now return to our Method Statement. 118 STANDARD/tlSRBS I DEFINE/ED ITM8RBS FRAGNET, D:\REPC0N4 ' Contents IfiRBS Templates & Tree S t r u c t u r e s Type Con u Seuer- Insta H a t i o n - L a t e r a I s (Concrete P ipe) Methods Statement Lon Con Excavat ion Support Techniques Type: Method C l a s s DEFINE/EDIT MfiRBS FRAGNET M&RBS PATH: RM»T .pHT^TrtT V D e s c r i p t i o n : M^iiii mmMT^W-.uT^ SUS&EL Type: Assoc ia ted*Fragnet : F3:Def ine Fragnet 3 II - I ! . I). . / : l , i ,t n i l - i unl n n K r : l ' v i t | F7:Loq A l t - P : P r i n t Figure 4.2.2.8: Form for assigning/defining a fragnet for a method in the Standard M&RBS. 119 STANDARD/M&RBSIDEFINE/EDIT M&BBS FRAGNET Record List" "Btipnrf bXit" D:\BEPC0N4 Contents Excauat ion Add Del [Fragnet — Excauate J i T i a b e r Sho Pump Deuat Form/Reinf Assemble F S o i l Beneu H u r r y TBM 1 uminun S 1&BBS Templates & Tree S t r u c t u r e s 2OWJ Seuer Inst|~~ ^on 3on Type tement Fragnet : Aluminum Shoring CONSTITUENT/PREDECESSOR UINDOU ( E d i t Uindnu Add Df:li:tc" Nnui: n X i t ethod C l a s s iiir I i I in'ii I ; Task Fragnct Durat ion I ' l :Hc lp Tl-**-:Scrol l E n t e r : S e l e c t E s c : Ex i t 2 Figure 4.2.2.9: Defining a Fragnet for a method in the Standard M&RBS. Step 9: The next step is to use these defined method fragnets to form Operat ions fragnets. By definition Operations fragnets are composed of individual Method fragnets plus any additional tasks required to connect the fragnets. When we access the Define Tasks/Relationships screen for an Operat ion, e.g., Construct jacking shaft, then all the Methods under that Operat ion are listed along with their associated fragnet. If no fragnet is associated, a message is displayed which indicates that no fragnet has been defined for this component. Of course if the Operation has only a Resource under it, then this component does not have a fragnet associated with it. In this case 120 an Operation Fragnet is composed only of tasks. W e can now add any additional tasks and define their relationship to the method fragnets, if present. The use of this functionality will be elaborated upon in our discussion on fragnets. Step 10:We now explore the use of multi-media records. To define these records for a component, we need to navigate to that component. W e choose Define/Edit mult i-media records from the pop-up Window menu to open the Define/Edit form. The form for the Iseki UNCLEMOLE is shown in figure 4.2.2.10. W e must provide a code for the record (for a future implementat ion allowing for sorting and filtering by code), an optional descript ion, and an M&RBS record type, which we have to choose from a pop-up list. At present the records types are simply named as 1,2 and 3 and do not provide any functionality. Eventually, as we extend support to more formats, these will correspond to digital photographs, video and other proprietary formats. They will be used for two purposes: (1) to sort the records by format; and (2) to help determine the preview application 8 . To define the actual mult i -media file we then need to go a sub-window and provide the file path and an optional 8 A data format is nothing but precise specifications for encoding data about an object into the computer. There are various formats available to store images, both still and moving such as JPEG, GIF, TIFF and so on. Similarly, there are a multitude of formats for storing documents such as PDF, PS and DOC. Not all applications are able to recognize all these formats. We need special applications called previewers to view and edit such documents or images. 121 description as shown in figure 4.2.2.11. At present the user has to remember the entire path name, but we can easily configure it to provide a local directory listing to make the choice. Once he has indicated the path, the user can view the record using CompuServe 's C S H O W as the previewer. STANDAHD/M&HBSiDEF INE/UIEU MULTI_MEDIA RECORDS f i ild D:\REPC0N4 tf^ t;ir>-- ' :" •\$xr?.l Contents "Tfccofd~ "List Report eRTt T-M&RBS Templates & Tree S t r u Efconu Seuer Replacement-Main .on Zq 26 Zo Zo Zo Zo Zo Zo Zo Zo Zo Trenchless (Microtunnel DEF I M8RBS PATH: ROOT.Pipelns D e s c r i p t i o n Record type Type — Method Statement i E l l l l 1SRBS Record Type 2 18RBS Record Type 3 Type: . -Template: Pa th : i T " No. of M8RBS Records Code D e s c r i p t i o n Type: Method Statement": RDS v v _ _ L ! i J _ _ _ F 3 : A s s o c i a t e P i c t u r e s t r k i 11', r i l l i l t i A M S '•• .Yi-i'h F1T1-, ]>• I J ' . i - : F x i l n . l ' i | l l p . P i | l ) n Figure 4.2.2.10: Form for defining a multi-media records for a Standard M&RBS component. 122 STANDARD/M&RBSiDEFINE/UIEU MULTI_HEDIft RECORDS. i'ti: Edit. Hum: P f f l n T n ^ Record" L i s t fjjy^^Jj^^ D:SREFC0M4 18RBS Tenplates 8 Tree S t r u c t u r e s Type Son u Seuer : ,Bep 1 acement-Main L i Tie- (Concrete p ipe ) Method Statement Assign; P i c t u r e s M&BBS: I sek i Uncle Mole; Record: P h o t o l Photograph of UMCLEMOLE No. of p i c t u r e s D e s c r i p t i o n F i l e Name F ! Un u l'u.l .ures~ "F3: A s s o c i a t e P i c t u r e s ! merit: tr ki • u P . • ' . . . ' • .'"1 F7:Luu A l t - P : P r i n t Figure 4.2.2.11: Associating a multi-media file with a Standard M&RBS component. Step 11 :We can view the multi-media records independent of the component with which it is associated. To do this, we will return to the main M&RBS menu. If we choose record list f rom the menu we can now view the records all at once or by template. These can now be used to make the initial choice of a Method Statement during the setup process. Step !2:Finally, it is instructive to examine the report generat ion process. To generate a report, the user needs to define a contents profile which is 123 nothing but a list of predefined column formats he can choose. The report concatenates his choice of columns to produce custom reports. This is shown in figure 4.2.2.12. To produce the actual report he can choose to produce the report either for all or for selected templates, and have the output directed to the screen, to a printer or a print file. Appendix III contains a few sample reports generated using this process. STANDARD M&RBS REPORT CONTENTS PROFILE D:\REPC0N4 •iMiiaMBBHgif^ma-iatrr" •Erl~eTOrt ~1 P r o f i l e : : Type, Fragnets and Records r S i z e : D e s c r i p t i o n § k - 18 Type i 51 C l a s s Reference 1 110 Parameter/Cond i t ion Def i n i t i o n [• 150 M&RBS Fragnet 1 11 Rule S ta tus — F i l l e d F i l l e d • 11 Assoc ia ted PCBS i : 71 Meno F3:Change Status, tf>:Tag/Untag CKrtffri Esc: Exit"! Contents Width: 301 .• u i d t h of M&BBS P a t h / D e s c r i p t i o h : cblunh • 1-Mi l i»"A»i' • - . T i li I nl.-i : ,i-h i I l s i , : l > i l l l , i ' i | l lp, i 'ni)n Figure 4.2.2.12:Defining the contents of a report in the Standard M&RBS. The definition of the Resources in a Resource class or Method in a Method Class involves the same steps as listed from 1-7 and 10-12. Figure 4.2.2.13 shows a 124 sample of our implementation of the Equipment classification system provided by CIB-W75. STANDARD/MftFtBS! DEFINE/ED IT M&RBS PflRrtME TERS/CONDIT IONS _ D:\REPC0N4 Contents 18RBS Templates 8 Tree S t r u c t u r e s )euater ing Techniques Sen Equ 5pe )th Type — — Method C l a s s Earthmouihg equipment : t ' Type: Resource C l a s s i f ;pe !qu |Typ ,ab iat |Too •ROOT Resource C l a s s Earthmo wing equipment II^Excauators: Resource SubClass, Excaoators Trenchers Resource SubClass Trenchers Dredgers Resource Subclass , Dredgers Dozers . Resource SubClass, Dozers Scrapers Resource SubC1ass Scrapers raders Resource SubC1ass Graders Loaders Resource SubClass Loaders Backhoe Resource SubClass Backhoe Loaders 8 Excauators R ippers Resource SubClass Rippers F l : H c l p T l - " - : S c r o l l E n t e r : S e l e c t E s c : E x i t Figure 4.2.2.13:Resource Class definition showing the CIB-W75 classification for construction equipment. During the course of implementing the M&RBS, we found that we had developed a powerful tool for fragnets, and thus decided to develop it a little more to exploit its full benefits. Accordingly, we decided to allow the user to define standard fragnets which he could use in projects independent of the M&RBS. However, we had to take 125 care to avoid conflict between these fragnets and an M&RBS fragnet. A brief descript ion of how a fragnet can be defined follows. Step 1 : W e first move to the Standard Fragnets option and choose Add . W e need to give the fragnet a unique name, e.g., Test Sewer. Notice in the list shown in figure 4.2.2.14 that the fragnets associated with a Method have the corresponding M&RBS path listed against them. SjrANDARD/FRAGNETS "iileLi: i.dit I'uuc (.uiuLiluuiilk D:\REPC0N4 •Fragnet ; Dxcauate J a c k i n g Shafts (Timber Shore- J a c k i n g Shaft 'ump Deuaterg of J a c k i n g Shaft: l"orm/Reinf/Place t h r u s t b 1 ock Assemble. Frame <&. Guidance: Sys . toil Reneual 8 .Sepera t ion Sys H u r r y IBM: I n s t a l l a t n of p ipe M8RBS Template UiL-ik l.ugii. licpui L i Hit lAluminum Shoring Excauat ion Support Techniques xcauat ion Support Techniques ROOT.Shoring Fragnet Mame: Figure 4.2.2.14: Fragnet Listing under the Standard Fragnets. 126 Step 2: Next, choose to view the constituents. Of course there aren't any because we have not yet defined them. Note that the screen is exactly the same as the one on the M&RBS side. Step 3: W e start defining the fragnet by adding tasks. The task addit ion is a looping process which continues until the user decides to end it using the Escape key. The user then assigns predecessor relationships between the tasks as shown in figure 4.2.2.15. Note that we only allow the use of typical relationships. Further, by using location offsets, we allow the fragnet to loop onto itself f rom one location to the next. STANDARD/FRAGNETS D:\REPC0N4 > •• ' C o n s t i t u e n t s pFrag.net. : Excavate J a c k i n f M&RBS T e m p l a t e — C o n s t i t u e n t Task: No. of T y p i c a l Predecessors : Type. Pred: Const i tuent: Re l Lag mm i O f f s e t . f F8>F9Xi?3-1T: P e l ? Ins K F j e d g j ^ i F i B : Su i ten to Succ ; • i i' • ' 1 i i i 1 i • i ' 11 | f iM. i ig A l t - P : P r i n t Figure 4.2.2.15: Defining the constituent tasks of a fragnet. 127 Step 4: Once the user has defined the predecessor relationships, he can choose to check the logic of these relationships. S t e p 5: One final concept is that of a complex fragnet. A complex fragnet is one which is composed of other fragnets as well as linking tasks. To demonstrate this, let us use our defined test sewer fragnet as a part of a complex fragnet to construct a sewer line section. The steps for defining a complex fragnet are identical to the ones for a simple fragnet except that we now allow the user to choose a fragnet f rom a list of user def ined fragnets. The other steps are exactly the same. Figure 4.2.2.16 shows the assignment of a predecessor relationship between a task and a method. Note that at present the nesting of fragnets can be as deep as desired. This, however, is difficult to check and ensure adherence to our definit ions of a Method and an Operation. In a future study, this should be explored. Another issue to remember is that we should not allow Method fragnets to be used in the formulation of non-Operation complex fragnets as this will result in duplication if the user decides to use both the M&RBS and the fragnets. W e do not check for this. 128 STANDARD/FRAGNETS D:\REPC0N4 IJIISP •EtffiTSJnTn7T?S Check L o g i c Report e X i t [Fragnet Cxcauate J a c k i n iTimber Shore Ja Jump Deuaterg 6 r o r m / R e i n f / P l a c Assemble Frame Jo i1 Reneua1 fi H u r r y TBM Inst iluminum S h o r i n iTest Seuer M8RRS Template Fragnet : Construct Seuer P i p e l i n e Seen CONSTITUENT/FREDECESSORJJINDOU Delete Muue e X i t ' *\.n-V Add r Cons t i tuent Durat ion H u r r y TBM I n s t a l l a t n of p i p e l "Ensure C o r r e c t Alignment ! Const m e t Seuer I Fragnet L i s t Assemble Frame 8 Guidance Sys . S o i l Reneua1 & Seperat ion Sys ! l u r r y TBM I n s t a l l a t n of p ipe luminum Shoring Construct Seuer P i p e l i n e Seen Enter :Add E s c : E x i t !'• • .,• .tit S S.-.,i"-li Eu1.:r:Si li-"..t {"• r t'.i it 11 . 1 ' i f l l , i > Figure 4.2.2.16: Defining a Complex Fragnet. The Project M&RBS is exactly the same in structure and implementat ion as the Standard M&RBS with a few crucial differences: 1. W e allow the use of multiple Method Statements to define an overall project Method Statement. 2. W e allow access to and insertion of Standard M&RBS Method Statement templates in the Project Tree. 3. W e do not allow the definition of fragnets on the project side. They have to be predefined on the Standards side. 129 Figure 4.2.2.17 shows a tree structure defined for the project using our Standard Sewer Construction template as well as a locally defined template for pump house construction. The figure shows the Method Statement for a sewer project which is composed of two Standard Method Statements - Sewer and PumpHouse. Note that we represent the project Method Statement by the root. Since this statement is only for a particular project, we have no name for it. The structure under a Method Statement itself is similar to that on the standard side. r PBOJECT/HSRBSIDEFINE/EDIT M&RBS PflRflMETERS/CONDITIOMS D:NREPC0H4SPR0J1QSTHESIS E H 3 | UiTi'dou Check "Logic Report. eXTf. '_ ~" Seuer Methods Statement PumpHouse Methods Statement S-SubStruct Operat ion ]—CAT-E70B Resource 0 IH. FormSet Resource Carpenter Resource •—Shouelers Resource B u i l d P l n t h Method UaterProof Method : B a c k f i l l Method § - S u p r S t r u c t Operat ion Trenchless ( M i c r o t u n n e H i n g ) Seuer C o n s t r u c t i o n Pump House C o n s t r u c t i o n f o r Seuer P i p e ! i n e Cons truc t Subs truc ture , CAT-E7QB ( C a t e r p i l l a r H y d r a u l i c Excauator) ' . • i . ; .:• i.r • i .<iii i in FormUork f or the concrete Carpenter f o r the forms Shouelers to Shooel and Leue l the concre t B u i l d P l i n t h Wal ls UaterProof the, Foundation Backf i l l to the ground l eue l Cons truc t S u p e r s t r u c t u r e ; unpHouse .SubStruct .CastBase 1 , . P , n - "in.liiu M i l : 1 in- IcnplaU- .tl .• ith ii,ui. I f ' l i l I'lrln.' n» I I ! 1 in I I i .1 \ i i i 'i • l I "I ii . . I I hi I ' M - 1 i il:0t 1 i • I n^ t i I \ \ . .- I > i—I Figure 4.2.2.17: Project M&RBS for a Sewer Project assembled from two Standard Method Statements. 130 4.2.3 Physical Component Breakdown Structure (PCBS) The implemented structure for the PCBS is exactly the same as the M & R B S 9 (except the fragnets). W e will therefore not dwell much on demonstrat ing its use, but will illustrate its application sufficiently in the creation of a Physical representat ion for a sewer project. Figure 4.2.3.1 shows the Template listing for the Standard PCBS side. Note that we can have templates at different levels. Higher level templates can then be made by combining those from a lower level. Figure 4.2.3.2 shows a Standard Template for our hypothetical sewer project. As discussed earlier, we can have a choice to have a deep or a flat hierarchy depending on the type of project. W e have decided to represent the sewer project using a relatively flat breakdown structure. Figure 4.2.3.3 shows sample parameter and condition definition. Note the similarity in the screen design for the PCBS and M&RBS. 9 In fact as good programming practice dictates to make as much of the program code reusable as possible, we have a common executable file for these two varied applications which responds appropriately to the calling program. 131 STANDARD/PCBSiDEFINE/EDIT PCBS 8 PARAMETERS/CONDITIONS Add D:\REPC0N4 rPCBS;Tenplates 8 T r e e . S t r u c t u r e s Type tSewer P i p e l i n e Ins tn l l » i t t o n " P r o . j c i ' • i.i'je'ntionft i ) Pro.]' . 8 >euer VIpe1ine 1nsta11atlon P r o j e c t ( M i c r o t u n e 11ng) Fro j e c t leuer P i p e l i n e Benedia t ion P r o j e c t (Convent ional ) P r o j e c t leuer Pipe 1 ine Rened i a t i on P r o j e c t (M i crotunne l i n g ) Pro jec t . lain L i n e Subproject . a t e r a l Connect ion Subproject leuer P i p e - r u n E1 ement [acking Shaft . Element, lece i u i n g ' S h a f t Element Trench f or con uent i ona1 seuer c o n s t r u c t ion Elenent Ian-hole Elenent 'ressure R e l i e f ualue Elenent lush ing Syphon Elenent 'auenent S t r u c t u r e Elehent I i I • .it i h i , i ! i i .'At. I i i I I' i : !'<• i I T I , In , ! H i' i Figure 4.2.3.1: Template Listing for Standard PCBS. 132 STANDARD/FCBS!DEFINE/EDII PCBS « PflRflMETERS/COHDITIOHS 'Record "List" Report H t i C * D:\REPC0N4 Contents rPCBS Templates &* Tree S t r u c t u r e s Type 3euer P i p e l i n e I n s t a l l a t i o n P r o j e c t (Conuentional) P r o j e c t eu ieu la i ,at leu ac lec [Tre Ian 're lu 'ao -ROOT P r o j e c t JackShaft Element Seuer P i p e l i n e I n s t a l l a t i o n P r o j e c t ( H i c r o t u n e 1 Jacking' 1 Shaft: r P i p e l Plpe2 Recushaft —Man-hole -PRU —Pipe-run - S h a f t L o c s —Manhole OOT.Piperun Subelement Subelenient Element Element Element L o c a t i o n L o c a t i o n L o c a t i o n Pipe Type 1 (For use u i t h more than one p i P ipe Type Z (For use u i t h more than one p i Rece iu ing Shaft Manhole Pressure R e l i e f Value P i p e - r u n L o c a t i o n Locat ion of J a c k i n g 8 rece i u i n g Shaf t s : &•Man Manhole locn f o r Manholes located independen I" . . h . i l i i U n v J i i u '.'i I ' : ! i i - - l i . - n p l c i l i «I n l i l i - u - ' l ' " l i l - l ' i I n s « I . . . m i I ••••] | i i j i i i - i 1 / ( 1 [ ' , i n . i i n .) • . i i l i l i u i - l ! ' ! • : | i r I t ' l l - F ' i : l n - i - i l ! i l r ii - l i - y i -1 Figure 4.2.3.2: Standard Physical Breakdown Structure for a Sewer Project. 133 STANDARD/PCBSiDEFINE/EDIT PCBS 8 PARAMETERS/CONDITIONS D:\REPC0N4 ;ef fTITia g e T e t e l 1 La PCBS:: Seuer P ipe 1 ine Insta H a t ion P r o j e c t (M icrbtune 1 ing) B/QVL Uni-i D e s c r i p t i o n : Class:: llljlll •m 1 Ualue Type: Boolean Cond Std Ualue 1 Std Ualue 2 " F ' l J R e l p y F Z : L i s t F10KanFrvSTtscf :.- i i | FY:Log A1 t-P: 1'r int Figure 4.2.3.3: Parameter definition for Standard PCBS Component. 4.2.4 Standard Fragnets The implementat ion of feasibility rules has been left to future work. W e therefore chose instead to give a short demonstrat ion of the ability to copy fragnets over to the PROJECT LEVEL and use them in the Activity list. To access the fragnets for use on a project they have to be copied to the PROJECT LEVEL. This is achieved in the Activity Spreadsheet by selecting Frag f rom the bar menu. The system then asks us for a fragnet to insert into the list as shown in Figure 4 .2 .4 .1 . The project level does not differentiate between M&RBS and non-134 M&RBS fragnet at present. In the absence of a hierarchical planning structure, we decided to map each task onto an activity. The algorithm therefore numbers each task as an activity and inserts it into the spreadsheet. In the case of a complex fragnet (one comprised of several fragnets), all of the tasks of the underlying fragnets are coded as activities. The routine assigns the location default set by the user to each activity and task durations if any are assigned to the activity as duration per location. The precedence relationships defined in the Standard Fragnets are also maintained. D:\REPC0N4\PR0J10NTHESISl ACTIUI TV DATA/DESCRIPTION; UINDOU r Code - D e s c r i Fragnet Fragnet, lExcauate Jacking: Shafts ITimber Shore Jack ing Shaft IPump Deuaterg: of Jacking: Shaft - i I • ! I l l J ! . ' < • I i l l :< 1 • • . •• tesemb1e Frame 8 Guidance Sys . S o i l Reneual 8 Seperat ion Sys Slurry TBH I n s t a l l a t n of pipes Huminun Shoring |Test: Seuer Construct: Seuer P i p e l i n e Seen •' i 'Hi' 11- il I '. H I i.h rli'i i i • i f i . . I'JI • i T i , r . i i i p , i ' > | i i i i Figure 4.2.4.1: Copying Standard Fragnets to Project Level. 135 4.3 Validation W e need to validate two things. The first is the validity of our initial idea that we can design a methods selection system which would achieve our stated aim of providing the user with a toolkit to encode his knowledge of construction methods in a readily usable form for use as appropriate, to automate or facilitate the methods selection process for selected aspects of future projects; as well as meet the design principles. The second is the validity of the model we have implemented. W e have to test it using real world scenarios to prove that it can represent actual Method Statements in a way that is useful for not only assisting in decision making, but in a way that improves decision making 4.3.1 Validity of the initial idea The validation of the initial ideas can be checked by analyzing the degree to which we have succeeded in meeting the previously stated objectives. Our analysis is summarized in Table 4.3.1.1 136 Table 4.3.1.1: Evaluation of our conceptual model against the stated aim and design principles Initial Design Principle Degree to Examples of how we achieved it which met Simple structure and High 1. t ransparent working. 2. By keeping the number of system components small, i.e. by using a very terse but precise language. ( Implemented) The user has access to the system's reasoning process, and can easily follow its trace with the knowledge of a simple set of conventions. (Not yet implemented) Ease in updating and Medium - 1. By providing the ability to readily add maintaining the data High new methods, new resources; edit standard M&RBS templates easily, etc. 2. By providing access to mult i -media records, we provide the user with a tool to keep his data current. 3. By instituting checks to maintain data integrity. 137 Taking advantage of Medium advances in technology Flexibility to ensure different Very High modes of use Al lowing users to work at Very High multiple levels of detail To design the system so as Very High to allow its use for purposes other than methods selection. The ability to store and manipulate digital images is now commonly available. W e are enabling the user to take full advantage of this through the use of mult i -media records This has been a major focus. See the discussion on Modes of operat ion and Setup options. The system design has also focused strongly on this aspect. See the initial discussion on M&RBS. 1. W e provide independent access to records. 2. W e allow for the use of f ragnets independent of the M&RBS. 138 4.3.2 Validity of the implemented model There are a number of aspects to be validated. 1 . The ability to meaningfully represent Method Statements, methods and resources in a way that improves decision making To validate this aspect we revisit the Yellow Brick Road project ment ioned in Chapter 3. You are back in your role as the Senior Manager responsible for planning in a firm that specializes in sewer construction. You are presented with the system implemented as explained in section 4.2 and asked to determine if the system can meaningfully represent Method Statements, methods and resources in a way that improves decision making. You decide that the system needs to satisfy the following three requirements in order to achieve this: a. The representation should be complete. b. The representation should be easy to use. c. The representation should provide meaningful insights to allow better choices. You decide to evaluate each of these against the backdrop of the Y B R project. 139 a. Is the representation complete? What was needed in the bid preparation of the Y B R project was an efficient way to represent all information available to the company in the field of conventional sewer construction and trenchless sewer construction methods available on the market. In the system the Standard M&RBS can be used to completely store information about already tried and new construct ion methods, as well as supporting information in the form of the resources needed, their production rates under different condit ions and their capabil it ies and limitations; and the tasks needed to perform the work using a particular method in the form of fragnets. In addition, the system provides the use of mult i-media records to store information that cannot be readily encoded. This can further be. coupled with the Standard PCBS to provide the user with a spatial perspective on the use of certain methods. Thus the system provides a complete representation of construction methods and their applicability. b. Is the representation easy to use? Ease of use deals with providing the user with an intuitive and comfortable working environment that performs its stated functions efficiently with a min imum number of errors while keeping details of the actual implementat ion hidden f rom the user. In the case of the Y B R project, this can be measured in terms of the ease with which information about the company's methods for convent ional sewer 140 construction can be retrieved and the ease with which new information (obtained from Iseki as well as others companies engaged in trenchless construction activities) can be entered into the system for easy future reference. In order to make the system easier to use for users in the target domain, i.e., construction, the system uses a near industry terminology. The system provides the user with the tools to develop a classification structure which he can easily customize as per his changing needs. Using this classification structure, it would be easy to retrieve data on any construction method. Similarly, this classification structure also helps the user to enter data about a new method or resource. Another feature of the system is the ability to browse the multi-media records to easily pinpoint useful data to be retrieved. Further, a number of checks have been implemented in the system to trap errors. The user can also use multi-media records to keep up to date information about new and evolving construction technologies without explicitly encoding them in the system, thereby using the system as a data store which he can tap for more information. If using a new technology appears beneficial under some particular circumstances, then the user can obtain more detailed information on them. Having said this, it is probably fair to say that ease of use is relative. What one might regard as a very user-friendly system may not be regarded similarly by someone else. Thus we can say that the system is relatively easy to use. 141 c. Does the representation help provide insights for better choices? If the system was used in the bidding for the Y B R project, then it should have been capable to allow the user to come up with the choices of hydraulic shoring for the trench as opposed to t imber shoring as this was a better choice. The system is capable of this as it provides the user with the ability to mix and match methods and resources to develop new Method Statements for the construction of a particular job. In addit ion, the system allows the user to associate the individual M&RBS components with PCBS components to give the use a spatial perspective . The implemented system can therefore be used to completely and meaningful ly represent information, retrieve and view information about construction methods and use this to make better choices. The ability to reason and reach conclusions that an expert would make. Since the implementation of the model is not 100% complete, we cannot test its validity under field conditions. However, we detail here a procedure that could be used, to give the reader an idea of how we envisage the testing of such models. W e envisage two ways for testing the model: ] . By testing data from previous projects. 142 By enlisting the help of experts. Let us now explore each of these techniques: 1 . By testing data from previous projects: To use this alternative would require data on at least four major projects to completely validate the system. The first two projects will need to have a fairly obvious choice of Methods. The other two would then have a choice of construction methods alternatives available for their construction. For example, if we decide to choose four sewer installation projects to validate the model, then the following indicates a meaningful choice for the projects: Project 1: The project conditions allow it to be constructed using only microtunneling and pipe jacking. Project 2: The project conditions allow it to be constructed using only conventional means. Project 3: The project conditions allow for the adoption of either of the two methods. Project 4: The project conditions allow for the adoption of either of the two methods. By mapping the response of the implemented model to each of the above scenarios we can determine if it is robust enough. 143 2. By enlisting the help of experts: To use this technique we would need to create several sample project scenarios, similar to the one above. W e would then interview a number of experts to gain the methods alternative that they would have preferred to use in each of these and the reason for their choice. W e would also in this course try and determine their reasons for not selecting any of the other available methods alternatives. By comparing the response of the system to the expert 's response we would validate the system. 144 5. Recommendations for future work In the previous chapter (section 4.3), we summarized what was accompl ished in relation to the objectives stated at the outset for the thesis. However, the method selection problem domain is rich with challenges. Though we have come a long way in developing our system, much work remains to be done. The system, though sufficiently robust, needs to be validated in other areas of civil engineering construct ion. W e present in this chapter our vision of what should be done to develop this system further to its logical end - its active use by the construction industry. This chapter is divided into three sections. The first section lists the major components of the system yet remaining to be worked on. The second lists the deficiencies in the current implementation that require further attention and the third lists a series of features that might be added to the system to make it more user friendly and acceptable to the construction industry. 5.1 Items requiring major focus Some of the suggestions for future work are evident f rom the discussion on conceptual design: l . The first would be to implement the reasoning system described earlier and test it using real world and synthetic examples. 145 2. The next logical step in the development of the system would be to extend the reasoning further to enable the system to analyze all the feasible alternatives and rank them as to the degree to which each alternative can meet the stated project alternatives. 3. The implementat ion of a hierarchical planning structure is also an evident choice for the immediate future. This structure would represent activities as independent trees having only one branch level beneath them, that of tasks. The user now has the advantage to work at the composite activity level (i.e. a coarser level of detail) or at the task level (i.e. in finer detail). The user can benefit f rom the much greater control offered by this structure both over the execut ion of the project and the planning thereof. Also, now he does not need to plan separately for different purposes, for example, generally the site personnel are provided with detailed day-by-day schedules (sometimes planned to the minute) whereas senior management is provided with a very broad plan focusing on the complet ion of important milestones. The general practice is to prepare only one plan to an intermediate level of detail and then either blow it up for site and extract the milestone achievement dates for the senior management . This process has a major deficiency of being subject to errors. If the user plans using a hierarchical structure, he can prepare the plan at the finest level of detail and then roll it up as necessary for reporting purposes. Also through the use of fragnets we have now provided him with the ability to define standard activity trees, which will greatly facilitate this hierarchical planning process. 146 4. W e have not treated the cost aspect of method selection at all in this research (nor, for that matter, safety or risk). Cost is usually an overriding factor in the selection of a method, especially in the case of new, unproven methods. Detailed cost est imates are generally not necessary for making a methods selection decision; a rough unit cost estimate is sufficient. Therefore, relatively simple but robust cost models need to be developed which account for the site condit ions, the company's own resources, indirect costs, etc. These models should allow for the treatment of perceived risks. 5. At present the reasoning model is not complete enough to interpret the use of complex Method Statements. For example, on some sewer jobs, part of the works is constructed using microtunneling, whereas the remaining part is constructed using the conventional open-cut technique. The ability to reason about "Hybrid" Method Statements needs to be added. 6. Our treatment of resources is thorough on the methods selection side. However, it needs more work when used in the generation of the initial project plan. W e have successfully worked out the way to assign resources to activities. However, the resource levels are dependent on the method selected and product and site condit ions. Ideally the system should help the user to decide on appropriate resource levels, prior to exiting the setup process. This will considerably reduce the planning effort required. 147 7. Another issue is the integration with the Internet. The recent development of the first DOS based graphical browser could well pave the way in this direction. Further, we can realize other benefits by integrating it with previewers such as Ghostscript which are freely available. This is important to take advantage of the weal th of information that is available (and likely to increase in the future) on the internet. 8. A final recommendat ion would be to port the entire application to a modern graphical user environment, i.e. Windows. In addition to wide user acceptance, this would give us multi-tasking which is lacking in the current system. 5.2 Wrinkles that need ironing out Various parts of the design have been implemented. For these parts, that we have implemented, this section lists some of the shortcomings that might be addressed as a part of a future research effort. 1 . The ability to copy individual Methods or Resources into a Method Statement must be added. Presently, the user has to define each individual method or resource in a Method Statement, and add a path name corresponding to this component in a method or resource class. 148 2. At present only scanned images can be stored as mult i-media records. Al lowing the inclusions of videos, and soundtracks would be an asset. The integration of file previewers such as the ones for CAD drawings would be useful. 3. The ability to pick from the Standard fragnets, while using them directly in schedul ing for a project would be a useful feature. 4. More work needs to be done on the checking of logic for fragnets. 5. Users need to be given the tools to make additions to the linguistic parameter list, as they think about additional feasibility options. 6. A select-sort facility to produce more customizable reports needs to be worked on. For example, if the user only wants to see the Operat ions in a Method Statement to get an idea of the final activities, he presently needs to print out a whole report including all of the components. 5.3 Performance and usability improvement features This section is organized entirely from the perspective of an end-user of the system and as such is somewhat reflective of the idiosyncrasies of the author as regards to computer systems. 1 . In practice, an expert would not like his Standard Templates tampered with by other users. This would require him to keep constant checks on the data and 149 would obviously lead to ill-feeling. An ability, therefore, to restrict access to the S T A N D A R D S (e.g., by using a password) is needed. 2. The system requires the user to select a Method Statement which he thinks is feasible to start the automated reasoning process. He would therefore like to have the ability to organize the Method Statements into classes representing his v iew of feasible Method Statements. This should be included as a part of the system. 3. In actual use, the Standard M&RBS would expand to include many Method Statements, Method Class and Resource Class templates. The same is true for the Standard PCBS. The addition of searching and filtering capabil it ies to retrieve information f rom these would be most welcome. 4. A similar ability as above with records is also desirable. 5. The Interface needs a little revamping to make the user access to information easier. For example, records should be moved inside the template, so that they can also be viewed f rom the tree menu. 6. An integrated help facility would serve to reduce the user effort in memoriz ing steps and thus increase his productivity considerably. 150 BIBLIOGRAPHY Abdul-Malak, M. U., Mezher, T. and Murphree, E. Jr. (1995). "Decision Support System Framework for Construction Technology Transfer and Diffusion" Transportat ion Research Record, n 1491, Jul 1995, pp. 49 - 6 1 . A l -Hammad, I. (1991). (1991). "A Knowledge-based f ramework for construction method selection." Ph.D. thesis, Department of Civil Engineering, University of British Columbia, Canada. Alkass S. and Harris F. (1988) "Expert System for earthmoving equipment selection in Road Construction." A S C E Journal of Construction Engineering and Management , 114 (3), pp. 426-440. Amer ican Concrete Pipe Associat ion (1980). "Concrete Pipe Handbook" Vienna, Virginia, U. S. A., ISBN 0960386815. Awad Sal iman H. (1989). "An Interactive Knowledge-Based Formwork Selection System For Buildings." Ph.D. thesis, The Pennsylvania State University, U. S. A. Belford, G. G. and Santone, A. L. (1989). "Object-Oriented Databases for Construct ion Data" Software Track, Proceedings of the Twenty- Second Annual Hawaii Conference on Systems Design, Vol. 2, pp. 559-568. Brandon, P. and Martin B. (1995). "Integrated Construction Information" E & FN SPON. London, U. K., ISBN 0419203102. Caterpil lar Inc. (1992). "Caterpillar Performance Handbook, 2 3 r d Edit ion" Peoria, Illinois, U. S. A. CIB Working Commission W75 - Mechanization in Building (1984). "Recommended International Classification Of Construction Machines And Equipment" CIB Working Commission W75 - Mechanizat ion in Building, Prague. Clarke, N. W. B. (1968). "Buried Pipeline" Maclaren and Sons Ltd., London, ISBN 08533401202. Commit tee on Application of Expert Systems to Material Selection during Structural Design (1995). "Computer - Aided Materials Selection During Structural Design" National Academy Press, Washington, D. C , U. S. A., ISBN 0309051932. Echeverrry, D., Ibbs, W. and Kim S. (1991). "Sequencing Knowledge for Construct ion Scheduling." A S C E Journal of Construction Engineering and Management , 117 (1), pp. 118-130. Encarnagao, J. L. and Lockerman, P. C. (Eds) (1990). "Engineering Databases - Connect ing Islands of Automation Through Databases" Springer - Ver lag, Berlin, Hiedelberg, Germany, ISBN 0387520597. Fenly, C. and Harris, H. (1988). "Expert Systems: Concepts and Appl icat ions" Cataloguing Distribution Service, Library of Congress, Washington D.C., ISBN 0844406112. Fischer, M.A and Aalami, F. (1996). "Scheduling with Computer- interpretable Construct ion Method Models." A S C E Journal of Constriction Engineering and Management , 122 (4), pp. 337-347. Gray, C. and Little J. (1985). "A Systematic Approach to the Selection of a Crane for a Construction Site." Construction Management and Economics 3, pp. 121-144. Hadjigeorgiou J. (1988). "A Knowledge-Based System for Selection of Excavating Equipment" Technical Report No. 08, Division of Mechanical Engineering, National Research Council Canada. Halpin, D.W. and Woodhead, R.W. (1976)."Design of Construction and Process Operations", John Wiley and Sons, New York, NY, U. S. A., ISBN 0471345652. Hendrickson, C , Zozaya-Gorastr iza , C. and Rehak D. (1989). "Knowledge Based Process Planning for Construction and Manufacturing." Academic Press, Boston, Massachusetts, U. S. A., ISBN 0127819002. Institution of Public Health Engineers (1985). "NO-DIG 85: Proceedings of the First International Conference, London 16-18 April 1985" London, U. K., ISBN 0905188071 . loannou, P. G. and Martinez, J. G. (1996). "Comparison of Construct ion Alternatives Using Matched Simulation Experiments" A S C E Journal of Construct ion Engineering and Management, Vol. 122. No. 3, pp. 231 - 2 4 1 . loannou, P. G. and Sou-Sen, L. (1991). "Construction Technology/ Method Identification and Selection System" Preparing for Construction in the 2 1 s t Century - Proceedings of Construction Congress' 9 1 , Cambridge, Massachusetts, pp. 638 - 643. loannou, P. G. and Yiu L.Y. (1993). "Advanced Construction Technology System". A S C E Journal of Construction Engineering and Management , 119 (2), pp. 288-306. ISO (1994a). "Building Construction Core Model, Project Proposal" ISO TC184/SC4/WG3 Document N341 , October 1994. Joint Task Force of the American Society of Civil Engineers and the Water Pollution Control Federation (1982). "Gravity Sanitary Sewer Design and Construct ion" American Society of Civil Engineers, New York, New York and Water Pollution Control Federation, Washington, D. C , U. S. A., ISBN 0872623130. Liggesmeyer, P. (1996). "Selecting Engineering Techniques using Fuzzy Logic Based Decision Support" Proceedings of the IEEE Symposium and Workshop on Engineering of Computer-Based Systems, Friedrichshafen, Germany, pp. 427-434. 153 Lim B. T. C. (1989). "Causal Modeling of Construction Project Performance." Ph.D. thesis, Heriot-Watt University, U. S. A. Lin, K. and Haas, C. (1996). "An Interactive Planning Environment for Critical Operat ions." A S C E Journal of Construction Engineering and Management , 122, (3), pp. 212-222. Mutagwaba, W. K. and Terzepoulos, N. G. (1994). "Knowledge-Based System for Mine Method Selection" Transactions of the Institution of Mining and Metallurgy, Section A: Mining Industry, Vol. 103, Jan-Apr 1994, pp. A27-A32. Nichols, H. L. Jr. (1976). "Moving the Earth - The Workbook of Excavation Third Edition" Mc-Graw Hill, U. S. A. Occupat ional Safety and Health Administration (1990). "Construct ion Standard for Excavations" Associated General Contractors of Amer ica, Washington, D. C , U. S. A. Ontario Concrete Pipe Associat ion (1989). "Concrete Pipe Design Manual" Etobicoke, Ontario, Canada. Peurifoy, R and Ledbetter, W. (1996). "Construction Planning, Equipment and Methods 4 t h Edition" Mc-Graw Hill International Editions, Singapore, ISBN 0070498369. Portland Cement Associat ion (1968). "Design and Construction of Concrete Sewers" Skokie, Illinois, U. S. A. R. S. Means Company Inc. (1987). "Means Heavy Construction Cost Data 1 s t Annual Edition" R. S. Means Company Inc., Kingston, Massachusetts, U. S. A. Ratay, R. (1995). "Handbook of Temporary Structures in Construction", Mc-Graw Hill, New York, U. S. A. 4 Reda, R. and Carr, R. I. (1989). "Time-cost Tradeoff Among Related Activit ies." A S C E Journal of Construction Engineering and Management , 115 (3), pp. 475-486. Russell, A. D., Guindy, K. and Alldrit, M. (1997). "Computer System for the Selection of Trenchless and Conventional Methods for Underground Utilities" North Amer ican NO-DIG '97 Conference Papers, pp.357-370. Shaked, O. and Warszawski , A. (1995). "Knowledge-Based System for Construction Planning of High-Rise Buildings" A S C E Journal of Construct ion Engineering and Management, Vo l .121, No. 2, pp. 172 - 182. Skibniewski, M. J. and Chao, L. (1992). "Evaluation of Advanced Construct ion Technology with A H P Method" A S C E Journal of Construction Engineering and Management, Vol. 118, No. 3, pp. 577-593. Skibniewski, M. J. and Chao, L. (1995). "Neural Network Method of Estimating Construction Technology Acceptabil ity" A S C E Journal of Construction Engineering and Management, Vol. 121, No. 1, pp. 130-142. Sou-Sen, L. (1992). "Object-Oriented Representation Model of Construct ion Technology Information (Information Management) ." Ph.D. thesis, The University of Michigan, U. S. A. Stein, D., Mollers, K., Bielecki, R. (1989). "Microtunnell ing - Installation and Renewal of Nonman-size Supply and Sewage Lines by the Trenchless Construction Method" Ernst & Sohn Verlag fur Architektur und technische Wissenschaf ten, Berlin, Germany, ISBN 3433012016. Syal, M G. (1992). "Construction Process Knowledge Model to Assist Method Selection in Project Planning." Ph.D. thesis, The Pennsylvania State University. Syal, M. G., Parfitt, M. K., and Wil lenbrock, J. H. (1993). "Design Information Hierarchy for Construction Method Selection Process" Comput ing in Civil and 155 Building Engineering - Proceedings of the Fifth International Conference (V-ICCCBE), Anaheim, California, U. S. A., Vol. 1, pp. 742 - 749. Tatum, C. B. (1987). "Classification System for Construction Technology.", A S C E Journal of Construction Engineering and Management, Vol. 114, No.3, 344-363. The Pipelines Industries Guild (1984). "Pipelines Design and Construct ion" Construct ion Press, New York, U. S. A. Thomson, J. C. (1993). "Pipejacking and Microtunnell ing" Blackie Academic and Professional, Great Britain, U. K.JSBN 0751401021. Trinh, T. T. P. and Sharif, N. (1996). "Assessing Construction Technology by Integrating Constructed Product and Construction Process Complexit ies: A Case Study of Embankment Dams in Thailand." Construction Management and Economics, 14, pp. 467-484. University of Texas, Petroleum Extension Service, Pipeline Contractors Associat ion (United States) and Texas Education Agency (1966). "A primer on Pipeline Construction 2 n d Edition" Petroleum Extension Service, University of Texas, Aust in, Texas, U. S. A. Winstanley, G., Chacon, M. and Levitt, R. (1993). "An Integrated Project Planning Environment" Intelligent Systems Engineering, Vol. 2, No.2, pp. 9 1 -102. Yokel , F. Y. (1980). "Recommended Technical Provisions for Construct ion Practice in Shoring and Sloping of Trenches and Excavations" Department of Commerce and National Bureau of Standards Washington, D. C , U. S. A. Yokel, F. Y., Tucker, R. L. and Reese, L. C. (1980). "Soil Classification for Construction Practice in Shallow Trenching" Department of Commerce and National Bureau of Standards Washington, D. C , U. S. A. Appendix I - E-R Diagram Appendix II - Command Listing L is t d i s p l a y Command Name Screen Location Act ion Add (A) Menu Bar Opens up a form to secure data for creating a template/fragnet. Delete (D) Menu Bar Deletes the selected template/fragnet. Move (M) Menu Bar Al lows user to sort the templates as desired/fragnet. Edit (E) Menu Bar Al lows the user to change the template/fragnet name. Contents / Consti tuents (C) Menu Bar Al lows user to bring up a window to enable the user to access contents of a selected template/fragnet. Report (R) Menu Bar Al lows the user to define report contents and also to create the reports. eXit (X) Menu Bar Closes the active window and returns to the client window. Right Arrow (-») Status Bar Move right to select Menu Item. Left Arrow (<-) Status Bar Move left to select Menu Item. Up Arrow (t) Status Bar Scroll up to select a template/fragnet. Down Arrow {I) Status Bar Scroll down to select a template/ fragnet. Home Move to the first template/fragnet in the list. End Move to the last template/fragnet in the list. Page Up Move up the template/fragnet list by one screen height. Page Down Move up the template/fragnet list by one screen height. Tab and Shift+Tab Scroll by a screen length to view additional information on fragnets. Enter Status Bar Select item to access its contents. F1 Status Bar Brings up context sensitive help. Esc Status Bar Interrupts the active process and returns control to the client process. 160 Graphical Tree Display Format Command Name Screen Location Act ion Edit (E) Menu Bar Switches the computer to edit mode to enable user access to records. Window (W) Menu Bar Gives a choice list of the functionalit ies available in the active window. eXit (E) Menu Bar Closes the current w indow and returns to the client window. F3 Brings up the Window choice list in a pop-up menu. F5 Status Bar Inserts a component as a lower branch of the tree than the selected component. F9 Status Bar Inserts a component in the same level of the tree as the selected component. Ctrl+F5 Status Bar Inserts a template in a lower branch of the tree than the selected component. Ctrl+F9 Status Bar Inserts a template in the same branch of the tree as the selected component. + or Right Arrow (->) Status Bar Expands the tree to show components one level below in the hierarchy. - or Left Arrow (<-) Status Bar Collapses the tree to the selected component. Up Arrow ( t ) Status Bar Scroll up to select a component . Down Arrow (I) Status Bar Scroll down to select a component . * Blows up the selected component to show all the levels in the hierarchy. Tab and Shift+Tab Scrolls the component text. Enter Status Bar Selects a particular component for editing. F1 Status Bar Brings up context sensit ive help. Esc Status Bar Interrupts the active process and returns control to the client process. 161 Report Display (On Screen) Command Name Screen Location Act ion Up Arrow (t) Status Bar Scroll the screen up. Down Arrow (I) Status Bar Scroll the screen down. Right Arrow (-^) Status Bar Scroll the screen right. Left Arrow (<-) Status Bar Scroll the screen left. Tab and Shift+Tab Status Bar Scroll the screen by one screen length. F1 Status Bar Brings up context sensit ive help. Esc Status Bar Interrupts the active process and returns control to the client process. F o r m I n p u t Command Name Screen Location Act ion Tab or Shift+Tab Status Bar Moves the focus to the next form element. F1 Status Bar Brings up context sensit ive help. Esc Status Bar Interrupts the active process and returns control to the client process. F10 Status Bar Confirms entries made in a form. F3 Button in form Opens up a sub-form for further entry or to call an external application for previewing. F2 Status Bar Brings up a scrollable pop-up list indicating the choices available for the current field. Up Arrow (t) Scrolls up to select an item in a scrollable list box or a pop-up list. Down Arrow (I) Scrolls down to select an item in a scrollable list box or a pop-up list. Left Arrow (<-) Status Bar Scrolls the text in a scrollable field to the right. Right Arrow (->) Status Bar Scrolls the text in a scrollable field to the left. F9 Inserts a record for data entry. F8 Deletes a record. Enter Status Bar Selects an item in a pop-up list. 162 Appendix III - Sample Report U B C C O N S T R U C T I O N M A N A G E M E N T L A B T y p e , F r a g n e t s and R e c o r d s S e l e c t : S e l e c t i v e l y Report Date: Report Tine: 150CT97 16:83:25 R E P C O N ™ Page 1 Of 14 l e n p l a t e : T r e n c h l e s s ( M i c r o t u n n e l l i n g ) S e w e r C o n s t r u c t i o n METHOD, RESOURCE BREAKDOWN STRUCTURE fKRBS PATH I DESCRIPTION ROOT |Trenchless (Microtunnelling) Seuer Construction Type Methods Statement Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 WIDE 2 N Achievable Production Rate P/C CLASS P METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH I DESCRIPTION ROOT.JACKSHAFT | Construct Jacking Shaft Type Operation Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.JACKSHAFT.CAT-325 DESCRIPTION CAT-325 ( C a t e r p i l l a r Hydraulic Excavator) Type Resource Class Reference Earthraving equipment ROOT.Excavators.CAT-325 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Bucket Capacity And EQ 8.9 Average Excavation Rate And E0. 6 Maxinun Working Radius And Eq B8B8 Length of wheel base And EQ 4368 Width of wheel base And 0) 2998 P/C CLASS P P P P P TYPE UNIT Quantatitive TYPE UNIT Quantatitive TVPE UNIT Quantatitive n3 Quantatitive tH/nn Quantatitive m Quantatitive MM Quantatitive m Page 2 Of 14 METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.JflCKSHftFT.ALUMSHORE DESCRIPTION Shoring using Aluminum Hydraulic Shores Type Nethod Class Reference Excavation Support Techniques ROOT.AluirShore PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N Maxinun allowable surcharge load And E Q Z B B B B P/C CLASS P N Max load on hydraulic cylinder(2 inch) And E Q m C Tachnical C Technical TVPE UNIT Quantatitive Quantatitive lb Quantatitive lb METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.JACKSHAFT.ALUMSHORE.SHORELABOR DESCRIPTION Labour for i n s t a l l i n g / r e m o v i n g shoring Type Resource Class Reference Labor ROOT. SHORELABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.JACKSHAFT.ALUMSHORE.SHORESETS DESCRIPTION Modular Aluminum Hydraulic Shore Sets Type Resource Class Reference Foundation Engg 8 s o i l compaction equipnent ROOT.SupportSys.AluwUaler PARAMETERS INHERITED DESCRIPTION P/C CLASS COND UALUE 1 UALUE 2 N Maximum allowable surcharge load C Technical And EQ N Max load on hydraulic cylinder (2 inch) C Technical And EQ I B B TVPE UNIT Quantatitive lb Quantatitive lb METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.JACKSHAFT.DEWATER DESCRIPTION Deuatering the Jacking Shaft Type Method Class Reference Deuatering Techniques ROOT.SUMP-DRAIN PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N Max s i z e of p a r t i c l e s And EQ 3 P/C CLASS P TVPE UNIT C Technical Quantatitive Quantatitive i n Page 3 Of 14 METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.JACKSHAFT.DEUATER.SELF-PRIME DESCRIPTION S e l f - P r i d i n g Pump Class Reference General-use equipment used i n construction process ROOT.Pumps.Self-prime PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Pumping Rate And EQ Z.27 P/C CLASS P TYPE UNIT Quantatitive n3/nn METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.JACKSHAFT.DEUATER.PUMPOPER DESCRIPTION Punp Operator Type Resource Class Reference Labor ROOT.PUHPOPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z P/C CLASS TYPE UNIT METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.JACKSHAFT.MTINSTALL DESCRIPTION I n s t a l l Microtunneling Equipment Type Nethod Class Reference Equipment I n s t a l l a t i o n Procedures ROOT.MTINSTALL PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Y Achievable Production Rate P/C CLASS P TYPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.JACKSHAFT.MTINSTALL.TECHNICIAN DESCRIPTION Technically Q u a l i f i e d Person (Mostly Operator) Class Reference Labor ROOT.TECHNICIAN PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z P/C CLASS TYPE UNIT METHOD, HESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.JACKSHAFT.PJINSTALL DESCRIPTION I n s t a l l pipe jacking equipment O N O N Class Reference Equipment I n s t a l l a t i o n Procedures ROOT. PJINSTALL Page 4 Of 14 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.JACKSHAFT.PJINSTALL.TECHNICIAN DESCRIPTION Qual. Technician to i n s t a l l eguip.(Mostly Oper) Type Resource Class Reference Labor ROOT.TECHNICIAN PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 P/C CLASS TVPE UNIT METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOI.RECUSHAFT [DESCRIPTION Construct Receiving Shaft Type Operation Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH R00T.RECUSHAFT.CAT-325 DESCRIPTION CAT-325 ( C a t e r p i l l a r Hydraulic Excavator) Type Resource Class Reference Earthnoving equipment ROOT.Excavators.CAT-325 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Bucket Capacity And Eq l . B N Average Exacavation Rate And Eq 6 N Haxiwun Working Radius And Eq BBBB N Length of wheel base And Eq 436B N Width of wheel base And EQ 2999 P/C CLASS P P P P P TVPE UNIT Quantatitive N3 Quantatitive « 3 / « n Quantatitive [414 Quantatitive m Quantatitive m 3; METHOD, RESOURCE BREAKDOWN STRUCTURE - J MSRBS PATH ROOT. RECUSHAFT.ALUMSHORE DESCRIPTION Shoring using Aluminum Hydraulic Shoring Type Method Class Reference Excavation Support Techniques ROOT.Alun-Shore Page 5 OF 14 PARAMETERS INHERITED DESCRIPTION P/C CLASS COND UALUE 1 UALUE 2 V Achievable Production Rate P N Maximum allowable surcharge load C Technical And 01 N Max load on hydraulic cylinder (2 inch) C Technical And 0) IBB TVPE UNIT Quantatitive Quantatitive lb Quantatitive lb METHOD, RESOURCE BREAKDOWN STRUCTURE N8RBS PATH ROOT.RECUSHAFT.ALUMSHORE.SHORESETS DESCRIPTION Modular Aluminium Hydraulic Shore Sets Type Resource Class Reference Foundation Engg & s o i l compaction equipment ROOT.SupportSys.AlumUaler PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Maximum allowable surcharge load And EQ 2BBBB N Max load on hydraulic cylinder And 0] IBB P/C CLASS C Technical C Technical TVPE UNIT Quantatitive lb Quantatitive lb METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.RECUSHAFT.ALUMSHORE.SHORELABOR DESCRIPTION Labour for i n s t a l l i n g shoring Type Resource Class Reference Labor ROOT.SHORELABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.RECUSHAFT.DEUATER DESCRIPTION Dewatering of the Receiving Shaft Type Method Class Reference Dewatering Techniques ROOT.SUMP-DRAIN PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N Max s i z e of p a r t i c l e s And EQ 3 P/C CLASS C Technical TVPE UNIT Quantatitive Quantatitive in O N METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH I DESCRIPTION ROOT.RECUSHAFT.DEUATER.SELF-PRIME | Self priming Pump Type Resource Class Reference General-use equipment used in construction process Page 6 Of 14 |ROOI.PuNps.Self-prine PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Pumping Rate And EQ 2.Z7 P/C CLASS TVPE UNIT Quantatitive n3/nn METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.RECUSHAFT.DEWATER.PUMPOPEB DESCRIPTION PUMP Operator Type Resource Class Reference Labor ROOT.PUNPOPEH PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 P/C CLASS TVPE UNIT METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH I DESCRIPTION ROOT.PIPEINSTAL | I n s t a l l a t i o n of pipe using Shield Tunneling Type Operation Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT. PI P EI NSTfiL. MI CROTUNEL DESCRIPTION Microtunnelling Type Method Class Reference S o i l florrou MT Methods (NonSteerable) ROOT.IMMDCASING O N M5 PARAMETERS INHERITED DESCRIPTION P/C CLASS COND UALUE 1 UALUE 2 V Achievable Production Rate P N F e a s i b i l i t y of use - S o i l Type C Technical And EQ Cohesive running And EQ Bouldery N N value of s o i l C Technical And WR 5 5B N Maximum allowable s i z e of s o i l grains C Technical And EQ 5B N Suitable i n condns with large inclusions C Technical And EQ False TVPE UNIT Quantatitive L i n g u i s t i c Quantatitive I Quantatitive m Roolean Page 7 Of 14 METHOD, RESOURCE BREAKDOWN STRUCTURE IISflBS PATH ROOT.PIPEINSTAL.MICROTUNEL.UNCLEMOLE DESCRIPTION Iseki Uncle Mole Type Resource Class Reference Specialized equipment for c i v i l engineering uork ROOT.Tunnelling.UNCLE MOLE PARAMETERS INHERITED DESCRIPTION P/C CLASS COND UALUE 1 UALUE Z V Achievable Production Rate P N Maximum Grain Size/Diameter of Shield P N Avg Production Rate for S o i l s with Sands P And EQ 8.33 N Avg Production Rate i n Clays And EQ 65 P N Avg Production Rate in S o i l s u i t h Gravel P And EQ 1Z5 N Avg Production Rate u i t h Crushed Rock P And Eq 25 N Nominal Pipe Inside Diameter And UR 256 580 N Suitable for ground uater And EQ True Y F e a s i b i l i t y of use - S o i l Type And EQ Cohesive running And EQ Bouldery P P C Technical C Technical Y N value of s o i l And UR 5 58 Y Maximum allowable s i z e of s o i l grains C Technical And EQ 58 Y Suitable in condns u i t h large inclusions C Technical And EQ False TYPE UNIT Quantatitive Quantatitive mm Quantatitive mm/mn Quantatitive nm/mn Quantatitive mm/mn Quantatitive mm/mn Quantatitive mm Boolean L i n g u i s t i c Quantatitive I Quantatitive mm Roolean METHOD, HESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.PIPEINSTAL.HICROTUNa.MOLE-OPER DESCRIPTION Mole Operator Type Resource Class Reference Labor R00T.MOLE-OPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z P/C CLASS TYPE UNIT <= METHOD, HESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.PIPEINSTAL.PIPEJACK DESCRIPTION Pipe jacking Type Method Class Reference Pipelaying methods ROOT.PipeJackin Page 8 Of 14 PARAMETERS INHERITED DESCRIPTION P/C CLASS COND UALUE 1 UALUE 2 V Achievable Production Rate P N N value of s o i l C Technical And UR 5 58 Maximum allowable s i z e of s o i l p a r t i c l e s C Tachnical And EQ 56 N N Suitable i n condns with large inclusions C Technical And EQ False TVPE UNIT Quantatitive Quantatitive I Quantatitive i Boolean METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.PIPEINSTAL.PIPEJACK.JACKINGRIG Jacking Rig Type Resource Class Reference Specialized equipment for c i v i l engineering work ROOT.PipeLaying.ISEKI PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Maximum Jacking Distance And EQ 15B N Nominal Inside Pipe Diameter And UR 25B 56B N Average Jacking Speed And EQ 4.2 N Suitable for ground water And EQ True P/C CLASS P P P P TVPE UNIT Quantatitive m Quantatitive m Quantatitive mm Boolean METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.PIPEINSTAL.PIPEJACK.JRIGOPER DESCRIPTION Jacking Rig Operator Type Resource Class Reference Labor ROOI.JRIGOPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 P/C CLASS TVPE UNIT METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH I DESCRIPTION ROOT.TESTPIPE | Water test the pipe as s p e c i f i e d by design Type Operation Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive Page 9 Of 14 METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.TESTPIPE.UATERTEST DESCRIPTION Using a water test for t e s t i n g the pipe Class Reference Pipe Testing Methods ROOT.WATER-TEST PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate P/C CLASS P TYPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.TESTPIPE.WATERTEST.PUMP DESCRIPTION Punp to Maintain uater pressure Class Reference General-use equipMent used i n construction process ""IT.Pumps.Convention PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Pumping Rate And EQ 4.5 P/C CLASS P TVPE UNIT Quantatitive «3/nn METHOD, RESOURCE BREAKDOWN STRUCTURE H8RBS PATH ROOT.TESTPIPE.WATERTEST.PUMPOPER DESCRIPTION Pump Operator Type Resource Class Reference Labor ROOT.PUMPOPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z P/C CLASS TVPE UNIT METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKJACK |DESCRIPTION Restore the Jacking Shaft Type Operation Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M8RRS PATH ROOT.BACKJACK.REKSHORE DESCRIPTION Renove Shoring Class Reference Excavation Support Techniques ROOT.RenAlShore PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive Page IB Of 14 METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.RACKJACK.REMSHORE.SHORELABOR DESCRIPTION Labor for installing/removing shoring Type Resource Class Reference Labor ROOT.SHORELABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKJACK.BACKFILL DESCRIPTION B a c k f i l l the Jacking Shaft Class Reference E a r t h - f i l l construction techniques ROOT. BACKFILL PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKJACK.BACKFILL.BACKLOADER DESCRIPTION Back-hoe Loader Type Resource Class Reference Earthnoving equipment ROOT.Backhoe.CAT-416B PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Bucket Capacity And Eq B.76 P/C CLASS P TVPE UNIT Quantatitive n3 METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKJACK.BACKFILL.LOADEROPER DESCRIPTION Rack-hoe Loader Operator Class Reference Labor ROOT.LOADEROPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.RACKJACK.BACKFILL.PCOMPACTOH DESCRIPTION Hand-held P l a t e compactor Class Reference Foundation Engg S s o i l compaction equipment ROOT.HandComp.PCompactor Page 11 Of 14 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Compaction Rate And EH 5 P/C CLASS P TVPE UNIT Quantatitive n2 METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.BACKJACK.BACKFILL.COMPOPER DESCRIPTION Conpactor operator Type Resource Class Reference Labor R00T.C0M0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Productivity P/C CLASS TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M&RRS PATH ROOT.BACKJACK.RESTPAU DESCRIPTION Restore the Pavewent Type Method Class Reference Pavewent Construction Techniques ROOT.PATCHING PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.BACKJACK.RESTPAU.LABOR DESCRIPTION Labor for spreading and l e v e l l i n g asphalt Type Resource Class Reference Labor ROOT.LABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z P/C CLASS TVPE UNIT METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.BACKJACK.RESTPAU.DCOMPACTOR DESCRIPTION Hand-held Dual Drun Compactor Type Resource Class Reference Foundation Engg & s o i l compaction equipment ROOT.HandConp.DConpactor PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Conpaction Rate And EQ 5 P/C CLASS P TVPE UNIT Quantatitive « Z Page 12 Of 14 METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKJACK.RESTPAU.CONPOPER DESCRIPTION Compactor operator Type Resource Class Reference Labor R00T.C0M0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKRECU |DESCRIPTION Restore the Receiving Shaft Type Operation Class Reference PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Y Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKRECU.REMSHORE DESCRIPTION Remove The Shoring Class Reference Excavation Support Techniques ROOT.RemAlShore PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKRECU.REMSHORE.SHORELABOR DESCRIPTION Labor for installing/removing shoring Type Resource Class Reference Labor ROOT.SHORELABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH ROOT.BACKRECU.BACKFILL DESCRIPTION B a c k f i l l the Jacking Shaft Class Reference E a r t h - f i l l construction techniques ROOT.BACKFILL PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive Page 14 Of 14 PARflflETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Y Achievable Production Rate P/C CLASS P TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE N8RBS PATH ROOT JACKRECU. RESTPAU. LABOR DESCRIPTION Labor for spreading and l e v e l l i n g asphalt Type Resource Class Reference Labor ROOT.LABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.BACKRECU.RESTPAU.DCOMPACTOR DESCRIPTION Hand-held Dual Drum Compactor Type Resource Class Reference Foundation Engg 8 s o i l compaction equipment ROOT.HandComp.DCompactor PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Compaction Rate And EQ 5 P/C CLASS P TYPE UNIT Quantatitive m2 METHOD, RESOURCE RREAKDOWN STRUCTURE M8RBS PATH ROOT.BACKRECU.RESTPAU.COMPOPER DESCRIPTION Compactor operator Type Resource Class Reference Labor R00T.COM0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS TYPE UNIT Quantatitive O N Page 13 Of 14 METHOD, RESOUBCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.RACKRECV.RACKFILL.BACKLOADER DESCRIPTION Back-hoe Loader Type Resource Class Reference Earthmoving equipment R00T.flackhoe.CAT-416R PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Ducket Capacity And EQ 8.76 P/C CLASS P TYPE UNIT Quantatitive M3 METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.BACKRECU.BftCKFILL.LOADEROPER DESCRIPTION Back-hoe loader operator Type Resource Class Reference Labor ROOT.LOADEROPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Productivity P/C CLASS TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.BACKRECU.RACKFILL.PCOMPACTOR DESCRIPTION Hand-held P l a t e Compactor Type Resource Class Reference Foundation Engg & s o i l compaction equipment ROOT.HandComp.PCompactor PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Compaction Rate And EQ 5 P/C CLASS P TVPE UNIT Quantatitive mZ METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH ROOT.BACKRECU.BftCKFILL.COMPOPER DESCRIPTION Compactor operator Type Resource Class Reference Labor R00T.C0M0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity P/C CLASS TVPE UNIT Quantatitive METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH ROOT.RACKRECU.RESTPAU DESCRIPTION Restore Pavement Type Method Class Reference Pavement Construction Techniques ROOT.PATCHING 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0050316/manifest

Comment

Related Items