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 A S A D H. U D A I P U R W A L A B.E. (Construction), T h e University of Bombay, 1993  A T H E S I S S U B M I T T E D IN P A R T I A L F U L F I L L M E N T O F THE 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 - ^  T H E U I V E R S I T Y O F BRITISH C O L U M B I A October 1997 © A s a d H. Udaipurwala, 1997  In  presenting  this  degree at the  thesis  in. partial fulfilment  University of  freely available for reference copying  of  this  department; or publication of  British Columbia, and study.  thesis for scholarly by  this  his  or her L  Civ\\  purposes  representatives.  l^c^iQ&£YVP)C^  DE-6  (2/88)  \ & ^ ' Oc-bpb^y  requirements  I agree  that the  may be It  thesis for financial gain shall not  The University of British Columbia Vancouver, Canada  Date  the  I further agree that  permission.  Department of  of  is  an  advanced  Library shall make it  permission for extensive  granted  by the  understood be  for  that  allowed without  head  of  my  copying  or  my written  ABSTRACT Selection of appropriate construction methods is key to a successful project. However, the multitude of available methods alternatives, and the variety of resources available to e x e c u t e these methods, m a k e the task of selecting an appropriate m e t h o d  very  c u m b e r s o m e . This is aggravated by the constant introduction of new technologies and the increasingly complex nature of modern facilities. With computing capabilities n o w b e c o m i n g widely available, it would be advantageous to automate, at least in part, the task of storing information about conventional as well as new construction m e t h o d s , and reasoning about their applicability to a particular project. To achieve this goal w e need to develop a vocabulary for referring to construction methods and the  constructed  product, w h i c h is rich e n o u g h to represent the wide spectrum of available construction m e t h o d s and projects, at the s a m e time being simple e n o u g h for easy manipulation by a computer.  In this thesis, w e develop a standard vocabulary for referring to construction m e t h o d s for use in a computerized environment to enable the user to store information on construction m e t h o d s , reason about their feasibility for use on a particular project and develop a preliminary project schedule for the methods selected. T h e major focus is on understanding how construction professionals decide on the use of certain m e t h o d s in particular project situations, and how this can be incorporated in the design of the m e t h o d s selection system. This system design is discussed in detail, and parts of the s y s t e m implemented to date are presented using an example for u n d e r g r o u n d utility construction.  TABLE OF CONTENTS Abstract  ii  Table of contents  iii  List of tables  v  List of figures  vi  Acknowledgement 1. I N T R O D U C T I O N 1.1  P R O B L E M IDENTIFICATION  viii 1 1  1.2  RESEARCH METHODOLOGY  2  1.3  THESIS ORGANIZATION  3  2. P R O B L E M D E F I N I T I O N 2.1  LITERATURE REVIEW  2.1.1 2.1.2  Construction related literature Literature related to other industries  4 4  5 14  2.2  T H E CONSTRUCTION INDUSTRY  15  2.3  DEFINING T H E PROBLEM SCOPE  16  3. P R O B L E M A N A L Y S I S  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 PROPOSED SOLUTION 4.1  CONCEPTUALIZATION  4.1.1 4.1.2 4.1.3  4.2  M e t h o d s and Resource Breakdown Structure ( M & R B S ) Physical C o m p o n e n t Breakdown Structure (PCBS) Feasibility Rules 4.1.3.1 M o d e s of Operation 4.1.3.2 Option 2: Semi-Automated Project Setup 4.1.3.3 Option 3: Project Setup with access to S T A N D A R D S but with no s y s t e m help 4.1.3.4 Option 4: Independent Project Setup 4.1.3.5 Option 1: A u t o m a t e d Setup  IMPLEMENTATION  4.2.1 4.2.2 4.2.3  General C o m m e n t s M e t h o d s and Resource Breakdown Structure ( M & R B S ) Physical C o m p o n e n t Breakdown Structure (PCBS)  30 33  37 56 69 69 73 78 81 81 108  109 110 131  iii  4.2.4 4.3  Standard Fragnets  VALIDATION  4.3.1 4.3.2  Validity of the initial idea Validity of the implemented model  5. RECOMMENDATIONS FOR FUTURE W O R K  134 136  136 139  145  5.1  ITEMS REQUIRING MAJOR FOCUS  145  5.2  W R I N K L E S THAT NEED IRONING OUT  148  5.3  P E R F O R M A N C E A N D USABILITY I M P R O V E M E N T F E A T U R E S  149  Bibliography  151  A p p e n d i x I - E-R Diagram  157  A p p e n d i x II - C o m m a n d listing  159  A p p e n d i x III- S a m p l e r e p o r t  163  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 and design principles  137  v  LIST OF FIGURES 2.1.1  S c h e m a t i c 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 S a m p l e Project P C B S for illustrating the addressing of P C B S and M & R B S c o m p o n e n t s  87  4.1.3.5.2 S a m p l e Project M & R B S for illustrating the addressing for a parameter of a P C B S or M & R B S c o m p o n e n t  89  4.1.3.5.3 S a m p l e M & R B S for illustrating the syntax and structure of a rule file  95  4.1.3.5.4 S a m p l e P C B S for illustrating the syntax and structure of.... a rule file  96  4.1.3.5.5 S c h e m a t i c representation of the proposed methods selection system  106  4.1.3.5.6 S c h e m a t i c representation of the Standard level in the proposed  107  Method selection system 4.2.2.1  T e m p l a t e listing in Standard M & R B S  111  4.2.2.2  W i n d o w 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  C o m p l e t e d Method Statement for constructing a sewer  115  using microtunneling 4.2.2.6  Defining a Condition for a Standard M & R B S c o m p o n e n t  116  4.2.2.7  Parameter/Condition listing for a Standard M & R B S component. Form for assigning/defining a fragnet for a method in the Standard M & R B S  117  4.2.2.8  119  vi  4.2.2.9  Defining a Fragnet for a method in the Standard M & R B S  120  4.2.2.10  Form for defining a multi-media records for a Standard M&RBS component  122  4.2.2.11  Associating a multi-media file with a Standard M & R B S  123  component 4.2.2.12  Defining the contents of a report in the Standard M & R B S  124  4.2.2.13  R e s o u r c e Class definition showing the C I B - W 7 5 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 C o m p l e x Fragnet  129  4.2.2.17  Project M & R B S for a S e w e r Project assembled from t w o  130  Standard Method Statements 4.2.3.1  T e m p l a t e Listing for Standard P C B S  132  4.2.3.2  Standard Physical Breakdown Structure for a S e w e r Project  133  4.2.3.3  Parameter definition for Standard P C B S C o m p o n e n t  134  4.2.4.1  Copying Standard Fragnets to Project Level  135  vii  ACKNOWLEDGEMENT I w o u l d like to appreciate the constant guidance and support of m y supervisor Dr. Alan Russell.  His keen sense of direction and thorough grasp of the realities of the  construction industry have been invaluable in this research effort.  I w o u l d also like to appreciate the insights provided by Dr. T h o m a s Froese into the various aspects of designing computer systems. William W o n g , the senior p r o g r a m m e r in the Construction M a n a g e m e n t lab is responsible for the computerised implementation of the s y s t e m . I would like to sincerely acknowledge his patience during the design d e v e l o p m e n t and his appreciation for the nuances of the design.  I w o u l d like to acknowledge the financial support of T h e National Research Council C a n a d a - Industrial Research Assistance Program, and the Natural Sciences  and  Engineering Research Council of Canada.  I w o u l d like to m a k e a special mention of my friend and colleague A n o o p S h a r m a . In an effort to c o m e up with a complete and rigorous methods representation structure, w e decided to explore t w o widely divergent problem domains for methods selection, n a m e l y that of underground sewer construction and high-rise construction. A n o o p ' s  thesis  focuses  sewer  on  high-rise  construction  whereas  mine focuses  on  underground  construction. T h e long hours w e spent in discussing the requirements of our individual p r o b l e m d o m a i n s have influenced to a large degree the design of the s y s t e m as discussed in the thesis.  viii  Finally, I w o u l d like to extend a word of thanks to my friends and family for their e n c o u r a g e m e n t and support.  ix  1. INTRODUCTION 1.1 Problem Identification It is n o w generally accepted by all parties concerned that planning a n d scheduling is critical to the success of any construction project. W h a t therefore is planning a n d s c h e d u l i n g ? T h e c o m m o n l y held view is that it is breaking d o w n the w o r k into activities and calculating their duration and sequence.  Let us look at the steps involved in planning and scheduling a typical construction project. T h e y are:  1. Estimating the quantities. 2. Defining the activities to be performed. 3. Calculating their duration and sequence. 4.  R e s o u r c e allocation.  T h e y m a y not necessarily take place in the order specified. However, implied in all the a b o v e is the choice of method(s) used for constructing the structure.  For  e x a m p l e , if for constructing a concrete high-rise, the m e t h o d used is installing precast elements, then the quantities and cost estimated will be those for precasting as against if the choice of method w a s cast-in place concrete. Therefore, m e t h o d  1  selection is not only an integral but also a most essential part of planning a n d scheduling.  Both academicians and practitioners are aware of this and have tried to a p p r o a c h the p r o b l e m in different ways. In practice, for example, the m e t h o d  selection  exercise involves one or more brainstorming sessions before bidding for a job. From the a c a d e m i c point of view, little research has been d o n e on w h a t is involved in the process of m e t h o d selection per se, but people have tried to break the problem d o w n into smaller m a n a g e a b l e chunks (e.g., crew selection, e q u i p m e n t selection) and c o m e up with a solution to these. This approach, however, has the serious limitation of being too focused on the particular application d o m a i n selected and/or not being very easily implementable in practice.  T h e object of this thesis is therefore to approach the method selection p r o b l e m as a w h o l e , investigating the requirements for effective method selection and c o m i n g up with a solution which is readily implementable in practice.  1.2 Research methodology Having identified the need for a method selection system, w e now have to c o m e up with a research strategy that w o u l d help us to satisfy this need. W e first refer to the available literature on the subject. Combining these with our o w n (limited) practical experience and advice from a f e w seasoned construction professionals, w e s e e k to  2  design a m e t h o d selection system. W e then try to devise a structure w h i c h w o u l d m e e t most (if not all) of our requirements and test this for c o n f o r m a n c e .  1.3 Thesis Organization In the s e c o n d chapter w e define the problem more precisely and identify its s c o p e a n d limits. T h e third chapter analyzes the problem in depth and identifies the major factors w h i c h  affect  method  selection. In the fourth chapter, w e  present  the  conceptual design of a method selection environment and s o m e selected aspects of it that have been implemented to date. T h e fifth chapter is our wish list of w h a t can be d o n e to e n h a n c e the s y s t e m to m a k e it more adaptive, responsive a n d usable.  3  2. Problem Definition In this chapter, w e will attempt to c o m e up with a precise s c o p e definition for the m e t h o d selection problem. Note that this is not the scope definition for our s y s t e m , but a s c o p e definition of the method selection problem d o m a i n . T h e chapter starts off with a review of related studies in both the construction and other d o m a i n s . Next, w e identify the various phases of a construction project and how the  method  selection decision may affect t h e m . W e integrate our findings f r o m this with those f r o m the literature review to c o m e up with a robust scope definition of t h e m e t h o d selection problem.  2.1 Literature review  Not a lot of work has been d o n e in the areas of method selection as related to construction work. However, there is a large body of research w o r k 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. O n e , details w o r k s w h i c h w e have f o u n d to be of interest in the construction literature, while the other f o c u s e s on all the other industries.  4  2.1.1 Construction related literature  Literature related to construction methods selection  Halpin & W o o d h e a d (1976), in their work on C Y C L O N E - a s y s t e m for simulating construction operations, c a m e up with a constituent structure for a construction operation, while defining each of its constituents. According to the authors,  a  construction operation has a construction method focus. It results in the p l a c e m e n t of a definable piece of construction, and e n c o m p a s s e s several distinct construction processes, each having its o w n work technology and work task s e q u e n c e s . A construction process has a basic technological s e q u e n c e focus and is defined as a unique collection of work tasks related to each other t h r o u g h a  technological  structure or s e q u e n c e . A work task corresponds to a f u n d a m e n t a l field action and w o r k unit.  T a t u m (1987), in his classic paper, highlighted the importance of classifying and tracking construction technologies. He further developed the ideas laid out by Halpin & W o o d h e a d to c o m e up with fairly generic definitions of construction technology, resources and processes, as well as project requirements. T h e s e are: "Construction t e c h n o l o g y is defined as the combination of resources, processes, and conditions that produce a constructed product."  "A resource can be either materials and  p e r m a n e n t equipment, or construction applied."  "Construction processes are the  methods  constructed  and  the  tasks  needed  to  build  a  product."  "Project  5  requirements  and site characteristics are the major conditions  of  construction  technology."  Zozaya-Gorostriza,  Hendrickson  and  Rehak (1989), in their expert s y s t e m  on  planning construction processes, have e m p h a s i z e d the importance of selecting the right m e t h o d of construction. However, they adopt a very narrow definition of a construction  m e t h o d . T h e y define construction  method  as the combination  of  resources, i.e. crews, required to perform an activity. T h e y accordingly use a d a t a b a s e of rules to enable the user to select the appropriate crews. T h e y have used the CSI Masterformat to classify the crews. A n interesting question is w h e t h e r construction processes determine the activities to be performed or w h e t h e r activities lead to construction processes. T h e authors are of the first opinion. This view is also s h a r e d by Fischer and Aalami (1996), w h o , in their research on the d e v e l o p m e n t of a computer-interpretable construction methods model, treat the need to a n s w e r the t w o basic questions asked of construction m a n a g e r s - "how m u c h will it cost" and "how long will it take?" Their s y s t e m proposes the use of a template to capture the information of applicability of methods to activities. Their model first d e t e r m i n e s the activities n e e d e d for a project and then assigns applicable m e t h o d s to it. It starts with a s e e d activity and assigns the applicable m e t h o d s to this. It t h e n g o e s on breaking d o w n this activity into lower level assigning applicable m e t h o d s 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. T h e y used the Analytic Hierarchy Process developed by Saaty to assign weightings to process a n d product complexity attributes, and then combined the t w o to c o m e up with an overall technological complexity value for a particular project. T h e y are of the opinion that both product (i.e., physical) and process (i.e., method) attributes should be considered in assessing the technological requirements of a project.  Skibniewski and C h a o (1992) have also used the A H P technique in the evaluation of technologies. Their proposed model is a hierarchy of evaluation elements. T h e y use the evaluation hierarchy to determine the cost and benefit factors for e a c h of the technology alternatives by doing a pairwise comparison for each element. T h e t w o factors are t h e n c o m b i n e d to determine a priority setting for each alternative. T h e y t h e n perform a sensitivity analysis to evaluate the c h a n g e in the overall priority setting if the weighting of the evaluation elements is c h a n g e d .  In Skibniewski and C h a o (1995), the authors extended the a b o v e process. T h e y n o w obtain the weighting for each of the evaluation elements by  interviewing  experts. T h e experts are asked to give their j u d g m e n t as to their acceptability of new technologies against a base (conventional) technology by giving weights to the evaluation elements. T h e s e weights are then used to train a neural network. T h e trained neural network then can be used for evaluating the acceptability of a n e w technology.  7  Adbul-Malak,  Mezher  and  Murphree  (1995)  have  used  a  new  approach  to  construction method selection (an approach which w e prefer). In their work, they have identified a n u m b e r of potential barriers to the acceptance of a t e c h n o l o g y by the contractor as s h o w n in Figure 2 . 1 . 1 . T h e y have used these to develop a ruleb a s e d s y s t e m , which the contractor can use to assist him in evaluating applicable m e t h o d s . T h e set of barriers he w a n t s assistance on, however, is his choice. Alternatively, the contractor can use an A H P - b a s e d expert s y s t e m . In this, the contractor is provided with a hierarchy in which all the relevant factors are organized in a logical and systematic w a y from the goal to the factors a n d sub-factors, and d o w n to the alternatives of the technology choice. T h e s y s t e m t h e n leads the contractor through each element in the hierarchy asking him to j u d g e their relative importance with respect to a higher level criterion or property, i.e. perform a pairwise comparison.  These  comparisons  are  then  analyzed  using  AHP  to  rank  the  alternatives f r o m which the user can m a k e a choice.  8  IMPEDIMENTS CONSTRUCTION MARKET CONDITION  Project-Imposed Constraints: • Interdependences between operations. • Site Conditions  Level of Competition Market Share  Contractor's Financial Constraints: • Sources of Funds • Assurance of Performance  NEEDS-BASED THRUSTS  Owner-Imposed Constraints: • Budget • Specifications Governmental Constraints Human Resource Constraints  r  Competitive Advantage • cost • schedule • quality  r r  Problem Solution Vanishing Skills  Figure 2.1.1: Schematic representation of factors affecting technology transfer and diffusion decisions (Adbul-Malak, Mezher and Murphree (1995)).  Further w o r k related to construction methods w a s d o n e by Leu S o u - S e n (1992) in his thesis  in which  he proposed the use of a semantic data m o d e l for  the  representation of knowledge of identification or selection of construction m e t h o d s . In his research, he implemented this using a Hypertext  database. The  system,  however, left the feasibility entirely to the discretion of the contractor. Further, o n c e the m e t h o d w a s selected, not m u c h help w a s provided to the contractor as to the related activities and their sequencing.  A l - H a m m a d (1991) in his thesis proposes a knowledge-based a p p r o a c h to the selection of construction methods. He uses a two-tiered screening a p p r o a c h to accomplish this. He first narrows his range of applicable m e t h o d s by screening out  9  the infeasible m e t h o d s using broad-brush rules. T h e s e m e t h o d s are t h e n further analyzed for their level of conformance to the project at hand. His final m o d e l , however, t e n d s to focus more on the latter. Also, his s y s t e m has one important limitation, that of keeping the knowledge completely inaccessible to the user of the s y s t e m - i.e. the user cannot readily modify the rules within the s y s t e m .  Syal (1992) in his thesis has presented a conceptual method selection m o d e l for both the design and construction phases of a project. Syal defines a construction m e t h o d as a combination of construction option and the resources n e e d e d to perform the option. His approach a s s u m e s that all projects are m a d e up of standard w o r k items such as those indicated in the CSI Masterformat. Associated with e a c h w o r k item are a n u m b e r of alternatives for construction of the item. T h e alternative a d o p t e d for use on a project is called the construction option. A s s o c i a t e d with e a c h construction option is a defined set of resources required to perform it. In cases w h e r e a w o r k item consists of subsection items belonging to m o r e t h a n one work division, for example, a concrete column which e n c a s e s a steel section, the w o r k item is broken d o w n into subsection items and a construction option is selected for e a c h subsection item.  l o a n n o u and Martinez (1996) have proposed the use of matched simulation to c o m p a r e t w o alternative methods, although no formal definition of w h a t they m e a n by a method is given. Their method tries to eliminate the inherent defects of individual simulation runs for each method by assigning a single r a n d o m n u m b e r 10  s e e d to e a c h uncertain variable (in this case they have defined the  uncertain  variables as activities) and then comparing the results of the simulation.  All the a b o v e works, however, have a few c o m m o n shortcomings, w h i c h w e have s u m m a r i z e d below:  1. T h e foregoing systems have the serious limitation of being very difficult to implement  in  practice.  All  of the  techniques  suggested  so  far,  although  intellectually challenging (they all seek to model the m e t h o d s selection problem so as to achieve m i n i m u m user involvement in the choice of a construction m e t h o d ) , 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, t h e y are still m o r e unlikely to accept such computationally intensive techniques as p r o p o s e d above.  2 . A s e c o n d major shortcoming that w e found in a n u m b e r of these s y s t e m s is the very broad and often v a g u e scope definition. A majority of these s y s t e m s try to develop a single model that can be used for selecting construction m e t h o d s for a project, that is, both for the design and construction of a project. T h e s e s y s t e m s thus tend to fail because they try to achieve too m a n y things with a single m o d e l .  11  3. A relatively minor shortcoming that w e found with the a b o v e is that they tend to f o c u s on a few areas such as high-rise construction or road construction. Other construction d o m a i n s such as underground construction tend to remain relatively unexplored. S o m e of these present m a n y unexpected design and construction challenges such as varying underground conditions.  Other Construction related literature  l o a n n o u and Yiu (1988) developed a database for storing, tracking, and retrieving new construction technologies in a readily usable m a n n e r as a part of an initiative by the Construction Industry Institute. T h e y used the CSI Masterformat for grouping the construction technologies. This database has been used by Syal (1992) a n d A b d u l Malak et al. (1992) as a source for construction methods.  A s o m e w h a t related body of research is that focusing on the design of selection s y s t e m s for other t h a n methods selection. A few that w e looked into are the f o r m w o r k selection s y s t e m for construction of regular structures such as high-rises d e v e l o p e d by Saliman (1989), a system for crane selection for high-rise construction by Gray and Little (1985), the earth-moving equipment selection s y s t e m by A l k a s s et al (1988), a n d a knowledge-based system for selecting excavation  equipment  d e v e l o p e d by Hadjigeorgiou (1988) for the National Research Council of C a n a d a . T h e s e w o r k s tend to focus more on the selection a m o n g s t a particular class of e q u i p m e n t rather then the selection of equipment for a class of works. For e x a m p l e ,  12  although a hydraulic excavator can also be used for lifting, the s y s t e m limits its selection of hydraulic excavator only for excavation operations. A n exception is the w o r k by Lin and Haas (1996) on developing an interactive e n v i r o n m e n t for the design of critical operations involving the use of large semi-stationary equipment.  A n o t h e r a r e a of research that reflects more on the thought process that construction planners e n g a g e in while planning a project is that of selection a n d s e q u e n c i n g of activities. Echeverry,  Ibbs and Kim (1991) have identified the factors  affecting  s e q u e n c i n g of activities, which include physical factors as well as factors related to the m e t h o d selected. Reda and Carr (1989), in their paper on time-cost tradeoff, identified the conflicts raised by the use of various resources and m e t h o d s w h e n determining construction duration.  Rule-based or knowledge based systems for automatic activity generation  and  s e q u e n c i n g have also received considerable research attention. Prominent a m o n g t h e s e are  PLANEX  by Hendrickson  et al. (1989), H I S C H E D  by S h a k e d  and  W a r z a w s k i (1995), and O A R P L A N by Winstanley, C h a c o n and Levitt (1993). A related work has been the development of building product and process m o d e l s w h i c h seek to give a context independent structure for representing  information  related to the construction product or process. T h e Building Construction  Core  Model by ISO, which seeks to give a detailed b r e a k d o w n of all the processes, actors and resources involved on the construction of high-rises, has been e x a m i n e d . This  13  m o d e l proposes that a construction process be expressed in terms of a series of w o r k tasks.  A final area of research is that related to the storage and retrieval of construction experience and using this to advantage on future projects. T h e thesis by Lim (1989) provides an e x a m p l e of this type of work.  2.1.2 Literature related to other industries  A lot of w o r k has been d o n e in the manufacturing industries for the  effective  selection of production methods. T h e shortening of product cycles and increasing customer a w a r e n e s s are prompting these industries to m a k e the most out of their production  units. O n e work that w e explored  because of its similarity to  the  construction process is the knowledge-based system for selection of the best mining m e t h o d , d e v e l o p e d by M u t a g w a b a and Terezopoulos (1994). This s y s t e m follows a two step a p p r o a c h : first eliminate the obviously infeasible methods, a n d t h e n use a rule value interrogation m e c h a n i s m to arrive at a decision with s o m e level of confidence. A n o t h e r very interesting work is the manuscript on the d e v e l o p m e n t of an expert s y s t e m 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  a p p r o a c h suggested by Liggesmeyer (1996), is the use of fuzzy logic.  14  2.2 The Construction Industry  T h e construction of any project involves at least two distinct phases:  1.  Design  2.  Construction  Generally,  design  and  construction  are  carried  out  by  separate  specialized  c o m p a n i e s w h i c h themselves sub-contract part of the w o r k out to other  more  specialized 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 d e s i g n e d taking the construction method into account. Method selection in the construction p h a s e is m u c h more f o c u s e d . That is, given a structure that is to be constructed in a fixed time and budget, and given the general guidelines as to the method(s) to be followed, formulate a detailed strategy for a plan of action identifying the major operations  involved  and the  method(s)  for performing  these  operations.  This  includes consideration of physical parameters such as site a n d w e a t h e r conditions, contract conditions and the structure itself. T o a large extent, the factors to be considered while making design decisions are formalized. For e x a m p l e , if in the design p h a s e a decision has to be m a d e regarding the choice of a shoring s y s t e m , then the factors to be considered are the depth of excavation, lateral load on the  15  shoring, etc. T h e actual construction decisions are based in large part on heuristics a n d past experience, not m u c h of which is d o c u m e n t e d , or the d o c u m e n t a t i o n is not in an easily usable form. For example, if in the construction p h a s e a decision has to be m a d e regarding the choice of a shoring system, then factors such as s p a c e availability for storage, availability of sub-trades, etc. need to be c o n s i d e r e d . Further, the construction of a structure is influenced to a large d e g r e e by the  regional  conditions, trade practices and the prevailing regulations and c o d e requirements. For e x a m p l e , in V a n c o u v e r the generally followed G r o u n d Wall S u p p o r t S y s t e m ( G W S S ) is Shotcreting while in Toronto it is Timber Piles and Lagging leading to different choices for the s a m e problem in different jurisdictions. A final aspect to keep in mind is that a contractor's investment is typically greater t h a n that of a designer, and so the degree of risk exposure is larger.  2.3 Defining the problem scope M e t h o d selection is a very fundamental aspect of the construction of every project. T h e decision of the method to be followed is taken at different stages  during  construction, and it may also happen that the choice of a m e t h o d at o n e stage affects the choice of a method at a subsequent stage, or a s u b s e q u e n t m e t h o d decision results in a review of s o m e assumptions previously m a d e .  16  T h e s c o p e of the method selection problem domain is, however, limited to the choice of a method to perform the key or strategic project operations. T h e 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 w h i c h processes will be used a n d , therefore, for us, method selection is a key to the successful planning of a project. Conventional planning a n d budgeting 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. T h u s , while solving the p r o b l e m of method selection, w e will have to develop a solution w h i c h lays out the results of our m e t h o d s selection process in the f o r m of the conventional activity structure used by existing tools for modeling a project.  17  3. PROBLEM ANALYSIS In this chapter w e explore a hypothetical project scenario, that of the construction of a trunk s e w e r in a busy d o w n t o w n area, in order to explore the range of issues to be considered while making a decision to adopt one or a particular set of m e t h o d s on a project, a n d the thought process that goes into it. T h e scenario has b e e n m o d e l e d loosely on the Clark Drive Sanitary Sewer project in d o w n t o w n V a n c o u v e r , as well as another minor project on the outer e d g e s of the city w h i c h the author had a c h a n c e to visit. Although the context is a sewer project, w e will try a n d identify as m a n y aspects relevant to the general methods selection p r o b l e m as possible.  Scenario  Y o u are a senior m a n a g e r responsible for planning in a construction firm contracting for s e w e r construction in the Greater Oz regional district. T h e City of O z has just issued a tender for the construction of a 7 5 0 m m (internal diameter) concrete trunk s e w e r in d o w n t o w n Oz on their main arterial road, the Yellow Brick Road (YBR), extending f r o m the north end of Munchkin Street to the north side of O. N. (Ozland National) rail yard to tie in with an existing G O R D sewer line. T h e entire length of the proposed s e w e r installation is approximately 3 0 0 m . T h e concrete trunk s e w e r is to be installed at depths from 3.5 m to 6 m (invert) below the existing g r o u n d surface.  18  T h e following table summarizes the soil conditions at t h e proposed pipe elevations along the length of the proposed sewer.  Table 3.1: Soil Profile along the Yellow Brick Road Location  Soil Conditions  O. N. Rail yard to Palace Street  Moist  to wet, very  loose  to  compact,  SAND  Invert depth 4.5 m  containing trace to s o m e gravel variable a m o u n t s of organics including w o o d w a s t e a n d topsoil as well as construction debris (FILL)  Palace street to Fairy Street  Very  dense,  dry,  SANDSTONE  or  Invert level 4.5 to 6.25 m  C O N G L O M E R A T E , containing gravel a n d cobbles.  Fairy Street to Munchkin Street  V e r y dense, moist, SILT a n d S A N D , s o m e gravel,  Invert depth 3.5 to 6 m  cobbles a n d boulders (TILL LIKE).  C o n t a m i n a t e d groundwater is expected only in the loose materials b e t w e e n O. N. Rail Y a r d a n d Palace Street at depths of 2 to 5 m.  T h e City of O z requires y o u to prepare and submit a lump s u m bid for t h e project in t w o w e e k s ' time. A s a part of the bid submittal y o u are also required to submit a project plan to complete the work within a o n e month time f r a m e a n d a statement of the m e t h o d s y o u will use to execute the project (a Method Statement), with special attention directed at the steps to be followed to ensure t h e continued flow o f traffic.  19  Y o u also have a bid submittal for a sewer pipeline for the city of M u n c h k i n in three d a y s time. Traditionally you would call a meeting of the senior technical a n d site personnel and thrash out a project plan. Being a person with foresight t h o u g h , y o u decide that this time w h e n you call the meeting you will ask the m e m b e r s to stay a r o u n d for a discussion to formulate the design of a s y s t e m to aid the planners to perform method selection and initial project plan preparation, a s y s t e m w h i c h could hopefully have basic knowledge of construction methods and their applicability as well as capitalize on the years of experience gained by the c o m p a n y . Y o u inform the c o n c e r n e d senior persons and your boss of your intentions. Y o u r boss thinks this is an excellent idea. T h e first meeting sets out an initial schedule of three meetings to isolate the major factors involved in methods selection. T h e s e t h e n w o u l d considered  in the  next  round  of meetings to discuss  actual  system  be  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.  Y o u say that the c o m p a n y has d o n e similar work in Oz a year ago. If w e c a n dig out the project records, then w e can probably use the s a m e m e t h o d s w e did on that project.  20  2. T h e technical t e a m suggests that w e can use a phased construction t e c h n i q u e to keep the traffic flow unhindered, but s o m e congestion cannot be a v o i d e d . Use of a p h a s e d a p p r o a c h all d e p e n d s on the product (sewer line) a n d t h e  site  characteristics, both of which need to be studied in more detail. T h e y a g r e e to provide the planning department with the major operations involved in using this approach. 3. T o achieve the time target the planning and technical t e a m s a g r e e to look into the use of overtime. However, local by-laws would have to be consulted to e n s u r e feasibility. T h e acceptance of local sub-trades will also be required. 4.  T h e technical and planning departments also agree to look into t h e use of increased resources and crewing. This all d e p e n d s on previous  production  figures. 5. A senior person f r o m the technical department suggests that he has heard about t h e use of new trenchless technologies for constructing u n d e r g r o u n d utilities. This technology can be used to advantage in urban conditions. 6.  The  product  development  team  informs  the  group  that  they  have  been  a p p r o a c h e d by several c o m p a n i e s e n g a g e d in the trenchless installation of utilities, and they are actively researching a few interesting ones. 7.  Y o u need to know if there are any local contractors that adopt this t e c h n i q u e . Y o u also w o u l d like to know the approximate unit cost of the w o r k so that y o u  21  can c o m p a r e it with the traditional approach. T h e product d e v e l o p m e n t t e a m agrees to find out.  Method selection related discussion  1. T h e c o m p a n y has been using the open-cut technique for s e w e r  installation  successfully for a number of years now and maintains records for all t h e projects it has e x e c u t e d . T h e s e records contain s o m e valuable information on project challenges and how these w e r e met. However, they need to be systematically analyzed and maintained. 2. T h e c o m p a n y has in its cadre a number of personnel, expert in various areas of s e w e r construction. T h e c o m p a n y seeks to leverage their expertise by regularly providing t h e m with training and sending t h e m to trade s h o w s a n d conferences. This long-term investment will, however, be lost to the c o m p a n y if the e m p l o y e e decides to leave or retires. 3. T h e c o m p a n y subscribes to a number of trade m a g a z i n e s to keep abreast of the latest construction trends. It encourages all e m p l o y e e s to read t h e s e a n d other related magazines. A few e m p l o y e e s take an active interest and collect clippings or references for future use. T h e information is, however, limited to t h e s e f e w individuals and does not percolate d o w n or up through the organization. 4. T h e  company  maintains  an  ever-increasing  collection  of  manufacturer's  h a n d b o o k s and specifications for the machines (their sizes, production rates, modes  of use, etc.) that it owns and also information about a n y  product  22  promotions sent to its office. T h e c o m p a n y even has a product d e v e l o p m e n t department, which investigates new products, and trends, w h i c h m a y provide a competitive a d v a n t a g e to the company. To refer to this data for the relevant details is, however, a very tedious and often unrewarding experience. 5. T h e c o m p a n y endeavors to keep track of the latest c h a n g e s in rules  and  regulations and standards related to work methods, personnel safety a n d local by-laws. 6. T h e c o m p a n y is also heavily investing in information technology a n d c o m p u t i n g to keep pace with the new computer-based tools.  However, the c o m p a n y has not been able to develop the m e a n s for organizing, storing, and analyzing these discordant sources of information, resulting in t h e s e not being used to full potential. A process for method selection needs to d r a w f r o m t h e s e sources of information and mold the knowledge in these sources to productive use. T h e c o m p a n y should therefore try to develop a single d a t a b a s e c a p a b l e of storing information from such a wide spectrum of sources.  O n e of the newer e m p l o y e e s also presents a diagram for the factors  affecting  construction method selection f r o m a paper by Abdul-Malak et al (1995). This d i a g r a m is s h o w n in figure 3 . 1 . 1 .  23  IMPEDIMENTS CONSTRUCTION MARKET CONDITION  Project-Imposed Constraints: • Interdependences between operations. • Site Conditions Contractor's Financial Constraints: • Sources of Funds • Assurance of Performance  Contractor's Attitude Toward Risk  Owner-Imposed Constraints: • Budget • Specifications Governmental Constraints  r  Level of Competition  r  Market Share  r  Expected Future Volume of Work  NEEDS-BASED THRUSTS  Level of Risk Exposure  Human Resource Constraints  r  Competitive Advantage • cost • schedule • quality  r r  Problem Solution Vanishing Skills  Figure 3.1.1: Factors affecting the choice of a construction alternative (AdbulMalak, Mezher and Murphree (1995)) . 1  It is decided that you will identify a list of important factors that are n e e d e d for designing a m e t h o d s selection environment and put it forth for consideration and finalization at the next meeting. After studying the t w o discussions y o u c o m e up with the following list:  1.  Project requirements.  2.  Product and site characteristics.  3. Previous w o r k s of a similar nature. 4.  Major operations involved.  5. Process characteristics.  24  6.  R e s o u r c e capabilities and limitations.  7.  Local by-laws and regulations.  8. Availability of resources and/or expertise. 9.  C o m p a n y Policy.  10. Market Conditions.  3.2 Interplay between the major factors  At t h e s e c o n d meeting you present your s u m m a r y but the conversation drifts first into the discussion of the Y B R Sanitary S e w e r Project.  Project related discussion  1. Y o u inform the meeting that the records for the previous project w e r e f o u n d a n d that a preliminary duration estimate w a s prepared based on t h e m . However, based on the m e t h o d s followed previously, it does not s e e m possible for the project to be completed in a month's time. Resourcing up or crewing up w o u l d not help due to the space restrictions on the site which w o u l d lead to conflict. 2. T h e technical t e a m informs the group that they have studied the preliminary plan based on the previous  project. T h e previous  project also used a  phased  a p p r o a c h to construction. However, a few things will need to be altered. T h e  1  For the sake of convenience, we have reproduced this figure from chapter 2. 25  previous project involved the use of timber shoring t h r o u g h o u t a n d there w a s minimal g r o u n d water s e e p a g e . This project, however, has a certain section with very loose sand and organic till with considerable g r o u n d w a t e r s e e p a g e . This w o u l d necessitate the use of a Trench Shield support s y s t e m at the location. Also, the invert level along the trench w a s more then the acceptable value of 6 m for timber shoring. A l u m i n u m hydraulic shoring could be used instead. Also, considerable dewatering will need to be carried out. T h e possibility of using s o m e s y s t e m such as well-point or freezing to stop the s e e p a g e s e e m s unlikely considering the congested site conditions. This m e a n s that one of the side s e w e r s w o u l d need to be tapped to dispose off the p u m p e d water. 3. Y o u r t e a m also points to the fact that the phased a p p r o a c h w o u l d lead to the blocking of at least one of the cross streets all the time due to the need for storage. 4. T h e liaison personnel inform the meeting of the local by-laws that prohibit w o r k after 7 p.m. Due to the cold conditions at this time of the year, starting the w o r k before 7 a.m. would not be possible. This leaves us with a time w i n d o w of 10 hours per d a y excluding non-working hours. 5. T h e product d e v e l o p m e n t t e a m inform the group that they have talked to a n u m b e r of trenchless technology c o m p a n i e s regarding this project. T h e response has b e e n most encouraging. T h e y finally decided to c h o o s e Iseki Microtunneling for detailed discussions as they have a local subsidiary. Based on t h e design of the sewer line, Iseki suggests that w e can achieve the installation with  a  26  m i n i m u m of trenching. The c o m p a n y suggests that for installing t h e 2 . 4 m long pipe sections, the jack shaft dimensions need to be 3.65 m w i d e x 5.8 m long and the receiving shaft 2.4 m wide x 4.3 m long. This w o u l d fit in the p r o p o s e d site width and provide the necessary clearance for operation of the equipment. T h e pits can be used for both jacking and receiving, thus serving a dual purpose. T h e pits will only be needed at the intersections. Tunnelling in the soil conditions and  at  the  grades  required  can  be  achieved  using  their  DISCMOLE  microtunneling head. T h e shafts can only be constructed using conventional m e a n s . T h e achievable production rate is of the order of 1 to 1.5 m of pipe installation per hour. T h e microtunneling c o m p a n y is prepared to either sell, lease or rent the machinery and train the personnel, or take the j o b as a s u b contract. Considering the competitive e d g e this w o u l d yield, it is better to buy the machinery. There is only one catch. T h e pipe has not been d e s i g n e d  to  withstand the axial jacking loads. Our c o m p a n y will therefore have to p u r s u e a design c h a n g e . Iseki has agreed to give a draft plan and schedule by the e n d of the week. 6. Y o u say that w e will prepare a draft plan and budget for the two m e t h o d s and present the two to the senior m a n a g e m e n t for approval. It all d e p e n d s o n their a c c e p t a n c e of the risks associated with investment in a new technology.  Method Selection Related Discussion  27  T h e ten factors identified by you are approved at the meeting. T h e following points c a m e out in the discussion on the interplay of the factors:  1.  T h e project requirements were very important in the selection of a m e t h o d as they helped in narrowing the choices quickly. For example, the requirement for maintaining the traffic flow virtually eliminated the use of the spread t e c h n i q u e .  2.  T h e product and process complexities as well as the major operations  and  resource capabilities are very highly interrelated and it w o u l d be very hard to characterize one without the other. For example, the production rate for an excavator for pipe-laying is very much d e p e n d e n t on the weight a n d location of the pipe. 3. T h e local by-laws could be more readily interpreted as limitations on the use of certain m e t h o d s as opposed to factors for their selection. 4.  A l t h o u g h the last three conditions, i.e. availability of resources and/or expertise, company  policy  and  market  conditions,  are  not  actively  considered  while  selecting the m e t h o d , they are always at the back of one's mind, a n d therefore their effect is very intangible.  3.3 Isolating the requirements for effective method selection  T h e third and final meeting w a s a short one and consisted of the  following  discussion:  28  Project-related discussion  1. Y o u inform the meeting that two draft schedules and budgets w e r e prepared and submitted for perusal by senior m a n a g e m e n t . M a n a g e m e n t has decided to bid using the  second  method,  i.e. the trenchless  technology  option, a n d  are  reasonably confident of winning the bid, considering the a d v a n t a g e s of the m e t h o d . Discussions with City Engineers s e e m to indicate that if the m e t h o d is a c c e p t e d the design change will not be very hard to get.  Method Selection related discussion  1.  Considering all the discussions in the previous meetings, it w a s felt that for an effective m e t h o d selection environment all the stated factors played major roles. However, it w a s found that the details for the last three factors, i.e. availability of resources and/or expertise, c o m p a n y policy and market conditions, w e r e either not easily achievable or not well d o c u m e n t e d . Also these three factors w e r e m o r e a j u d g m e n t a l decision rather then a c o n f o r m a n c e decision.  2.  In the interest of getting the system design underway, these three factors w e r e d r o p p e d f r o m the list.  29  4. THE PROPOSED SOLUTION T h e first step in the design of any system is to determine or b o u n d the s c o p e of the s y s t e m , i.e. to lay d o w n w h a t w e expect the system to perform. In the c a s e of our s y s t e m it is as follows.  Aim W e are endeavoring to provide the user with a toolkit to enable him to e n c o d e his k n o w l e d g e of construction methods in a readily usable form for use, as appropriate, to a u t o m a t e or facilitate the methods selection process for selected aspects of future projects. T h e final product of the s y s t e m is a preliminary project plan for the particular method c h o s e n .  However, construction professionals are already e n g a g e d in the m e t h o d s selection process. W h a t , therefore, would be the benefit of using our s y s t e m as against the traditional brainstorming m e t h o d ? A n s w e r i n g this question leads us to the s e c o n d important step, which is to lay d o w n the design principles, i.e. w h a t are the b e n c h m a r k s against which w e will evaluate the performance of the final product? In the c a s e of our system, these design principles are as follows.  30  Design Principles  1  T h e s y s t e m structure should be as simple as possible to use, a n d to the extent possible w e should keep the workings of the s y s t e m transparent to the user.  2  T h e data structure should be such as to allow e a s e in maintaining  and  updating the data. W e will evaluate this using the following criteria: a. the s y s t e m should be so designed as to take the b u r d e n of maintaining data consistency away from the user as m u c h as possible. b. the s y s t e m should be so designed as to allow easy updating of the d a t a in order to keep pace with technological a d v a n c e m e n t s . 3  Recently  there  have  been t r e m e n d o u s  advancements  in the  computer  industry, especially in the area of information technology, and there is still a huge potential for additional development. Our s y s t e m design should keep in mind these inevitable changes and be prepared to take full a d v a n t a g e of t h e m as they arrive. This entails a modular s y s t e m design. In c a s e of future i m p r o v e m e n t s in information technology, w e can then easily incorporate t h e m without disturbing other unrelated parts that are already i m p l e m e n t e d . 4  T h e s y s t e m should be flexible to allow for different m o d e s of use, keeping in mind the varying needs of different construction projects.  5  Not all people like to work at the s a m e level of detail. S o m e prefer to w o r k at very fine levels of detail while for others, coarser levels of detail are g o o d  31  e n o u g h . T h e system design should recognize these varying views of users, a n d should cater to both. 6  Users may wish to use the system as a database of available construction m e t h o d s . T h e s y s t e m design should cater to the user's need to retrieve d a t a irrespective of w h e t h e r he needs to prepare the preliminary plan for a project.  7  T h e learning curve for using the system should be kept as short as possible. O n e of the w a y s this can be effectively achieved is to m a k e use of as m a n y industry terms as possible. Another w a y is to provide on-line help  and  wizards.  T h e third step is to conceptualize the problem d o m a i n and the s y s t e m structure. T h e fourth  step  involves  the  actual  system  development,  including  refining  and  redefining s o m e of the assumptions m a d e during the third step. T h e final step involves  evaluation  determination  of  the  of successes  system and  against  failures  in  the  benchmarks  meeting  these  we  have  set,  benchmarks,  and  modifications to correct mistakes.  Steps three, four and five are generally iterative and influence e a c h other to a large extent. A l t h o u g h to m a k e the thesis more readable, w e 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 question. Since w e are designing a m e t h o d s selection system, w h a t exactly is a m e t h o d ? To a n s w e r this a n d other related questions let us look at a f e w definitions of a m e t h o d : •  M e t h o d : a procedure or process to obtain an object. (Webster's Dictionary).  •  T e c h n o l o g y : a technical method of achieving a practical purpose.  (Webster's  Dictionary). •  A construction method can be defined as a combination of construction option selected for the execution of the work item and the associated resources to perform the construction option. (Syal et al (1993)).  •  Construction technology is defined as the combination of resources, p r o c e s s e s and conditions that produce a constructed product. (Tatum (1987)).  •  Construction technology or method is a combination of resources (labor and equipment) required to perform a certain activity. (Hendrickson et al (1989)).  •  Construction  technology  is  a  combination  of  resources,  methods  and  environmental requirements and constraints that produce a construction product, ( l o a n n o u e t a l (1993)). •  M e t h o d s 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 f o r a project f r o m Trinh a n d Sharif(1996) is also worth considering in our effort t o find the definition o f a construction m e t h o d : •  Both product and process complexities need to be considered for assessing the technological requirement for a project. (Trinh et al (1996)).  T w o very important points that are evident f r o m all of the a b o v e definitions are: 1.  Most authors agree that a method represents a process and that resources are an important element in describing it.  2 . T h e terms technology and method signify the s a m e things. A l t h o u g h w e initially g a v e t h o u g h t to the issue of differentiating between a construction t e c h n o l o g y a n d a construction method, w e later dropped the idea for the s a m e reason.  For purpose of this study, therefore, w e define a construction method as follows:  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 w h a t w e m e a n by m e t h o d s 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.  w h e r e 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 e x a m p l e , the following can be valid elements of a set of construction m e t h o d s for constructing a trench: Excavation using hydraulic backhoe and timber shoring  O n the other hand, a combination of the following does not constitute a valid set of construction m e t h o d s for constructing a trench: Blasting, Excavation using hydraulic backhoe and timber shoring as blasting and shoring are incompatible.  This definition now identifies all the information that w e need t o perform effective m e t h o d s selection. This information and the c o m p o n e n t s w h i c h provide it are a s 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 m e t h o d s that can be used to construct a product. This information is stored in the "Methods a n d Resource B r e a k d o w n Structure" ( M & R B S ) . 2.  W e need information about the designed product to be constructed. In this research w e are only worrying about methods selection f r o m t h e contractor's point of view in a typical three step (Design - Bid - Build) construction contract. W e are a w a r e that the selection of s o m e methods m a y affect the design of a component.  For example, if a designer has designed a s e w e r 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, w e are not treating this as a part of the research b e c a u s e : a . In most cases if the designer has a s s u m e d a construction m e t h o d during design, he explicitly states it as a part of the construction tender. b. A majority of the decisions related to construction m e t h o d selection are t a k e n by the contractor in a conventional contract as o p p o s e d to the designer. T h e designer is primarily concerned about the constructibility of his design w h e r e a s the contractor is concerned with the detailed specifics of how to construct the designed product. W e think it is in t h e latter decisions that methods selection is more important. T h e only facility w e have provided in the system that links design and construction is that the user is provided with a m e s s a g e that m a k e s him a w a r e 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 m a y impact the method(s) selected is provided by the "Physical C o m p o n e n t B r e a k d o w n Structure" ( P C B S ) .  3.  Finally, w e need a m e c h a n i s m to reason about the applicability of m e t h o d s for particular products subject to certain constraints. This is provided in the s y s t e m t h r o u g h "Feasibility Rules".  W e will now systematically develop each of the a b o v e parts of our s y s t e m a n d t h e n present w h a t 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 methods. W e  found  several characteristics  of hierarchical  and  construction  object-oriented  m o d e l s to be of interest to our application.  A d v a n t a g e s of hierarchical database models include the following:  1.  T h e ability for the user to breakdown his thoughts into progressively finer levels of detail as he m o v e s d o w n the hierarchy.  37  2. A hierarchical database model is very intuitive to civil engineers w h o have b e e n e x p o s e d to hierarchical classification structures during their education. 3. Most of the indexes for classifying information available on the internet are hierarchically arranged and therefore w e could eventually take full a d v a n t a g e of information available in t h e m .  Object-Oriented Database Models have the following advantages: 1.  T h e ability to arrange methods into classes according to their c o m m o n attributes. For e x a m p l e , excavation  using backhoe and blasting can be classified  as  excavation methods. 2. T h e ability to inherit attributes f r o m a higher level object or class. This proves very a d v a n t a g e o u s to the user if he classifies his m e t h o d s by function, e.g., excavation 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 f o u n d that the foregoing models as well as other true d a t a b a s e m o d e l s failed to provide us with the flexibility that w e w a n t e d , as stated in one of the primary design principles. Therefore w e decided to implement a quasi-hierarchical, quasi-objectoriented d a t a b a s e model which would allow us to take a d v a n t a g e of all t h e a b o v e characteristics. However, w e then faced a serious problem. Most of the true d a t a b a s e m o d e l s have been d e v e l o p e d after considerable thought and deliberation by experts to attain t w o  38  primary objectives, i.e., to maintain data integrity (for e x a m p l e , to avoid replication) and to allow for e a s e of maintenance (insertion and deletion). Our decision not to adopt a true d a t a b a s e model meant that w e now had to do a considerable a m o u n t of checking in our programming to ensure these objectives are met.  Since w e did not use any of the formal data models, our design d e v e l o p m e n t also did not follow any formal design methodology. W e , however, f o u n d it useful to identify all the entities in the system and the relationships a m o n g t h e m using an entity-relationship diagram. This diagram is presented in A p p e n d i x I.  In general w e can say that every construction project has a single goal, for e x a m p l e , 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  c h o s e n to n a m e the  root of our hierarchical tree structure  as  Method  S t a t e m e n t for the s a m e reason. A n o t h e r reason to c h o o s e this n a m e w a s that M e t h o d Statements is a term quite c o m m o n l y used in the construction industry. It has now b e c o m e c o m m o n to submit a Method Statement (a statement of m e t h o d s the contractor proposes to use) for major construction projects.  Please note that w e have not defined (and do not plan to define) the s c o p e of a construction project so as not to restrict the user. Although w e discourage t h e user 39  f r o m defining a very narrow scope for a construction project a n d , therefore, a M e t h o d Statement, w e do not restrict him from doing so. For e x a m p l e , the user m a y c h o o s e to have a Method Statement for constructing a round c o l u m n . Also, as per a true hierarchical data model, w e have c h o s e n to allow the user to define the root only once which cannot be repeated a n y w h e r e else in t h e hierarchy; although a case could be m a d e for the use of multiple roots, i.e. t w o or m o r e Method S t a t e m e n t s having a c o m m o n set of methods. For example, construct trench a n d construct excavation as two roots can have the s a m e set of m e t h o d s under t h e m . T h e primary reason for avoiding this is that it would lead to a c a s e of multiple inheritance and therefore additional checks.  A M e t h o d Statement has the following attributes:  1. A n a m e which has to be unique (unique, that is, a m o n g Method Statements). However, a Method can have the s a m e n a m e as a Method Statements. H o w a n a m e is used will be m a d e clear in the section on feasibility rules. 2.  A set of Parameters and Conditions.  3. A m e m o .  A l t h o u g h w e could have allowed insertion of all m e t h o d s to achieve the s c o p e of the Method Statement directly under it, w e found that m e c h a n i s m to allow a M e t h o d  40  S t a t e m e n t 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 Operation.  A n Operation 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  A n Operation 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 allowed Methods to be included as a direct part of Method Statement, t h e n to create the activities for the preliminary project plan w e w o u l d have t o m a p e a c h M e t h o d as an activity. Further, w e would have t o forge p r e c e d e n c e relationships b e t w e e n Methods. This would have been difficult for the user as the p r e s e n c e o r a b s e n c e o f processes is contingent o n the project conditions and  constraints.  However, the presence o f physical locations is guaranteed based on the M e t h o d Statement as is their precedence relationships. Since an Operation always o p e r a t e s on a physical object, for example, construct trench (construct is the operation and trench is the physical object) and a n operation can b e performed b y a set o f 41  m e t h o d s (note that a set can be null), it can now be m a p p e d onto an activity in the preliminary project plan and precedence relationships can be f o r m e d a m o n g t h e m . This d o e s a w a y with the problem of presence or a b s e n c e of m e t h o d s . For e x a m p l e , consider the Method Statement for conventional sewer pipe installation using an open-cut technique. T h e presence or absence of a method of shoring is contingent on the soil conditions i.e. if the trench is in stable rock there is no need for shoring a n d , therefore, no need for a method for it. However, physically there n e e d s to be a trench and t h e n only w e can lay a pipeline. T h e operation, construct  trench  therefore, precedes the operation, lay pipeline. Constructing a trench m a y or may not involve shoring the trench. Note that the user is now working at a m u c h coarser level of detail, that of constructing a trench as o p p o s e d to excavating trench a n d shoring trench.  Since an operation now m a p s one on one to activities w e now have to i m p o s e a constraint that it is an indivisible piece of work as w e do not have the m e a n s to predict the n u m b e r of interruptions and their effect on other operations. In our e x a m p l e , this, therefore, m e a n s that once construction of a trench for a pipe-run has b e e n started, it has to be finished for a given location. W o r k can be interrupted b e t w e e n locations, however.  A n operation has the following attributes:  42  1. A n a m e w h i c h has to be unique (unique, that is, a m o n g Operations). However, a Method can have the s a m e n a m e as a Operation. H o w this n a m e is used will be m a d e clear in the section on feasibility rules. 2.  A set of Parameters and Conditions.  3. A memo.  A n Operation is performed by using one or more set of methods, d e p e n d i n g on the project conditions and the requirements. T h e next level in the hierarchy  after  operations is therefore a method. Since w e are preparing our preliminary project plan at the Operations level, w e need to perform a check that all M e t h o d s under an Operation are compatible. For example, the user should not specify t w o m e t h o d s s u c h as blasting for excavating the trench and shoring under an operation called construct trench. How do w e check for this? Well, in this case w e d o not perform a check. W e leave this check to the discretion of the user specifying the b r e a k d o w n .  Consider again the operation "construct trench" for laying a s e w e r pipeline. T h e project soil conditions 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 j a c k h a m m e r i n g , may have to be adopted. In s o m e cases, especially for highly m e c h a n i z e d processes, such as microtunneling, a method signifies nothing m o r e t h e n the use of a piece of equipment, (e.g. Iseki's uncle mole). In s u c h cases,  43  instead of having an intermediate method level in our hierarchy, w e c a n allow for resources to be attached directly under an operation (this is w h e r e w e diverge f r o m the true hierarchical structure). W e need to check that if a resource is specified directly under an operation, it is compatible with any other m e t h o d s specified. For e x a m p l e , putting a method called laying pipeline by pipe-layers under an operation Lay Pipeline is incompatible with specifying a pipe-laying m a c h i n e as a resource under that operation. W e leave it to the discretion of the user. A final c h e c k w h i c h w e again leave to the discretion of the user for the present is  incompatibility  b e t w e e n an operation and any methods or resources directly under it. For e x a m p l e , an Operation, construct jacking shaft, cannot have a resource, microtunneling h e a d , under it.  A M e t h o d has the following attributes, not all of w h i c h need to be specified: 1. A n a m e w h i c h has to be unique a m o n g Methods. O n the other h a n d , an operation can have the s a m e n a m e as a Method. T h e use of a Method n a m e will be elaborated upon in the section on feasibility rules. 2 . A set of Parameters and Conditions. 3. A m e m o .  A m e t h o d can be performed by one or more resources. Resources, therefore, are allowed as the next hierarchical element in our b r e a k d o w n . A l t h o u g h the user can specify resources for a method in great detail, ( for e x a m p l e , pipe-laying by pipe-  44  layers requires pipe-layer, helper, hydraulic excavator, excavator operator, chain, hook, w i n c h , rope etc.) w e discourage this. It is most beneficial to specify only the key resources for a m e t h o d . Resources such as chains and hooks do not help in reasoning about the feasibility of a method and are therefore unnecessary to track. A g a i n a check of compatibility between the resource and the method a n d a m o n g the resources t h e m s e l v e s is n e e d e d . User discretion in this aspect is w a r r a n t e d . A resource has the following attributes: 1. A n a m e w h i c h has to be unique. T h e use of this n a m e is elaborated u p o n in the section on feasibility rules. 2 . A set of Parameters and Conditions. 3. A m e m o .  N o w consider the design of the second most important feature of a m e t h o d - its procedural nature, i.e., a method is a series of ordered tasks. W e n o w need to allow the user to define this series of ordered tasks, which w e refer to as a fragnet.  A fragnet is a series of ordered tasks. A work task corresponds to a f u n d a m e n t a l field action and work unit (Halpin & W o o d h e a d ( 1 9 7 6 ) ) . Since it is a f u n d a m e n t a l field action, its duration is d e p e n d e n t to a large extent on prevailing field conditions. In s o m e cases, however, (e.g., setting up a microtunneling machine) the duration is relatively constant over a w i d e range of field conditions. In this case the user must be able to specify a standard value for the duration. In all other c a s e s w e need a  45  m e c h a n i s m to d e d u c e the duration of the tasks d e p e n d i n g on the project conditions. W e discuss this in more detail w h e n w e treat the actual operation of the s y s t e m . A task is performed by resources. W e therefore need a w a y of specifying w h i c h resources are required to perform that task. Now w e begin to realize the benefits of our quasi-hierarchical b r e a k d o w n . Since w e have resources as a sub-level to the m e t h o d s and the m e t h o d s are a series of tasks, w e can simply assign all the resources under a method to every task for that m e t h o d . T h e quantity of resource assignment, however, needs to be decided. This again d e p e n d s on the project conditions and has to be decided while preparing the preliminary project plan. Additional 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 therefore,  consists  of tasks  each  having  duration  and  resource  fragnet,  assignment  (indirectly).  W e n o w need to specify the sequencing of tasks. W e use the traditional C P M p r e c e d e n c e relationships for this purpose. In addition, w e now need to allow for the repetition of this set of ordered tasks over multiple locations. W e also need to m a k e the traditional checks for loops and dangling activities.  C o m i n g back to our Methods and Resource B r e a k d o w n structure, w e can n o w associate a fragnet as a complete object with a method to complete the definition of a method.  46  However, w e have previously mentioned that in the preparation of the preliminary project plan, operations are m a p p e d one-to-one to activities. Since an operation can be performed by one or more methods (or resources), w e need a m e c h a n i s m to c o m b i n e 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 operation fragnet as a c o m p l e x object m a d e up of several methods fragnets plus additional tasks, if required, to link t h e m together. W e can now provide p r e c e d e n c e  relationships  b e t w e e n m e t h o d fragnets and also between method fragnets and any linking tasks. For e x a m p l e , if Task A has a precedence relationship with Fragnet B, and Fragnet B is c o m p o s e d of Tasks one, two and three, then in effect Task A has a p r e c e d e n c e relationship with all three tasks. Since Tasks one, t w o and three also have a precedence  relationship  between  themselves,  two  of the  three  relationships  b e t w e e n T a s k A and Tasks one, two and three are unnecessary. This m a y s e e m wasteful but it is quite acceptable considering the reduction in the a m o u n t of user input and thereby maintenance of data integrity and e a s e of use for the user.  This operation fragnet can now be copied as one complete entity into an activity. Indeed w h a t w o u l d be the most desirable solution w o u l d be to provide a hierarchical planning structure at the project level, consisting of activities w h i c h t h e m s e l v e s consist of tasks for the project so that the user can work at multiple levels of detail. If he w i s h e s he can only work with activities, or for detailed day-to-day planning he m a y c h o o s e to work with the tasks. In that case then the entire operation fragnet w o u l d a p p e a r as a tree in the project with the fragnet n a m e as the activity root and 47  the tasks as the branches under it. Such a planning structure is left to future work. Its d e v e l o p m e n t constitutes the work of an entire thesis in itself.  W h a t has been described so far enables the user to e n c o d e his k n o w l e d g e 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,  c o n f e r e n c e papers or indeed from colleagues. However, the strength of a h u m a n expert is derived not only from his knowledge about how to construct projects, but also f r o m his knowledge of current and upcoming technologies about m e t h o d s and resources. He can then use this knowledge, as appropriate, for the construction of new projects. Therefore, our system should be able to store s u c h k n o w l e d g e .  W h a t information should be stored to achieve m a x i m u m benefit to the user? W e keep in mind that while it is theoretically possible to store all construction related information, practically it should be avoided because: 1. All stored information needs to be in a form usable by the s y s t e m . Information for information sake requires unnecessary computer storage w h i c h is a l w a y s at a shortage for the average construction user. 2 . T h e larger the a m o u n t of data stored, the greater the effort required to maintain a n d update it.  48  In our M e t h o d s and Resource Breakdown structure, m e t h o d s and resources are our major building blocks (Operations are context-sensitive). It w o u l d therefore be most a d v a n t a g e o u s to store knowledge about m e t h o d s and resources. W e accomplish this by m e a n s of a classification structure. W e have introduced the c o n c e p t of a m e t h o d class and a resource class. A method may be classified according to function (e.g. pipe-laying methods), availability (e.g. sub-contracted m e t h o d s ) , etc. Since w e provide no restriction for the user to use one particular classification s y s t e m , it m e a n s that one method can belong to multiple classes. W e therefore should check to ensure the consistency of data for the s a m e m e t h o d listed under different classes. S u c h a check has not been implemented. A m e t h o d under a m e t h o d class can also have resources under it as in the Method S t a t e m e n t a n d have a set of ordered task (fragnet) associated with it. T h e attribute set also remains the s a m e . Although  it m a y  be a d v a n t a g e o u s  to have a multi-level m e t h o d  classification  structure, w e have avoided this because: 1.  T h e n u m b e r of methods at a construction c o m p a n y ' s disposal are not that many; and  2.  This eliminates at least one check, that of ensuring the integrity of d a t a for t h e s a m e m e t h o d listed in two sub-classes under the s a m e class or different classes.  A resource class is similar to a method class with the only difference being that here w e d o allow for  multi-level classification. Specifically, it is possible to define a  49  resource sub-class under a class, and then define resources under the sub-class. A g a i n , resources have the s a m e attribute set as in the Method Statement.  Having classified m e t h o d s and resources, w e now need to be able to use t h e m to build n e w or innovative Method Statements. Therefore, w h e n defining n e w M e t h o d Statements, w e need to have an ability to pick a method f r o m a m e t h o d class a n d insert it at the appropriate level in the Method Statement. W e also need to be able to a c c e s s resources in a resource class (or sub-class) while defining n e w m e t h o d s under a m e t h o d class, or while inserting it directly under an operation in a M e t h o d Statement. T o ensure that all methods used in any Method Statement are available for future use, w e require the user to first define the method under a m e t h o d class before trying to associate it with a Method Statement. W e also need to e n s u r e that all self-owned as well as inherited attributes from the method class are available to a m e t h o d in a Method Statement, and that any conflicts b e t w e e n t h e m are resolved. A similar check needs to be d o n e for resources.  W e now a d d r e s s the issue of data maintenance and currency. In this d a y a n d age w h e r e information technology is becoming ever more accessible a n d e a s y to use, w e should develop our system take advantage of it. Specification sheets c o m m o n l y used construction equipment are now available online.  for  In addition, a  n u m b e r 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  specification s h e e t s . Therefore, w e should provide the user with an interface to 2  c o n n e c t to this wealth of information. Further, if he finds that d u e to s o m e 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. Additionally the user should be provided with the capability to develop a local d a t a b a s e of multim e d i a records. T h e s e can take the form of scanned-in articles f r o m trade journals or specifications f r o m manuals, h a n d b o o k s and other sources. T h e user should be able to readily access these records while formulating project plans. A n ability to search through these records is essential. For e x a m p l e , consider the scenario in which the user is looking for trenchless pipe installation t e c h n i q u e s w h i c h are steerable. A quick look through all his records will enable him to quickly narrow d o w n to steerable methods. This can be achieved by allowing t h e user to associate records with appropriate c o m p o n e n t s in the M & R B S . 3  Parameters and Conditions: Our s y s t e m design has now reached the stage w h e r e w e can store information about m e t h o d s and resources and use this stored information to develop effective Method  2  Statements.  However, w e  need to facilitate the  reasoning  about  the  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 d a t a banking could also allow  users to catalog and retrieve information about multi-media records.  51  applicability of m e t h o d s to suit project conditions and requirements. This help could range f r o m complete and rigorous automation of the reasoning process, to just providing all the information related to a method to the user, allowing him to d o the reasoning independently.  To facilitate reasoning w e require the knowledge of w h a t m a k e s o n e  method  different f r o m another, and information as to a method's applicability. Every m e t h o d has s o m e inherent qualities which m a k e s it different f r o m other m e t h o d s . W e call these  parameters. T h e y can be tangible items such as m a x i m u m  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. Conditions deal with tangible values that need to be satisfied for a m e t h o d to be feasible. For example, to use soil displacement m e t h o d s , all pipe runs should be less than sixty meters in length.  O n e might argue that a method's parameters can also refer to feasibility conditions. For e x a m p l e , consider the parameter(s) for use of soil displacement m e t h o d s . W e can have a parameter that says that m a x i m u m pipe length that can be installed in a single run is equal to sixty meters. Interpreted differently, it can be said that o n e of the conditions for the use of soil displacement methods is that all pipe-runs should be less than or equal to sixty meters. W h a t then, in our opinion, is the a d v a n t a g e of differentiating b e t w e e n parameters and conditions. T w o main reasons justify this differentiation:  52  1.  P a r a m e t e r s refer to qualities inherent to the methods. T h e s e qualities might not always be limiting conditions for judging a method's feasibility. However, t h e s e m a y be important items for general project planning work. For e x a m p l e , consider the  parameter  of power  requirement  of an electrically  driven  pipe-jacking  m a c h i n e , e.g., 35 kW/hr. T h e knowledge of this requirement is not important for j u d g i n g its feasibility, but is important w h e n renting a generator for the project. 2. Conditions refer to things expected from the project. T h e y m a y or m a y not m a p to parameters of methods. For example, the feasibility condition for placing e x p o s e d cast-in-place concrete is that the precipitation should not be high  Let us now look at the kinds of values that parameters and conditions can a s s u m e and h o w to represent t h e m . S o m e of t h e m are obvious, such as (1) quantitative, for e x a m p l e , m a x i m u m production rate = 20 ft/day, or, (2) a range of quantitative variables, for example, operating height of C A T E70B (one piece b o o m , 1.39m) = 3.78 m to +6.505 m. In addition w e also need to give the user with the ability to use c o m m o n l y e m p l o y e d construction and civil engineering terms. S o m e e x a m p l e s of these w o u l d be (1) soil class n a m e s (e.g. sand), (2) group n a m e s (e.g. Gravelly sand) and (3) material n a m e s (e.g. pipe materials can be steel, reinforced c e m e n t concrete or prestressed concrete). T h e s e terms are more linguistic t h e n quantitative. Additionally, the need exists to represent items such as permit requirements. T h e availability of Boolean variables ((Yes, No), (True, False)) facilitates this.  53  A similar case can be m a d e for the need for parameters and conditions  for  resources.  A s a next step, w e need to understand how experts think about feasible m e t h o d s . In general, it can be said that h u m a n s think from w h o l e to part (Fenly a n d Harris (1988)), i.e. in laying a sewer pipeline, an expert would look at the project conditions and requirements and eliminate s o m e choices straight away. For e x a m p l e , consider the c a s e w h e r e he has to reason about a project for laying a pipeline in a busy urban a r e a . T h e work corridor available to him is very narrow, e.g., 5 m. T h e soil condition is s u c h that it needs to be supported immediately. He has to lay a 1200 mm  diameter  sewer  main.  He  will  immediately  look  for  alternatives  conventional open-cut technique, i.e. trenchless methods. He will t h e n narrow d o w n  the trenchless  methods  according to their s p a c e  to  the  further  requirements,  m a x i m u m installable pipe diameter, etc.  W h a t this m e a n s for us is that w e should allow for the screening out of obviously infeasible m e t h o d s before proceeding to more detailed reasoning. W e c a n readily achieve  this  by  having  Conditions  assigned  to the  Method  statement  which  eliminates the use of that particular combination of methods, given the p r e s e n c e or a b s e n c e of certain conditions. W e can also have parameters for M e t h o d S t a t e m e n t as also Method class and Resource class which reflect one general p a r a m e t e r of all m e t h o d s a n d / or resources under that particular Method Statement (or M e t h o d Class or Resource Class). This will help the user by reducing  his  data-entry 54  requirements and potential for mistakes. A s operations are context sensitive to the M e t h o d Statements, they do not have any parameters or conditions a s s i g n e d , but they can inherit parameters f r o m a Method Statement to allow for further inheritance by m e t h o d s or resources. A s conditions refer to the feasibility of o n e specific set of m e t h o d s (Method Statement) or an individual Method or Resource, their inheritance is not allowed. Further, although the parameters may be c o m m o n to  several  m e t h o d s and/or resources, their values need not be the s a m e and m a y actually d e p e n d on a n u m b e r of variables. W e therefore allow inheritance of p a r a m e t e r definitions but not their values.  In our previous discussion on M & R B S , w e have described a s y s t e m for the user to e n c o d e his k n o w l e d g e of construction methods and resources and their applicability. T h e user c a n then tailor this knowledge for use on a specific project either himself or automatically by using help provided by the system. To achieve this goal, w e have used a two-tier s y s t e m architecture. T h e first layer is referred to as S T A N D A R D S . A user can use S T A N D A R D S to e n c o d e his knowledge of m e t h o d s as described a b o v e . He can then use selected parts of S T A N D A R D S on the s e c o n d layer called P R O J E C T as applicable. This layer refers to the project at hand, with all its attendant design and site conditions.  O n the P R O J E C T layer w e have provided a similar structure as for S T A N D A R D S with a f e w differences as follows:  55  1. W e provide the user with the ability to build only one Method S t a t e m e n t for a project.  This  Method  Statement  may,  however,  be  composed  of  several  Standard Method Statements for different facets of the project. 2 . W e d o not have Method or Resource classes on a P R O J E C T level. 3. A l t h o u g h a user can insert new operations and methods in a Project Method Statement, w e do not allow him to c h a n g e any of the c o m p o n e n t s that he has copied over f r o m S T A N D A R D S . 4.  In a Project Method Statement, for the items copied over f r o m S T A N D A R D S w e d o not allow the user to modify any standard values for the  parameters.  However, w e provide the user with additional fields to enter new values adjusted for the project at hand. For example, a c o m p a n y data sheet m a y  provide  production rates for equipment under ideal conditions with adjustment factors for deviations f r o m this ideal. T h e 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 w e need information about the product to be constructed.  We  provide  this  information  through  the  Physical  Component  B r e a k d o w n Structure (PCBS).  56  T o design the structure of our P C B S , w e 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.  T h e physical description of the project in terms of the c o m p o n e n t s that need to be constructed to complete the project and their description. For e x a m p l e , in the c a s e of a pipeline project, these are the actual pipe-runs, the m a n h o l e s , the lateral service connections and any other a p p u r t e n a n c e s  s u c h as  flushing  s y s t e m s . W e also need to know the length of e a c h pipe-run, the d e p t h of installation  (invert  level), grade  of  installation,  number  of  pipe-runs,  pipe  materials and sizes, n u m b e r of manholes, size of manholes, m a n h o l e materials, their locations, size of lateral connections their location and number,  design of  a p p u r t e n a n c e s , joining techniques between the different elements, existence of b e n d s and/or corners and their design etc. 2. T h e details of the construction site such as length and width of work corridor, soil conditions such as soil type, water-table and toxicity, o v e r h e a d conditions s u c h as o v e r h e a d cables and structures, surface conditions such as existence of p a v e m e n t , its type and traffic conditions and climatic/weather conditions s u c h as a v e r a g e temperature, precipitation and humidity. 3. Project constraints such as time constraints, cost constraints, noise constraints and contract conditions stipulating use of certain techniques.  57  4. T h e need for temporary structures to be constructed for use of a particular set of m e t h o d s . For example, if w e are using microtunneling, w e need information on the location and size of jacking and receiving shafts.  C o n s i d e r n o w how one might describe the physical c o m p o n e n t s of a project for p u r p o s e s of method selection and evaluation. A n u m b e r of authors have s u g g e s t e d a hierarchical structure for the physical representation of projects (Winstanley et al. (1993), Syal (1992), Hendrickson et al. (1989)) This structure w e f o u n d is most suitable for tiered structures such as residential or commercial high-rises w h e r e the project can be successively broken d o w n into lower and lower levels of detail, for example,  a high-rise project consists of superstructure  superstructure  consists  and substructure.  of typical floors. A typical floor consists  of  The  horizontal  e l e m e n t s (slabs) and vertical elements (columns and walls) and so on. A similar b r e a k d o w n for linear construction projects such as pipelines and roads, a n d block structures such as d a m s is very difficult  t h o u g h not impossible. In our attempt to  develop a universal methods selection environment, w e decided to use a q u a s i hierarchical  quasi-object-oriented  structure  for  the  physical  breakdown.  structure can be adapted to the project at hand by using a d e e p  This  hierarchical  b r e a k d o w n for tiered projects or a flat tree structure for linear projects. This structure also provides us with an easy mapping onto our M & R B S w h i c h is also similarly structured.  58  Here w e describe the tree structure from the top d o w n . At the root of t h e tree is the project itself i.e. the entire product, site and temporary structure c o m b i n a t i o n . T h e a d v a n t a g e 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 m a y have o n e sub-project to lay a main line and another to lay a lateral service line. If there is only o n e sub-project, it m e a n s that the sub-project is equivalent to the project a n d therefore one can avoid using it. A sub-project (or project) can have o n e or m o r e s y s t e m s under it (this is not a very useful concept for pipeline projects). example,  a  high-rise  project  could  be  decomposed  into  two  For  sub-projects  -  superstructure and substructure. T h e superstructure can be further described in t e r m s of a mechanical system, a structural s y s t e m and an electrical  system.  Naturally a s y s t e m can itself have m a n y subsystems, e.g. a mechanical s y s t e m can have a H V A C s u b s y s t e m and a sprinkler s u b s y s t e m ; an electrical s y s t e m can have a c o m m u n i c a t i o n s s u b s y s t e m and a power-supply s u b s y s t e m ; a structural s y s t e m can have a horizontal s u b s y s t e m of slabs and a vertical s u b s y s t e m of c o l u m n s and walls. Every s y s t e m or s u b s y s t e m is c o m p o s e d of elements. For e x a m p l e , a vertical structural s u b s y s t e m is c o m p o s e d of elements c o l u m n s and e l e m e n t walls, an electrical s u b s y s t e m is c o m p o s e d of element panels and element cables.  An  e l e m e n t can also represent temporary structures to be constructed for completing the s y s t e m . A n element can further consist of sub-elements; e.g., e l e m e n t c o l u m n s can consist of the sub-element, round columns and the sub-element, rectangular columns.  59  However, w h a t happens in the case of a pipeline project w h i c h d o e s 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 w h a t h a p p e n s if the project has only one sub-project? T h u s w e need the ability to insert e l e m e n t s directly under project. Of course, the sub-elements go under the elements. Similarly, consider the scenario of a contractor w h o only takes electrical contracts for highrises, a n d d o e s not need to divide the project into sub-projects dealing  with  substructure and superstructure. His concern is limited to a single s y s t e m . However, this s y s t e m has s u b s y s t e m s which have elements and so o n . Therefore, w e need to allow direct insertion of s y s t e m under the project level. This obviously leads to another scenario w h e r e a system may not have sub-systems e.g. a contractor for foundation work for an e m b a n k m e n t may have a drainage s y s t e m of s a n d piles a n d p u m p and a pre-load s y s t e m . However, the pre-load has no s u b s y s t e m .  We  therefore need the ability to insert elements directly under the s y s t e m level.  However, to successfully develop a system to represent the d e s i g n e d product, w e need more t h a n the a b o v e c o m p o n e n t s . W e need to know the location at w h i c h an e l e m e n t or sub-element occurs. This w e achieve by introducing a new c o m p o n e n t in our b r e a k d o w n structure called location. A location can now represent an element or s u b - e l e m e n t or s y s t e m or sub-system, and can be duplicated as m a n y times as n e e d e d , for e x a m p l e , for a pipeline w e can have locations representing jacking shafts, receiving shafts and pipe-runs for using the microtunneling m e t h o d a n d t h e n w e can replicate these locations the appropriate number of times for the project at 60  h a n d . For a high-rise w e could have a location representing a typical floor w h i c h gets repeated, for example, twenty-five times for a twenty-five storey project. A typical floor can be a system c o m p o n e n t in our Physical b r e a k d o w n .  T h e important a d v a n t a g e that w e get from using locations is the ability to perform spatial reasoning easily. T h o u g h w e could have d o n e the reasoning without using a location c o m p o n e n t , it would have been a lot more c u m b e r s o m e . Consider, an e x a m p l e w h i c h involves developing a P C B S for a pipeline project w h i c h is to be constructed using microtunneling and pipe-jacking with precast concrete m a n h o l e s . In terms of spatial information, w e 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 excavation and  related  activities all the w a y to restoration of the surface. By using a location c o m p o n e n t , w e can simply say that this c o m p o n e n t 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 c o m p o n e n t s to determine their coordinates and an additional reasoning construct to instruct the inference e n g i n e that three c o m p o n e n t s with the s a m e coordinates have the s a m e location a n d therefore only o n e pit needs to be d u g . W e now only have to reason in the time d o m a i n to determine w h e n each c o m p o n e n t is constructed. A similar case can be m a d e for the use of the s a m e pit as a receiving shaft and then a jacking shaft for s u b s e q u e n t pipe-runs.  The  system  now  only  has  to  be  instructed  when  the  additional  61  installations to use a pit (formerly being used as a receiving shaft) as a jacking shaft need to be m a d e .  A n o t h e r e x a m p l e from an unrelated construction domain is that of a typical high-rise building. A typical floor has one slab and m a n y columns and a building has m a n y typical floors. In this case, w e represent each typical floor by a location, a n d t h e n have the appropriate c o m p o n e n t s of slab and columns under it. This s a v e s us t h e trouble of defining the number of typical floors and their c o m p o n e n t s as well as p r e c e d e n c e relationships between typical floors and a m o n g c o m p o n e n t s m o r e t h a n once. O n c e defined for one s y s t e m c o m p o n e n t w e can replicate it the required n u m b e r of times. T h e a b o v e discussion also points to the fact that locations are a m e a n s to represent the spatial positioning of one or a group of project c o m p o n e n t s . Therefore w e allow insertion of locations only under the project or sub-project components.  W e now need to know two things: 1. W h i c h c o m p o n e n t of the P C B S is at which location? H o w w e achieve this is explained in detail in the section on feasibility rules. 2 . W e need to know the number of c o m p o n e n t s to be constructed at e a c h physical location. For example, if a location represents a typical floor then w e need to  62  k n o w the n u m b e r of columns per typical floor. To a n s w e r this question w e need to discuss the parameters and conditions associated with a c o m p o n e n t .  It is important to note that there is a difference b e t w e e n parameters a n d conditions as t h e y relate to the M & R B S and the P C B S . In the case of the P C B S , w e define parameters as the attributes which are expected of the final constructed product (as o p p o s e d to M & R B S w h e r e a parameter is a quality inherent to a c o m p o n e n t ) . Conditions in a P C B S are the constraints placed on the project. In this c a s e w e are using a very broad definition of constraints to use items such as: 1.  Contractual conditions of time, cost, etc.  2.  Spatial constraints such as lack of a d e q u a t e storage area, insufficient h e a d r o o m , etc.  3. U n k n o w n factors such as weather, undetected underground utilities resulting in risk e x p o s u r e , etc. 4.  General  site conditions such as site dimensions, surface, s u b s u r f a c e  and  o v e r h e a d conditions.  Parameters by definition are localized to certain c o m p o n e n t s in the P C B S w h e r e a s , conditions are global attributes of the project as a w h o l e (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 d o w n w a r d inherited but conditions can be d o w n w a r d inherited. For example, w h a t is a constraint on t h e  63  project (or sub-project) is also a constraint for all elements under it. However, there are exceptions. A s an example, a pipeline installation project consists of a n u m b e r of pipe-runs e a c h of varying length. W h e n w e reason about the applicability of a set of m e t h o d s (Method Statement), it would be fairly simple to adopt a reasoning process s u c h as: 1.  Determine the total length of pipeline to be installed.  2.  Determine the time frame in which the project is to be e x e c u t e d .  3.  Divide the total length of the pipeline by the time frame to determine t h e a v e r a g e production rate required to be achieved.  4.  C o m p a r e this production rate with the achievable production rate indicated as a p a r a m e t e r to the Method Statement. If the production rate required/ production rate achievable is greater than or equal to one, then the Method S t a t e m e n t is likely to be feasible.  T o adopt this a p p r o a c h , w e would need to go to each pipe-run, find its length a n d s u m up all the lengths. This is very inefficient if a n u m b e r of Method S t a t e m e n t s are to be c o m p a r e d . In such cases, it would be more efficient to a g g r e g a t e all  pipe  lengths a n d store t h e m as a project parameter for easy access. W e therefore need an aggregation m e c h a n i s m to s u m up individual lower c o m p o n e n t p a r a m e t e r values to higher level c o m p o n e n t parameter values. To achieve this therefore w e need to define the s a m e parameters at both the higher and the lower levels in the hierarchy. T o avoid this and all the associated errors, w e allow for d o w n w a r d inheritance of  64  parameters  but  not their values.  Parameters  and  conditions  can  have  either  quantitative values, e.g. time frame for project completion equals 100 days, n u m b e r of c o m p o n e n t s 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 .  A n o t h e r important point to note is the case of temporary structures. A l t h o u g h t h e s e structures are subject to the s a m e conditions as the project, their p a r a m e t e r s are d e p e n d e n t on the methods used. For example, Iseki microtunneling Inc. d o e s not require the  s a m e jacking  shaft  diameter  as Soltau  microtunneling. Inc.  Their  p a r a m e t e r values are therefore derived from the m e t h o d s used and their conditions are all inherited f r o m higher level c o m p o n e n t s .  In addition to the parameters and conditions described above, all of the  PCBS  c o m p o n e n t s have the following properties: 1. A n a m e w h i c h is unique to that particular level which is used for referencing this c o m p o n e n t ; and 2. A memo.  A s in the case of M & R B S , w e provide a t w o tiered s y s t e m architecture. Accordingly, there is a Standard P C B S and a Project P C B S . T h e differences b e t w e e n a S t a n d a r d and a Project P C B S are as follows:  65  1. A l t h o u g h in the Standard P C B S w e can define parameters and conditions for a P C B S c o m p o n e n t , they a s s u m e values only w h e n they are used in the Project P C B S . How they are used is explained in the section on Feasibility Rules. A g a i n h o w d o w e inform the user of a valid set of values for a parameter or condition w h e n a Standard P C B S is used on a project. This is explained below as multim e d i a records. 2.  T h e location specification in the standard P C B S is only a template. W h e n used in t h e Project P C B S , this template must be replicated the requisite n u m b e r of times for the project at hand.  3.  If the user e m p l o y s one of the Standard P C B S s for the project at h a n d , w e d o not allow him to modify or delete any of the c o m p o n e n t s copied f r o m the Standard P C B S . He can however add new c o m p o n e n t s .  W e mentioned the difficulty of conveying to the user valid values for parameters in a Project P C B S . W e can solve this problem using multi-media records w h i c h w e can associate with Standard P C B S c o m p o n e n t s . T h e s e multi-media records can be notes on c o m m o n l y used classification systems, g o v e r n m e n t regulations, s c a n n e d in specification  sheets for temporary  structures, clips f r o m training v i d e o s  or  c o m p a n y promotion videos, or even sound clips recorded by the person designing the S t a n d a r d P C B S . T h e possibilities are limitless. 4  4  Some interesting work on automated content recognition systems by Photios et al. (1995)  could be used to advantage.  66  A l t h o u g h w e have designed a viable system for representing information a b o u t the physical structure to be constructed, w e immediately realize that the structure will tend to be tailored for use with a single Method Statement. This is in part d u e to the need to treat temporary structures. For every variation of the Method S t a t e m e n t a n e w P C B S has to be defined. This can be a daunting and often times wasteful task w h i c h could prevent the adoption of our s y s t e m or ones like it by construction planners. A s an example, consider a Method Statement for installation of a sewer line using microtunneling. At present w e have to dig and e x p o s e all lateral and service connections to the sewer. W e therefore have an element such as excavation for lateral in our Standard P C B S . In the near future if a s y s t e m is d e v e l o p e d w h i c h allows connection of laterals or service connections remotely without excavation as is the case with P V C 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 a n d t h e other without. He will accordingly need t w o P C B S s , one with the e l e m e n t excavation for laterals and one without. T h e only difference b e t w e e n these P C B S s is the a b s e n c e of this element. However, if the user has to define the entire P C B S tree again for this it will be a w a s t e of his productive time. W e o v e r c o m e this by allowing the user to define individual c o m p o n e n t s of the P C B S independently of the S t a n d a r d P C B S tree and then use t h e m as necessary in formulating new P C B S trees. T h e s e w e refer to as Templates. For example, the user can define templates s u c h as piperun element, jacking shaft element, receiving shaft element and excavation for  67  lateral element, and then use t h e m as necessary to m a k e a P C B S . He can also formulate templates for entire systems, sub-systems or sub-projects c o m p o s e d of lower level element and sub-element templates and then use these to formulate his P C B S tree. However, since a location is just a representation  of the  spatial  positioning of a P C B S c o m p o n e n t with no individuality w e d o not allow the user to have a Location template. Since while defining templates w e allow the user to specify p a r a m e t e r and conditions for the c o m p o n e n t s in the templates, w e n o w have to perform a check to avoid conflict between these parameters and conditions a n d any that are inherited f r o m a higher level P C B S component. For e x a m p l e , consider a s e w e r pipeline P C B S c o m p o s e d of two sub-projects - main line a n d p u m p house. If w e have defined the main line sub-project as a template with its o w n conditions s u c h as soil conditions etc. and w e are defining a condition called soil condition for the project c o m p o n e n t (Root) which is to be inherited d o w n w a r d s , t h e n there is a conflict b e t w e e n the two soil conditions. W e have to resolve this. If w e had a d o p t e d a true object-oriented data representation structure, this could readily be d o n e . For the time being, w e require the user to check for any conflicts.  W e n o w have robust structures to represent the physical information that w e need to k n o w about the structure to be constructed as well as our k n o w l e d g e of construction m e t h o d s . W e now have to bind the two together with a reasoning s c h e m a to complete our m e t h o d s selection system. This is explained in the next section.  68  4.1.3 Feasibility Rules  O u r feasibility rules are the m e c h a n i s m w e use for a u t o m a t e d feasibility checking of m e t h o d s and s u b s e q u e n t preliminary plan generation. Unlike other expert s y s t e m s , 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 a u t o m a t e or facilitate the user's method selection process for the selected aspects of future projects. W e therefore clarify the various w a y s that w e intend to facilitate the user's m e t h o d selection process.  4.1.3.1 M o d e s of Operation  Construction projects by their very nature are unique ventures. Every project has to deal with new and varying site and design challenges. Still, there are characteristics  of certain projects which  m a k e t h e m similar and t h u s  some  help  in  classifying t h e m , e.g. residential projects, pipeline projects, road projects, etc. T h e grouping and classification of projects, t h o u g h interesting, are outside the s c o p e of this thesis.  For  companies  contractors,  doing  it w o u l d  the  same  work  be advantageous  repeatedly, to automate  like the  residential reasoning  high-rise about  the  feasibility of construction methods for use on a specific project a n d preliminary plan generation. For c o m p a n i e s w h o specialize in only one or t w o areas of construction but concentrate on a lot of design variations and/or geographic locations,  encoding  69  their previous k n o w l e d g e in a computer-interpretable f o r m and using it to a d v a n t a g e on future projects with or without automation would be good e n o u g h . For large multinational c o m p a n i e s w h o tend to bid for large unique projects with a n u m b e r of conventional c o m p o n e n t s as well as s o m e unique ones, it w o u l d be most useful to piece  together  knowledge  of  the  conventional  components  from  previous  experience, freeing up time to focus on the unique aspects. C o m p a n i e s should in this c a s e be able to formulate a Project M & R B S and P C B S without reference to any S T A N D A R D S . W e therefore end up allowing the user four m o d e s of use. 1. A u t o m a t e d setup of Project M & R B S and P C B S f r o m the S T A N D A R D S along with initial project plan generation and feasibility reasoning. 2.  Use of o n e or more Standard Method Statements without s y s t e m help with the use of the associated P C B S for project setup,  3.  Use of one or more Standard P C B S templates along with independent use of one or more Standard Method Statements for project setup.  4.  Formulation of the project Method Statement and P C B S without any reference to STANDARDS.  W e will eventually be able to provide complete and thorough s y s t e m 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 e n s u r e d a t a integrity and compatibility.  70  T o use the first and second options, associations b e t w e e n c o m p o n e n t s in the M & R B S a n d appropriate c o m p o n e n t s in the P C B S have to be m a d e . W e start with the s e c o n d option. There are two important differences b e t w e e n the first a n d the s e c o n d options: 1.  T h e first option has a very rigid definition of project s c o p e as c o m p a r e d to the s e c o n d option. T h e first option a s s u m e s a project s c o p e involving construction of the entire facility and not its parts. T h e second option does not restrict the user to this definition.  2. T h e first option uses e n c o d e d expert knowledge with expert discretion for the reasoning and the user only performs the task of supplying the facts w h i c h f o r m the basis of this reasoning. T h e second option on the other hand uses expert k n o w l e d g e with user discretion. T h e user in this case performs the dual tasks of collecting the facts and analyzing t h e m . T h e expert k n o w l e d g e in this c a s e 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 e n s u r e that the user does not overlook an important item.  R e a s o n s for choosing the second m o d e of operation over the first include: 1.  T h e 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 w a n t s to use expert k n o w l e d g e on a major variant of the s a m e t h e m e , he will have to use his o w n discretion in doing so. There is a fundamental limit as to the reasoning  71  capability of any expert system. This arises f r o m the fact that h u m a n s t e n d to use an adaptive reasoning process which allows t h e m to collate task specific information, past experience, available alternatives and c o m m o n s e n s e to arrive at a solution as opposed to machines which are designed to use prescriptive reasoning. Prescriptive reasoning is the process of finding a solution to problems f r o m a k n o w n set of solutions (knowledge base) to best fit the facts. This m e a n s that to have a machine reason about a broader subject, more k n o w l e d g e needs to be c o d e d in the knowledge base. This is restricted both by the a m o u n t of effort required and also the difficulty of encoding certain forms of k n o w l e d g e (such as c o m m o n sense). In order to m a k e a s y s t e m usable, therefore, a trade-off has to be m a d e b e t w e e n the a m o u n t of user effort and the viability of providing a m o r e intelligent s y s t e m . This is especially true in the construction d o m a i n  where  variations in the design of projects is more the rule rather than the exception, requiring different j u d g e m e n t s to be m a d e about the applicability of specific methods. 2 . A l t h o u g h a project is similar to one for which k n o w l e d g e is e n c o d e d 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 s y s t e m . For e x a m p l e , consider a local V a n c o u v e r contractor w h o w a n t s to diversify into other regions s u c h as Alberta. Construction of a pipeline in Alberta needs preparation for winter w o r k w h e r e a s the s a m e work in V a n c o u v e r w o u l d not require it. T h e  72  e n c o d e d k n o w l e d g e w o u l d not reflect Alberta's location and climate, a n d could therefore give erroneous results. 3. A less significant but still relevant reason w o u l d be the lack of confidence in the machine's reasoning capability. It should be noted that the author k n o w s of no knowledge-based  methods  selection  practitioners on actual projects -  system  which  is currently  in  i.e. there is still a long w a y to g o  use  by  before  k n o w l e d g e - b a s e d 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 w a n t help at their fingertips but out of the way. Psychologists tell us that people have very short attention s p a n s . Construction 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 & R B S c o m p o n e n t s with P C B S c o m p o n e n t s , w e conclude that our design should allow: 1. T h e user to access expert knowledge easily while setting up the Project M & R B S and P C B S . 2.  T h e expert knowledge should be in the form of suggestions and not conclusions.  73  3. T h e expert k n o w l e d g e 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, w e allow the user (expert) to associate a Standard M e t h o d S t a t e m e n t with any level in a Standard P C B S except location, b e c a u s e it is project dependent. T h e association should, of course, be comparable with the s c o p e of the Method Statement. For example, if w e have a Method Statement for construction of a p u m p house for a sewer pipeline, it is expected that the user will associate this Method Statement with the system component, pump house. Association with a s u b s y s t e m such as sub-structure or with physical elements such as c o l u m n s or slab w o u l d be fruitless. This, however, cannot be automatically c h e c k e d , as w e d o not know the structure of the Standard P C B S or Standard M & R B S a priori. User care is therefore  warranted.  Once  the  proper  association  has  been  done,  however,  additional help can be provided. For example, w e provide the ability to associate e a c h lower level c o m p o n e n t in the Method Statement i.e. Operations, M e t h o d s and Resources with one or more c o m p o n e n t s in the Standard P C B S template w h i c h are a part of the hierarchy of the c o m p o n e n t associated with the Method Statement. For e x a m p l e , if the user has associated a Method Statement with the s y s t e m p u m p 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 s u b -  74  s y s t e m as well as with the Element strip footing. T h e following t w o c h e c k s are a u t o m a t e d to help the user avoid mistakes: 1. W e check that the Sub-system, substructure, and Element, strip footing, are a part of the system pump house; a n d , 2 . W e check that the associated Sub-system and Element are f r o m the s a m e Standard P C B S template as that associated with the Method Statement. This is b e c a u s e , as discussed earlier, a Standard P C B S 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, w e need to e n s u r e that our Method Statement is referring to parameters for sewer pipeline c o m p o n e n t s as against oil pipeline components. A n association is basically a reference to the P C B S c o m p o n e n t (it is comparable to a spreadsheet being e m b e d d e d in a w o r d processing application and being referenced from there).  Using the second option involves the following steps:  S t e p 1: T o start, the user adds a new project and selects the s e c o n d option for setup. S t e p 2 : T h e setup routine then prompts the user as to w h i c h Standard  Method  Statement T e m p l a t e he would like to use to plan the project a n d presents him with a list of previously defined Templates to c h o o s e f r o m .  75  S t e p 3: O n c e he selects a particular template is selected, the s y s t e m copies over that Method Statement to the Project M & R B S . S t e p 4: T h e system then creates a Project P C B S with Project as the root. T h e next step involves the copying over of the associated Standard P C B S template (or template part) to the Project P C B S . S t e p 5: T h e setup algorithm then determines if any locations w e r e defined for the copied Standard P C B S template (if association is m a d e only with a part of a Standard P C B S 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. S t e p 6: O n completing the generation of all locations, the s y s t e m 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 condition defined for that P C B S tree. S t e p 7: T h e user is informed that the setup has been successfully c o m p l e t e d and is presented with an option to  prepare the initial project plan, to c o p y over  another Method Statement or to exit. If the user c h o o s e s to add another Method Statement, then steps 2-7 are repeated. If the user, on the other hand, c h o o s e s to prepare the initial project plan, the setup  algorithm  searches the Project M & R B S for any Operations and sends t h e m over as activities to the scheduling algorithm which numbers t h e m sequentially and assigns the first P C B S location as default to each activity. It t h e n assigns  76  the  resources  under that operation  to the  corresponding  activity.  On  completing this, the setup algorithm terminates.  Note that w h e n the user specifies multiple Method Statements the s y s t e m d o e s not check their compatibility. T h e setup algorithm should, however, be intelligent e n o u g h to detect any conflicts in the location specification. Locations belong to the entireproject a n d critically affect the development of the initial project plan. Accordingly, if the user defines the s a m e 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  overwriting the previous one.  T h e setup algorithm is not concerned with the P C B S structure. For e x a m p l e , during setup w h e n the user copies over the first Method Statement, if the  associated  Standard P C B S template (or part of a Standard template) is a s y s t e m , it inserts it directly under the project. If the Standard P C B S 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. T h e only exception is a S u b s y s t e m or S u b element, in which case the setup algorithm puts it under the first S y s t e m or Element in the Project P C B S tree. T h e only check w e do is to ensure that t w o c o m p o n e n t s at the s a m e level are not named the s a m e to ensure referential integrity.  O n c e 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  Operation. T h e s e durations will then be copied over to the respective activities as activity duration per location. T h e user can c h o o s e not to do this a n d durations directly to activities.  If the user does decide to c o m p u t e  assign  operation  durations he will have to know the physical characteristics of the project. Here is w h e r e our associations c o m e to the aid of the user. T h e user can go to e a c h and every task of a method and access in a w i n d o w the associated P C B S c o m p o n e n t s and their parameters. He can enter the appropriate values and variables for the parameters and s u m up the quantities by aggregating t h e m all for one c o m p o n e n t . A s he knows the n u m b e r of c o m p o n e n t s 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 e a c h task, the duration of the Operation fragnet (and so the activity) can be c o m p u t e d using critical path m e t h o d . W o r k can then proceed on the project level planning and scheduling.  T h e user can take this approach a step further. For the Project P C B S , he can define the condition and parameter values for all of the c o m p o n e n t s . He can then c o m p a r e 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 s o m e Methods and/or Operations and/or resources under it. For this w e need to provide the ability to access individual Methods and R e s o u r c e s in the Standard M & R B S from the Project M & R B S . Changing the Operations will h o w e v e r not c h a n g e 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, w e d o allow the user to modify the Project M & R B S and P C B S while using this second option.  W e n o w describe briefly the working of the third and fourth options before moving on to a t h o r o u g h discussion of the automated setup ( o p t i o n l ) .  4.1.3.3 Option 3: Project Setup with access to S T A N D A R D S but with no s y s t e m help.  If the user c h o o s e s to use the third option, he will be able to copy over the Standard P C B S templates and M & R B S Method Statement templates independently a n d use these to set up his project. W h a t w e m e a n by independent is that the associations b e t w e e n a Standard Method Statement template and Standard PCBS. template(s) no longer hold. T h e 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 c h o o s e s the third option he is presented with a further choice to c o p y a Standard Method Statement template or Standard P C B S t e m p l a t e or quit adding the new project.  S t e p 3 a : l f he c h o o s e s to copy a Standard P C B S template he is presented with a list of defined templates to select from. He can c h o o s e a template to copy. T h e  79  s y s t e m then uses a similar setup algorithm to the one detailed  above  (without the part dealing with the M & R B S ) to define project locations and assign  location  ranges to c o m p o n e n t  parameters  and  conditions.  The  algorithm then goes to step 4. S t e p 3 b : l f he c h o o s e s to copy a Standard Method Statement template t h e n again he is presented with a list of defined templates to c h o o s e from. O n c e he selects a template it is copied over and the underlying Operations are sent to the scheduling algorithm as activities. Now, however, he has no a c c e s s to the P C B S as w e do not have any associations. T h e burden of how to determine the task durations rests entirely on the user. T h e algorithm t h e n m o v e s to step 4. S t e p 4 : T h e user is again prompted with the s a m e screen as in step 2 above. Depending on his response, the algorithm either executes step 3a, step3b or exits.  For option 3, w e do no additional checks except maintain referential a n d directional integrity.  80  4.1.3.4 Option 4: Independent Project Setup  O n adding a new project, if the user decides to use option 4, then the s y s t e m just g e n e r a t e s an empty project P C B S with only one location, that of G P R J (General Project -modifiable by the user) and an empty M & R B S tree.  4.1.3.5 Option 1 - A u t o m a t e d Setup  W e now discuss in detail the automated setup of a Project P C B S , M & R B S , and generation of a preliminary project plan using feasibility rules and our setup engine. To d o this the user first needs to define feasibility rules. T h e next section details our implementation s c h e m a for feasibility rules. T h e following section then discussed the setup e n g i n e and its operation.  Feasibility Rules: W e looked at a n u m b e r 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. T h e rule file w o u l d contain all the rules for determining the feasibility of the Method Statement as well as the underlying m e t h o d s and resources (we do not test the feasibility of Operations).  T h e following are the advantages and disadvantages of this a p p r o a c h :  81  Advantages: a . Since all the rules are in a single coherent file, w e do not need to have external addressing to call the rules for methods and resources. b. Debugging the rule file w o u l d be a lot simpler. Disadvantage: T h e rule file is contrary to our modular design a p p r o a c h . Specifying all the rules in a single file w o u l d m e a n that the rules for the feasibility of a m e t h o d (or resource) w o u l d have to be defined in each rule file. This will most certainly lead to incoherent rules and difficult system maintenance.  2.  A n o t h e r possible approach is a totally modular one. This a p p r o a c h w o u l d m e a n that the rules for feasibility of a c o m p o n e n t reside with the c o m p o n e n t a n d the setup engine is responsible for chaining t h e m . T h e a d v a n t a g e of this a p p r o a c h is modularity and ease of maintenance. T h e disadvantage is the extensive external addressing that w e would have to implement.  W e finally decided to implement a hybrid approach which collects the rule file triggering  in  one  file,  but  the  rules  themselves  reside  with  the  respective  c o m p o n e n t s . This m e a n s the use of a structured rule file. W e f o u n d 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 c o m m a n d s w h i c h the  82  p r o g r a m recognizes and executes at startup. W e decided to adopt a variant of this a p p r o a c h to reduce the user effort in specifying the rules.  To start determining the final structure of our rule file, w e first need to formulate a g o o d range of possible feasibility rules Let us look at a few e x a m p l e s :  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 t h e n the Method Statement is infeasible Rule2: If the pipeline alignment is irregular or if the number and location of u n d e r g r o u n d 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.  M e t h o d - Skip Shoring  Rule: If soil type is not T y p e A ( O S H A Classification) or if the soil condition is s u b m e r g e d , then the Method is infeasible.  83  5. Method - Soil Displacement Method of Microtunneling Rule: If the grain s h a p e is angular or if the soil condition is s u b m e r g e d or if the pipe alignment is irregular or if the pipe diameter is greater than 2 0 0 m m or if piperun is greater than 60 m, then the Method is infeasible.  6. Resource - Hydraulic Excavator (CAT E70B) Rule: If the m a x i m u m weight of pipe is greater than 1000 kgs, then the R e s o u r c e is infeasible.  7.  Resource - Soltau Microtunneling Head (RVS 250A)  R u l e l : If the pipe's m i n i m u m 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 R e s o u r c e is infeasible.  T w o points are apparent as w e analyze the sample rules: 1. All of the rules are basically elimination rules, i.e. w e are trying to d e t e r m i n e the least possible  combination  of conditions which would  m a k e the  use of  a  c o m p o n e n t infeasible. 2.  All our rules can be represented by the following general statement:  84  C h e c k if "argument" satisfies "condition". If not then c o m p o n e n t is infeasible.  O n e additional point not highlighted in the above stated rules is that the feasibility of the higher level c o m p o n e n t in a Method Statement (e.g. Method) is contingent on all the lower level c o m p o n e n t s (e.g. Resources) being feasible. If any of the lower level c o m p o n e n t s are infeasible, the higher level c o m p o n e n t also b e c o m e s infeasible.  Consider the second point listed above. W e have to know w h a t condition n e e d s to be satisfied and what are the arguments for it. W e have already solved the p r o b l e m of the conditions by allowing specification of feasibility conditions as o n e of the attributes of all M & R B S components. A r g u m e n t s in our case then refer to the parameter and condition values of the appropriate Project P C B S c o m p o n e n t s . For e x a m p l e , in the rule for hydraulic excavator, the m a x i m u m weight of the pipe is a parameter of the Project P C B S c o m p o n e n t Sub-element - Pipe-length . In the case of the rule for Skip Shoring, the soil condition refers to the condition - soil condition w h i c h is one of attributes of the Project P C B S C o m p o n e n t - Project.  W e therefore have all the ingredients to analyze feasibility rules. However, w e need to reference t h e m and incorporate t h e m in our rules. So w e need a referencing s c h e m a . W e have used the following s c h e m a :  85  1.  Since w e are referencing different parts of the s y s t e m w e need to have a n a m i n g convention. 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 C o m p o n e n t B r e a k d o w n Structure  SMRBS  Standard Method and Resource B r e a k d o w n Structure  PPCBS  Project Physical C o m p o n e n t Breakdown Structure  PMRBS  Project Method and Resource B r e a k d o w n Structure  2. A s previously explained, under S T A N D A R D S w e allow the user to have the ability to have a n u m b e r of templates both in the Standard P C B S a n d M & R B S . W e therefore need a w a y to specify which templates w e are referring to.  We  have already mentioned that w e have a unique n a m e for each t e m p l a t e of a particular c o m p o n e n t type. Since w e are using a wholistic a p p r o a c h for the a u t o m a t e d setup, i.e. w e allow the user to only deal with the entire project, w e can use this unique template name to refer to it. For e x a m p l e , a Standard Project T e m p l a t e called Sewer pipeline will be referred to as " S P C B S . S e w e r pipeline". This obviously constrains the user from using a period (.) in the t e m p l a t e n a m e . In the case of a Project P C B S or M & R B S , w e do not need this template n a m e .  3. W e now have to tell the system which c o m p o n e n t in the t e m p l a t e w e  are  referring to or in the case of Project P C B S or M & R B S , the c o m p o n e n t in the tree.  86  Tree structures are very c o m m o n l y used in computer software, and a standard convention has been developed for referring to a particular level in a tree.  This  convention separates successive levels in a tree called branches by their n a m e separated by a period. For example, if w e have a Project template called S e w e r S y s t e m with a breakdown as s h o w n in figure 4.1.3.5.1 below, then If w e w a n t to refer to the element, Jacking shaft, w e indicate its address as : S e w e r S y s t e m . M a i n Line.Jacking Shaft T o integrate this addressing with our general referencing structure, w e enclose it within s q u a r e brackets. So the complete address for the element pipe-run w o u l d be: S P C B S . S e w e r S y s t e m [ S e w e r System.Main Line.Jacking Shaft]  Sewer System - Project  M a i n Line - S u b - p r o j e c t  Receiving Shaft - Element  Lateral - Sub-project  Pipe-run - Element  J a c k i n g 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 c o m p o n e n t n a m e then the address w o u l d soon b e c o m e unmanageable. W e therefore restrict a user to a ten character reference name for each c o m p o n e n t w h i c h has to be unique to a particular branch level in the tree structure. T h e root is n a m e d R O O T by default but can be c h a n g e d by the user.  4. O u r final step would be to reference a parameter or condition. This can be d o n e by entering an '*' after the c o m p o n e n t w h o s e parameter w e are referring to followed by the parameter name and an'!' followed by the condition n a m e . So to refer to a parameter, e.g., diameter of pipe for Element pipe-run, the address w o u l d be:  S P C B S . S e w e r System[Sewersys.Main line.Piperun*diameter of pipe]  T o refer to a feasibility condition, e.g., soil type, in the Project M & R B S s h o w n figure 4.1.3.5.2, the following address will be used: PMRBS[Sewerlnst.Trench.Skipshore!Soil type]  88  Sewerlnst - Method Statement ( O p e n - c u t Sewer Installation)  Trench - Operation  Lay P i p e - O p e r a t i o n  (Construct Trench)  (Lay Pipeline)  Exctrnch - M e t h o d (Excavate Trench)  Skipshore - M e t h o d (Shore Trench using Skip Shoring) Conditions: 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 conditions and parameters in our rules, w e need to m a k e a f e w c h a n g e s to our condition and parameter structures. Referring back to our rules, the reader will find that w e have used a number of and/or operators to link conditions together. While specifying conditions it would be a d v a n t a g e o u s if the user is able to specify t h e m as multiple statements using and/or operators. However, w e cannot reason about a parameter (or Project P C B S conditions) as an a r g u m e n t to a condition if the parameter has more than one value i.e. if w e allow use of the and/or operators in the parameters as well. W e will then not know which p a r a m e t e r value is serving as an argument to which condition statement. T h u s w e 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  conditions. Level reasoning refers to the need for reasoning about the feasibility of lower c o m p o n e n t s in a Method Statement, once w e find that the overall statement is feasible. This w e can achieve by treating the feasibility condition as a function, w h i c h returns a value of true or false w h e n supplied with the appropriate a r g u m e n t s . For e x a m p l e , consider the feasibility condition Soil T y p e = T y p e A. If w e treat this as a function and supply it with an argument of a project soil condition of T y p e B, it will perform the following steps to arrive at a result. 1. A c c e p t the value of the project condition as an argument, in this c a s e T y p e B. 2.  C o m p a r e this with the expected value, in this case T y p e A.  3.  If the a r g u m e n t matches the expected value, then return true, else return false. For this case, the result will be false.  By doing this w e can call the feasibility condition as a function with a r g u m e n t s . In our e x a m p l e this would be:  Soil t y p e ( P P C B S [ S e w e r S y s ! S o i l Condition])  w h e r e P P C B S [ S e w e r S y s ! S o i l Condition] is the address of the argument.  90  W e can also deal with multiple statement conditions by just providing the condition function  with  two  arguments.  For  example,  consider  the  condition  called  U n d e r g r o u n d : Soil type = T y p e A and Soil condition<>Submerged.  W e can n o w call this function as follows: U n d e r g r o u n d ( P P C B S [ S e w e r S y s ! S o i l Type], P P C B S [ S e w e r S y s ! S o i l condition])  T h e steps for arriving at a value of true or false are exactly the s a m e except that now t w o values are c o m p a r e d .  There is one final convention w e need to develop to complete the d e v e l o p m e n t of our rule file. This convention is because of the fact that although w e are a w a r e of the feasibility conditions as an attribute of a M & R B S component, the a r g u m e n t s for testing this condition are an attribute of a Project P C B S c o m p o n e n t . T h e r e f o r e they are project dependent, and the feasibility of an M & R B S c o m p o n e n t can therefore only be tested w h e n copied onto the project side. W e need a w a y to supply t h e s e a r g u m e n t s to the condition functions to evaluate a c o m p o n e n t ' s feasibility. This w e can achieve by again using a variant of our previous strategy, that of using a condition function. W e can similarly define a c o m p o n e n t function. W h e n evaluating the feasibility of a c o m p o n e n t on the project side w e supply the a r g u m e n t s for the conditions of the c o m p o n e n t by enclosing t h e m in curly braces. T h e n the a r g u m e n t s to the conditions of a method, e.g., Excavation, are specified as follows: E x c a v a t i o n { a r g 1 , arg2, arg3} 91  H o w these a r g u m e n t s are used internal to a method is e x a m i n e d 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 P C B S conditions or parameters  Components  Lower level c o m p o n e n t s  Conditions  Conditions of the particular c o m p o n e n t to w h i c h the rule belongs  Routines  T h e actual reasoning  End  Stops processing of a rule file  To begin defining a rule file, w e need to associate the highest level c o m p o n e n t in our Method Statement template with the highest level c o m p o n e n t in a S t a n d a r d P C B S template i.e. a Project. No other associations are necessary t h o u g h if the user wants, he can associate lower level c o m p o n e n t s  in the Standard  PCBS  template to lower level c o m p o n e n t s in the Standard Method Statement template. S t e p 1 : W h a t the system does next is copy all the parameters and conditions of all c o m p o n e n t s in the Standard P C B S template into the a r g u m e n t s section of the rule file as project parameters or conditions, and n u m b e r i n g  them  sequentially starting from a r g 1 , . . . . T h e only difference is for p a r a m e t e r s or  92  conditions of locations which are copied as a r g i l 1 a n d so o n , as t h e n u m b e r of locations are not known a priori. W h e n a rule encounters an a r g u m e n t of the f o r m , a r g i l 1, it looks for all locations of the type 11 a n d then tests the validity of the feasibility  conditions for the first condition  of all these  locations. This points to a programming problem, that of keeping track of all locations of a particular type. This w e solve by internally tracking t h e locations as 11, 12,... although externally w e allow naming t h e m differently. O n replication w e provide each location of the s a m e type with a letter sequentially such as 11a, 11b,... to keep track of t h e m .  Step 2: T h e s y s t e m then copies all the methods and resources under t h e M e t h o d s and Resources under the Method Statement in the c o m p o n e n t s section of the  rule  file  sequentially  as project  M&RBS  components,  as c o m p o n e n t 1 , c o m p o n e n t 2 , . . .  again  numbering  . Note that only  them  resources  directly under an operation are copies and not any Methods.  Step 3: This step copies all the conditions defined directly for the Method S t a t e m e n t in the conditions section of the rule file, again numbering t h e m sequentially as c o n d i t i o n l , condition2,... .  Steps 2 a n d 3 c a s c a d e d o w n and are repeated for all underlying M e t h o d s a n d Resources. For the resources, there are no underlying c o m p o n e n t s a n d therefore the c o m p o n e n t s section remains empty. T h e arguments section also remains e m p t y to be defined by the user.  93  W h a t the user has to do next is to call all the conditions in turn specifying the a r g u m e n t s as per the calling convention discussed above ( E x c a v a t i o n { a r g 1 , arg2, arg3}). After this the user calls each and every c o m p o n e n t in order giving it the appropriate arguments. He then goes d o w n to each c o m p o n e n t ' s rule file and repeat the s a m e procedure for t h e m . T h e values of the a r g u m e n t s for a c o m p o n e n t (listed in the a r g u m e n t s section) are supplied by the calling routine. To illustrate the foregoing consider the following Standard M & R B S and Standard P C B S .  94  Sewerlnst - Method Statement (Open-cut technique for Sewer Installation) Conditions: project setting <> congested Parameters: max. production rate = 12 m/day  Trench - O p e r a t i o n (Construct t r e n c h )  Laypipe - Operation (Lay Pipeline)  Conditions: Parameters:  Conditions: Parameters: ,  CAT325 - Resource (Caterpillar Hydraulic Excavator) Conditions: min. clear site width = 5 m Parameters: max. production rate = 0.9 yd /hr 3  SkipShore - Method (Trench Support using Skip Shoring) Conditions'. Underground Conditions soil type = Type A and soil condition <> submerged Parameters:  Labor - Resource (Labor)  Pavrem - Method ( Pavement Removal) Conditions: Parameters:  Timber - Resource (Timber for Shores)  Conditions soil toxicity = none Parameters:  Conditions: soil grain <> angular  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 w i d t h = site clear height = soil type = soil condition = Parameters  Rpe - Hement (The pipe t o be laid) Conditions Parameters pipe diameter = invert level =  excvn - Element ( hole t o lay t h e pipe) Conditions Parameters w i d t h of excavation = depth of excavation =  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 Defining arguments ( corresponds to Step 1 in the formulation of a rule file) 5  arg1 = P P C B S [ S e w e r S y s ! w e a t h e r ] arg2= P P C B S [ S e w e r S y s [setting] arg3= P P C B S [ S e w e r S y s . p i p e * p i p e material] arg4= P P C B S f S e w e r S y s . p i p e * pipe diameter] arg5= P P C B S [ S e w e r S y s . p i p e * l n v e r t level] arg6= P P C B S [ S e w e r S y s . e x c v n * w i d t h ] arg7= P P C B S [ S e w e r S y s . e x c v n * d e p t h ]  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!site width] a r g i l 2 = PPCBS[SewerSys.pipe-run!clear height] a r g i l 3= PPCBS[SewerSys.pipe-run!soil type] a r g i l 4 = PPCBS[SewerSys.pipe-run!soil condition] a r g i l 5= PPCBS[SewerSys.pipe-run!toxicity]  [Components] R E M Defining C o m p o n e n t s (corresponds to Step 2 in the formulation of a rule file) componentl =PMRBS[Sewerlnst.Trench.CAT325] component2=PMRBS[Sewerlnst.Trench.Skipshore] component3=PMRBS[Sewerlnst.Trench.Pavrem]  [Conditions] R E M Defining Conditions (corresponds to Step 4 in the formulation of a rule file) c o n d i t i o n l = P M R B S [ S e w e r l n s t ! p r o j e c t setting]  [Routines] R E M Calling conditions and other c o m p o n e n t s as functions If c o n d i t i o n l (arg2)=True then  (return code =1 condition =condition1  97  break) else continue If c o m p o n e n t l {argM 1-arg6}<>0 then (return code = returned return code condition = returned condition c o m p o n e n t = returned c o m p o n e n t break) else continue If component2{argl13,argl14,argl16,argl16}<>0 then (return code = returned return code condition = returned condition c o m p o n e n t = returned c o m p o n e n t break) else continue  return c o d e = 0  [End]  Rule file for Method Skipshore:  [Arguments] R E M Defining a r g u m e n t s ( corresponds to Step 1 in the formulation of a rule file) 98  arg1={argl13} arg2={argl14} arg3={argl15} arg4={argl16}  [Components] R E M Defining C o m p o n e n t s (corresponds to Step 2 in the formulation of a rule file) c o m p o n e n t l = PMRBS[Sewerlnst.Trench.Skipshore.Labour] component.2 = PMRBS[Sewerlnst.Trench.Skipshore.Timber]  [Conditions] R E M Defining Conditions (corresponds to Step 4 in the formulation of a rule file) condition 1 = P M R B S [ S e w e r l n s t . T r e n c h . S k i p s h b r e ! u n d e r g r o u n d conditions]  [Routines] R E M Calling conditions and other c o m p o n e n t s as functions If condition 1(arg1, arg2) = True then  (return code =2 condition =condition1 break)  else continue If c o m p o n e n t l {arg3}<>0 then (return code = returned return code 99  condition = returned condition c o m p o n e n t = returned c o m p o n e n t break) else continue If c o m p o n e n t 2 { a r g 4 } < > 0 t h e n (return code = returned return code condition = returned condition c o m p o n e n t = returned c o m p o n e n t break) else continue return code = 0  [End]  Rule file for Resource Labor:  [Arguments] R E M Defining arguments ( corresponds to Step 1 in the formulation of a rule file) arg1={arg3}  [Components] R E M Defining C o m p o n e n t s (corresponds to Step 2 in the formulation of a rule file)  100  [Conditions] R E M Defining Conditions (corresponds to Step 3 in the formulation of a rule file) c o n d i t i o n l = PMRBS[Sewrlnst.Trench.Skipshore.Labor!toxicty]  [Routines] R E M Calling conditions and other c o m p o n e n t s as functions If c o n d t i o n l ( a r g l ) = True then (return code = 3 condition = c o n d i t i o n l break) else continue return code = 0  [End]  T h e final aspect of our conceptual design is the d e v e l o p m e n t of the setup engine. T h e steps involved are: S t e p 1 : T h e 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. S t e p 2: If he c h o o s e s option 1 - A u t o m a t e d setup he is presented with a list of M & R B S templates to copy over to the P R O J E C T layer.  101  S t e p 3: W h e n he chooses one of the displayed templates, the setup copies over the Standard  Method  Statement template  algorithm  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 algorithm brings this to the users attention and asks him to select another template. S t e p 4: T h e setup algorithm then cycles through each location asking the user for the n u m b e r of each of these that he w o u l d like to create. S t e p 5: T h e algorithm then assigns the entire location range to each p a r a m e t e r and condition of all the components. S t e p 6: T h e algorithm next cycles the user through the parameters a n d conditions of each c o m p o n e n t so that he can specify the locations at which they occur, if any, and specify their parameter values for these locations. S t e p 7: T h e algorithm next calls the rule file of the Method Statement and transfers control over to it. S t e p 8: If all the rules are satisfied then a return code of zero is sent back to the setup engine. T h e algorithm then proceeds to step 10. If, however, any of the rules fail, then the appropriate return code, condition n a m e ,  and  c o m p o n e n t n a m e are returned to the setup engine. T h e setup e n g i n e then informs the user which condition of which particular c o m p o n e n t has failed, and presents the user with an option to either continue regardless of the failure or to find another c o m p o n e n t of a similar type followed by continued  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.  S t e p 9 a : If the user opts to continue, then control is transferred back to the rule file w h e r e it stopped processing.  S t e p 9 b : If the user opts to choose another c o m p o n e n t of a similar type, the user is prompted that he will have to do so manually. T h e only assistance the machine provides  him with is that it will look at the return c o d e w h i c h  specifies which type of c o m p o n e n t failed. If it w a s a Method or a Resource the algorithm finds the class that the c o m p o n e n t belongs to and presents a list of available Methods/ Resources in that class. T h e algorithm then p a u s e s in order to let the user study the list as well as the c o m p o n e n t attributes and select one that he thinks is suitable. T h e algorithm then moves  control  back to the  rule file to continue f r o m w h e r e  it  was  interrupted, and repeats steps 7 and 8.  S t e p 9 c : If the user decides to use the option to exit processing the  Method  Statement, then the computer m o v e s to step 13.  S t e p 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 a n d the Resources under the Operation as their assigned resources. It also s e n d s the entire location range to the scheduling algorithm. T h e  scheduling  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 1 1 : 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 P C B S as well as M & R B S parameters as an aid in assigning the task a duration.  S t e p 12: O n c e this is complete, control is transferred to the scheduling algorithm w h i c h c o m p u t e s the duration of each Operation and copies it to the activities. Control then shifts back to the setup algorithm.  S t e p 13: O n c e this is complete, the setup algorithm asks the user if he w o u l d like to add another Method Statement template to the project or w o u l d he like to exit.  S t e p 1 4 a : If the user decides to add another Method Statement template, the setup algorithm backs up and stores a copy of the Project P C B S ,  Project  104  M & R B S and activity spreadsheet and then m o v e s back to step 1 (without options 2,3 and 4).  S t e p 1 4 b : If the user decides to exit, the setup algorithm terminates.  T h e user can now inspect all the stored feasible project plans and decide w h i c h 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 Project Level  Changing: 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. . .)  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: • Parameterized description of anticipated site  |Mn3itipnsl^^^^^^^^^^^^^^^^^^^B|| Multi-med'a description of project & site  "•; M 4. PROCESS  VIEW OF  >&j S i  PROJECT  Project M&RBS.; Methods S Resource Representation • Method Statements) • Opera! ons • Methods • Resources Interactive Cycle Design Environment Project Planning & Scheduling Environment  Industry  u • •  Competitiveness, both domestic and international Computer Literacy Sources of information - trade literature, sales personnel other jobs, post-project analysis, ..  5. PERFORMANCE  • • • • •  EVALUATION  Cost Time Safety Risk Environmental Impact  Constraints  • •  1  Stakeholder Involvement Financial Resources  1< 6.  OUTPUT  Method Statement(5  G|c|§DeJg^l^^^pP|^^B Plan & Schedule Cost Evaluation Explanation ofTesults frar  "i;  Figure 4.1.3.5 Schematic Representation of the Proposed Methods Selection System  •• 1  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.  STANDARD METHODS & RESOURCE BREAKDOWN STRUCTURE O  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 w a s  to  produce  a preliminary  project  plan,  including  Method  Statements, w e elected to implement our methods selection s y s t e m within  an  existing project planning environment. W e chose to use R E P C O N ™ (REPresenting CONstruction), a research system developed at the University of British C o l u m b i a . A l t h o u g h s o m e of the actual implementation and conceptualization of the m e t h o d s selection environment has been influenced to s o m e extent by this choice, w e have tried to keep it as generic a possible. R E P C O N ™ is a repetitive construction modeling environment. It operates under M S DOS® or in protected m o d e under Windows®. It has been written in C a n d C + + , and data storage and manipulation are provided by Btrieve's Microkernel  Database  Engine®. For modeling repetitive construction, R E P C O N ™ uses the concepts of locations and typical relationships. O n c e a typical precedence relationship b e t w e e n activities has b e e n defined it gets repeated from location to location, unless s u p e r s e d e d by a n o n typical p r e c e d e n c e relationship. This m a k e s the job of planning simpler for the user. Other features such as use of multiple calendars, resource loading, cost allocation, date and float computations, etc. which are generic to almost all m o d e r n project scheduling software systems are also supported.  6  Programming of the concepts discussed herein was done by William Wong of the  Construction Management Laboratory.  108  Implementation of the conceptual design previously described involves a massive p r o g r a m m i n g effort. To get the m a x i m u m a m o u n t implemented in the relatively short time s p a n available, w e developed the following strategy . First, w e decided to focus 7  on getting the major c o m p o n e n t s of our system up and running before adding various  checks,  user  interface  (Ul)  features  and  other  subtle  performance  improvements. T h e implementation a s s u m e s a user knowledgeable in construction.  T h e discussion of the implementation has been arranged  to follow roughly the  s a m e pattern as that for the conceptual design.  4.2.1 General Comments  The  system  uses  a graphical  user  interface  similar to the traditional  WIMP  (Windows, Icons, Menus, Pointer) interface standard, without the icons, i.e. in effect w e 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 c o d e for help with the Windowing etc. For DOS development, however, no such help is available.  109  A s w e have a consistent set of screens, w e also have a very small set of c o m m a n d s that the user needs to be familiar with. A context-sensitive help facility is also available. T h e table in Appendix II lists the c o m m a n d set and their functionality. T h e c o m m a n d s have been grouped according to the format. S o m e c o m m a n d s  are  c o m m o n to multiple formats.  4.2.2 Methods and Resource Breakdown Structure (M&RBS)  The  M&RBS  aspect  has been the primary focus of the implementation.  The  discussion of the implementation has been kept quite short, as the applications' screen shots convey most of the information.  Implementation of the M & R B S can best be explained by leading the reader t h r o u g h the setup of a simple Method Statement. T h e example selected c o r r e s p o n d s to a Method Statement to install a sewer using microtunneling. T h e steps follow:  S t e p 1: W e start by adding a new Method Statement as s h o w n in figure 4.2.2.1. T h e template list has been sorted for easy reference ( A future implementation consideration w o u l d be to group the list to allow e a s e of access).  110  STflMIfflBD/M&BBS i jEEB~DeTete Edit.  Mofue  Contents  JfecurfTTst  .  Report.  1&BBS Templates S Tree S t r u c t u r e s onu Seuer Replacement-Main L i n e (Concrete pipe) Conu Seuer R e p l a c e m e n t - L a t e r a l s (Concrete pipe) Conu Seuer Replacement-Manholes (Concrete Pipe) Conu' Seuer , B e p l a c e m e n t - B e n d s & C o r n r s ( C o n c r e t e P i p e ) Conu Sewer Replacement-Main L i n e , (Steel pipe) Conu Seuer R e p l a c e m e n t - L a t e r a l s (Steel pipe) Conu Seuer Replacement-ManholeS: (Steel pipe) Conu Seuer Replacement-Bends&Corners ( S t e e l p i p e ) Conu Seuer Replacement-Main L i n e (U C l a y p i p e ) Conu Seuer R e p l a c e m e n t - L a t e r a l s (U C l a y p i p e ) Conu Seuer Replacement-Manholes (U C l a y p i p e ) Conu Seuer R e p l a c e m e n t - B e n d s & C o r n e r s ( D - C l a y p i p e ) Conu Seuer I n s t a l l a t i o n - M a i n L i n e ( C o n c r e t e P i p e ) Conu Seuer I n s t a l l a t i o n - L a t e r a l s (Concrete Pipe)  M&RBS Template  Trenthie&s ( I  "•  imp  D:SBEPC0M4  eXTf"  type Methods Statement Methods Statement Methods Statement Methods Statement Methods"Statement Methods Statement Methods Statement Methods Statement Methods Statement Methods Statement Methods Statement Methods Statement Methods Statement Methods Statement  &^.-.jmii.j  Type: g ethods^StS-tene'n t «J  1  j II.-:  < 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  S t e p 2: Next, w e w a n t to view the contents of the n e w template. This is d o n e by selecting contents on the bar m e n u . A w i n d o w o p e n s showing t h e M e t h o d Statement that w e have created as the root of a tree as s h o w n in figure 4.2.2.2. This ensures that the names of the Method S t a t e m e n t  in t h e  template listing as well as the tree structure are the s a m e . T o e n s u r e referential integrity, w e d o not allow modification of the root. T h e user then selects the first  item from W i n d o w  in the bar m e n u ,  i.e.  Define/Edit  Parameters a n d Conditions.  111  S TANDARD/M&RBSIDEFIHE/EDIT  «V&'M  M8RBS PflRflME TERS/COHDITIONS Report. C o n t e n t s KEcard L i s t  18RBS Templates 8 Tree S t r u c t u r e s ^onuSeuer.Replacement-Mam Line (Concrete-pipe) Trench l e s s  -ROOT  Fl:Help  ( M i c r o t u n n e l l i n g ) Seuer  Methods Statement  U-»«-:ScroIl  Installation  D:\REPC0N4 eXit  Type Methods Statement Type": Methods  Statement  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 ) Sewer  Instal  E n t e r :Select" E s c : Ex i t  Figure 4.2.2.2: Window showing the contents of a newly defined Method Statement.  S t e p 3: W e insert t h e first Operation as a sub-tree. In this case, t h e Operation is t h e construction of a jacking shaft. T h e form for this purpose is s h o w n in figure 4.2.2.3. T o ensure that t h e user selects t h e right c o m p o n e n t , w e have a scrollable list box which limits his choice to c o m p o n e n t s w h i c h m a y c o m e directly under the level above. W e should check that the Operation is indeed a sub-tree and not a leaf, but at present w e do not check this.  112  STANDABD/M8RBSiDEFINE/EDIT M&RBS PARAMETERS^COMDITIONS Add . I Contents Bi:cord List Report 18BBS Templates 8 T r e e S t r u c t u r e s 2oriu Seuer Bep l a c e m e n t - M a i n L i n e (Concrete pipe) on 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  Installation  eKTF"  D:\REFC0N4  Type Methods S t a t e m e n t Type: Methods  Statement;  DEFINE/EDIT M8BBS FABAMETEBS/CONDITIONS M&RBS P A T H :  H«h"T  .Description;: Type:  [X]  -to.  al  .Uiitffl"  5frfflai«I-jL  Inherit parameter/condition d e f i n i t i o n  pffiTl^lniFPa^  i 1 li, I , f ' : i • l  rif'...it n n I  from aboue  leuel  1  | F7:Log  Alt-P:Print  Figure 4.2.2.3: Defining Operations in a Method Statement.  S t e p 4: W e n o w have t w o options. O n e is to continue defining t h e operation subtree, or define all t h e operations at once a n d then define their c o m p o n e n t s . W e will continue with t h e definition of the Operation sub-tree.  S t e p 5: W e insert t h e next lower level component, in this case a Resource, in t h e f o r m of C A T E70B Hydraulic Excavator. W e continue at t h e s a m e level a n d insert a Method for Shoring which involves t h e use of A l u m i n u m Hydraulic Shores. Note in figure 4.2.2.4 that t h e screen f o r m requires t h e user to define a Method in a Method Class. In theory, w e could d o this by simply  113  copying t h e method directly from t h e Method class; however, this feature has not yet been implemented. Also, if this w e r e possible, w e could u s e it to define various crew combinations as a Resource Sub-Class a n d import t h e m into t h e Method Statement. This would m e a n that, although while copying w e indicate a Sub-Class, w h a t actually gets copied over are t h e Resources.  STANDARD/M8RBS!DEFINE/EDIT  M8RBS PARAMETERS/CONDITIONS Contents  1SRBS Templates 8 T r e e S t r u c t u r e s Zonv Seuer .Replacement-Maih L i n e (Concrete- p i p e ) on T r e n c h l e s s  D:\REPC0N4  Type Methods  ( M i c r o t u n n e 1 1 i n g ) Seuer C o n s t r u c t i o n ;  Statement  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 " Description: ^ ;tVm ff&^tU-U' Type:  "  ..  tr  >ikiiv,-ji  3  Template: •?!;-yy; flfrMTgg;".' . Path: T ^ a K a ^ ^ i B ^  ;  '}•'*>? ,  33  ' ^SfrTiH;?1_J  Se  •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  level  F3:Define Parameter/Condition  II  H. i  '  M.i.l  -iui I M M - i i  |  F7TLog"ftrt^PTPfint  Figure 4.2.2.4: Defining a method in a Method Statement.  114  S t e p 6: W e insert a Resource - Shoring Labor under the shoring M e t h o d . W e continue defining the tree to complete the entire Method S t a t e m e n t as s h o w n 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 Cbhu Seuer Replacement-Main L i n e (Concrete pipe) Trenchless Edit f P '  Type Methods; Statement  ( 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 .•-• ' •  BOOT  Methods; Statement T r e n c h l e s s  CAT-E70B Besource 0-AlumShore Method I—ShoreLahor -Besource L-ShoreSets Besource Deuater Method g - 1 n s t 1 E q u i p Method •RecuShaft Operation/ P i p e I n s t a 1 O p e r a t i on •Testpipe Operation  type:  Methods Statement;  ( M i c r o t u n n e l l i n g ) Seuer C o n s t r  CAT-E7QB ( C a t e r p i 1 1 a r H y d r a u 1 i c Excau S h o r i n g u s i n g Aluminum H y d r a u l i c Shor Labor f o r S h o r i n g Modular A1urn i n u m H y d r a u 1 i c S h o r e Se Deuatering the Jacking Shaft I nsta11 P i p e j a c k i n g Equipment and S o i Construct Beceiuing Shaft I n s t a l l the Pipe U a t e r t e s t t h e p ipe as; s p e c i f i e d by des :  OOT.JackShaft .'J.D.itct Uiiif'.uu  i I  i'-  < '.'..,<  t  I'II  • ! .. •  ! ! i Ins I.i n|ili>fi- lit  i» t'  .'i I I ft  MIMI.UI  l ' tt I  Di.-li'li' r*<:  V) I n .  I n .1:1 I.  ill.  , T (  ..m- !t:ui-l  :i:Ui-  Figure 4.2.2.5: Completed Method Statement for constructing a sewer using microtunneling.  S t e p 7: W e next define the parameters and conditions for each c o m p o n e n t in t h e Method Statement. W e demonstrate the parameter/condition definition of t w o c o m p o n e n t s . Method - Microtunneling has got a feasibility condition for use in cohesive soils with cobbles. T h e definition of this condition is s h o w n in figure 4.2.2.6. W e then m o v e d o w n to the resource - Iseki U N C L E M O L E .  115  This resource also has t h e s a m e feasibility condition a n d therefore inherits it f r o m t h e Method. Further, it has parameter definitions such as M a x i m u m grain size of cobbles and A v e r a g e production rates in various soils. T h e definition of these is s h o w n in figure 4.2.2.7. T h e abbreviations 'P' a n d ' C in t h e P/C column stand for parameter and condition respectively. T h e abbreviations 'Q' and 'L' in the B/Q/L column stand for quantitative a n d linguistic values respectively. T h e s e indicate t h e type of values that a particular parameter or condition c a n accept. If w e had a n y parameters or conditions accepting Boolean variables it would be indicated by a 'B' in t h e last c o l u m n .  STANDARD/MftRBS!DEFIHE/EDIT  <j-.,<> .  ..-v.  M&RBS  PARAMETERS/CONDITIONS  1&RBS T e n p l a t e s & T r e e S t r u c t u r e s Doriu Seiier Replacement-Main L i n e (Concrete Def ine  D:SREPC0N4  b F r ~ s c i " c  Contents pipe)  Type Methods  Stateneht  Parameter/Condition  Add Delete! M8RBS: t r e n c h l e s s  (Microtunnelling)  Seuer  Construction  Condition Description: • Class F T "  U a l u e Type:  Cond S t d U a l u e 1  11 ii. .  . . ' I i- t I H I i  B/Q/L-i  1 .••  Std  I - i r | F7:Log  Linguistic  Ualue 2  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 f i ; . •* * t . >>;£. •> C o n t e n t s  D:\REPC0N4l  v  1&RBS Temp 1ates & Tree S t r u c t u r e s Conu Seuer Replacement-Main L i n e  (Concrete  pipe)  Type; Methods Statement  Def ine P a r a m e t e r / C o n d i t i on  M&RBS: T r e n c h l e s s  (Microtunnelling)  Seuer  Construction  Description; P/C Class P Maximum. G r a i n S i z e / D i a m e t e r o f S h i e l d Aug P r o d u c t i o n 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 i n C l a y s Aug P r o d u c t i o n Rate i n S o i l s u i t h G r a u e l Aug P r o d u c t i o n 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 Technical  Inherited  Parameter/Condition  I'l:Hclp U « - : S c r o l l  EnteriSuluct  P / C : Parameter/Conditiun  Ei»c:Exit  Figure 4.2.2.7: Parameter/Condition listing for a Standard M&RBS component.  S t e p 8: T o demonstrate t h e use of fragnets, w e temporarily m o v e out of t h e M e t h o d Statement Template w e are in a n d g o to a Method Class T e m p l a t e , e.g., that of Excavation Support Techniques, a n d select t h e appropriate m e t h o d , e.g., installation of A l u m i n u m Shores. T o install t h e shores w e have to perform a series of tasks. W e g o into t h e Contents of t h e M e t h o d Class T e m p l a t e , m o v e d o w n t h e tree to t h e method of interest, a n d then bring up the W i n d o w listing (by pressing F3) to bring up t h e f o r m for t h e fragnet  117  definition as s h o w n if figure 4.2.2.8. Since w e do not already have a fragnet defined for this, w e press F3 again to bring up the fragnet definition w i n d o w . In this w e start by adding a new fragnet, e.g., A l u m i n u m Shoring. This is s h o w n in figure 4.2.2.9. W e will discuss more on fragnet definition shortly. For now, a s s u m e that w e have completed defining the tasks for this m e t h o d fragnet. W e exit the definition screen, go back to the associated fragnet field and add the fragnet w e just defined from a pop-up list. A s soon as w e have d o n e this, the application marks this fragnet as used by a m e t h o d and prohibits its use by another method. By doing this w e can prevent the user f r o m performing the mistake of making a w r o n g association of this fragnet with another m e t h o d . If he does wish to reuse the fragnet, he can m a k e 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 m e t h o d s , w e now return to our Method Statement.  118  STANDARD/tlSRBS I DEFINE/ED ITM8RBS FRAGNET, ' Contents  D:\REPC0N4  IfiRBS Templates & Tree S t r u c t u r e s Con u Seuer- I n s t a H a t i o n - L a t e r a I s (Concrete Pipe)  Type Methods  Lon Con E x c a v a t i o n S u p p o r t T e c h n i q u e s  Statement  Type: Method C l a s s  DEFINE/EDIT MfiRBS FRAGNET M&RBS PATH: RM»T .pHT^TrtT  V  M^iiii mmMT^W-.uT^  Description:  SUS&EL  3  Type:  Assoc i a t e d * F r a g n e t : F3:Define Fragnet  I I - I ! . I). . / : l , i ,t  n i l - i unl n n K r : l ' v i t  | F7:Loq  Alt-P:Print  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 Contents Record  1&BBS Templates & Tree S t r u c t u r e s 2OWJ S e u e r Inst|~~ ^on F r a g n e t : Aluminum S h o r i n g 3on E x c a u a t i o n CONSTITUENT/PREDECESSOR UINDOU (Edit Uindnu Add Df:li:tc" Nnui: Add  Del  iiir I i I in'ii I ;  Task Fragnct  D:\BEPC0N4  List" "Btipnrf bXit" Type tement ethod  Class  nXit Duration  [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  2  1 uminun S I'l:Hclp  T l - * * - : S c r o l l E n t e r : S e l e c t E s c : Ex i t  Figure 4.2.2.9: Defining a Fragnet for a method in the Standard M&RBS.  S t e p 9: T h e next step is to use these defined method fragnets to f o r m Operations fragnets. By definition Operations fragnets are c o m p o s e d  of individual  Method fragnets plus any additional tasks required to connect t h e fragnets. W h e n w e access the Define Tasks/Relationships screen for an Operation, e.g., Construct jacking shaft, then all the Methods under that Operation are listed along with their associated fragnet. If no fragnet is associated, a m e s s a g e 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 c o m p o n e n t does not have a fragnet associated with it. In this c a s e  120  an Operation Fragnet is c o m p o s e d only of tasks. W e can now a d d any additional tasks and define their relationship to the method fragnets, if present. T h e  use of this functionality will be elaborated  upon  in  our  discussion on fragnets.  S t e p 10:We now explore the use of multi-media records. To define these records for a  component,  we  need  to  navigate  to that  component.  We  choose  Define/Edit multi-media records from the pop-up W i n d o w m e n u to o p e n the Define/Edit form. T h e form for the Iseki U N C L E M O L E is s h o w n in figure 4.2.2.10. W e must provide a code for the record (for a future implementation allowing for sorting and filtering by code), an optional description, a n d an M & R B S record type, which w e have to choose from a pop-up list. A t present the records types are simply n a m e d as 1,2 and 3 and d o not provide any functionality. Eventually, as w e extend support to more formats, t h e s e will correspond to digital photographs, video and other proprietary formats. T h e y will be used for two purposes: (1) to sort the records by format; and (2) to help determine the preview application . To define the actual multi-media file 8  w e then need to go a sub-window and provide the file path and an optional  8  A d a t a 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 s h o w n  in figure 4 . 2 . 2 . 1 1 . A t present t h e user  has to  r e m e m b e r t h e entire path name, but w e c a n easily configure it to provide a local directory listing to make t h e choice. O n c e he has indicated t h e path, the  user  c a n view  the record  using  CompuServe's  CSHOW  as t h e  previewer.  STANDAHD/M&HBSiDEF INE/UIEU MULTI_MEDIA RECORDS f i ild tf^t;ir>-- ' :" •\$xr?.l C o n t e n t s "Tfccofd~ "List T-M&RBS Templates & T r e e S t r u Efconu Seuer R e p l a c e m e n t - M a i n (Microtunnel .on Trenchless Zq DEF I 26 Zo Zo M8RBS PATH: R O O T . P i p e l n s Zo D e s c r i p t i o n Zo Zo Type: . Zo Zo T e m p l a t e : Zo P a t h : i T " Zo No. o f M8RBS Records Code Description  Record  Report eRTt  D:\REPC0N4  Type — Method S t a t e m e n t  type  iEllll  Type: Method Statement":  1SRBS Record Type 2 18RBS Record Type 3  RDS  tr  vv__L!iJ___ ki  11', F3:Associate  rilli  Pictures  l i A M S '•• .Yi-i'h F1T1-, t  ]>• I J ' . i - : F x i l  n.l'i|llp.Pi|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  18RBS T e n p l a t e s 8 T r e e S t r u c t u r e s Son u S e u e r ,Bep 1 acement-Main L i Tie:  fjjy^^Jj^^  (Concrete p i p e )  D:SREFC0M4  Type Method Statement  merit: Assign; P i c t u r e s M&BBS: I s e k i U n c l e Mole; Record: Photol Photograph of UMCLEMOLE No.  of p i c t u r e s Description  tr  F i l e Name  ki  F ! U n u l'u.l.ures~  "F3: A s s o c i a t e  •u P.  •  Pictures!  '.  .  . ' •  .'"1  F7:Luu  Alt-P:Print  Figure 4.2.2.11: Associating a multi-media file with a Standard M&RBS component.  S t e p 11 :We c a n view t h e multi-media records independent of t h e c o m p o n e n t with which it is associated. T o d o this, w e will return to t h e main M & R B S m e n u . If w e choose record list from t h e menu w e c a n n o w view t h e records all at once or by template. These c a n n o w be used to make t h e initial choice of a Method Statement during t h e setup process.  S t e p !2:Finally, it is instructive to examine t h e report generation  process. T o  generate a report, t h e user needs to define a contents profile which is  123  nothing but a list of predefined column formats he can choose. T h e report c o n c a t e n a t e s his choice of columns to produce custom reports. This is s h o w n in figure 4.2.2.12. To produce the actual report he c a n c h o o s e to produce the report either for all or for selected templates, a n d have t h e output directed to the screen, to a printer or a print file. A p p e n d i x III contains a f e w s a m p l e 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, F r a g n e t s and Records r Size:Description § k - 18 Type i 51 C l a s s R e f e r e n c e 1 110 P a r a m e t e r / C o n d i t i o n Def i n i t i o n [• 150 M&RBS F r a g n e t 1 11 R u l e • i:  11 A s s o c i a t e d 71 Meno  Status — Filled  Filled  PCBS  F3:Change Status, tf>:Tag/Untag CKrtffri Esc: Exit"! Contents Width:  • 1-Mi li»"A»i'  301 .• u i d t h of M&BBS P a t h / D e s c r i p t i o h : c b l u n h  • - . T i li I nl.-i : ,i-h i I l s i , : l > i l  ll,i'i|llp,i'ni)n  Figure 4.2.2.12:Defining the contents of a report in the Standard M&RBS.  T h e definition of the Resources in a Resource class or Method in a M e t h o d Class involves t h e s a m e steps as listed from 1-7 and 10-12. Figure 4.2.2.13 s h o w s a  124  s a m p l e of o u r implementation of t h e Equipment classification s y s t e m provided by CIB-W75.  STANDARD/MftFtBS! DEFINE/ED IT M&RBS PflRrtME TERS/CONDIT IONS Contents 18RBS Templates 8 T r e e S t r u c t u r e s ) e u a t e r i n g Techniques Sen Equ Earthmouihg equipment 5pe t ' )th if pe !qu |Typ ,ab iat |Too  D:\REPC0N4  Type — — Method C l a s s Type: Resource C l a s s  :  ;  _  •ROOT Resource C l a s s Earthmo wing equipment II^Excauators Resource S u b C l a s s , E x c a o a t o r s Trenchers Resource S u b C l a s s T r e n c h e r s Dredgers Resource S u b c l a s s , D r e d g e r s Dozers . Resource S u b C l a s s , Dozers Scrapers Resource SubC1ass S c r a p e r s raders Resource SubC1ass G r a d e r s Loaders Resource S u b C l a s s L o a d e r s Backhoe Resource S u b C l a s s Backhoe L o a d e r s 8 E x c a u a t o r s R ippers Resource S u b C l a s s R i p p e r s :  Fl:Hclp Tl-"-:Scroll Enter:Select  Esc:Exit  Figure 4.2.2.13:Resource Class definition showing the CIB-W75 classification for construction equipment.  During t h e course of implementing t h e M & R B S , w e found that w e had d e v e l o p e d a powerful tool for fragnets, a n d thus decided to develop it a little more to exploit its full benefits. Accordingly, w e decided to allow t h e user to define standard fragnets w h i c h he could use in projects independent of the M & R B S . However, w e had t o take  125  care to avoid conflict between these fragnets and an M & R B S fragnet. A brief description of h o w a fragnet can be defined follows.  S t e p 1 : W e first m o v e to the Standard Fragnets option and c h o o s e A d d . W e need to give t h e fragnet a unique name, e.g., Test Sewer. Notice in t h e list s h o w n in figure 4.2.2.14 that the fragnets associated with a M e t h o d have the corresponding M & R B S path listed against t h e m .  SjrANDARD/FRAGNETS  "iileLi:  i.dit  D:\REPC0N4  I'uuc  (.uiuLiluuiilk  UiL-ik l.ugii.  licpui L  i Hit  •Fragnet ; M8RBS Template Dxcauate J a c k i n g S h a f t s (Timber Shore- J a c k i n g S h a f t 'ump Deuaterg of J a c k i n g S h a f t : l"orm/Reinf/Place t h r u s t b 1 ock Assemble. Frame <&. Guidance: S y s . toil Reneual 8 . S e p e r a t i o n Sys H u r r y IBM: I n s t a l l a t n of p i p e lAluminum S h o r i n g  xcauation  Support  Excauation Support  Techniques  Techniques  ROOT.Shoring  F r a g n e t Mame:  Figure 4.2.2.14: Fragnet Listing under the Standard Fragnets.  126  Step 2:  Next, c h o o s e to view t h e constituents. Of course there aren't a n y b e c a u s e w e have not yet defined t h e m . Note that t h e screen is exactly t h e s a m e as the o n e on the M & R B S side.  S t e p 3:  W e start defining t h e fragnet by adding tasks. T h e task addition is a looping process which continues until t h e user decides to e n d it using t h e Escape key. T h e user then assigns predecessor relationships b e t w e e n t h e tasks as s h o w n in figure 4.2.2.15. Note that w e only allow t h e u s e of typical relationships. Further,  by using  location offsets, w e allow t h e  fragnet to loop onto itself from o n e location to t h e next.  STANDARD/FRAGNETS > pFrag.net. Excavate  D:\REPC0N4 ••  ' Constituents M&RBS  : Jackinf  Constituent  T  e  m  p  l  a  t  e  —  Task:  No. of T y p i c a l P r e d e c e s s o r s : Type. Pred: C o n s t i t u e n t :  R e l Lag  mm  Offset.  i  f F8>F9Xi?3-1T: P e l ? Ins K F j e d g j ^ i F i B : Su i t e n t o Succ ;  • i i' •  '  1  i i i  1  i  • i  '  11 | f i M . i i g A l t - P : P r i n t  Figure 4.2.2.15: Defining the constituent tasks of a fragnet. 127  S t e p 4:  O n c e the user has defined the predecessor relationships, he can c h o o s e to check the logic of these relationships.  S t e p 5:  O n e final concept is that of a complex fragnet. A complex fragnet is one which  is c o m p o s e d  of other  fragnets  as  well  as  linking  tasks.  To  d e m o n s t r a t e this, let us use our defined test sewer fragnet as a part of a complex fragnet to construct a sewer line section. T h e steps for defining a complex fragnet are identical to the ones for a simple fragnet except that w e now allow the user to choose a fragnet f r o m a list of user defined fragnets. T h e other steps are exactly the s a m e . Figure 4.2.2.16 s h o w s the assignment of a predecessor relationship b e t w e e n a task and a m e t h o d . Note that at present the nesting of fragnets can be as d e e p as desired. This, however, is difficult to check and ensure a d h e r e n c e to our definitions of a Method and an Operation. In a future study, this should be explored. A n o t h e r issue to r e m e m b e r is that w e 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 & R B S a n d the fragnets. W e do not check for this.  128  STANDARD/FRAGNETS  D:\REPC0N4  IJIISP •EtffiTSJnTn7T?S Check L o g i c [Fragnet Cxcauate J a c k i n iTimber Shore J a ump D e u a t e r g 6 orm/Reinf/Plac Assemble Frame Jo i1 Reneua1 fi H u r r y TBM I n s t iluminum S h o r i n i T e s t Seuer ! C o n s t m e t Seuer  Report  eXit  M8RRS Template F r a g n e t : C o n s t r u c t Seuer P i p e l i n e  Seen  J  r  CONSTITUENT/FREDECESSORJJINDOU  Delete  Muue  r Constituent H u r r y TBM I n s t a l l a t n o f "Ensure C o r r e c t A l i g n m e n t  pipel  '  *\.n-V  Add  eXit Duration  I  Fragnet L i s t Assemble Frame 8 Guidance S y s . S o i l Reneua1 & S e p e r a t i o n Sys ! l u r r y TBM I n s t a l l a t n of p i p e luminum S h o r i n g C o n s t r u c t 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.  T h e Project M & R B S is exactly the s a m e in structure a n d implementation a s t h e Standard M & R B S with a f e w crucial differences:  1. W e allow t h e use of multiple Method Statements to define a n overall project M e t h o d Statement. 2. W e allow access to a n d insertion of Standard  M&RBS  Method  Statement  templates in t h e Project Tree. 3. W e d o not allow t h e definition of fragnets on t h e project side. T h e y have to be predefined on t h e Standards side.  129  Figure 4.2.2.17 s h o w s a tree structure defined for the project using o u r Standard S e w e r Construction template as well as a locally defined template for p u m p h o u s e construction. T h e figure shows the Method Statement for a sewer project w h i c h is c o m p o s e d of t w o Standard Method Statements - Sewer and P u m p H o u s e . Note that w e represent the project Method Statement by the root. Since this s t a t e m e n t is only for a particular project, w e have no name for it. T h e structure under a Method Statement itself is similar to that on the standard side. r  PBOJECT/HSRBSIDEFINE/EDIT M&RBS PflRflMETERS/CONDITIOMS E H 3 | UiTi'dou Check "Logic Report. eXTf.  D:NREPC0H4SPR0J1QSTHESIS '_ ~"  Seuer Methods Statement T r e n c h l e s s ( 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 PumpHouse Methods Statement 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 Construct Substructure, S-SubStruct Operation ]—CAT-E70B Resource CAT-E7QB ( C a t e r p i l l a r H y d r a u l i c E x c a u a t o r ) 0  IH. FormSet Resource Carpenter Resource •—Shouelers Resource B u i l d P l n t h Method U a t e r P r o o f Method : Backfill Method § - S u p r S t r u c t Operat ion  '.•i.; .:• i.r • i .<iii i i n FormUork f o r t h e c o n c r e t e C a r p e n t e r f o r t h e forms S h o u e l e r s t o Shooel and L e u e l t h e B u i l d P l i n t h Walls U a t e r P r o o f the, F o u n d a t i o n Backf i l l t o t h e ground l e u e l Construct Superstructure;  unpHouse.SubStruct.CastBase , . P , n - "in.liiu M i l : 1 in- I c n p l a U - .tl 1  ! 1 in I  I i .1 \ i i  i 'i •  l I " I ii ..II hi I ' M - 1  .• ith ii,ui. I f ' l i l  i il:0t  1  I'lrln.' n»  i • I n^t i I  \\  concret  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)  T h e implemented structure for the P C B S is exactly the s a m e as the  M&RBS  9  (except the fragnets). W e will therefore not dwell much on demonstrating its use, but will illustrate its application sufficiently in the creation of a Physical representation for a s e w e r project.  Figure 4.2.3.1 s h o w s the Template listing for the Standard P C B S side. Note that w e can have templates at different levels. Higher level templates can t h e n be m a d e by combining those from a lower level. Figure 4.2.3.2 s h o w s a Standard T e m p l a t e for our hypothetical sewer project. A s discussed earlier, w e can have a choice to have a d e e p or a flat hierarchy depending on the type of project. W e have decided to represent the sewer project using a relatively flat b r e a k d o w n structure.  Figure  4.2.3.3 s h o w s sample parameter and condition definition. Note the similarity in the screen design for the P C B S and M & R B S .  9  In fact as g o o d programming practice dictates to make as much of the program c o d e  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 Add  rPCBS;Tenplates 8 T r e e . S t r u c t u r e s tSewer P i p e l i n e I n s t n l l » i t t o n " P r o . j c i '  • i.i'je'ntionft i )  >euer VIpe1ine 1 n s t a 1 1 a t l o n P r o j e c t ( M i c r o t u n e 11ng) leuer P i p e l i n e B e n e d i a t i o n P r o j e c t (Conventional) leuer P i p e 1 ine Rened i a t i on P r o j e c t (M i c r o t u n n e l i n g ) lain L i n e .ateral Connection leuer P i p e - r u n [acking S h a f t . lece i u i n g ' S h a f t Trench f o r con uent i ona1 s e u e r c o n s t r u c t i o n Ian-hole ' r e s s u r e R e l i e f ualue l u s h i n g Syphon 'auenent S t r u c t u r e  I i  I •  D:\REPC0N4  PCBS 8 PARAMETERS/CONDITIONS  .it i h i , i ! i i .'At. I i i I I' i : !'<• i I  TI,  Type Pro.]'.  8  Fro j e c t Project Pro j e c t . Subproject Subproject E1 ement Element, Element Elenent Elenent Elenent Elenent Elehent  In , ! H i' i  Figure 4.2.3.1: Template Listing for Standard PCBS.  132  STANDARD/FCBS!DEFINE/EDII PCBS « PflRflMETERS/COHDITIOHS C o n t e n t s 'Record "List" R e p o r t rPCBS Templates &* T r e e S t r u c t u r e s 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 eu ieu la i ,at leu ac lec [Tre Ian 're lu 'ao  -ROOT Project JackShaft Element Pipel Plpe2 Recushaft —Man-hole -PRU —Pipe-run -ShaftLocs —Manhole OOT.Piperun I" . . h . i l i i  |ii j ii i - i  1/(1  [',  in  i n .)  Project(Hicrotune1  1  P i p e Type 1 ( F o r use u i t h more t h a n one p i P i p e Type Z ( F o r use u i t h more t h a n one p i Receiuing Shaft Manhole Pressure R e l i e f Value Pipe-run Location L o c a t i o n of J a c k i n g 8 r e c e i u i n g S h a f t s &•Man Manhole l o c n f o r Manholes l o c a t e d independen  : ! ii-- li.-nplcili  . i  Type Project  Seuer P i p e l i n e I n s t a l l a t i o n J a c k i n g ' Shaft: r  Subelement Subelenient Element Element Element Location Location Location  U n v J i i u '.'i I '  (Conuentional)  D:\REPC0N4 HtiC*  •.iililiui-l  :  «I  nlili-u-'l  !'!•: |ir I t ' l l -  '"lil-l'i  F'i:ln-i-il  Ins « I  !il  r ii -  ...mi I  ••••]  li-yi-1  Figure 4.2.3.2: Standard Physical Breakdown Structure for a Sewer Project.  133  STANDARD/PCBSiDEFINE/EDIT PCBS 8 PARAMETERS/CONDITIONS  ;ef La  fTITia  D:\REPC0N4  1  geTetel  PCBS:: Seuer P ipe 1 ine  I n s t a H a t i o n P r o j e c t (M i c r b t u n e 1 i n g ) B/QVL  Description: Class:: llljlll  Cond S t d U a l u e  •m  U a l u e Type:  1  Boolean  Std Ualue  Uni-i  1  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 T h e implementation of feasibility rules has been left to future work. W e therefore c h o s e instead to give a short demonstration of t h e ability to copy fragnets over t o the P R O J E C T L E V E L and use t h e m in the Activity list.  To access t h e fragnets for use on a project they have to be copied to t h e P R O J E C T L E V E L . This is achieved in t h e Activity Spreadsheet by selecting Frag f r o m t h e bar menu. T h e system  then asks us for a fragnet to insert into t h e list a s s h o w n in  Figure 4 . 2 . 4 . 1 . T h e project level does not differentiate b e t w e e n M & R B S a n d n o n -  134  M & R B S fragnet at present. In t h e absence of a hierarchical planning structure, w e decided to m a p each task onto an activity. T h e algorithm therefore n u m b e r s each task as an activity a n d inserts it into t h e spreadsheet. In t h e case of a complex fragnet (one comprised of several fragnets), all of t h e tasks of t h e underlying fragnets are c o d e d as activities. T h e routine assigns t h e location default set by t h e user to each activity and task durations if any are assigned to t h e activity as duration per location. T h e precedence relationships defined in t h e Standard Fragnets are also maintained.  ACTIUI TV DATA/DESCRIPTION; UINDOU  r Code -  D:\REPC0N4\PR0J10NTHESISl  Descri Fragnet, Fragnet  lExcauate J a c k i n g : S h a f t s ITimber Shore J a c k i n g S h a f t IPump Deuaterg: of J a c k i n g : S h a f t -i  I •  ! Ill  J  !.'<  •  I i l l :<  1  ••.  ••  tesemb1e Frame 8 Guidance S y s . S o i l Reneual 8 S e p e r a t i o n Sys S l u r r y TBH I n s t a l l a t n o f pipes Huminun S h o r i n g | T e s t : 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  •if  i . . I'JI • i  Ti,r.iiip,i'>|iiii  Figure 4.2.4.1: Copying Standard Fragnets to Project Level.  135  4.3 Validation  W e need to validate two things. T h e first is the validity of our initial idea that w e can design a m e t h o d s selection system which would achieve our stated aim of providing the user with a toolkit to e n c o d e his knowledge of construction m e t h o d s in a readily usable f o r m for use as appropriate, to automate or facilitate the m e t h o d s selection process for selected  aspects of future projects; as well as m e e t the  design  principles. T h e second is the validity of the model w e have i m p l e m e n t e d . W e have to test it using real world scenarios to prove that it can represent actual Method Statements in a w a y that is useful for not only assisting in decision m a k i n g , but in a w a y that improves decision making  4.3.1 Validity of the initial idea  T h e validation of the initial ideas can be checked by analyzing the d e g r e e to w h i c h w e have s u c c e e d e d in meeting the previously stated objectives. O u r analysis is s u m m a r i z e d 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 w e achieved it  which met Simple structure and  High  transparent working.  1. By keeping the n u m b e r of s y s t e m c o m p o n e n t s small, i.e. by using a very terse but precise language. (Implemented) 2. T h e user has access to the system's reasoning process, and can easily follow its trace with the k n o w l e d g e 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 & R B S templates easily, etc. 2. By providing access to multi-media records, w e provide the user with a tool to keep his data current. 3. By instituting checks to maintain data integrity.  137  Taking a d v a n t a g e of  Medium  a d v a n c e s in technology  T h e ability to store and manipulate digital images is now c o m m o n l y available. W e are enabling the user to take full a d v a n t a g e of this through the use of multi-media records  Flexibility to e n s u r e different  V e r y High  m o d e s of use  This has been a major focus. S e e the discussion on M o d e s of operation and Setup options.  Allowing users to work at  V e r y High  T h e s y s t e m design has also f o c u s e d strongly on this aspect. S e e the initial discussion on  multiple levels of detail  M&RBS.  To design the system so as to allow its use for purposes other t h a n m e t h o d s selection.  Very High  1. W e provide independent a c c e s s to records. 2. W e allow for the use of fragnets independent of the M & R B S .  138  4.3.2 Validity of the implemented model T h e r e are a n u m b e r of aspects to be validated.  1. T h e  ability  to  meaningfully  represent  Method  Statements,  methods  and  resources in a w a y that improves decision making  T o validate this aspect w e revisit the Yellow Brick Road project  m e n t i o n e d in  Chapter 3. Y o u are back in your role as the Senior M a n a g e r responsible for planning in a firm that specializes in sewer construction. Y o u are presented with the s y s t e m implemented as explained in section 4.2 and asked to d e t e r m i n e if the  system  can  meaningfully  represent  Method  Statements,  methods  and  resources in a w a y that improves decision making. Y o u decide that the s y s t e m needs to satisfy the following three requirements in order to achieve this: a. T h e representation should be complete. b. T h e representation should be easy to use. c. T h e  representation  should  provide  meaningful  insights  to  allow  better  choices.  Y o u decide to evaluate each of these against the backdrop of the Y B R project.  139  a.  Is the representation complete? W h a t w a s needed in the bid preparation of the Y B R project w a s an efficient w a y to represent all information available to the c o m p a n y in the field of conventional sewer construction and trenchless sewer construction m e t h o d s available on the market. In the system the Standard M & R B S can be used to completely  store  information  about  already  tried  and  new  construction  m e t h o d s , as well as supporting information in the f o r m of the  resources  n e e d e d , their production rates under different conditions and their capabilities and limitations; and the tasks needed to perform the work using a particular m e t h o d in the form of fragnets. In addition, the s y s t e m provides the use of multi-media records to store information that cannot be readily e n c o d e d . This can further be. coupled with the Standard P C B S to provide the user with a spatial perspective on the use of certain methods. T h u s the system provides a complete representation of construction m e t h o d s 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  m i n i m u m n u m b e r of errors while keeping details of the actual implementation hidden f r o m the user. In the case of the Y B R project, this can be m e a s u r e d in terms of the e a s e with w h i c h information about the c o m p a n y ' s methods for conventional s e w e r 140  construction can be retrieved and the ease with which n e w  information  (obtained from Iseki as well as others c o m p a n i e s e n g a g e d in trenchless construction  activities) can be entered  into the s y s t e m for e a s y  future  reference. In order to make the s y s t e m easier to use for users in the target d o m a i n , i.e., construction, the system uses a near industry terminology. T h e s y s t e m 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 w o u l d be easy to retrieve data on any construction m e t h o d . Similarly, this classification structure also helps the user to enter data about a new method or resource. A n o t h e r feature of the s y s t e m is the ability to browse the multi-media records to easily pinpoint useful d a t a to be retrieved. Further, a number of checks have been implemented in the s y s t e m to trap errors. T h e user can also use multi-media records to keep up to date information  about  new  and  evolving  construction  technologies  without  explicitly encoding t h e m in the system, thereby using the s y s t e m as a d a t a store w h i c h he can tap for more information. If using a new t e c h n o l o g y appears beneficial under s o m e particular circumstances, t h e n the user can obtain more detailed information on t h e m . Having said this, it is probably fair to say that ease of use is relative. W h a t one might regard as a very user-friendly s y s t e m m a y not be  regarded  similarly by s o m e o n e else. T h u s w e can say that the system is relatively easy to use.  141  c.  Does the representation help provide insights for better choices? If the s y s t e m w a s used in the bidding for the Y B R project, then it should have been capable to allow the user to c o m e up with the choices of hydraulic shoring for the trench as o p p o s e d to timber shoring as this w a s a better choice. T h e s y s t e m is capable of this as it provides the user with the ability to mix and match methods and resources to develop new Method S t a t e m e n t s for the construction of a particular job. In addition, the s y s t e m allows the user to associate the individual M & R B S c o m p o n e n t s with P C B S c o m p o n e n t s to give the use a spatial perspective  The  implemented  meaningfully  system  represent  .  can  therefore  information,  retrieve  be  used  and  to  view  completely information  and about  construction methods and use this to m a k e better choices.  T h e ability to reason and reach conclusions that an expert w o u l d make. Since the implementation of the model is not 1 0 0 % complete, w e cannot test its validity under field conditions. However, w e detail here a procedure that could be used, to give the reader an idea of how w e envisage the testing of s u c h models.  W e envisage two w a y s 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: T o use this alternative would require data on at least four major projects to completely validate the system. T h e first two projects will need to have a fairly obvious choice of Methods. T h e other t w o w o u l d t h e n have a choice  of  construction  methods  alternatives  available  for  their  construction. For example, if w e decide to c h o o s e four s e w e r installation projects to validate the model, then the following indicates a meaningful choice for the projects: Project 1: T h e project conditions allow it to be constructed using only microtunneling and pipe jacking. Project 2: T h e project conditions allow it to be constructed using only conventional means. Project 3: T h e project conditions allow for the adoption of either of the two methods. Project 4: T h e project conditions allow for the adoption of either of the two methods. By mapping the response of the implemented model to each of the a b o v e scenarios w e can determine if it is robust e n o u g h .  143  2. By enlisting the help of experts:  T o use this technique w e would need to create several s a m p l e project scenarios, similar to the one above. W e would then interview a n u m b e r of experts to gain the methods alternative that they w o u l d have preferred to use in each of these and the reason for their choice. W e w o u l d 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 w e w o u l d validate the system.  144  5.  Recommendations for future work  In the previous chapter (section 4.3), w e summarized w h a t w a s a c c o m p l i s h e d in relation to the objectives stated at the outset for the thesis. However, the m e t h o d selection problem domain is rich with challenges. T h o u g h w e have c o m e a long w a y in developing our system, much work remains to be d o n e . T h e s y s t e m , t h o u g h sufficiently  robust,  needs to be validated  in other areas  of civil  engineering  construction. W e present in this chapter our vision of w h a t should be d o n e to develop this s y s t e m further to its logical end - its active use by the construction industry. This  chapter  is divided  into three sections. T h e first section  lists the  major  c o m p o n e n t s of the s y s t e m yet remaining to be w o r k e d on. T h e s e c o n d 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 s y s t e m to m a k e it m o r e user friendly and acceptable to the construction industry.  5.1 Items requiring major focus  S o m e of the suggestions for future work are evident f r o m the discussion  on  conceptual design: l.  T h e first w o u l d be to implement the reasoning system described earlier a n d test it using real world and synthetic examples.  145  2. T h e next logical step in the development of the s y s t e m w o u l d be to extend the reasoning further to enable the system to analyze all the feasible alternatives a n d rank t h e m as to the degree to which each alternative can m e e t the stated project alternatives. 3. T h e implementation of a hierarchical planning structure is also an evident choice for the immediate future. This structure would represent activities as i n d e p e n d e n t trees having only one branch level beneath t h e m , that of tasks. T h e user now has the a d v a n t a g e 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 r o m the m u c h greater control offered by this structure both over the execution 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) senior  management  is provided  with  a very  broad  plan focusing  whereas on  the  completion of important milestones. T h e 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 m a n a g e m e n t .  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 t h e n roll it up as necessary for reporting purposes. Also t h r o u g h the use of fragnets w e have now provided him with the ability to define standard activity trees, w h i c h 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 estimates 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 conditions, the c o m p a n y ' s o w n resources, indirect costs, etc. T h e s e  models  should allow for the treatment of perceived risks. 5. At present the reasoning model is not complete e n o u g h to interpret the use of c o m p l e x Method Statements. For example, on s o m e sewer jobs, part of the works  is constructed  using  microtunneling, w h e r e a s  the  remaining  part  is  constructed using the conventional open-cut technique. T h e ability to reason about "Hybrid" Method Statements needs to be a d d e d . 6.  O u r treatment of resources is thorough on the methods selection side. However, it needs more work w h e n used in the generation of the initial project plan. W e have successfully worked out the w a y to assign resources to activities. However, the resource levels are d e p e n d e n t on the method selected and product a n d site conditions. 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.  A n o t h e r issue is the integration with the Internet. T h e recent d e v e l o p m e n t of the first D O S based graphical browser could well pave the w a y in this direction. Further, w e can realize other benefits by integrating it with previewers s u c h as Ghostscript which are freely available. This is important to take a d v a n t a g e of the w e a l t h of information that is available (and likely to increase in the future) on the internet.  8. A final r e c o m m e n d a t i o n w o u l d be to port the entire application to a m o d e r n graphical user environment, i.e. W i n d o w s . In addition to w i d e user a c c e p t a n c e , this w o u l d give us multi-tasking which is lacking in the current s y s t e m .  5.2 Wrinkles that need ironing out  Various parts of the design have been implemented. For these parts, that w e have i m p l e m e n t e d , this section lists s o m e of the shortcomings that might be a d d r e s s e d as a part of a future research effort.  1. T h e ability to copy individual Methods or Resources into a Method S t a t e m e n t must be a d d e d . Presently, the user has to define each individual m e t h o d or resource in a Method Statement, and add a path n a m e corresponding to this c o m p o n e n t in a method or resource class.  148  2. At present only scanned images can be stored as multi-media records. Allowing the inclusions of videos, and soundtracks would be an asset. T h e integration of file previewers such as the ones for C A D drawings w o u l d be useful. 3. T h e ability to pick from the Standard fragnets, while using t h e m directly in scheduling for a project would be a useful feature. 4.  M o r e work needs to be done on the checking of logic for fragnets.  5.  Users need to be given the tools to m a k e additions to the linguistic p a r a m e t e r list, as they think about additional feasibility options.  6.  A select-sort facility to produce more customizable reports needs to be w o r k e d on. For e x a m p l e , if the user only wants to see the Operations in a Method Statement to get an idea of the final activities, he presently needs to print out a w h o l e report including all of the c o m p o n e n t s .  5.3 Performance and usability improvement features  This section is organized entirely from the perspective of an end-user of the s y s t e m and as such is s o m e w h a t reflective of the idiosyncrasies of the author as regards to c o m p u t e r systems.  1.  In practice, an expert would not like his Standard T e m p l a t e s t a m p e r e d with by other users. This would require him to keep constant checks on the d a t a and  149  w o u l d obviously lead to ill-feeling. A n ability, therefore, to restrict a c c e s s to the S T A N D A R D S (e.g., by using a password) is needed.  2.  T h e s y s t e m requires the user to select a Method Statement w h i c h he thinks is feasible to start the automated reasoning process. He w o u l d therefore like to have the ability to organize the Method Statements into classes representing his v i e w of feasible Method Statements. This should be included as a part of the system.  3.  In actual use, the Standard M & R B S would e x p a n d to include m a n y  Method  Statements, Method Class and Resource Class templates. T h e s a m e is true for the Standard  P C B S . T h e addition of searching and filtering capabilities  to  retrieve information f r o m these would be most w e l c o m e .  4. A similar ability as a b o v e with records is also desirable.  5. T h e Interface needs a little revamping to m a k e the user access to information easier. For example, records should be m o v e d inside the template, so that they can also be viewed f r o m the tree m e n u .  6. A n integrated help facility would serve to reduce the user effort in memorizing steps and thus increase his productivity considerably.  150  BIBLIOGRAPHY Abdul-Malak, M. U., Mezher, T. and Murphree, E. Jr. (1995). "Decision Support S y s t e m Framework for Construction Technology Transfer and Diffusion" Transportation Research Record, n 1 4 9 1 , Jul 1995, pp. 4 9 - 6 1 .  Al-Hammad, I. (1991). (1991). "A Knowledge-based framework for construction method selection." Ph.D. thesis, Department of Civil Engineering, University of British Columbia, C a n a d a .  Alkass S. and Harris F. (1988) "Expert S y s t e m for earthmoving e q u i p m e n t selection in Road Construction." A S C E Journal of Construction Engineering and M a n a g e m e n t , 114 (3), pp. 426-440.  A m e r i c a n Concrete Pipe Association (1980). "Concrete V i e n n a , Virginia, U. S. A., ISBN 0 9 6 0 3 8 6 8 1 5 .  Pipe  Handbook"  A w a d Saliman H. (1989). "An Interactive K n o w l e d g e - B a s e d Formwork Selection S y s t e m For Buildings." Ph.D. thesis, T h e Pennsylvania State University, U. S. A.  Belford, G. G. and Santone, A. L. (1989). "Object-Oriented Databases for Construction Data" Software Track, Proceedings of the T w e n t y - S e c o n d A n n u a l Hawaii Conference on Systems Design, Vol. 2, pp. 559-568.  Brandon, P. and Martin B. (1995). "Integrated Construction Information" E & FN S P O N . London, U. K., ISBN 0 4 1 9 2 0 3 1 0 2 .  Caterpillar Inc. (1992). "Caterpillar Peoria, Illinois, U. S. A.  Performance  Handbook,  23  rd  Edition"  CIB W o r k i n g Commission W 7 5 Mechanization in Building (1984). " R e c o m m e n d e d International Classification Of Construction Machines A n d Equipment" CIB Working Commission W 7 5 - Mechanization in Building,  Prague.  Clarke, N. W . B. (1968). "Buried Pipeline" Maclaren and S o n s Ltd., L o n d o n , ISBN 0 8 5 3 3 4 0 1 2 0 2 .  C o m m i t t e e on Application of Expert Systems to Material Selection during Structural Design (1995). "Computer - Aided Materials Selection During Structural Design" National A c a d e m y Press, W a s h i n g t o n , D. C , U. S. A., ISBN 0 3 0 9 0 5 1 9 3 2 .  Echeverrry, D., Ibbs, W. and Kim S. (1991). "Sequencing K n o w l e d g e for Construction Scheduling." A S C E Journal of Construction Engineering and M a n a g e m e n t , 117 (1), pp. 118-130.  E n c a r n a g a o , J. L. and Lockerman, P. C. (Eds) (1990). "Engineering Databases - Connecting Islands of Automation T h r o u g h Databases" Springer - V e r l a g , Berlin, Hiedelberg, Germany, ISBN 0 3 8 7 5 2 0 5 9 7 .  Fenly, C. and Harris, H. (1988). "Expert Systems: C o n c e p t s and Applications" Cataloguing Distribution Service, Library of Congress, W a s h i n g t o n D.C., ISBN 0844406112.  Fischer, M.A and Aalami, F. (1996). "Scheduling with Computer-interpretable Construction Method Models." A S C E Journal of Constriction Engineering a n d M a n a g e m e n t , 122 (4), pp. 337-347.  Gray, C. and Little J. (1985). "A Systematic A p p r o a c h to the Selection of a Crane for a Construction Site." Construction M a n a g e m e n t and E c o n o m i c s 3, pp. 121-144.  Hadjigeorgiou J. (1988). "A Knowledge-Based S y s t e m for Selection of Excavating Equipment" Technical Report No. 08, Division of Mechanical Engineering, National Research Council C a n a d a .  Halpin, D.W. and W o o d h e a d , R.W. (1976)."Design of Construction Process Operations", John Wiley and Sons, New York, NY, U. S. A.,  and  ISBN 0 4 7 1 3 4 5 6 5 2 .  Hendrickson, C , Zozaya-Gorastriza , C. and Rehak D. (1989). " K n o w l e d g e Based Process Planning for Construction and Manufacturing." A c a d e m i c Press, Boston, Massachusetts, U. S. A., ISBN 0 1 2 7 8 1 9 0 0 2 .  Institution of Public Health Engineers (1985). "NO-DIG 85: Proceedings of the First International Conference, London 16-18 April 1985" L o n d o n , U. K., ISBN 0905188071.  l o a n n o u , P. G. and Martinez, J. G. (1996). "Comparison of Construction Alternatives Using Matched Simulation Experiments" A S C E Journal of Construction Engineering and M a n a g e m e n t , Vol. 122. No. 3, pp. 231 - 2 4 1 .  l o a n n o u , P. G. and S o u - S e n , L. (1991). "Construction T e c h n o l o g y / Method Identification and Selection S y s t e m " Preparing for Construction in the 2 1 Century Proceedings of Construction Congress' 9 1 , Cambridge, Massachusetts, pp. 638 - 643.  s t  l o a n n o u , P. G. and Yiu L.Y. (1993). "Advanced Construction T e c h n o l o g y System". A S C E Journal of Construction Engineering and M a n a g e m e n t , 119 (2), pp. 2 8 8 - 3 0 6 .  ISO (1994a). "Building Construction Core Model, Project T C 1 8 4 / S C 4 / W G 3 Document N 3 4 1 , October 1994.  Proposal"  ISO  Joint T a s k Force of the A m e r i c a n Society of Civil Engineers and the W a t e r Pollution Control Federation (1982). "Gravity Sanitary S e w e r Design and Construction" A m e r i c a n Society of Civil Engineers, New York, New Y o r k and W a t e r Pollution Control Federation, W a s h i n g t o n , D. C , U. S. A., ISBN 0 8 7 2 6 2 3 1 3 0 .  Liggesmeyer, P. (1996). "Selecting Engineering T e c h n i q u e s using Fuzzy Logic Based Decision Support" Proceedings of the IEEE S y m p o s i u m and W o r k s h o p on Engineering of C o m p u t e r - B a s e d Systems, Friedrichshafen, G e r m a n y , pp. 4 2 7 - 4 3 4 .  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 Operations." A S C E Journal of Construction Engineering and M a n a g e m e n t , 122, (3), pp. 2 1 2 - 2 2 2 .  M u t a g w a b a , W . K. and Terzepoulos, N. G. (1994). " K n o w l e d g e - B a s e d S y s t e m for Mine Method Selection" Transactions of the Institution of Mining and Metallurgy, Section A: Mining Industry, Vol. 103, Jan-Apr 1994, pp. A 2 7 - A 3 2 .  Nichols, H. L. Jr. (1976). "Moving the Earth - The W o r k b o o k of Excavation Third Edition" M c - G r a w Hill, U. S. A.  Occupational Safety and Standard for Excavations" W a s h i n g t o n , D. C , U. S. A.  Health Administration (1990). "Construction Associated General Contractors of A m e r i c a ,  Ontario Concrete Pipe Association (1989). "Concrete Pipe Design M a n u a l " Etobicoke, Ontario, C a n a d a .  Peurifoy, R and Ledbetter, W . (1996). "Construction Planning, E q u i p m e n t and M e t h o d s 4 Edition" M c - G r a w Hill International Editions, Singapore, ISBN 0070498369. t h  Portland C e m e n t Association (1968). "Design and Construction of Concrete S e w e r s " Skokie, Illinois, U. S. A.  R. S. M e a n s C o m p a n y Inc. (1987). "Means Heavy Construction Cost Data 1 A n n u a l Edition" R. S. Means C o m p a n y Inc., Kingston, Massachusetts, U. S. A.  s t  Ratay, R. (1995). "Handbook of Temporary Structures in Construction", McG r a w Hill, New York, U. S. A.  4  R e d a , R. and Carr, R. I. (1989). "Time-cost Tradeoff A m o n g Related Activities." A S C E Journal of Construction Engineering and M a n a g e m e n t , 115 (3), pp. 4 7 5 - 4 8 6 .  Russell, A. D., Guindy, K. and Alldrit, M. (1997). "Computer S y s t e m for the Selection of Trenchless and Conventional Methods for Underground Utilities" North A m e r i c a n N O - D I G '97 Conference Papers, pp.357-370.  S h a k e d , O. and W a r s z a w s k i , A. (1995). " K n o w l e d g e - B a s e d S y s t e m for Construction Planning of High-Rise Buildings" A S C E Journal of Construction Engineering and M a n a g e m e n t , V o l . 1 2 1 , No. 2, pp. 172 - 182.  Skibniewski, M. J. and C h a o , L. (1992). "Evaluation of A d v a n c e d Construction T e c h n o l o g y with A H P Method" A S C E Journal of Construction Engineering and M a n a g e m e n t , Vol. 118, No. 3, pp. 577-593.  Skibniewski, M. J. and Chao, L. (1995). "Neural Network Method of Estimating Construction T e c h n o l o g y Acceptability" A S C E Journal of Construction Engineering and M a n a g e m e n t , Vol. 1 2 1 , No. 1, pp. 130-142.  S o u - S e n , L. (1992). "Object-Oriented Representation Model of Construction T e c h n o l o g y Information (Information M a n a g e m e n t ) . " Ph.D. thesis, T h e University of Michigan, U. S. A.  Stein, D., Mollers, K., Bielecki, R. (1989). "Microtunnelling - Installation and R e n e w a l of Nonman-size Supply and S e w a g e Lines by the Trenchless Construction M e t h o d " Ernst & S o h n Verlag fur Architektur und technische W i s s e n s c h a f t e n , Berlin, Germany, ISBN 3 4 3 3 0 1 2 0 1 6 .  Syal, M G. (1992). "Construction Process Knowledge Model to Assist Method Selection in Project Planning." Ph.D. thesis, T h e Pennsylvania State University.  Syal, M. G., Parfitt, M. K., and Willenbrock, J. H. (1993). "Design Information Hierarchy for Construction Method Selection Process" C o m p u t i n g in Civil a n d 155  Building Engineering - Proceedings of the Fifth International C o n f e r e n c e (VI C C C B E ) , A n a h e i m , California, U. S. A., Vol. 1, pp. 742 - 749.  T a t u m , C. B. (1987). "Classification System for Construction Technology.", A S C E Journal of Construction Engineering and M a n a g e m e n t , Vol. 114, No.3, 344-363.  T h e Pipelines Industries Guild (1984). "Pipelines Design and Construction" Construction Press, New York, U. S. A.  T h o m s o n , J. C. (1993). "Pipejacking and Microtunnelling" Blackie A c a d e m i c and Professional, Great Britain, U. K.JSBN 0 7 5 1 4 0 1 0 2 1 .  Trinh, T. T. P. and Sharif, N. (1996). "Assessing Construction T e c h n o l o g y by Integrating Constructed Product and Construction Process Complexities: A C a s e Study of E m b a n k m e n t D a m s in Thailand." Construction M a n a g e m e n t and Economics, 14, pp. 467-484.  University of T e x a s , Petroleum Extension Service, Pipeline Contractors Association (United States) and T e x a s Education A g e n c y (1966). "A primer on Pipeline Construction 2 Edition" Petroleum Extension Service, University of T e x a s , Austin, Texas, U. S. A. n d  Winstanley, G., C h a c o n , M. and Levitt, R. (1993). "An Integrated Project Planning Environment" Intelligent Systems Engineering, Vol. 2, No.2, pp. 9 1 102.  Y o k e l , F. Y. (1980). " R e c o m m e n d e d Technical Provisions for Construction Practice in Shoring and Sloping of Trenches and Excavations" Department of C o m m e r c e and National Bureau of Standards W a s h i n g t o n , 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 C o m m e r c e a n d National Bureau of Standards W a s h i n g t o n , D. C , U. S. A.  Appendix I - E-R Diagram  Appendix II - Command Listing  List d i s p l a y Command Name  Screen Location  Action  A d d (A)  M e n u Bar  Delete (D)  M e n u Bar  M o v e (M)  M e n u Bar  Edit (E)  M e n u Bar  Allows the user to c h a n g e t h e template/fragnet n a m e .  Contents / Constituents (C)  M e n u Bar  Allows user to bring up a w i n d o w to enable the user to a c c e s s contents of a selected template/fragnet.  Report (R)  M e n u Bar  eXit (X)  Menu Bar  Right A r r o w (-»)  Status Bar  Allows the user to define report contents and also to create the reports. Closes the active w i n d o w a n d returns to the client w i n d o w . Move right to select M e n u Item.  Left A r r o w (<-)  Status Bar  Move left to select M e n u Item.  Up A r r o w (t)  Status Bar  Scroll up to select a template/fragnet.  D o w n A r r o w {I)  Status Bar  Scroll d o w n to select a template/ fragnet.  O p e n s up a f o r m to secure d a t a for creating a template/fragnet. Deletes the selected template/fragnet. Allows user to sort the t e m p l a t e s as desired/fragnet.  Home  Move to the first template/fragnet in the list.  End  Move to the last template/fragnet in the list. Move up the template/fragnet list by one screen height.  Page Up Page D o w n  Move up the template/fragnet list by one screen height.  T a b and Shift+Tab  Scroll by a screen length to view additional information on fragnets.  Enter  Status Bar  Select item to a c c e s s 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  Action  Edit (E)  M e n u Bar  W i n d o w (W)  M e n u Bar  Switches the c o m p u t e r to edit m o d e to enable user a c c e s s to records. Gives a choice list of the functionalities available in the active window.  eXit (E)  M e n u Bar  F3  Closes the current w i n d o w and returns to the client w i n d o w . Brings up the W i n d o w choice list in a pop-up m e n u .  F5  Status Bar  Inserts a c o m p o n e n t as a lower branch of the tree t h a n the selected component.  F9  Status Bar  Ctrl+F5  Status Bar  Ctrl+F9  Status Bar  + or Right A r r o w (->)  Status Bar  Inserts a c o m p o n e n t in the s a m e level of the tree as the selected component. Inserts a template in a lower branch of the tree than the selected component. Inserts a template in the s a m e branch of the tree as the selected component. Expands the tree to s h o w c o m p o n e n t s one level below in the hierarchy.  - or Left A r r o w (<-)  Status Bar  Up A r r o w ( t )  Status Bar  Collapses the tree to the selected component. Scroll up to select a c o m p o n e n t .  D o w n A r r o w (I)  Status Bar  Scroll d o w n to select a c o m p o n e n t .  *  Blows up the selected c o m p o n e n t to s h o w all the levels in the hierarchy.  T a b and Shift+Tab  Scrolls the c o m p o n e n t text.  Enter  Status Bar  Selects a particular c o m p o n e n t for editing.  F1 Esc  Status Bar Status Bar  Brings up context sensitive help. Interrupts the active process and returns control to the client process.  161  Report Display (On Screen) Command Name  Screen Location  Action  Up A r r o w (t)  Status Bar  Scroll the screen up.  D o w n A r r o w (I)  Status Bar  Scroll the screen d o w n .  Right A r r o w (-^)  Status Bar  Scroll the screen right.  Left A r r o w (<-)  Status Bar  Scroll the screen left.  T a b a n d Shift+Tab  Status Bar  F1  Status Bar  Scroll the screen by o n e screen length. Brings up context sensitive help.  Esc  Status Bar  Interrupts the active process and returns control to the client process.  Screen Location  Action  F o r m Input Command Name T a b or Shift+Tab  Status Bar  Moves the focus to the next f o r m element.  F1  Status Bar  Esc  Status Bar  Brings up context sensitive help. Interrupts the active process and returns control to the client process.  F10  Status Bar  Confirms entries m a d e in a f o r m .  F3  Button in form  O p e n s 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 A r r o w (t)  Scrolls up to select an item in a scrollable list box or a pop-up list.  D o w n A r r o w (I)  Scrolls d o w n to select an item in a scrollable list box or a pop-up list.  Left A r r o w (<-)  Status Bar  Scrolls the text in a scrollable field to the right.  Right A r r o w (->)  Status Bar  Scrolls the text in a scrollable field to the left. Inserts a record for d a t a entry.  F9 F8 Enter  Deletes a record. Status Bar  Selects an item in a pop-up list.  162  Appendix III - Sample Report  UBC  C O N S T R U C T I O N  MANAGEMENT  LAB  R E P C O N ™  Page 1  Type,  Fragnets  and  Records Report Date: Report Tine:  Select: Selectively  lenplate: 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 )  Sewer  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  Class Reference  Methods Statement PARAMETERS INHERITED DESCRIPTION COND UALUE 1 WIDE 2 N Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH I DESCRIPTION ROOT.JACKSHAFT | Construct Jacking Shaft  Type  P  TYPE  UNIT  Quantatitive  Class Reference  Operation PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.JACKSHAFT.CAT-325 CAT-325 ( C a t e r p i l l a r Hydraulic Excavator)  P/C CLASS  Type  Class Reference  Resource  Earthraving equipment ROOT.Excavators.CAT-325  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Bucket Capacity And EQ 8.9  P/C CLASS  P  P/C CLASS  TYPE  UNIT  Quantatitive  TVPE  UNIT  P  Quantatitive n3  Average Excavation Rate And E0. 6  P  Quantatitive tH/nn  Maxinun Working Radius And Eq B8B8  P  Quantatitive m  Length of wheel base And EQ 4368  P  Quantatitive MM  Width of wheel base And 0) 2998  P  Quantatitive m  150CT97 16:83:25  Of 14  Page 2  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.JflCKSHftFT.ALUMSHORE Shoring using Aluminum Hydraulic Shores  Type  Class Reference  Nethod  Excavation Support Techniques ROOT.AluirShore  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N Maxinun allowable surcharge load  And EQ ZBBBB  N  Max load on hydraulic cylinder(2 inch) And  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.JACKSHAFT.ALUMSHORE.SHORELABOR Labour for i n s t a l l i n g / r e m o v i n g shoring  EQ  P/C CLASS  TVPE  UNIT  P C  Tachnical  Quantatitive Quantatitive l b  C  Technical  Quantatitive l b  m  Type  Class Reference  Resource  Labor ROOT. SHORELABOR  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.JACKSHAFT.ALUMSHORE.SHORESETS Modular Aluminum Hydraulic Shore Sets  Class Reference  Resource  Foundation Engg 8 s o i l compaction equipnent ROOT.SupportSys.AluwUaler  N  Max load on hydraulic cylinder (2 inch) And EQ I B B  Type  Class Reference  Method  Deuatering Techniques ROOT.SUMP-DRAIN  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N Max size of p a r t i c l e s And EQ 3  TVPE  UNIT  Quantatitive  Type  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Maximum allowable surcharge load And EQ  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.JACKSHAFT.DEWATER Deuatering the Jacking Shaft  P/C CLASS  P/C CLASS  TVPE  UNIT  C Technical  Quantatitive l b  C Technical  Quantatitive l b  P/C CLASS  P C Technical  TVPE  UNIT  Quantatitive Quantatitive i n  Of 14  Page 3  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.JACKSHAFT.DEUATER.SELF-PRIME 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  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION M8RBS PATH ROOT.JACKSHAFT.DEUATER.PUMPOPER Punp Operator  Type  Class Reference  Resource  Labor  P/C CLASS  P  TYPE  UNIT  Quantatitive n3/nn  ROOT.PUHPOPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.JACKSHAFT.MTINSTALL I n s t a l l Microtunneling Equipment  TYPE  UNIT  P/C CLASS  TYPE  UNIT  Type  Class Reference  Nethod  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  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.JACKSHAFT.MTINSTALL.TECHNICIAN Technically Qualified Person (Mostly Operator)  P/C CLASS  P  Quantatitive  Class Reference Labor ROOT.TECHNICIAN PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z  METHOD, HESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION I n s t a l l pipe jacking equipment ROOT.JACKSHAFT.PJINSTALL ON ON  Class Reference Equipment I n s t a l l a t i o n Procedures ROOT. PJINSTALL  P/C CLASS  TYPE  UNIT  Of 14  Page 4 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.JACKSHAFT.PJINSTALL.TECHNICIAN Qual. Technician to i n s t a l l eguip.(Mostly Oper)  Type  Class Reference  Resource  Labor  P/C CLASS  P  TVPE  UNIT  Quantatitive  ROOT.TECHNICIAN PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH [DESCRIPTION ROOI.RECUSHAFT Construct Receiving Shaft  Type  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT. RECUSHAFT.ALUMSHORE Shoring using Aluminum Hydraulic Shoring  UNIT  P/C CLASS  TVPE  UNIT  Operation  Type  Class Reference  Resource  Earthnoving equipment ROOT.Excavators.CAT-325  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Bucket Capacity And Eq l . B  3; -J  TVPE  Class Reference  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION R00T.RECUSHAFT.CAT-325 CAT-325 ( C a t e r p i l l a r Hydraulic Excavator)  P/C CLASS  P  P/C CLASS  Quantatitive  TVPE  UNIT  P  Quantatitive N3  N  Average Exacavation Rate And Eq 6  P  Quantatitive «3/«n  N  Haxiwun Working Radius And Eq BBBB  P  Quantatitive [414  N  Length of wheel base And Eq 436B  P  Quantatitive m  N  Width of wheel base And EQ 2999  P  Quantatitive m  Type  Class Reference  Method  Excavation Support Techniques ROOT.Alun-Shore  Of 14  Page 5 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N Maximum allowable surcharge load And 01 N  METHOD, RESOURCE BREAKDOWN STRUCTURE N8RBS PATH DESCRIPTION ROOT.RECUSHAFT.ALUMSHORE.SHORESETS Modular Aluminium Hydraulic Shore Sets  Max load on hydraulic cylinder (2 inch) And 0) IBB  C Technical  Quantatitive lb  Resource  Foundation Engg & s o i l compaction equipment ROOT.SupportSys.AlumUaler  Max load on hydraulic cylinder And 0] IBB  Type  Class Reference  Resource  Labor  UNIT  Quantatitive Quantatitive l b  Class Reference  N  TVPE  P C Technical  Type  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Maximum allowable surcharge load And EQ 2BBBB  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.RECUSHAFT.ALUMSHORE.SHORELABOR Labour for i n s t a l l i n g shoring  P/C CLASS  P/C CLASS  TVPE  UNIT  C  Technical  Quantatitive l b  C  Technical  Quantatitive lb  ROOT.SHORELABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.RECUSHAFT.DEUATER Dewatering of the Receiving Shaft  Type  Class Reference  Method  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  UNIT  Quantatitive  P/C CLASS  C  Technical  ON  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH I DESCRIPTION ROOT.RECUSHAFT.DEUATER.SELF-PRIME | Self priming Pump  TVPE  Type  Class Reference  Resource  General-use equipment used in construction process  TVPE  UNIT  Quantatitive Quantatitive in  OF 14  Page 6 |ROOI.PuNps.Self-prine PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Pumping Rate And EQ 2.Z7  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.RECUSHAFT.DEWATER.PUMPOPEB PUMP Operator  Type  Class Reference  Resource  Labor  P/C CLASS  TVPE  UNIT  Quantatitive n3/nn  ROOT.PUNPOPEH PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2  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  P/C CLASS  TVPE  UNIT  P  Type  Class Reference  Method  S o i l florrou MT Methods (NonSteerable) ROOT.IMMDCASING  And N  N  N  M5  UNIT  Operation  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate N F e a s i b i l i t y of use - S o i l Type And EQ Cohesive running  ON  TVPE  Class Reference  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION MSRBS PATH ROOT. PI P EI NSTfiL. MI CROTUNEL Microtunnelling  P/C CLASS  EQ  P/C CLASS  Quantatitive  TVPE  UNIT  P C Technical  Quantatitive Linguistic  C Technical  Quantatitive I  C Technical  Quantatitive m  Bouldery  N value of s o i l And WR 5 5B Maximum allowable s i z e of s o i l grains And EQ 5B  Suitable i n condns with large inclusions C Technical And EQ False  Roolean  Of 14  Page 7 METHOD, RESOURCE BREAKDOWN STRUCTURE IISflBS PATH DESCRIPTION ROOT.PIPEINSTAL.MICROTUNEL.UNCLEMOLE Iseki Uncle Mole  Type  Class Reference  Resource  Specialized equipment for c i v i l engineering uork ROOT.Tunnelling.UNCLE MOLE  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate N Maximum Grain Size/Diameter of Shield N Avg Production Rate for S o i l s with Sands And EQ 8.33  TYPE  UNIT  P P P  Quantatitive Quantatitive mm Quantatitive mm/mn  N  Avg Production Rate i n Clays And EQ 65  P  Quantatitive nm/mn  N  Avg Production Rate in S o i l s u i t h Gravel And EQ 1Z5  P  Quantatitive mm/mn  N  Avg Production Rate u i t h Crushed Rock And Eq 25  P  Quantatitive mm/mn  N  Nominal Pipe Inside Diameter And UR 256 580 Suitable for ground uater And EQ True  P  Quantatitive mm  P  Boolean  N  Y  F e a s i b i l i t y of use - S o i l Type And EQ Cohesive running And  Y  Y  Y  METHOD, HESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.PIPEINSTAL.HICROTUNa.MOLE-OPER Mole Operator  P/C CLASS  EQ  Linguistic C  Technical  Bouldery  N value of s o i l And UR 5 58 Maximum allowable size of s o i l grains And EQ 58  Quantatitive I C  Technical  C Technical  Suitable in condns u i t h large inclusions C Technical And EQ False  Type  Class Reference  Resource  Labor  Quantatitive mm  Roolean  R00T.MOLE-OPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z  <= METHOD, HESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.PIPEINSTAL.PIPEJACK Pipe jacking  Type  Class Reference  Method  Pipelaying methods ROOT.PipeJackin  P/C CLASS  TYPE  UNIT  Of 14  Page 8  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 N 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  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.PIPEINSTAL.PIPEJACK.JACKINGRIG Jacking Rig  Suitable i n condns with large inclusions C Technical And EQ False  Type  Class Reference  Resource  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  N  N  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.PIPEINSTAL.PIPEJACK.JRIGOPER Jacking Rig Operator  Type Resource  Nominal Inside Pipe Diameter And UR 25B 56B Average Jacking Speed And EQ 4.2 Suitable for ground water And EQ True  P/C CLASS  TVPE  UNIT  Quantatitive Quantatitive I  Quantatitive i  Boolean  TVPE  UNIT  P  Quantatitive m  P  Quantatitive m  P  Quantatitive mm  P  Boolean  Class Reference Labor ROOI.JRIGOPER  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2  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  P/C CLASS  TVPE  UNIT  P/C CLASS  TVPE  UNIT  Class Reference  Operation PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  P  Quantatitive  Of 14  Page 9  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION M&RBS PATH Using a water test for testing the pipe ROOT.TESTPIPE.UATERTEST  Class Reference Pipe Testing Methods ROOT.WATER-TEST PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION Punp to Maintain uater pressure ROOT.TESTPIPE.WATERTEST.PUMP  P  TYPE  UNIT  Quantatitive  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  METHOD, RESOURCE BREAKDOWN STRUCTURE H8RBS PATH DESCRIPTION ROOT.TESTPIPE.WATERTEST.PUMPOPER Pump Operator  P/C CLASS  Type  Class Reference  Resource  Labor  P/C CLASS  P  TVPE  UNIT  Quantatitive «3/nn  ROOT.PUMPOPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z  METHOD, RESOURCE BREAKDOWN STRUCTURE |DESCRIPTION MSRBS PATH ROOT.BACKJACK Restore the Jacking Shaft  Type  TVPE  UNIT  P/C CLASS  TVPE  UNIT  Class Reference  Operation PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION M8RRS PATH Renove Shoring ROOT.BACKJACK.REKSHORE  P/C CLASS  P  Quantatitive  Class Reference Excavation Support Techniques ROOT.RenAlShore PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  P/C CLASS  P  TVPE  Quantatitive  UNIT  Of 14  Page IB  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION MSRBS PATH ROOT.RACKJACK.REMSHORE.SHORELABOR Labor for installing/removing shoring  Type Resource  Class Reference Labor ROOT.SHORELABOR  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.BACKJACK.BACKFILL B a c k f i l l the Jacking Shaft  UNIT  Quantatitive  E a r t h - f i l l construction techniques ROOT. BACKFILL  Type  Class Reference  Resource  Earthnoving equipment ROOT.Backhoe.CAT-416B  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Bucket Capacity And Eq B.76  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.BACKJACK.BACKFILL.LOADEROPER Rack-hoe Loader Operator  P  TVPE  Class Reference  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.BACKJACK.BACKFILL.BACKLOADER Back-hoe Loader  P/C CLASS  P/C CLASS  P  P/C CLASS  P  TVPE  UNIT  Quantatitive  TVPE  UNIT  Quantatitive n3  Class Reference Labor ROOT.LOADEROPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.RACKJACK.BACKFILL.PCOMPACTOH Hand-held Plate compactor  P/C CLASS  P  Class Reference Foundation Engg S s o i l compaction equipment ROOT.HandComp.PCompactor  TVPE  Quantatitive  UNIT  Of 14  Page 11 PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Compaction Rate And EH 5  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.BACKJACK.BACKFILL.COMPOPER Conpactor operator  Type  Class Reference  Resource  Labor  P/C CLASS  P  TVPE  UNIT  Quantatitive n2  R00T.C0M0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RRS PATH DESCRIPTION ROOT.BACKJACK.RESTPAU Restore the Pavewent  Type  Class Reference  Method  Pavewent Construction Techniques ROOT.PATCHING  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.BACKJACK.RESTPAU.LABOR Labor for spreading and l e v e l l i n g asphalt  Type  Class Reference  Resource  Labor  P/C CLASS  TVPE  UNIT  Quantatitive  P/C CLASS  P  TVPE  UNIT  Quantatitive  ROOT.LABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.BACKJACK.RESTPAU.DCOMPACTOR Hand-held Dual Drun Compactor  P/C CLASS  Type  Class Reference  Resource  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  TVPE  UNIT  Quantatitive « Z  Of 14  Page 12 METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.BACKJACK.RESTPAU.CONPOPER Compactor operator  Type  Class Reference  Resource  Labor R00T.C0M0PER  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH |DESCRIPTION ROOT.BACKRECU Restore the Receiving Shaft  Type  P  TVPE  UNIT  Quantatitive  Class Reference  Operation PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Y Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.BACKRECU.REMSHORE Remove The Shoring  P/C CLASS  P  TVPE  UNIT  Quantatitive  Class Reference Excavation Support Techniques ROOT.RemAlShore PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 V Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE MSRBS PATH DESCRIPTION ROOT.BACKRECU.REMSHORE.SHORELABOR Labor for installing/removing shoring  P/C CLASS  Type  Class Reference  Resource  Labor  P/C CLASS  P  TVPE  UNIT  Quantatitive  ROOT.SHORELABOR PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION MSRBS PATH ROOT.BACKRECU.BACKFILL B a c k f i l l the Jacking Shaft  P/C CLASS  P  TVPE  UNIT  Quantatitive  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  Quantatitive  UNIT  Of 14  Page 14 PARflflETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 Y Achievable Production Rate  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION N8RBS PATH ROOT JACKRECU. RESTPAU. LABOR Labor for spreading and l e v e l l i n g asphalt  Type  Class Reference  Resource  Labor ROOT.LABOR  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.BACKRECU.RESTPAU.DCOMPACTOR Hand-held Dual Drum Compactor  P  P/C CLASS  Class Reference  Resource  Foundation Engg 8 s o i l compaction equipment ROOT.HandComp.DCompactor  Type  Class Reference  Resource  Labor  TVPE  UNIT  Quantatitive  TVPE  UNIT  Quantatitive  Type  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Compaction Rate And EQ 5  METHOD, RESOURCE RREAKDOWN STRUCTURE DESCRIPTION M8RBS PATH ROOT.BACKRECU.RESTPAU.COMPOPER Compactor operator  P/C CLASS  P/C CLASS  P  TYPE  UNIT  Quantatitive m2  R00T.COM0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  ON  P/C CLASS  TYPE  Quantatitive  UNIT  Of 14  Page 13 METHOD, RESOUBCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION Back-hoe Loader ROOT.RACKRECV.RACKFILL.BACKLOADER  Type  Class Reference  Resource  Earthmoving equipment R00T.flackhoe.CAT-416R  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Ducket Capacity And EQ 8.76  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.BACKRECU.BftCKFILL.LOADEROPER Back-hoe loader operator  Type  Class Reference  Resource  Labor  P/C CLASS  P  TYPE  UNIT  Quantatitive M3  ROOT.LOADEROPER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE M&RBS PATH DESCRIPTION ROOT.BACKRECU.RACKFILL.PCOMPACTOR Hand-held Plate Compactor  Class Reference  Resource  Foundation Engg & s o i l compaction equipment ROOT.HandComp.PCompactor  Type  Class Reference  Resource  Labor  TVPE  UNIT  Quantatitive  Type  PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE Z N Average Compaction Rate And EQ 5  METHOD, RESOURCE BREAKDOWN STRUCTURE M8RBS PATH DESCRIPTION ROOT.BACKRECU.BftCKFILL.COMPOPER Compactor operator  P/C CLASS  P/C CLASS  P  TVPE  UNIT  Quantatitive mZ  R00T.C0M0PER PARAMETERS INHERITED DESCRIPTION COND UALUE 1 UALUE 2 N Average Productivity  METHOD, RESOURCE BREAKDOWN STRUCTURE DESCRIPTION M&RBS PATH Restore Pavement ROOT.RACKRECU.RESTPAU  Type  Class Reference  Method  Pavement Construction Techniques ROOT.PATCHING  P/C CLASS  TVPE  Quantatitive  UNIT  Of 14  

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