<%BANNER%>

Extended Production Integration for Construction (Epic): An Integration System for Building Construction


PAGE 1

EXTENDED PRODUCTION INTEGRATION FOR CONSTRUCTION (EPIC): AN INTEGRATION SYSTEM FOR BUILDING CONSTRUCTION By HUANQING LU A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Huanqing Lu

PAGE 3

To Hui

PAGE 4

iv ACKNOWLEDGMENTS I would like to thank my committee chair, Dr. R. Raymond Issa, for his valuable guidance and support. I greatly appreciate his meticulously going through the entire manuscript for me. Dr. Dennis Fukai provided valuable input in defining th e research topic and direction. I appreciate his support and motivation. Dr. Ian Flood provided insightful suggestions concerning methodology and theoretical issues. The recommendations of Dr. Robert Cox were very helpful in designing scenarios and case st udies. I am also grateful to Dr. Randy Chow, who offered me considerable advice and direction on technical solutions for the research proposal. I enjoyed working in his research group. I would like to thank Dr. William OBrien for his help with the researc h method and his valuable suggestions regarding the case study. I give special thanks to Jarkko Leinonen and others of VTT Building Technology, Finland, who gave me the inspiration to start this research.

PAGE 5

v TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................ ................................ ................................ .. iv LIST OF TABLES ................................ ................................ ................................ ............. viii LIST OF FIGURES ................................ ................................ ................................ ............. x ABSTRACT ................................ ................................ ................................ ....................... xii CHAPTER 1 INTRODUCTION ................................ ................................ ................................ ............ 1 Construction Industry and Information Technology ................................ ....................... 1 Surging Needs for an Integrated Computer System for Buildi ng Construction ............. 5 Introduction to the Research ................................ ................................ ........................... 8 2 LITERATURE REVIEW AND PROBLEM STATEMENT ................................ ......... 10 Key Terms ................................ ................................ ................................ ..................... 10 Early Works and the Establishmen t of Information Standards ................................ ..... 13 Implementations Based on IFC ................................ ................................ ..................... 18 Trial Implementation of IFC and System Architecture from CIFE .......................... 18 Other IFC Based Prototypes: ToCEE, ProMICE and VEGA ................................ .. 19 Alternative Methods ................................ ................................ ................................ ...... 23 Implementation of Building Project Model (BPM) ................................ .................. 23 Cross Sector Business Model for Interoperability ................................ .................... 24 T he COMMIT Project ................................ ................................ ............................... 24 Robust Mediation of Construction Supply Chain Information ................................ 24 Industry Efforts: Project Collaboration Networks (PCNs) ................................ ........... 25 Analysis and Discussions ................................ ................................ .............................. 27 Research Objectives and Methodology ................................ ................................ ......... 30 3 EPIC MODEL ................................ ................................ ................................ ................. 34 Analyze Construction Projects ................................ ................................ ...................... 34 Define the EPIC Model ................................ ................................ ................................ 36 Needs of Collaboration Support on Construction Projects ................................ ........... 40 Fitting the EPIC Model into the Existing Model World ................................ ............... 42

PAGE 6

vi Uniqueness and Value of the EPIC Model ................................ ................................ ... 44 Relations hips and Interactions between Participants ................................ .................... 47 Introduce Contract Conditions into the EPIC System ................................ .................. 49 From Events to Procedures ................................ ................................ ........................... 52 4 SYSTEM ARCHITECTURE AND IMPLEMENTATIO N ................................ ........... 54 Unified Modeling Language and Software Development ................................ ............ 54 Implementation of the EPIC Model ................................ ................................ .............. 56 Comparisons of System Implementations from Previous Studies ............................ 56 System Architecture ................................ ................................ ................................ .. 57 Transaction based Implementation ................................ ................................ ........... 60 Transaction Models and Transaction Design ................................ ................................ 61 Transaction Basics ................................ ................................ ................................ .... 61 Comparison of Transaction Models ................................ ................................ .......... 63 Efforts to Combine Different Transaction Models ................................ ................... 64 Transaction Design ................................ ................................ ................................ ... 67 Specification Language for Customized Transactions ................................ ............. 69 Prototype and Programming ................................ ................................ ......................... 72 Structure of the Prototype ................................ ................................ ......................... 72 Deployment Diagram ................................ ................................ ................................ 74 Definition of Transactions ................................ ................................ ........................ 74 Ex ecution of the Transactions ................................ ................................ ................... 76 Interactions among the Actors ................................ ................................ .................. 78 Outstanding Issues and Future Works ................................ ................................ .......... 79 5 CASE STUDY AND TESTING ................................ ................................ ..................... 81 Review o f Test Methods from Previous Studies ................................ ........................... 81 Test Plan ................................ ................................ ................................ ........................ 82 Proof of Concepts ................................ ................................ ................................ .......... 83 Demonstration of Functionality: A Case Study ................................ ............................ 83 Background ................................ ................................ ................................ ............... 84 Assumptions ................................ ................................ ................................ .............. 84 Simulation ................................ ................................ ................................ ................. 86 Sensitivity Analysis of the Performance Variables ................................ .................. 89 Conclusions ................................ ................................ ................................ ............... 96 Tests for Technic al Issues ................................ ................................ ............................. 96 Assumptions ................................ ................................ ................................ .............. 96 Design of Activity Flow ................................ ................................ ............................ 97 Results and Analysis ................................ ................................ ............................... 100 6 CONCLUSION AND RECOMMENDATIONS ................................ ......................... 104

PAGE 7

vii APPENDIX A ANALYSIS OF AIA A201 ................................ ................................ .......................... 106 B SAMPLE OUTPUT FROM SIMULATION PROGRAM ................................ .......... 113 REFERENCES ................................ ................................ ................................ ................ 118 BIOGRAPHICAL SKETCH ................................ ................................ ........................... 125

PAGE 8

viii LIST OF TABLES Table page 2 1 Major components of the VEGA platform ................................ ................................ 22 2 2 Research and industry efforts of integration systems ................................ ................ 28 2 3 Methods of va lidation ................................ ................................ ................................ 32 3 1 Basic elements of construction projects ................................ ................................ .... 35 3 2 Comparisons of models for integration ................................ ................................ ..... 45 3 3 Procedures and notices found in AIA A201 ................................ .............................. 51 4 1 Views and diagrams in UML ................................ ................................ ..................... 55 4 2 Implementations of integration models ................................ ................................ ..... 56 4 3 Comparison of transaction models ................................ ................................ ............ 64 4 4 List of valid databas e operations ................................ ................................ ............... 70 4 5 Code and content for steps ................................ ................................ ......................... 70 5 1 Comparison between test methods ................................ ................................ ............ 82 5 2 Steps in the change order procedure ................................ ................................ .......... 88 5 3 Combination of individual rejection rates ................................ ................................ 92 5 4 Ranges of execution times of individual steps ................................ .......................... 93 5 5 Average execution times of Procedure A and Procedure B ................................ ...... 94 5 6 Collection of activities ................................ ................................ ............................... 98 5 7 Valid activities for different actors and test schedule ................................ ................ 99 5 8 Execution times of system events ................................ ................................ .............. 99

PAGE 9

ix 5 9 Average execution tim es of special activities ................................ .......................... 100 5 10 Occurrences and average size of reviews ................................ .............................. 102

PAGE 10

x LIST OF FIGURES Figure page 1 1 Islands of information ................................ ................................ ................................ .. 4 2 1 Relationships between different models for construction projects ............................ 11 2 2 The ToCEE system a rchitecture ................................ ................................ ................ 20 2 3 Design research methodology ................................ ................................ .................... 31 3 1 Interactions between the basic elements ................................ ................................ .... 36 3 2 The EPIC project model ................................ ................................ ............................ 39 3 3 T he EPIC model in the existing model world ................................ ........................... 43 3 4 Analysis of the Contract Conditions ................................ ................................ .......... 50 3 5 The causes of system processes ................................ ................................ ................. 53 4 1 Sample UML diagram: a class diagr am ................................ ................................ .... 55 4 2 Multi layered structure of the EPIC system ................................ .............................. 58 4 3 Road map for the study of transaction models ................................ .......................... 63 4 4 Transaction structure of a multitransaction ................................ ............................... 65 4 5 Sample business procedure: the architect proposes a change ................................ .... 71 4 6 Class reference diagram of the EPIC system ................................ ............................. 73 4 7 Deployment diagram of the EPIC System ................................ ................................ 74 4 8 From predefined procedures to system transaction ................................ ................... 75 4 9 Execution of a prepared transaction ................................ ................................ .......... 76 4 10 System view and user view ................................ ................................ ..................... 77 4 11 Collaborations between actors ................................ ................................ ................. 78

PAGE 11

xi 5 1 Catch 22 that troubles the progress of integration systems ................................ ... 82 5 2 Formulation of a change order ................................ ................................ ................... 86 5 3 Variations in the cha nge order procedure ................................ ................................ .. 90 5 4 Comparison of the average execution time for Procedure A and B .......................... 95 5 5 Changes in the average execution time by procedure types ................................ .... 101 5 6 O ccurrences of review sessions ................................ ................................ ............... 102

PAGE 12

xii Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy EXTENDED PRODUCTION INTEGRATION FOR CONSTRUCTION (EPIC): AN INTEGRA TION SYSTEM FOR BUILDING CONSTRUCTION By Huanqing Lu December 2002 Chairman: R. Raymond Issa Co Chair: Ian Flood Major Department: Design, Construction and Planning The primary goal of this product integration study was to facilitate collaboration an d data exchange among participants on construction projects. The implementations that are based on information standards have often adopted closely coupled collaborations. The project participants collaborate at a higher detail level and with fine granula rity. However the diversified construction industry consists of businesses that vary in size and ability of adapting information technology. It is difficult to take a top down method and require participants to conform universally accepted standards for th e details of their operation. The Extended Production Integration for Construction (EPIC) is a loosely coupled integration system with the support of a viable collaboration mechanism. We examined the basic elements of construction projects and the typical relationship between project participants and their proper representation in a computer system. A conceptual model for

PAGE 13

xiii construction project was proposed based on the study of events, contract conditions and their impacts on the collaborations and interact ions among participants. Basic components of the model include actor, roles, processes, and information objects. Events were identified as the major issue that the system needs to consider in order to conduct the collaboration work. An attempt was made to convert contract conditions into enforceable rules in a computer system. A prototype system based on the proposed model was developed with Java, CORBA and UML. A case study of making change orders was used to demonstrate the functionality of the EPIC syste m. The factors that have impacts of the efficiency of the system were studied through sensitivity analysis. A comprehensive simulation with scenarios was designed to discover any potential problems in the technical solutions specifically designed for the s ystem.

PAGE 14

1 CHAPTER 1 INTRODUCTION This chapter explains the motivations, historical perspectives and the backgrounds for this research. The needs for an integrated computer application system for construction are analyzed in conjunction with the relationship between the uniq ue nature of the construction industry and the computer applications in the industry. Construction Industry and Information Technology It is a well accepted trait of the traditional construction industry that it is very fragment ed Because of the magnitu de and complexity of construction projects, they are often divide d into work packages according to well established specialization. Work packages are assigned to participants in different domains either within the same organization or from another organiza tion through the practice of subcontracting. Although specialization brings significant benefits to the industry, it also brings difficulties in communication and collaboration among participants in construction projects. The fragment ed nature of the cons truction industry creates a challenge for the applications of information technology in the construction industry. Software packages used by different parties are often independent from each other and have tremendous difficulties in exchanging information. Although commercial software packages are widely available for each domain, no mature solution exists to handle the task of integrating the software system across domains. C ommunication among independent systems is limited and sometimes frustrating at bes t. Paper based media, such as

PAGE 15

2 drawings and specifications, are still heavily relied on in many cases as a conventional way to convey information and ideas among domains of construction projects. Confusion and delays often occur because of their abstract na ture and because of constant reinterpretations by project participants. What make s things worse is that the construction industry has long been considered slow in its acceptance of new technolog ies [BRA97] in comparison to the manufacturing industry. Innov ations to the current system often face enormous hurdles to becoming successful. The applications of information technology in the construction industry are also defined by the one of a kind nature of many aspects of the construction product. A constructi on project often has unique products: the buildings designed specifically for the project. From time to time new processes must be devised to suit a unique design. Mass production is not as common as it is in the manufacturing industry. Most construction a ctivities must be carried out onsite. Unique project teams and organizations are established for each construction project through temporary arrangement and dissolve after the completion of the project. It is often difficult to make the project team run se amlessly. Because of its fragmentation and one of a kind nature the construction industry faces different challenges than the manufacturing industry does. Two types of solutions from two perspectives were pursued. From the perspective of construction ma nagement and engineering. Unique solutions are eliminated with standardizing the construction process, process reengineering, minimizing onsite product using prefabrication, and using new forms of project organization that advocate partnership rather than adversaries. From the perspective of the information technology. Proven techniques from manufacturing and other industries are adopted such as product modeling, process modeling, integration research, workflow management and concurrent engineering.

PAGE 16

3 The con cept of Computer Integrated Construction (CIC) comes from the perspective of information technology and is defined as a business process that links the project participants in a facility project into a collaborative team through all phases of a project [TEI94]. The process defined covers the entire duration of the project from client briefing, design, construction, and facility management. The purpose of CIC is to facilitate information exchanges and collaborative efforts among project participants, or m ore accurately the different computer systems used by the project participants. The objectives of CIC include, rapid production of high quality design, fast and cost effective construction of the facility; and effective facility management. Figure 1 1 is an interesting analogy that shows the development of information technology in the construction industry. Computer applications in different engineering domains are illustrated as Islands of Information in order to demonstrate the fragmented situation of the system. The natural barriers limit transportation between the islands as the independent status of the computer systems blocks communication among computer applications. Contour lines represent changes over time and the coastline is the frontiers of present research efforts. The dropping water level and bridges being built between islands represents the development of new infrastructures and applications to enable the communication among computer applications. The coastline of 2010 shows the goal that the researchers and the industry are trying to achieve in the near future. Eventually a unified continent will come into being, which means an ultimate integration system for the construction industry. The ideal system will have a combination of bot h current technologies and those currently under development.

PAGE 17

4 Figure 1 1. Islands of information, Matti Hannus, VTT (the Technical Research Center of Finland building technology), http://cic.vtt.fi/hannus/islands.html, 2002 Figu re 1 1 gave a historical view of computer applications in the construction industry. The very first computer application in this domain was the structural analysis (Finite Element Method) application. Sophisticated structural analysis theories and algorith ms were developed long before the dawn of the computer era but many of them could not be implemented without powerful and affordable computer facilities. The computerization of accounting systems in the 1960s was the first full scale involvement of compute r applications in business management. The development of computer hardware in the 1980s boosted graphic processing capability. Computer Aided Design (CAD) became popular in architectural and engineering design with Autocad as a successful example. However CAD in its early days was more like Computer Aided

PAGE 18

5 Drawing in most cases rather than Computer Aided Design. Software that produces geometric drawings without a proper model cannot exchange information efficiently with other software packages, such as structural analysis packages. Estimating software, which is closely related to accounting systems, has become one of the common computer applications for the construction industry. The CPM method was also computerized and became the backbone of major cons truction planning software. Almost all of these computer applications and systems share similar limits and frustrations in information exchange. The landscape of the construction industry was permanently changed in the 1990s by the accelerating developm ent of the computer technology. CAD evolved from 2D drawings to 3D modeling and visualization and Virtual Reality. It was realized that the lack of integration between computer applications could become a major obstacle to any further development. Differen t kinds of integration solutions were proposed and tested to build a viable integrated computer system for the construction industry. The current active areas related to CIC include the following, Developing standards for data exchange, such as STEP, IFC, AECXML, etc. Process modeling and optimization for construction. 3D modeling and visualizations. Developing web based project collaboration: touted as an all in one integration solution. Surging Needs for an Integrated Computer System for Building Construction The construction industry has long been considered as reluctant in adopting new technology. The construction industry has viewed innovation with suspicions or attempted to protect new thinking by protectionism [BRA97]. While the productivity and

PAGE 19

6 product quality was improved in the manufacturing industries by leaning production and applying worldwide manufacturing benchmarking studies of production standards, the construction industry remained low profile. Although the history of computer aide d project management can be traced back to a few decades ago, the actual development process was not able to go straight as expected. Changes in the construction industry and advances in new computer technology have sparkled refreshed needs and have rekind led the pursuance of integrated systems in the past decade. The general style of construction project management is changing along with the evolving of project organization. New forms of project organization were introduced to achieve higher level of con currency and optimization at the project level. Because of these the management style of the new methods is often more integrated and centralized when compared to the traditional way [CLO00]. An opportunity appears in this circumstance for the development of an integrated computer system for construction projects. The basic method for project organization or project delivery systems is often referred as the traditional method. The client, architect, and contractor are three independent parties bonded by c ontractual or administrative relations. The project is executed sequentially (design, bid, construction). Construction Management (CM), Design Build, and BOT are examples of the new forms of project organization that emerged in the recent decades and there fore are also called alternative methods. Although the traditional method is currently still the primary method for project organization, the alternative methods are challenging its domination.

PAGE 20

7 When compared to the traditional method, the management st yle of alternative methods are more centralized and requires intensive cooperation between the participants in the project. The CM method introduced a new role to the three major parties in the project organization as in the traditional method. A construct ion manager is often appointed at the beginning of the project and become the head of the project management team at construction stage. In the Design Build method the client employs a single party for the responsibilities of both design and construction. The design builder, which is in place of the architect and the contractor as in traditional method, has control over the project for the entire duration of the project. The BOT (build operate transfer) method is an even more centralized form of project org anization than the CM and Design Build methods. The financing, operation, and limited time ownership appears in the job list of the builder/developer. Traditionally the relationships in a construction project were adversary in natural rather than collabor ation. The alternative methods call for closer associations between different sections and stages of a construction project. As a result a platform in the industry is provided for the implementation of an integrated computer system for construction projec ts. The availability of new information technology is another factor that contributes to the advances of integrated computer system for construction project. The volume of information involved in a large scale construction project can be enormous and hard to manage without the support of a proper computer system. Key technology issues that have a critical impact on the advances of integration research for building construction include:

PAGE 21

8 The computational capability of the computer: 3D graphic and database applications need higher computational processing capability. Availability of low cost hardware: Decreases in hardware price make possible the extensive usage of computing facility at different levels of the construction industry. Advanced database applica tions: Organized information provides efficiency and increases productivity. The Internet and computer network: Provide infrastructure for the development of integrated computer application for building construction. Business Modeling and B2B application s: Provide support and methodology for general business management. The methods of choice for the professionals that are working on the integration issues have been expanded along with the flourishing of information technology. The chances are better tha n ever for making possible a viable integrated computer system for construction projects. Introduction to the Research Various methods have been proposed in search for a solution to the integration dilemma. Since late 1980s the most prolific results o f the research projects in this area have been the computer models for construction projects. Different perspectives were adapted for the models from either the product data or the process view of the construction project. Some of the research projects wen t a step further to build prototypes for the implementation of the proposed models while the others stayed at the conceptual level discussing the general issues related to the subject. Information standards have been initiated and widely accepted by the so ftware developers. The recent developments are tremendous industry effort to bring online project collaboration into reality with existing technology.

PAGE 22

9 However, the gap between academic research and industry applications still exists despite of the efforts from both sides. The current models for construction project provide static descriptions of the project but provide little support for the dynamic features required by real world systems. The interactions between process model and product model have been a ddressed but no sufficient solution has been provided. The establishment of an integration system should have built in flexibility so that existing software applications can easily become a member of it. This study addressed these issues by providing a n ew construction project model with the dynamic features in mind. System architecture and trial implementation was provided as a solution that includes the results of the current academic research while accommodating the existing condition of the industry. A prototype was built to demonstrate the operations of the system. A comprehensive test plan was design to validate the proposed model and demonstrate the functionality of the implementation system.

PAGE 23

10 CHAPTER 2 LITERATURE REVIEW AND PROBLEM STATEMENT This chapter presents a comprehensive review of the integration studies for the construction industry and states the research objectives and the methodology. Various solutions to the integration problem have been p roposed in the past decade through various research projects. Recent developments also include the flourishing of online project collaboration. However a perfect solution is yet to be found. This study proposes the modeling of a specific component to compl ement the existing model world for building construction. Key Terms Some terms that are essential to the correct understanding of the subject need to be defined before getting into any detail about the previous studies. Basic concepts in this area are cha nging from time to time. The following are some definitions agreed upon by the previous works. Figure 2 1 shows relationships between different types of models for construction project. Integration research. Integration research is a general concept that covers any effort that facilitates collaborations between the participants on construction projects through the use of information technology. Typical works include, establishment of an information standard, building models for the construction project, an d integrations between computer applications across domains to increase productivity and quality of the construction project.

PAGE 24

11 Data model. A data model is a generic concept from the domain of computer science. The data model specifies the basic data stru cture for the relationships and constraints of the information stored in an information system including integration systems for building construction [FRO92]. The data model provides low level support to any information system and in many cases it is not the point of interest for integration research. Figure 2 1. Relationships between different models for construction projects Conceptual model and application model. Conceptual models specify the categories of informati on used in a specific domain or database, such as construction industry [BJO92]. Reference models and Type models as explained below are two types of conceptual models. The conceptual model is a higher level concept as compared to the application model and the data model. Application models contain details in a specific domain and are often adopted in a certain computer applications. Reference model and type model. Reference models, also known as core models, are designed to be high level models that prov ide a unifying reference for more detailed application models that will be constructed on top of them. [FRO96]. The details are referred to Type models, which are more specific and describe the Conceptual Models Decided by the Levels of Details A pplication Models Reference Models Type Models Data Models increasing detail levels Decided by the Subjects of Modeling Project Models Product Models Product Models

PAGE 25

12 information structure for a restricted type or family of o bjects, such as a road model for highways [LUI93]. This pair of terms was mentioned extensively during the early days of the development of computer models for construction projects and it is not referenced as often any more. Information standards. Inform ation standards are results of collective research efforts that intend to standardize the data exchange and representation for the construction industry. Notable information standards include STEP, IFC, aecXML, and so on. Many integration systems are built upon prototypes and trial implementations of the information standards. Process model and product model. This is a pair of concepts that describes the same physical world from another dimension as shown in Figure 2 2. A process model consists of inform ation (process data) describing the production activities (design, planning, and production), structured by processes; operations, and paths [ANU98]. Process models form the basis for reasoning about and modification of existing processes, which lead to t he concept of process reengineering. The product model provides a formal method of describing a certain type of product and many elements associated with it. For the construction industry the product refers to the building and various types of structures. The product model in the construction industry is often associated with information standards such as IFC. Product model and process model are generic terms applied to business modeling as well as modeling for construction projects. Interactions between th e product model and the process model are critical aspects of the descriptions of a complete business model.

PAGE 26

13 Project model. Project model is a general term that provides a comprehensive description that covers various aspects of construction projects, suc h as, the building to be built, participants of the project, construction activities, cost and available resources, and project documents. A proper project model should include the elements of both the product model and the process model. Chapter 3 has det ailed information on the subject. Concurrent Engineering (CE). Concurrent engineering is defined as a systematic approach to the integrated, concurrent design of products and their related processes, including manufacturing and support [TUR97]. The orig inal idea was to interleave the processes of design and construction in order to take advantage of parallelism and concurrency. Concurrency is achieved from parallel work group and parallel production decomposition, concurrent resource scheduling, and con current processing [ANU00]. However it is difficult to implement the concept without proper support of computer systems. The benefits of concurrent engineering also include considerations of total project life cycle and better communication and information exchange across the domains and stages of a construction project. Concurrent engineering has been used as a motivation for the development of integration systems. Early Works and the Establishment of Information Standards Integration research started fro m the modeling efforts for construction projects. Early studies started from the graphic modeling for the building and were often referred to as CAD integration. It was soon realized that a common model is needed for construction projects rather than indiv idual models in different computer applications and domains [LUI93]. The model should cover technical domains such as design, estimating and cost analysis, and construction scheduling.

PAGE 27

14 The General Construction Object Model (GenCOM) [FRO92] is an early wor k that intended to build a standardized object oriented model for construction projects. Software models for construction project were defined in three levels, a data model, a domain model and a project model following the order from the conceptual model t o the applications. Four categories of classes were defined for product, process, resource, and organization. A prototype called OPIS was built to proof the concepts of the GenCOM model. The unified approach model [BJO92] was proposed as a generic const ruction process information model or framework. An object oriented conceptual model was used as well to structure information from different domains and to provide a framework to explain the relationships between building classification systems and product models. The scope of the model covers different viewpoints in a construction project from facts, constraints to knowledge. Each one of the viewpoints was analyzed using the method of software engineering. The Information Reference Model for Architecture, Engineering, and Construction (IRMA) [LUI93] is a combination of the better features of three conceptual models, the unified approach model, GenCOM, and the Building Project Model (BPM). IRMA is a framework for data standards that can be used as the core of a conceptual model for a construction project, or a basis for the implementation of specific computer application for construction projects. Four subtypes of project objects, namely products, activities, resources, and contract are defined in the IRMA m odel. A proprietary approach that starts from the needs of a specific construction project was also attempted as a solution to the integration. Stone and Webster Engineering

PAGE 28

15 Corporation and Columbia University conducted a multidisciplinary research in the integration of computer application for construction project [REI91]. The integration system was built with two commercial software packages: a relational database (the project database) and a 3D computer aided design system. The database stores non graph ical information for the objects in the 3D design model. The hardware used for the system was workstations and high speed network connections. The primary functionality of the system includes constructibility review, construction planning, management, and progress reporting. The research objective was to investigate the procedures to improve construction productivity and document the costs and benefits associated with the use of 3D model on a construction site. Many early works focused on the debates over the proper methodology for the integration of a construction project. Principles for the modeling of construction project and related domains were presented at the conceptual level and became the basis for later research. The establishment and development of the information standards was also benefits derived from the early studies. A few information Standards (STEP, IFC, and aecXML) have been developed in the past decade to standardize the modeling and data exchange for construction projects. The enacted standards have been widely adopted by many organizations and products in their solutions for integration systems. The Standard for The Exchange of Product Model Data (STEP) (ISO 10303) [NAT02] is an early standard for the computer interpretable represent ation and exchange of product data. STEP provides a collection of standards called Application Protocols (APs) that applies to various industries including building construction. The common

PAGE 29

16 methodology behind APs is comprised of the STEP physical file form at, the EXPRESS data definition language, and shared definitions as common resources. The STEP Building Construction Core Model (BCCM), which is the part of STEP designed for construction projects, represents the principles of many models that were develop ed previously [FRO95]. In 1997 the work of STEP BCCM was merged with the efforts of Industry Foundation Classes (IFC) through a memorandum of understanding between ISO TC184/SC4 and the International Alliance for Interoperability (IAI) [IAI97]. IFC is a cross system and vendor neutral data structure developed parallel to STEP by IAI. IFC represents a data structure for a construction project model and can be used for sharing data across different domains in a construction project. The definitions of clas ses provided by IFC comprise various types of objects encounter in construction projects. A text based structure is used for storing the definitions in a data file. IFC classes contain different categories of information such as physical information about buildings, project management information and so on. Basic concepts in the IFC model include usage scenarios, process diagram, object model (class, attribute, interface, and relationships), and test cases. Usage Scenarios are written descriptions of the p rocesses that users perform and capture the decisions and information that are used during each step of the process. A process diagram is a diagrammatic representation of a usage scenario. The object model is built with the classes, their interfaces, attri butes and relationships in a composite representation. The test cases are based on the usage scenarios developed along with the IFC information

PAGE 30

17 model and allow software developers to test their applications ability to conform to the IFC Specification. IF C classes are capable of enabling interoperability among AEC software applications. IFC based objects allow computer applications to share a single project model, and then allow users to define their own views of the project objects. Applications that supp ort IFCs allow members of a project team to share project data that evolve after design, through construction, and occupation of the building. Project information can be shared in three possible ways with IFCs: Physical files that may be shared across a n etwork. Databases with a standard interface, for example, the product model server. Shared objects with software programming interfaces. The aecXML for Architecture, Engineering and Construction is a new standard that will have a potential impact on the future development of IFCs. aecXML is an XML grammar that represents construction project information and it was designed for the exchange of AEC specific business to business information [COV02]. aecXML was initially proposed by Bentley Systems in 1999 an d later become a domain of the IAI. The purpose of aecXML is to enable communications between different software systems rather than the modeling of the construction project. The aecXML established a standard way of structuring data for a construction project and for automated data processing [HAR02]. While the development of IFCs has gone to extensive details in the modeling of a construction model, aecXML seems to be an easier and sometimes more practical solution. The fate of these two standards will be even tually decided by their acceptance from the construction and software industries.

PAGE 31

18 Implementations Based on IFC Many studies have made contributions to various aspects of the integration systems. A collection of relevant studies are reviewed and compared in detail below. Trial Implementation of IFC and System Architecture from CIFE A trial implementation of IFCs was built at Stanford Universitys Center for Integrated Facility Engineering (CIFE) [FRO99a]. The objectives were to determine how well IFC serves the real world representational needs of a project as in the case of project management information such as costs, schedules, etc. A charrette style exercise was conducted in a workshop. The procedure is shown as below: Review of the current status and c ontent of the IFC models Present several project scenarios developed in advance. Form two groups according to two basic scenarios, for estimating and scheduling. Prepare paper models of their scenario (each group is to apply IFC on paper) Implement the scenarios in a computer system using the IFCs The study found that information sharing among participants on the project was difficult without IFCs because of the variety of software used and because the project management portion of IFCs generally support s the current practice of estimating and scheduling. It was also suggested that the charrette test method should be done at the early stage of the model development. A prototype for a distributed, model based, integrated information system for constructio n project and facility management was developed under similar circumstances in CIFE [FRO00]. The study presented an integrated 4D planning tool with commercial scheduling and estimating applications and a shared model based project database.

PAGE 32

19 The construct ion applications integrated in the system include customized 4D tools (3D presentation with time visualization), Primavera Project Planner, and Timberline Precision Estimating. The construction applications were used simultaneously to analyze the effects o f changes to construction schedules during the construction stage. The system provided support for sharing project information among the software packages. The project information was stored in a shared database built with a schema based on the simplified IFC 2.0 model. The distinct feature of the CIFE prototype was to support multi disciplinary interaction and decision making to the project team. A test case scenario of a schedule review meeting based on an actual construction project was used to test th e system. A change that causes some complications was discussed in a project meeting with the support of the integration system. Other features of the system include three tier reference architecture, multi modal architecture, and transaction based servic es. The application tier, middle tier and data tier were defined following the generic concept of distributed systems. To support a wide variety of data exchange modes, different types of model were enclosed in the system from file based data exchange to a pplication to application data exchange. Transaction based integration was discussed as opposed to the model based integration but it was not investigated any further. Other IFC Based Prototypes: ToCEE, ProMICE, and VEGA ToCEE (Towards a Concurrent Engi neering Environment in the Building and Engineering Structures Industry) [TUR97, KAT98, SCH98, WAS98] was part of the ESPRIT project, which is a comprehensive information technology program of the European Commission. The objective of the ToCEE project was to develop an overall

PAGE 33

20 conceptual framework and specific software tools for concurrent engineering support in construction projects. The conceptual framework represents integration of various modeling and information management aspects in a construction pr oject that covers product, process, document, regulations and legal aspect modeling. The ToCEE system provides a media for project communications with three server subsystems: an information logistic system (ILS), a product data management system (PDM), a nd a document management system (DMS). The ILS answers requests from the clients and make contact with the other two subsystems. Information chunks are passed along between the subsystems. The system also has a gateway to the web that supports common Int ernet technologies. The system architecture of ToCEE as shown in Figure 2 2 is a simplified version from the original publication [TUR97]. Figure 2 2. The ToCEE system architecture The product data management server is another critical component of the ToCEE system [KAT98]. The implementation of the product data server adopted the IFC project model and has a layered structure that enables partitioning of product data according to engineering domains and stages of the construction project. Basic ope rations are defined for the product model server to provide specific product data management functionality. The project data was stored in STEP/SDAI based repositories to achieve interoperability. The focus of this research was on the modeling and visuali zation of product data for construction projects. IFC classes were implemented in Java and constitute the core of Java Interface Document Server Product Server Information Logistics Server Persistence Storage Web and Email FEA Web Browsers Email Clients CAD Clients Internet Interface s Servers Stora ge

PAGE 34

21 the system. ProMoTe (Product Model Technology) was a 3D data browser designed for the product model server [HAN99]. Virtual reality was furth er discussed as an interface to product data via product model server [HEM99]. The product model also provided common programming interfaces such as Java Servlet, RMI, and CORBA. A XML version of the product model also was implemented [HEM00]. User applica tions can be developed in auxiliary to the product model server. One example is an end user application that was built for presenting the progress of a construction project with a 3D interface that can be configured with timeline [LEI00]. The ProMICE (Prod uct and Process Models Integration for Concurrent Engineering in Construction) project intended to develop a generic integrated product and process model for life cycle design and construction of steelwork structures [ANU98, CUT99]. The objectives of ProMI CE project was, [ANU00] Review and compare the use of product model and process model in the construction industry in UK and France. Develop a generic product and process model for design and construction based on concurrent engineering principles. Inves tigate the possible support to the generic product and process model in various software systems such as CAD and virtual reality system. The focus of the ProMICE project was the integration between the product and the product model during design stages. U niversal Modeling Language [MCK02] was used as the primary tool for modeling, use cases and other diagrams. The differences in the process during the design stage between the traditional method and the alternative methods were studied to discover concurren cies. The research results of the ProMICE project contributed to the development of international standards include STEP and IFC [ANU00].

PAGE 35

22 The VEGA (Virtual Enterprises using Groupware tools and distributed Architecture) project [ZAR97, BEE98, JUN97, STE98 ] was a visionary project that integrates business and technical processes for the Large Scale Engineering industry. The objectives of the project were to specify and demonstrate a software architecture suited for a virtual enterprise for sharing informati on between different companies. The basic philosophy of the VEGA project was to use primarily existing technical solutions as components and extend their capabilities as needed to provide a platform that will enable collaborations in a flexible distributed environment [ZAR97]. The VEGA platform is the software infrastructure established in the VEGA project. The core of the VEGA platform was a CORBA based facility that support distributed access to a STEP model. The STEP model stores product model data in the format of EXPRESS schemata. Additional supporting services included a distributed workflow system, an interoperability service and the distributed information service. Table 2 1 shows a list of the basic components of the VEGA platform. Other issues ad dressed in the study include neutral specification of information, data conversion from STEP to common data, distribution of information, control of information flow, and security of information. Table 2 1. Major components of the VEGA platform Component Functionality Technology PDM Product model for the building IFC, STEP COAST Middleware that provides product data service CORBA WFL Workflow management system for process control WfMC framework DIS Document and message management system SGML, HTML, XM L The VEGA platform offers 3 classes of integration scenarios, ideal scenario, open scenarios, semi open scenarios, and closed scenario [STE98]. In the ideal scenario the client application interacts with the VEGA platform directly via the COAST. The loc al

PAGE 36

23 storage of data is not necessary except for cache purpose. The open scenario also uses a direct interaction between the client and the VEGA platform however the format of local data is different from the common system data. The semi open scenario appli es in the case that the data format conversion is too complex or not possible. Batch wise conversion of product data is used in this scenario. In the closed scenario the data exchange between the client and the VEGA system can only be accomplished with imp orting and exporting the entire data model. Alternative Methods Many researchers have studied the integration issue independently and have built computer models for construction project from scratch. This section covers research projects that use unique m odels as well as those that address specific issues that are relevant to the integration problem. Implementation of Building Project Model (BPM) An implementation of BPM was attempted with the intention to integrate design and construction for Design Bu ild (DB) and Build Operate Transfer (BOT) projects [LUI98]. The study starts with an idea simpler than IFCs called CA Dfc (Computer Aided Design for Construction and the communication in construction projects. The generalized activities and information flow in design and construction was analyzed in details and represented with IDEF diagrams. Six types of interactions between design and construction were identified. The concept of product modeling was extended to project modeling, which comprises two abs traction mechanisms that describe relations between design and construction. Two case studies were used to test the integration concepts.

PAGE 37

24 Cross Sector Business Model for Interoperability The goal of the study was to build an AEC business model that spe cifies a framework for business relations between the project members [YUM98]. The key issue was data ownership modeling from the context of multiple project members. An initial set of business roles and relationships for a typical construction project was defined and analyzed in detail. Examples with bidding and contracting involved were used to demonstrate the concept of the system. Implementation was not sufficiently addressed. The COMMIT Project The purpose of the COMMIT project [REZ98] was to define m echanisms to improve information management and thus support decision making in collaborative projects. The work of this project was not construction specific but was carried out within the context of construction. The primary issues were related to the sy stem supports for a collaborative system, such as ownership, rights, and responsibilities of the actors, version control, schema evolution, relations between the decision and contributing factors, dependencies between information items, and the notificatio n and propagation of changes. The information model is applicable to a wide range of industries. Industry specific concepts such as actor, discipline, and activities need to be added in order to implement the model. A prototype with facilities for managing roles and activities was built and a real life scenario was used to demonstrate the functionalities of the system. Robust Mediation of Construction Supply Chain Information The study was motivated by the difficulty in obtaining data from firms in the dece ntralized AEC industry [OBR01]. A mediation and wrapping infrastructure was built to support access to and sharing of semantically heterogeneous process information in the construction supply chain. This infrastructure was able to collect and share process

PAGE 38

25 related information from legacy systems. The major challenge was to accommodate heterogeneous data from different firms. The study was an extension to the existing integration theories and complement to works in data standardization. A wrapper system that was able to extract and process schedule information from a MS Project database and a scenario of activity rescheduling was used to prove the concepts. Industry Efforts: Project Collaboration Networks (PCNs) The acceptance of information standards and intensive efforts in related research along with the dot com boom brought about the flourishing of companies that are dedicated to online collaboration services for construction projects. At the height of the dot com boom in early 2000, the number of inter net startups that intended to create online exchanges for construction projects reached 200 and over $1.1 Billion venture capital was raised [FUS02]. This section was summary based on published reviews. It is not the task of this study to compare and analy ze existing commercial products in details. Existing commercial products tried to tackle the integration issue from different perspectives and provided similar products and services in general. Project Collaboration Networks (PCN), also known as project extranets or project specific Web sites, is a specific term coined for these products and services. PCNs are generally Internet based tools for sharing project specific documents, communications, and workflow [LAI01]. A certain product often focuses on one or more essential elements of PCNs and fits in the following categories, Comprehensive Collaboration: Citadon (www.citadon.com), Constructw@re (www.constructware.com), PrimeContract.com (www.primecontract.com), ProjectTalk (www.projecttalk.com) Document management systems: Buzzsaw (www.buzzsaw.com), Cosential (www.cosential.com), Integration (www.integration.arup.com), PlanDesk (www.plandesk.com),

PAGE 39

26 Project related messaging and workflow: eBuilder (www.ebuilder.net), ProjectEdge, (www.projectedge.com), Bi dding and procurement networks: Buildfolio (www.buildfolio.com), ProjectGuides (www.projectguides.com), Real estate and facility management: Bricsnet (www.buildingcenter.net). Technology that is involved in PCNs varies [CAR01]. The Entranet and applicati on servers are the computer technologies that have close relation to PCNs. The Internet has evolved from a text based system with simple interactivity to the object web. The object web is considered the next wave of Internet innovation [ORF97]. The web in the future shall be comprised of not only simple file servers but also application servers with business objects involved. PCNs should take advantage from the the successes of the application servers. Online project collaboration has been taken seriously as a technical solution to the integration problem in the construction industry. However many of the companies and products failed along with the bust of the dot com bubble. Many of these companies shared the same shortcomings with the other dot com startu ps, such as immature business models, and adverse economical environments. Additional factors that have contributed to the failures of many companies are that the customers requirements for an integration system were not accurately predicted. For example, many contractors often have a relatively stable relationship with a certain subcontractor. In this case an online bidding system may not fit in the picture at all [FUS02]. The conservative nature of the construction industry with its reluctance of accepti ng new technology and making changes, is another important factor that contributed to the failures. The future of PCNs will largely depend on the maturity of generic Internet based technologies such as application server and its acceptance by the constru ction industry.

PAGE 40

27 Based on the current situation the companies that are most likely to survive include, Autodesk, Citadon, Primavera Systems, Buildpoint, Meridian Project Systems, Constructw@re, and Bentley [JUR02, FUS02]. The time of PCNs may finally come after proper adjustments and tough competitions, Analysis and Discussions The objectives, subjects of study, implementation, technical and major contributions of the literature reviewed are compared in Table 2 2. More detailed side by side comparisons of models, implementations and test issues can be found in Tables 3 2, 4 2, 5 1. Based on their goals and features the previous studies can be divided to the following groups, early studies, information standards, implementations based on information standar ds, alternative methods, and industry efforts. Early studies are mostly individual efforts such as the OPIS prototype [FRO92]. Information standards (STEP and IFCs) were a collective result of these works and provide low level support to data representatio n and sharing between domains. The establishment of information standards represents a trend showing the shift of computer applications in construction projects from single machine and independent applications towards network and collaborative systems. Con ceptual frameworks, trial implementations and software architecture based on the information standards was designed in various research works, such as the ToCEE project [TUR97, KAT98, SCH98], the VEGA project [ZAR97, BEE98, JUN97], and CIFEs IFC trial imp lementation and system architecture. On the other hand because of the diversity of the construction industry there are cases in which the IFC based implementations would not apply. Alternative methods are sought after to cover these situation. These stu dies are related to the same integration

PAGE 41

28 Table 2 2. Research and industry efforts of integration systems Project Objectives Subject of modeling Implementation Technical Primary contributions OPIS prototype [FRO92] Build standard form of models for constr uction projects Product, process A prototype based on database system Object oriented databases Early efforts Information standards: STEP, IFC, aecXML Provide standards for data exchange and representation Process, product Used in applications developed by other parties EXPRESS Modeling language Widely accepted information standards The ToCEE project, [TUR97, KAT98, SCH98, WAS98] Develop a conceptual framework and tools for concurrent engineering support in construction projects Product data A system supports information logistic, product data, document management Java, HTML CORBA Modeling and visualization of product data The VEGA project, [ZAR97, BEE98, JUN97] Specify a software architecture for a virtual enterprise in the Large Scale Engineering industry Business and technical processes A platform that manage product data, workflow, and document. IFC, STEP, CORBA, WfMC, XML The principles of open platform and integration scenarios BPM based implementati on [LUI98] Integrate design and construct ion Product, process A prototype with modeling tools Proprietary system: PMshell A unique project model and implementation Cross sector business model [YUM98] Provide a framework for business relations between AEC players Relationships among project mem bers NA NA Study of relationships among project members The COMMIT project [REZ98] Define mechanisms to support information management and decision making in collaborative projects Actors, and project information A prototype with facilities for managing r oles and activities. Rational Rose, C++, CORBA Study of actors, roles, and their interactions. CIFE IFC trial implementati on [FRO99a] Determine how well IFCs works for project management information Building, resource, cost, and scheduling Represent ation of project data in scenarios IFCs Trial and test of IFCs for project management CIFE System Architecture [FRO00] Develop a distributed, model based, integrated system Product and process A prototype with 4D tools, P3, and Timberline IFC, ADO, LDAI OLE DB Support of multi disciplinary interactions and decision making Robust mediation for supply chain [OBR01] Propose a mediation infrastructure for sharing of process information Mediations between project members A wrapper system that extracts and processes info from a database Java, SQL, XML, MS Project. Provide a mechanism for interaction between parties PCNs, [CAR01, FUS02] Tackle the integration issue from different perspectives Document, process, and message Various commercial products Vary Development of commercial products

PAGE 42

29 issues but adopted methods not exactly based on the concepts of the information standards. Examples include the BPM based implementation [LUI98], the cross sector business model, the COMMIT project, and the robust mediat ion mechanisms for supply chains [OBR01]. A common goal of the integration study is to facilitate collaboration and data exchange between the participants on construction projects. The implementations based on information standards (primarily IFCs), whic h are found to be the dominating method for integration, often adopted closely coupled collaborations, which means the project participants collaborate at high detail level and with fine granularity. As a result sophisticated software and hardware faciliti es are often required for a fully functional system. It is also required that software applications involved in the project conform to a single information standard in order to work with the collaboration system. A typical application scenario of existing integration systems was to integrate design and construction to formulate a basis for concurrent engineering. Applications in Design Built and BOT projects were found as part of research initiatives [LUI98]. However the diversified construction industry c onsists of businesses that vary in size and in their capability of adapting information technology. Implementations with closely coupled collaboration are not favorable choices in many cases. The project participants often affiliate to different organizati ons and bear their own interests and agenda beside the common interest vested in the project. The participants need to maintain a high level of independence and hide the details of their internal operations from each other. Only those necessary are reveale d to each other. The situation is especially true in the case where the traditional method of project delivery is involved.

PAGE 43

30 Many organizations involved in the project may have their own choice of software applications or may not have sufficient facilities at all. It is difficult to make it as a prerequisite to join the system that the member applications have to conform to a single information standard. An alternative is to build a loosely coupled system with flexibility that allows various entities to joi n. The collaborations between the participants only occur at lower details and lower frequencies when compared to the existing IFC based implementations. The participants have safely guarded and clearly defined boundaries between them. The system should in clude definitions of rules regarding interactions between users and the procedures for modifying shared resource and information. The internal operations of each user are hidden behind the boundary as in many cases in actual construction projects. The part icipants have the liberty to use their applications of choice as long as the minimum requirements for collaboration is fulfilled. Research Objectives and Methodology Based on the observation of the existing studies it is found that a system with flexibili ty and a collaboration mechanism are needed for the purpose of system integration for construction projects. The research objectives of this study are to investigate the possibility of developing a loosely coupled integration system with the supports of a viable collaboration mechanism for integration system. The relationships between the collaborating parties are a critical issue for the success of the system. The following issues are addressed in this study: The typical relationship and interactions bet ween project participants and its proper representation in a computer system

PAGE 44

31 The development of a computer model for the loosely coupled system that is capable of enforcing the relationship and interactions between the project participants over shared proj ect information. Implementation of the proposed model that proves the concepts of the system. The verification of functionality of the proposed system. A scientific approach is needed to produce reliable results for design research such as this one. Nume rous factors need to be considered for the design as well as testing of the solutions during the study. A general design research methodology as shown in Figure 2 3 was applied to this work. The full research cycle has 4 steps as in Criteria, Description I Prescription, Description II, and procedures for feedbacks to the previous steps. Figure 2 3. Design research methodology The research work follows the general procedure as defined. The criteria or overall goal for this research project is id entified as developing a viable collaboration mechanism for the integration system. The stage Description I contains the observation and analysis of the existing works related to the subject of integration in construction. A new model for the representat ion of the relationships between the project participants is presented based on the reviews of the existing works and the analysis of the organization of the actual construction project. A prototype was is to demonstrate the new model and Prescription Focus Assumption and Experience Method Methods Result Descriptions I Focus Observation and Analysis Method Influence Result Descriptions II Focus Observation and Analysis Method Application Result Fo cus: Measure Criteria Result

PAGE 45

32 the operations o f the system. Results in this section constitute the stage Prescription. In the final stage Description II preliminary analysis and tests are conducted through a comprehensive test plan. The feedback from the Description II stage has contributed to the improvement of the work. The scope of the literature review was modified as well to focus on more relevant studies. As a result the concepts represented by the model were fine tuned to provide better descriptions of the subjects. It took a few iterati ons before the final version of the model and prototype came into being. Methods of validation are a critical issue to the success of the study. A summary of the methods of validation presented in the study is shown in Table 2 3. Theoretical validation (comparison to known problems) and experimental validation (with applications) are two common forms of validation for software engineering. The theoretical validation of work was accomplished through side by side comparison between this study and previous work. Comprehensive tests with 3 level testing and application scenarios were conducted as the experimental validation for the study. Table 2 3. Methods of validation Category Method Descriptions Theoretical Validation Side by side compar isons with previous works Primary Methods Experimental Validation Comprehensive test plan with 3 level of testing Logical verification Development of the prototype Alternative Methods Verification by acceptance Reviews and discussions with peers The validation of n ew design and methods in practice is difficult because of the tremendous amount of factors that could have an impact on the design process and the stochastic nature of the design. Two alternative forms of verifications [BUU90] were therefore suggested. One was logical verification: Consistency: no internal conflicts exist between individual elements in the theory

PAGE 46

33 Completeness: all relevant phenomena observed previously can be explained or rejected by the theory Coherence: well established and successful me thods are in agreement with the theory Cases and specific design problems can be explained by means of the theory The other form was verification by acceptance: Statements of the theory are acceptable to experienced practitioners (design consultants and em ployees in companies). Models and methods derived from the theory are acceptable to experienced practitioners. Logical verification of the consistency, completeness, coherency and explanatory power of the model was accomplished through the development of p rototype that is able to handle the requests and provide support to collaboration. Verification by acceptance was achieved through reviews and discussions about the research work with the faculty member and fellow researchers in the process of publications and presentations. The feedbacks obtained in the process contributed to the improvements implemented in the study.

PAGE 47

34 CHAPTER 3 EPIC MODEL The primary goal of the study was to build a proper model for the collaboration mechanisms for construction projects. This chapter starts with an analysis of construction projects and then defines the EPIC model in details. The features of the EPIC model are further discussed by comparing to the existing works. Analyze Construction Projects A project model describes the relationship between real life objects in a construction project and the corresponding information about objects in real life A project model is also defined as a software representation of construction data that supports the project throughout its life cycle [FAR99]. Previous studies tried to design project models with different methods. Early efforts start with the object or iented feature and the various views of the model [BJO92, FRO92, FRO95]. Some took the perspective of the product model and focused on the description of the building products and related issues. Others started with the processes that are involved in a con struction project. A modularized project model was also defined to support a wide range of computer applications for construction [FAR99]. A proper project model should capture the organizational structure and interactions between the basic elements of a c onstruction project. Therefore the analysis of the structures of construction projects is a basic step of the modeling work for construction projects.

PAGE 48

35 Table 3 1 shows a list of basic elements of the construction projects identified for this study. There are three categories for elements as in physical, information, and temporal elements. Physical elements are with physical forms and include the touchable part of a construction project. Information elements represent the concepts associated with construc tion projects such as cost and schedule. Temporal elements are those related to time, such as the occurrences of events. Table 3 1. Basic elements of construction projects Categories Elements Examples Participants Owner, architect, eng ineer, contractors, suppliers Documents Drawings, specifications, project manual, the contract, etc. Buildings Floors, walls, foundations, etc. Physical Elements Resources Labor, materials, equipment, tools, construction equipments, water, heat, etc. Design Shapes, colors, measurements of the building components, technical specifications, etc. Schedule Plan of activities, start time, finish time, resource assignment, etc. Estimate & accounting Cost items, analysis, etc. Information Elements Contract condit ions Articles and clauses, right and responsibility, procedures. Activities Excavation, concrete, painting, tiling, etc. Temporal Elements Events Weather conditions, changes in design, etc. Figure 3 1 shows the relationship between the elements of construction projects. The operations of a construction project as a system are essentially the interactions between the basic elements. The interactions between the elements happen either within a category or between categories of elements as shown below : Type 1 (within a category) : Participants own and use the resources, generate and used documents, and build the project. Events triggers the activities Type 2 ( between categories ): Design and estimating provides a description of the project.

PAGE 49

36 Construction schedule describes predefined activities. Contract conditions define relationships among participants. Documents carry various information elements of the project. Activities refer constantly to the information elements Participants initiate activities e ither in response to events or as planned. Figure 3 1. Interactions between the basic elements The focus of this study is the relations and interactions between the project participants with regards to the activities and sharing of information elements. Events are identified as major causes of deviation in activities and therefore drive the changes in information elements. Define the EPIC Model Rules have to be enforced upon the interactions between the participants using an integration system on a construction project. A full range of business procedures and interactions between the participants such as changes, claim, and payment are defined in contract conditions for various project delivery methods. On many occasions the project information which is often stored in a shared database in integration systems, is changed reference to Physical Elements participants the project documents generate and use resources build own and use Temporal Elements activities events incur Information design schedule estimate & accounting contract conditions carry assign describe define describe initiate Focus of this Study

PAGE 50

37 as the results of these procedures. The basic solution of the EPIC model is to represent and enforce the common rules of interactions between the project team members regarding to the modification of the project information. The design principles of the EPIC model are as follows: Build in complement to the systems developed from existing studies including product model servers and IFCs. Provide a loosely coupled collaboration system for the modifications of the shared project information as a result of the business procedures in construction projects. Represent and convert procedures derived from contract conditions into enforceable rules in the system. The acronym EPIC coi ned for this study stands for Extended Production Integration for Construction. The system has the flexibility to let the project participant choose their own computer applications as long as an agent application is developed and installed in their local system. This feature makes it possible that the results and products from previous efforts towards integration can be included in the EPIC system. For example, the IFC based product model can be defined as a component in the form of a shared project datab ase. The EPIC model is built upon the integration requirements of the computer applications and systems and the study of the typical organization of construction projects. Basic system components of the EPIC model include actor, roles, processes and inf ormation objects. The definitions and relations between the components are explained in detail below. Actors and roles. Actors represent the entities that are the participants on the construction project team. The internal operations of an actor in relati on to the construction project are defined as internal processes. For example, an actor playing a

PAGE 51

38 contractor has internal processes such as cost estimate and cost analysis. A certain actor may play different roles in a single project, for example, an archi tectural design firm may act as the designer and the construction manager. The boundary of an actor is the natural limits of the organization it represents. In actual construction projects, entities from different institutions coexist within a single proj ect organization and maintain clearly defined and safely guarded boundaries. Each entity conducts business operations primarily inside its boundary. The information exchange and sharing, which however does exist, is accomplished through an external process that occurs between the participants. The ownership of the information needs to be considered and rules must be followed through certain mechanism while executing external processes in the system. Information objects The information objects keep project information that needs to be shared between the actors. Sometime during construction Actors are required to share certain information with the others in the form of information objects. The complexity of the information objects varies from one type to ano ther. The building model from the architect is an example of the information object. It is the responsibility of the project team to reach agreement regarding the contents and the methods of information sharing as part of the definition of the project. Pro cesses. The analysis and modeling of the system processes is one of the goals of this study. The internal processes represent business activities occur internally within the actors and are implemented according to the in the computer system used by the act ors, for instance, as workflows or routines. EPIC system requires that the maintenance of the shared information objects by its owner be accomplished with internal processes. It

PAGE 52

39 is part of the business routines of the actor to access the shared information objects owned by other actors. The EPIC defines the external processes for this case as vehicles of information exchange and collaborations between the actors. Figure 3 2 shows the relations and interactions between the components of the EPIC model. Each actor has internal functionalities that are represented with internal process. For example, the in house estimating and accounting practice is internal processes of contractors. Shared information objects are setup as required by the business needs. For ex ample, on a typical construction project we may find a shared information model for the buildings. The actor also needs to maintain a coordination agent and a procedure Library for the purpose of providing system functionalities. Figure 3 2. The EPIC project model In the case when the shared information objects need to be accessed as required by internal operations, a request is submitted to the coordination agent from the internal proce ss. The agent looks up and executes the corresponding procedure in the procedure Actor 1 B A Procedure Library Internal Functionalities Maintain Actor 2 C Procedure Library Internal Functionalities Maintain Actor 3 .. D Procedure Library Internal Functionalities Maintain Events An illustration of the interpretation and execution of the external processes See Chapter 4 for details A Internal Processes External Processes Shared Information Objects Coordination Agents

PAGE 53

40 library. The predefined procedure contains information about how and where to locate the information needed. External processes are dispatched as the results of the execution of the procedures. A single request of the internal processes may lead a multi step activity that includes a group of external processes. The implementation of external processes is major challenge because of the complex nature of the shared information o bjects. It is required that the system maintains the integrity of the data contained in the shared information objects in a dynamic environment. Another important issue is that the system has to be able to operate efficiently in regarding to the process ex ecution in order to render acceptable performance. It is the goal of this study to propose a viable solution for the definition and implementation of the external processes. Needs of Collaboration Support on Construction Projects Many existing integration solutions focus on the capability of representing project information and information exchange between applications. However the ever changing nature of construction project requires integration systems equipped with facilities that are able to treat proje ct information as a dynamic entity. The project information changes either because of the normal progress of the project from preplanned activities or caused by uncertainties. As results of uncertainties, construction change is a proper example to demonstr ate the challenges to collaboration systems in terms of the capability of providing sufficient support. Construction changes are categorized with the reasons causing them. One example of the categorization is: design deficiencies, criteria changes, unfor eseen conditions, changes in scope and other [COM86]. Studies shows that the most frequent and most costly changes are often related to design, such as design change and design

PAGE 54

41 errors [AKI94]. A case of construction change with design change involved is us ed to demonstrate the needs of the support of an integration system. Change orders are the instrument used to handle construction changes on construction projects. Suppose in the case of a complicated change, the owner requested a substantial change to t he existing design. Additional design work has to be performed before issuing a change order. The design provided by the architects and engineer has to be crosschecked with the existing work and the other participants. A clearance from all relevant partici pants needs to be obtained before the change may proceed. Some fairly uncommon materials have to be preordered before the final decision is made about the proposed change. The architect needs to check the suppliers to make sure these materials are availabl e. Challenges and key issues related to the use of change orders are found as follows. Negotiation between the participants presents in preparation of complex change orders. For a complicated problem extensive communications among the participants are nee ded before an agreement can be reach. Turn around time for approval is significant enough to prevent closer participations of the relevant parties in the design process. Project information needs to be distributed among relevant parties. The proposed plan for changes need to be made available to the parties for review. The distribution of project information based traditional document such as drawings and specification results in reinterpretation and potential problems in accuracy and timeliness. The distri bution of project information is also an important step to present evidence in order to justify the change orders. There are possibilities of obtaining excessive price quote. Although the original contract is obtained competitively, the costs of most chang e orders are not determined through direct competition between bidders. This increases the possibility that a contractor could quote an excessive price for a change order. Documentation of the change orders is necessary and can be used as experience data for future decision making. In practice the contractors do not always comply with the requirements of documentation.

PAGE 55

42 The EPIC system is capable of providing support regarding various aspects of the change order process. Customized external procedures are used to form flows of decision makings and support simple reasoning to the negotiation process. Turn around time can be reduced through expediting the delivery of message and project information. The introduction of a shared project model into the system p rovides a basis for accurate distribution of the change plan. Pricing and availability of labor and materials can be stored in shared information among the users so that competitive prices can be obtained. The system also keeps track of decision making pro cess and the tracking recording may become part of the documentation for construction changes. There are case that the solution provided by the EPIC system may not cover or may not hold any advantages against the conventional ways. The advantages presen t only in the case of change orders with complicated problem where large amount of negotiations are required. For simple changes the system basically degrades to a message passing service. Change orders with little or no project information associated are not able to take advantage of the benefits associated with the shared project information. It is not possible to obtain competitive prices if the project is too simple that only one contractor and a single source of materials is involved. Fitting the EPIC Model into the Existing Model World The EPIC model is not only in complement with the existing models in regards to functionalities but also from the perspective of the general landscape of the computer modeling for construction projects. Figure 3 3 show s a sketch of relations between the real world and the modeling world for construction. Extensive studies have been conducted regarding the process model and product models at both the conceptual level and the application level [TUR99, FRO99b, CUT99].

PAGE 56

43 The project (building) and its resources are the primary subjects of modeling for product models. The content of the product model include the information such as the design, the schedule and the cost estimate. Process models are generally descriptions of the activities involved in construction projects. Application models are lower level models used by software packages and contain a certain type of information elements and often an implementation of either a product model or a process model. Figu re 3 3. The EPIC model in the existing model world Some other elements that have yet not been covered are events, document and participants. The project participants and their relationship need to be analyzed from the perspectives of project management. A s a major cause of the deviations in construction the events are a subject closely related to the modeling of the relationship between the project participants. The interactions between the existing models and the missing parts also need to be studied. The information carried in drawings and specifications has Existing works Co nceptual Models Application Models Process Models interact implement s Physical Elements participants resources the project documents Information Elements design schedule cost estimate contract conditions contain describe describe Temporal Elements events activities Real World Computer World (Models) describe Product Models

PAGE 57

44 become part of the product modeling. The project document that has not been well represented in the computer world is the contractual relations. The EPIC model presents a solution to the integrati on project that is associated with modeling of the events, the relationships between project participants, and the contract conditions. A collaboration mechanism is built with the proper models of the missing elements and fits in as one more piece to the p uzzle of the modeling world for construction projects. Uniqueness and Value of the EPIC Model The uniqueness and the value of the proposed model are demonstrated with a side by side comparison between the EPIC model and a selection of studies with signifi cant modeling efforts as chosen from Table 2 3. Table 3 2 shows the results of the comparison considering the subject of model, its objectives, the presence of collaboration mechanisms, and the technical solutions. This selected group of studies sha res a common goal of supporting the system integration between project participants but from different perspectives and with various methods. The ToCEE project and the CIFE system architecture represent the IFC based implementations. The Building Project M odel and the others took alternative roads that either start from scratch to build a model for construction projects or address a specific aspect related to the integration problem. The method chosen by the EPIC model is significantly different from the on e found in many IFC based implementations. IFC based systems use a top down method and require the participants to follow universally accepted standards at a high level of details in their operations. As a result, the definition of IFC standards tends to c over extreme details in every aspect of the construction project. The method often leads to a

PAGE 58

45 closely coupled collaborative system with participants maintaining a close connection between each other. The practice in actual construction projects is against a method that compromises too much the independence of the participants. Rather it is in favor of a method that keeps a distance between project participants while allowing them to collaborate. This is important because in most cases of the actual construc tion projects, the participants of construction need to have control over what type of business information has been published. Table 3 2. Comparisons of models for integration Studies Method of Integration Subjects of Modeling Collaborations Technical S olution The ToCEE project, [TUR97, KAT98, SCH98, WAS98] Closely coupled Product data With no clearly identified roles IFC based product data server system. CIFE System Architecture [FRO99a] [FRO00] Closely coupled Product, resource, cost, scheduling, and organization With no clearly identified roles IFCs, and software for construction Building Project Model, [LUI98] Closely coupled Product and process With no clearly identified roles Prototype with modeling tools Robust Mediation of Construction Sup ply Chain, [OBR01] Loosely coupled Relationship between parties (contractor subs) For roles from different entities Query processing and wrappers Cross Sector Business Model [YUM98] Loosely coupled Relationship and activities between parties For roles f rom different entities Reference to distributed facility The COMMIT Project [REZ98] Loosely coupled Actors, and information management For roles from different entities Modeling tools, notification, and information management. The EPIC Model, H. Lu, 20 02, this study Loosely coupled Relationship between parties, events, contract conditions For roles from different entities Rule based, distributed transactions The EPIC model adopts the notion of building a loosely coupled system that allows the particip ants to maintain a higher level of independency and the integrity of their existing computer systems. It acknowledges the differences in the capability between the potential users of adopting information technology and it provides the

PAGE 59

46 flexibility for the u sers to select their favorite applications. Only the necessary interactions between the participants are carried out to provide the functionality of collaboration. This method actually lowers the bar to joining the system so that a broader base of users ca n be reached. The principle of the EPIC model is a departure from the methods found in the current IFC based implementations but does not work against the using of IFC as a universal language for communication. The subject of the modeling is another matt er that separates the EPIC model from others. In order to design a viable collaboration mechanism for integration systems it is necessary to study the modeling of the relationship between the participants and the impact of events as well as the enforcement of contract conditions in the system. The results of the study make it possible to support a clearly defined boundary between the users and allow users from different business entities to collaborate without a glitch. The study of the relationship between the parties was found in a few studies [YUM98, REZ98] but the impact of events and contract conditions has never been formally investigated. The studies that share the most similarities with the EPIC model are the COMMIT project [REZ98] and the cross s ector business model for construction [YUM98]. The collaboration between the project participants is the primary concern of this group of studies. What make them different are the proposed technical solutions. The cross sector business model made reference to distributed facilities such as CORBA and discussed some concepts but was not able to present an implementation that demonstrated the concepts as discussed. The COMMIT project focused more on information management and manipulation of information in fin e granularity rather than the actual

PAGE 60

47 relationships between the project participants. In comparison the EPIC model addresses the events, rules and procedures that are related to the interactions between the participants. Because of the difficulties of ver ifying the benefits that the proposed system may bring, many previous studies only provide proof of concept tests. The EPIC study makes an attempt to verify the claimed benefits with simulations designed and executed upon scenarios and prototypes. It was f ound that the application of the EPIC system provides a possibility to optimize the existing business procedures during the construction stage. The value of the EPIC model is summarized as the follows. Used an integration method that is in contrast to the top down method represented by some IFC based system. Conducted study of event and contract conditions and their impacts to the collaborations in integration systems. Provided a unique technical solution to the representations of business relations in c onstruction projects and the implementation associated with it. Attempted to verify the benefits of the proposed system in regarding to the optimization of the business procedures. Relationships and Interactions between Participants Project participants (actors) are the decision makers with regards to the construction project and at the same time they provide information and services to the other actors as may be required by their roles on the project team. Only some of the business activities within the actors organizations are relevant to a particular project and need to be considered in the EPIC model. Among the relevant activities only the external ones, as shown in Figure 3 3, have contact with other actors. The behaviors of the participants in a co llaborative system are regulated with predefined rules and procedures. It is common to use contracts to define the basic rules of

PAGE 61

48 engagement between the participants on a construction project. The rules and procedures embedded in a collaborative system sho uld bear the same meanings as defined in the contract. The existing identifications of the roles in the contract can be used as the basis for the basic setup of the EPIC implementation. Predefined procedures derived from the contract conditions can be conv erted into enforceable rules for the interactions in the EPIC system. Different types of contractual relations are available for construction projects and defined in separate versions of standard contracts, such as, owner architect, owner contractor and general contractor subcontractor. Various types of contractual relations may coexist on an actual construction project. The complete view of the business relationship on a construction project can be obtained by decomposing the contractual relatio ns found on the project. In this study a concept of Basic Construction Unit (BCU) is defined as part of the EPIC model and it represents a simple contractual relation between some project participants. A BCU is generally corresponding to a certain type o f contract and contains the parties, their right and responsibilities, as well as the procedures. For instance, AIA documents A201 can be use as the framework to build a BCU for a construction project with traditional delivery method. The owner and the con tractor are the primary parties in the BCU while at the same time the architect has to be involved as a party in the BCU because of the critical role of the architect as the administrator of the contract. A model for the entire construction project can be recursively constructed with BCUs which may include different types of contractual conditions. Such a model is able to capture the features of the business arrangement and the organizational chart of a

PAGE 62

49 construction project. The implementation of such a mo del has the potential to provide strong support for the business operations found on the project. Construction contracts have different flavors according to which party is responsible for the construction management services. A typical case involving a tra ditional project method will be used in the study. The basic parties are the owner, the architect, and the contractors. Other common participants are the suppliers and the engineer. The case contains only one BCU and five participants. Introduce Contract Conditions into the EPIC System The contract conditions, which is often called the bible, define many critical business procedures in a construction project and need to be examined in details for the definition of BCUs. The study of the common procedures found in contract conditions contributes to the design of external processes that represents the interactions and activities between the project participants. Because of the previous assumption of the study the AIA Document A201, General Conditions of the Contract for Construction, was analyzed and used as an example for the implementation of the EPIC model. The common elements of the standard contract conditions are identified for the purpose of the study: Definitions and interpretations: basics conce pt and rules Right and responsibilities: identified with words like may, shall, must, and specify the right or responsibility for a certain party to act. Procedures: a sequence of activities that contain notices, submission, requests, approval, an d decisions, often specified as routines or solutions to various issues that may arise during the construction process. Simple communications: notices and requests that occurs between the major parties.

PAGE 63

50 The document was studied on a clause by clause basi s. A notation system as shown in Figure 3 4 is used to indicate the type of the elements found in the text. A complete text with the notations is attached as Appendix 1. Titles for the clauses were inserted in the original text as a method of identificatio n of the clauses rather then accurate descriptions of the contents. Article 2 Owner 2.1 General 2.1.1 The Owner 2.1.2 Information relevant to mechanics lien rights 2.2 Information and Services Required 2.2.1 Owners financial arrangement 2.2. 2 Owners responsibility to secure approvals for construction 2.2.3 Furnishing survey and description of the site 2.2.4 Reasonable promptness to furnishing upon request 2.2.5 Free copies of drawings to the Contractor 2.3 Owners Right to Stop th e Work 2.4 Owners Right to Carry out the Work Figure 3 4. Analysis of the Contract Conditions The definitions, interpretations, rights, and responsibilities as defined in the text of the contract conditions provide guidelines for the design and setup o f the EPIC system. For example, the types of roles and the setup of shared information objects may follow the parties and rules as defined in the contract conditions. Procedures and simple communications are the basis for the design of external processes f or the system. Table 3 3 shows a summary of clauses that contain procedures (P) and simple communications (SC) in the document AIA A201. The procedures or simple communications may or may not involve transfer of project information from one party to anot her. A certain item could occur in the one or more of following scenarios, Responsibility (shall, must) Definitions and Interpretations Simple Notices, Orders, and Right (may) Procedures Transfer of Project Information

PAGE 64

51 Initialization: at the beginning of the project Upon request: occur when needed Periodical: occur within certain interval or according to a schedule Finalization: occur at the end of the project. Table 3 3. Procedures and notices found in AIA A201 Clause Descriptions Type Occurrence Proj. Info. 2.1.2, 2.2.1, 2.2.3, 2.2.4 Owner provides info about mechanics lien, financial arrangement, site info, and others. P Initialization Y 2.3 Owner sends notice to stop the Work SC Upon request N 2.4 Owner carries out the Work P Upon request N 3.2.1, 3.2.2, 3.3.1, 3.7.3, 3.17 Contractor checks contract document, reports errors, unsafe procedure, variance with law, or infringement of copyr ight or patent SC Initialization Upon request Y 3.8.2 Use of allowance P Upon request Y 3.8.3 Selection of equipment and material by owner SC Upon request Y 3.10.1, 3.10.2 Contractor submit and update construction schedule and schedule of submittals P Periodical Y 3.11.1 Contractor keeps a record copy for field ops SC Periodical Y 3.12.5 Contractor reviews and submits submittals P Upon request Y 3.14.2 Written consent for cutting and patching P Upon request N 4.1.2 Written consent for authorities of Architect P Initialization N 4.2.11 Architects decision on performance matters P Upon request Y 4.3.4, 4.3.5, 4.3.7, 4.3.8, 4.4.1 4.4.3, 4.4.5 Claims: Filing and review of claim, Architects review and decision. P Upon request Y 5.2.1 Contractor i nform the owner about subs P Initialization N 6.2.2 Contractor report defects by other contractors SC Upon request Y 7.2.1, 7.3.1, 7.3.3 7.3.6, 7.3.9, 7.4 Changes: Change order and construction change directives, minor changes P Upon request Y 8.2.2 Con tractors notice of commencement SC Initialization N 9.2 Contractor submits schedule of Values P Initialization Y 9.3.1, 9.4.1, 9.5.1, 9.5.2, 9.6.1, 9.6.3, 9.6.5, 9.7 Payments: Application, approval, withhold, P Periodical Y 9.8.2 9.8.5, 9.9.1, 9.10 .1 9.10.3 Substantial completion, partial occupancy or use and final completion. P Finalization Y 10.3.1, 10.3.2 Handling of hazardous materials P Upon request Y 11.4.1, 11.4.10 Property insurance: purchase and maintenance P Initialization N 11.4.10 Pr operty insurance: adjustment of loss P Upon request Y 11.5.2 Contractor provide copies of bonds P Initialization N 12.1.1, 12.1.2, 12.2 Uncovering of work P Upon request Y 13.2.1 Written consent to assign contract P Finalization N 13.5.1 13.5.4 Arrang ement for test, inspections and approvals P Upon request N 14.1.3, 14.2.2, 14.2.4, 14.4.2, 14.4.3 Termination P Finalization N 14.3.2 Suspension by owner P Upon request N This work is an attempt to convert the contract conditions into enforceable rule s in a collaboration system regarding to information sharing. The implementation of the

PAGE 65

52 external process based on a selection of procedures in this table will be discussed in Chapter 5. From Events to Procedures As a common practice the predefined construc tion schedule is the essential basis for the routine time control of the project. Before the commencement the entire operation of the project is decomposed into activities during construction planning. The dependencies between the activities are analyzed t o arrange the activities in a fixed sequence of works for the construction project. The anticipated date of start and finish for each activity is computed to formulate a schedule with calendar dates. The construction schedule made before the start of the project only provides guidance to the execution of the project and is subject to periodic revisions and corrections often triggered by events. In this study an event is defined as an occurrence during the course of the execution of a construction project that causes changes in the predefined construction schedule. Events are irregularities in the construction process and are caused by the issues that are not foreseeable during the planning stage of the project, for example the unforeseeable underground con ditions. The events vary from one construction project to another but it is possible to identify a limited set of common events and their impact on the project by studying previous construction projects. The physical activities as defined in the schedule or caused by events are the sources of the system processes in the EPIC model. The primary function of the EPIC model is to maintain the dataset of the system in regards to the changes and updates caused by the physical activities in the project. Figure 3 5 shows the correlation between the events and the system processes.

PAGE 66

53 Physical construction activities are either defined in the construction schedule or caused by events. Although the nature of the physical activities may be the same as shown in the ex ample, the EPIC system needs to handle the planned tasks and on demand tasks with different sets of internal and external processes. Extra system processes are required to modify the original as planned project information. Many of these processes represen t the collaboration and re negotiations between the parties. Figure 3 5. The causes of system processes Only the external processes make contacts with other actors to access shared information or for the purposes of collaboration. The design of external process is included as part of the EPIC system while at the same time the implementation of the internal processes is left to the users. The rules embedded in the contract conditions need to be enforced through the design of the external process. The external processes need to be represented with a set of procedures in the form of a library at the initialization stage of the system. The procedure library is different from one project to another although the method of its design is the same. Normal Oper ations Plan for excavation define schedule Planned Task Routine Procedures Routine Contacts Daily cost update Update the shared DB and notify Excavation Cases Contract Conditions Set rules for Variances cause events On demand Special Proc edures Change in qualities Draft change order Approval and update Extra work Special Contacts Cases Sources Physical Activities System Processes Internal External

PAGE 67

54 CHAPTER 4 SYSTEM ARCHITECTURE AND IMPLEMENTATION The EPIC system as described in this chapter is basically an implementation of the proposed EPIC model. The software prototype developed is used as a platform and infrastructure for the testing and verification of th e EPIC model. An engine is available to process predefined procedures and enforce the rules upon the access to certain types of shared information objects. A transaction based implementation is chosen as the underlining technical solution. Unified Modeli ng Language and Software Development Unified Modeling Language (UML) has been used as a tool in many works during the development of the EPIC implementation system. Basics about UML are included below to help in the understanding of the content of this cha pter. UML is a relatively new modeling language created as notations for object oriented design and analysis methodology by Grady Booch, James Rumbaugh, and Ivar Jacobson and later adopted by Object Management Group, Inc. (OMG) as a standard in 1997. Soon UML become the standard modeling language for software development and is supported by all major software modeling tools. A notable feature of UML is that UML uses geometrical symbols to visually represent the functions and relationships of a software sy stem. The application of UML is highly flexible and varied according to the features of the area of applications as well as the preference of the developers. A collection of concepts and modeling tools is available

PAGE 68

55 for the definition and description of the work with different natures. Various diagram types as shown in Table 4 1 are used to describe specific aspects of a software system. Table 4 1. Views and diagrams in UML Views Diagrams Contents Usage Class diagram Relationships between classes de fined Common Component diagram Relationships between software components Rare Static Deployment diagram How the software deployed Rare Sequence diagram Interactions between objects Common Collaboration diagram An alternative presentation of sequenc e diagram Rare Activity diagram Procedures Common Dynamic State diagram State transition of the system Rare Use Case Use case diagram How the system interaction with outside world Common Figure 4 1 shows an example of UML diagrams. The diagram describes the relationship between design document classes and other classes in a project model. Similar diagrams can be prepared for other applications. The design document is composed of 3D model, drawings, and specifications. Architects are the providers of the desi gn documents. The design document provides a general description of the proposed construction project. The owner needs to approve the design document and in the end own it. Contractors are the users of the design document. Figure 4 1. Sample UML d iagram: a class diagram 1..* 1..* use 1..* 1..* provide Architect Contractor 0..* 0..* 0..* Design Docume nt 3D Model Drawings Specs 1..* 1..* approve and own Owner 1..* 1..* describe Project Notations: Compose of Class Association and direction 0..* 0 or more

PAGE 69

56 Implementation of the EPIC Model The EPIC system is basically an implementation of the proposed EPIC model. The principles behind the system design are stated before the development work. A system architect is defined to provide an overview of the implementation system. The features of the proposed model require a technical solution with a transaction based system. Table 4 2. Implementations of integration models Studies Presence of A Building Model Granularity of Collaborations Co mponents and Facilities Case Study The ToCEE project, [TUR97, KAT98, SCH98, WAS98] IFC Full Implementations Fine Information Logistics Server, Document Management Server, Product Management Server Not Found CIFE System Architecture [FRO99a] [FRO00] IFC Full Implementations Fine User Applications, Adaptors, Common project database A hypothetic schedule review meeting Building Project Model, [LUI98] Non IFC Full Implementations Fine GUI, Project Modeling Environment Design and assembly of precast concret e structure Robust Mediation of Construction Supply Chain, [OBR01] None Coarse Mediator, wrapper, and user databases. Resource balancing The COMMIT Project [REZ98] Not Found Fine Interfaces for managing project actors, roles, and activities, project inf ormation manager and document manager. Making changes to a wall The EPIC Model, H. Lu, 2002, this study Simple Representations Coarse Procedure Definition, Transaction Execution, Distributed Database. Collaborations regarding a change. Comparisons of System Implementations from Previous Studies The information about implementations from previous studies is compared side by side with the implementation efforts in this study. In Table 4 2 many studies placed their focus on the implementation of the buil ding model either in IFC format or independent format. Because the primary focus of this study was not on the

PAGE 70

57 representation aspect of the building model simple java objects are used to present an abstract view of the building model. A loosely coupled syst em that features a coarse level of collaboration is promoted in the EPIC model in contrast to the fine granularity of collaborations as seen in many studies. The components and case study of each study are in accord with the functionality and technical so lutions found in their implementation system. Many studies have included graphic user interface in their implementation, which provides better presentation and is also what is lacking in this study. A detailed comparison between the case studies is present ed in Chapter 5. System Architecture Some notions have to be kept in mind while thinking about designing an implementation system. It is important that the system be designed as a loosely coupled distributed system that consists of autonomous component s, as opposed to a monolithic system with close ties between different parts within the system. The organization of construction projects, which is often temporary and customized for a particular construction project, requires loose control and flexibility An implementation system of integration model should allow new members to join in and the current members to regroup for any new construction project. Because of the variety of computer systems involved in construction project the implementation should b e able to take advantage of common modeling paradigm and common meta model while at same time keeping an open door for other model such as the document model. When implementing solutions with existing technologies one has to guard against losing contact wi th the reality of the construction processes.

PAGE 71

58 The application system based on the EPIC model, which will be referred to the EPIC system in this study, maintains a group of shared information between the participants of a construction project. The EPIC sys tem has a multi layer structure from users to data layers as shown in Figure 4 2. Figure 4 2. Multi layered structure of the EPIC system The data layer consists of a group of databases that store co nsistent project information such as a building model, resource listings of the contractors, and materials availability listings from the suppliers. The agent layer contains gateway facilities that enable user applications (in the user layer) to make conta ct with the system. The computer applications used by the participants on the project are represented in the EPIC system with agents. The agents are developed particularly for the unique functionalities of the user applications. Between the agent layer an d the data layer is the middleware that handles the requests invoked by the operations of the user applications. The Cons truction Software Resource Listings s Material Listings Building Model CAD Packages Engineering Software Collaboration Mechanisms User Applications Agents Decision Makers Middleware Layer Data Layer Boundary of EPIC System Local Functionalities of the Parties EPIC System Components Legend Others

PAGE 72

59 middleware layer contains critical components that enable collaborations between the parties of the project. The middleware layer can be im plemented as a transaction system that is capable of handling advanced transactions. The nature of the EPIC system is a dynamic work environment for project data and document management. During the construction stage the EPIC system acts as a run time syst em maintaining a set of consistent storage of project data. The system provides different views of the project to members of the construction team that carry out different tasks. The software applications used by decision makers from different parties act as clients to the EPIC system and access project data subject to the coordination of the system. The operations of the EPIC system are driven by events that have impact on the project and the decisions made by the members of the project team. During the construction the effect of any events and the information generated by the normal construction process are constantly recorded by altering the dataset in the user applications used by the decision makers. The user applications send update requests to the d ata layer so that the other user applications may share the changed view. Data from different parties is reconciled in the middleware layer according to certain predefined rules before being saved into the consistent data storage. The EPIC system was impl emented as a distributed application system over a computer network with Java and CORBA as enabling technology. Team members are able to work at different locations in a collaboration environment provided by the system. The system bears the potential to ex ploit concurrency in the construction process by increasing the accuracy and timeliness of information delivery.

PAGE 73

60 The key technical issue of the system design is the collaboration mechanism that represents the business arrangement between the participants on the construction project. Because of some unique features of the construction industry f ile locking mechanisms as seen in document management system or standard transactions as widely used in database systems cannot meet the requirements of the task i n EPIC system. Advanced transaction models are used as a technical solution to develop the collaboration layer for the EPIC system. Transaction based Implementation Traditional transaction service has been shown to be sufficient technology for the concurre ncy control for common database systems [ELM92]. However a traditional transaction system does not apply in the case of the EPIC model because of the unique requirements brought by the following features of the construction industry and construction projec ts, The organization s of a construction project are temporary and customized according to a specific project. A complex information entity, the building, is the center of c onstant information exchange among participants in the project. More human invol vement is required than in a generic workflow system, such as office automation. The EPIC system has to be designed to consider these issues The feature of temporary organization requires a framework that enables flexible regrouping of different types of business entities for new projects. A data model for buildings such as IFCs has to be part of the system for the purpose of project information management. Constant human interventions imply that the system has difficulty in achieving a higher level of automation and the processes (workflow, activities) may run for long extended times.

PAGE 74

61 Advance transaction systems, which are developed to accommodate long running activities and distributed objects are a viable technical solution to the EPIC system. A preli minary study [LU02] has been conducted to compare in general the difference between a traditional transaction system and an advanced transaction system. Further investigations are needed to test the system in the context of actual construction projects. Transaction Models and Transaction Design Basics about transaction and transaction models are reviews in this section to provide a basis for the development of a transaction based implementation for the EPIC system. Principles and methods of transaction de sign are also discussed in details. Transaction Basics A transaction is a sequence of read and write actions that are grouped together to form a database access [RYA95]. The functionalities of transactions require it has properties commonly referred to as the ACID properties: Atomic: the transaction either completes or fails as one unit Consistent: resources (database) must maintain a consistent state Isolated: no interface is allowed between transactions Durable: the result of the transaction is not los t even in the presence of failure However in many cases of applications the properties of traditional transactions do not apply. Advanced transaction models were motivated by complex applications like office automation, CAD/CAM and software engineering. T he tasks in these systems are characterized with the following features: Long duration, could run for hours or even days Cooperative tasks Operate on heterogeneous systems It is no longer feasible to implement these tasks with the traditional transaction model. New transaction models, which are referred to in general terms, as extended

PAGE 75

62 transaction models or advanced transaction models are developed for these special tasks [MOS87, GAR90, ELM90, WEI92, BUC92, ZHA94]. Key features of these models include c omplex transaction structure non serializable correctness criterion capability of running against both transactional and transactionless object Transaction models can be characterized by transaction structure, object structure on which the transactions operate against, and correctness criterion. Figure 4 3 is a road map showing how a transaction model is characterized. The physical structure of transaction varies as a result of making extensions to the original transaction model. A flat transaction has a single start point and end point, and was studied extensively for database management system. A nested transaction may contain subtransactions which may recursively contain other subtransactions. Closed nestings are actually nested transactions with trad itional transaction semantics [GRA96]. Open nestings relax the rule of isolation in ACID properties by making the effect of the transactions visible to other transactions running concurrently. Some transaction models try to cover both open nesting and clos e nesting and therefore are called combinations [ELM90]. The object structure becomes relevant because complex applications for which advanced transaction models are designed often contain more than simple objects. An example of a simple object is a ph ysical page in a database. Operations on a simple object do not consider the semantics of the object. Complex objects could encapsulate a set of objects and often have a set of inheritance relations with other objects. Sharing of state and/or behavior amon g objects may be involved. A transaction operating on one object

PAGE 76

63 may spawn additional transactions on component objects. An active object is able to respond to events by triggering actions for certain condition. Figure 4 3. Road map for the study of transaction models Serializability is a common correctness criterion for database systems. It sets conditions to make sure the execution of transactions does not incur any conflictions within the database system. Any non serializable correctness criterion, which is not as restrictive, leads to an advance transaction model. Comparison of Transaction Models Some notable works regarding advanced transaction models include, nested transactions [MOS87], sagas [GAR90], multi level transactions [WEI92], flexible transactions [ELM90, ZHA94], and multitransactions [BUC92]. The transaction structure, object structure and correctness criterion are three dimensions of the concept space of transaction models. Different transaction models can be described usin g the combinations of the values from these dimensions. For example, the original transaction concept uses flat transactions operating on simple objects and use serializability as correctness criterion. Sagas use open nesting transactions on simple object with non serializability as correctness criterion. Multitransaction goes to the other end of the Transaction Model Transaction Structure Flat Transaction Closed Nesting Open Nesting C ombinations Object Structure Simple Objects Complex Objects Active Objects Correctness Criterion Serializability Non Serializability

PAGE 77

64 spectrum, with combination transactions on active objects using non serializable correctness criterion. Table 4 3 is a comparison of the transaction models. Ta ble 4 3. Comparison of transaction models Transaction Models Transaction Structure Object Structure Correctness Criterion Recovery Mechanisms Traditional Model Flat Transaction Simple Object Serializable Nested Transaction Closed Nesting Simple Obj ect Serializable Multi level Transaction Open Nesting Simple Object Non serializable Commutativity Saga Open Nesting Simple Object Non serializable Log based Flexible Transaction Combinations Simple Object Non serializable Retry and Compensating Mult itransaction Combinations Active Object Non serializable Compensating Transaction The technical solution adopted in the EPIC system is a transaction system with open nested transactions and non serializable correctness criterion that operates on complex objects. The basic logic about relaxing the ACID properties of transactions is that the semantic information about the transaction and its objects can be used to achieve a higher level of concurrency. Transactions are decomposed into smaller steps and non serializable correctness criteria are used. Some key research issues include, failure recovery, correctness and dependency issues, and partitioning and granularity of objects. Efforts to Combine Different Transaction Models Efforts have been made to unify various existing advanced transaction models. Some of them have been successful in one aspect or another but a perfect solution has yet to be found. An overview of some of these studies is presented below. DOM [BUC92] is a result of early studies on adva nced transaction models. Multitransactions are defined as a concept of the general transaction structure for flat transactions, nested transactions, sagas, flexible transactions, and multi level transactions. Figure 4 4 is an illustration of the structure of a Multitransaction. Toptransaction is a

PAGE 78

65 closed nested transaction with a complex transaction structure but it appears as an atomic transaction to peers. A Multitransaction is a combination of Toptransactions with global transaction semantics but it perm its partial results to become visible outside of a Multitransaction. In order to accommodate the requirement of saga, a compensating transaction is designed to remove already committed partial results in the situation when a rollback occurs. A compensating transaction needs to be defined for each member Toptransaction of a Multitransaction. The concept of contingency transaction comes from the study on Flexible Transactions [ELM90, ZHA94]. It gets executed if the primary transaction fails. Figure 4 4. Transaction structure of a multitransaction Depending on the requirements of the application and the transaction design, the DOM transaction model may behave as a traditional flat transaction, a transaction model that allows for closed nesting and the execution, or combinations of closed and open nesting. DOM provides a good method in capturing transaction structure, however it does not address sufficiently the correctness criterion issues, which are critical to the success of an advanced transaction model. The ACTA framework [CHR90, CHR91, CHR94] is a tool to analyze and formally specify different transaction models especially regarding the criterion issues. Multitransaction Toptransaction Contingency transaction Compensating transaction

PAGE 79

66 According to the study, the flexibility of a transaction model depen ds on the combinations of four notions [CHR91]: Visibility: the ability of a transaction to see the result of another transaction while executing Performance: the ability of a transaction to write to a database Recovery: the ability to keep the database i n a correct state in case of failure Consistency: the correctness of the state of the database produced by a committed transaction. The ACTA framework captures not only the interactions between transactions but also the effects of transactions on objects. Each object has a state and a status associated with it. The state is represented by the content of the object and the status contains synchronization information. Each transaction has a View Set containing the object set potentially visible to the transac tion and an Access Set containing objects already accessed by the transaction. A transaction may transfer an object in its Access Set to another transaction via delegation. The activity of delegation makes the state and partial results of the delegator become visible to the delegatee. The ACTA framework presents a simple way to define dependencies between transactions for the reasoning of the behaviors of the transaction. Commit Dependency and Abort Dependency are known as completion dependencies. If Transaction A develops a commit dependency on Transaction B, Transaction A cannot commit until Transaction B either commits or aborts. If Transaction A develops an Abort dependency on Transaction B, and if Transaction B aborts, Transaction A should also a bort. ASSET [BIL94] is a flexible transaction facility based on a set of transaction primitives. These primitives are designed according to the principle of ACTA, and can be

PAGE 80

67 used to define customized transaction models for specific applications. Many of th e existing advanced transaction models can be specified with ASSET. It is also possible to use ASSET to specify activities or workflows that normally has transaction like properties. ASSET is actually an implementation of ACTA. Basic primitives in ASSET i nclude, initiate(), begin(), commit(), wait(), abort(), self(), and parent(). Special primitives are setup for the functions of ACTA including delegate(), permit(), and form_dependency(). These primitives can be used for the description and execution of tr ansactions. In research incorporating DOM model, CTM [GEO96] addressed the issues about application specific transaction model in the circumstances when distributed object system are involved. The primary value of CTM is to provide a framework about handl ing objects in heterogeneous, autonomous, and/or distributed (HAD) systems and detailed descriptions and reasoning about correctness criteria. CTM provides facilities to ensure the correctness and reliability of distributed applications by supporting cus tomized transaction model according to the specific requirement of each application. The CTM framework can handle not only transactional objects but also transactionless objects with no transactional support at the local systems. Transaction Design The f irst step to build a transaction based implementation for the EPIC model is to transform business procedures on construction projects into transactions. Common business procedures are i dentified through extensive study of the practice of construction proj ect management. The system processes and transactions are designed based on the analysis of the basic elements of the business procedures and their interactions with the project information. Customized transactions are needed to cope with the various impa cts

PAGE 81

68 to project information brought by the business procedures. Multi level hierarchy and ACTA properties are the two primary features of the advanced transaction model incorporated in the design of the transaction system for the EPIC system. The transact ion design for the EPIC system adopted from the DOM study the transaction structure with two levels of hierarchies. A multitransaction contains three types of steps, subtransaction, decision and message Subtransactions carry out activities that need to ac cess remote databases. The Message is simply a step that a communication needs to be sent to a remote site and an answer is required. Decision steps are the checkpoint in the transaction where decisions are made regarding if the transaction is successful. Multitransactions, which are combinations of subtransactions and messages in a certain way, are representations of business procedures in the EPIC system. The occurrence of a certain event requires a business procedure to be initiated and in turn trigger s a corresponding multitransaction in the EPIC system. Multit ransactions behave either as a flat transaction or advanced transaction with steps depending on the nature of the business procedure the transaction represents. During the execution a multitransa ction has three states, execution, commit or rollback. Multitransactions at execution state read, modify the shared project information, or send collaboration messages as may be required by the business procedure. A multitransaction at commit state simply removes all locks and finalizes the modifications made to the shared project information. In the case of rollback more complicate operations are required within the system. Compensating transactions are used to eliminate the effects of the partially execut ed multitransaction during rollbacks. Details

PAGE 82

69 and the reasons for the rollback are sent back to the initiator of the transaction. So the initiator is able to modify the parameters of the previous transaction and to try to execute again after receiving the information carried with a rollback. The concepts from the ACTA framework are implemented within the distributed database and the transaction design. The strategy of handling failed transactions is through rollbacks and reviews. The lock mechanism for th e distributed database is specifically designed with the notions of ACTA framework. An ACTA lock allows any users to read the locked information however has to register with the user ID and the execution status. If a rollback ever occurs any readers with d irty read will be informed accordingly. Specification Language for Customized Transactions The design of a multitransaction for a business procedure is based on the actual practice on a construction project and may vary from one project to another. The u sers of the EPIC system should have a certain level of flexibility in designing multitransactions with predefined rules. A simple language is designed in EPIC for the users to specify transactions based on the needs of their business operations. A scenari o is used to show how the language represents a business procedure in the format of transaction. The EPIC system maintains two types of distributed databases, a simple database for currently available materials and resource, and a building model with highe r level complexities. Five types of actors exist in the EPIC system, owner, architect, engineer, contractors, and suppliers. The operations on the distributed databases are represented with subtransactions in the transaction format. A complete list of pos sible operations against the distributed databases is shown in Table 4 4. The operations on distributed databases as well as the

PAGE 83

70 actors are coded as part of the specification of the language. Other two basic elements of the transactions are message (M) and decision (D). Table 4 4. List of valid database operations Code Database Description Valid User P00 Building Model Read in product model information ARC, C, ENG, OW P01 Building Model Pre update of product model ARC, C P02 Building Model Final update of product model ARC, C P03 Building Model Direct update of product model C, ENG P04 Building Model Mark the product model OW, C R00 Resource Listing Reserve resource ARC R01 Resource Listing Update resource list C S00 Material Listing Reserve materia ls ARC, C S01 Material Listing Update materials list S Note: Owner(OW), Architect(ARC), Engineer(ENG), Contractor(C), Supplier(S) Transactions are composed of steps, which are container of the basic elements, namely, subtransaction, message, and decisio n. Steps can be simple or composite as shown in Table 4 5. Table 4 5. Code and content for steps Type Code Content Meaning Composite A Steps Alternative, successful if any member step is successful Composite C Steps Concurrent, successful if only all member steps are successful Simple S Subtransaction, or message A simple step equal to its content Simple D Decision A simple decision step. Figure 4 5 shows an example of a business procedure to check and determine whether there are enough resources available to make the changes proposed by the architect. The procedure shown in Figure 4 5 is one of the possible scenarios that could occur when an architect is proposing a change to the project. The architect needs to check the availability of critical materials from suppliers and labor and equipments from the contractors. If all the prerequisite conditions with regards to the materials and resources are met, a request will be sent to the owner for approval. The architect proceeds to the design stage up on approval of the owner.

PAGE 84

71 Alternative procedures are available to check the contractors resources and the suppliers materials for availability. It is assumed that the resources and materials could be obtained from different sources. If the first attempt to get a resource or material from a certain contractor or supplier fails, another attempt will be made towards another contractor or supplier. The failure of either of the first two stages will result in the failure of the entire procedure. Another cause of failure occurs when the owner rejects the change request. Figure 4 5. Sample business procedure: the architect proposes a change The specification language designed for this study can be applied in this case. The procedure as shown in Figure 4 5 can be represented with simple code like this: A(R00, *) D A(S00, *) D S(P04) S(M, OW) D Steps of transaction are delimited with . A single content code is specified for either a composite or simple step. The second code within the bracket indica te the target of the content code, which could be the receiver of a message or the location of the N Start Check C1 Check C2 Check Cn Y Y Y N Y N Check S1 Check S2 Check Sn Y Y Y Y N Y N Design Starts Upload Msg Review Transaction fails, rollback, restart Check C ontractors Resource Check Suppliers Materials Owners Review Update Decision Start Process C1, C2, Cn are contractors; S1, S2, Sn are suppliers.

PAGE 85

72 database to which the subtransaction should be sent. In the case where no target code is present, the target uses a default value. For example the scenario p resented above has only one building model, so the default target code of S(P04) is ARC. A target code * means all targets that the specific content code may apply to. For example, R00 is a subtransaction for checking resource of the contractors, * means all contractors. Prototype and Programming The section provides programming details about the prototype. UML diagrams are used to illustrate the structure of the prototype as well as the functionality and dynamic aspects of the system. Structure of the Prototype The efforts of implementing the EPIC model results in a distributed software system that is capable of providing functionality as specified in the model. The primary technology used in the development is Java and CORBA. Figure 4 6 is a cl ass reference diagram showing the relationships between the components of the prototype system. Procedure definitions component contains syntax of a simple language that allows the users to define procedures according to their needs. Some predefined proced ures have been provided and used in the tests. Procedure execution component actually is a software engine that is capable of interpreting and executing the user defined procedures. A substantial amount of the steps in the procedures incur activities that access the shared database system. The synchronization and data integrity of the database is maintained with an advanced transaction system. Other type of activities that are involved in the execution of the procedures is message passing and decision makin g. This part of the functionality is accomplished through sending system calls to the coordination and control component.

PAGE 86

73 Figure 4 6. Class reference diagram of the EPIC system The entire system that contains multiple copies of the actor cla sses is started simultaneous with a single starter program. Each actor will initialize and start up the client side (procedure definition and handling) and the server side (shared information objects). Classed for various types of information are defined in the system. Project information such as the members of the project team and the parameters for initialization of the shared databases are stored in a ProjectInfo class. Both client side and the server side of the actor read in project information durin g the initialization process. Information objects identified in the prototype include message, materials, resources, and building Message com.hlu.information Resource com.hlu.information Material com.hlu.information BuildingComponent com.h lu.information Procedure Definitions TransGenerator com.hlu.client ProcedureFactory com.hlu.client ProcedureLibrary com.hlu.client ProcedureDefinition com.hlu.client InfoObjectPool com.hlu.client Shared DBs ShareInfoObject com.hlu.starter Building com.hlu.server ACIDLock com.hlu.server ACTALock com.hlu.server Catalogue com.hlu.server Catalogue com.hlu.server Lock com.hlu.server Reservation com.hlu.server MTransaction com.hlu.transaction Step com.hlu.transaction STransaction com.hlu.transaction Procedure Execution Dispatcher com.hlu.client CorbaAdaptor com.hlu.client Decorder com.hlu.client Coordination and Control CoordinationAgent com.hlu.client MessageHandler com.hlu.client Actor com.hlu.starter Project Info com.hlu.information

PAGE 87

74 components. A transaction system with two level semantics is used for the implementation of the procedures. Figure 4 7. Deployment diagram of the EPIC System Deployment Diagram The deployment diagram of the prototype shows the physical view of the system. The relationship between software components and the layout of hardware is illust rated in Figure 4 7. The system can be deployed on a group of computers that are connected with a network. The CORBA naming service is the basic facility that enables the actors find out the existence and location of other actors. Each actor registers a me ssage handler and a distributed database if required with the CORBA system. The coordination agent, which is the client side of the actor, looks up the location of other actors by name in order to make contact with them. Definition of Transactions The ac tivity diagram in Figure 4 8 shows how a predefined procedure is converted to a transaction in the prototype. Transaction templates are prepared in the CORBA Naming Service List of Remote Objects Actor 1 (Architect) Server side: Distributed DB Client side: Coordination Agent Message Handler Actor 2 (Contractor) Server side: Distributed DB Client side: Coordinatio n Agent Message Handler Other Actor Communication Links Register Register Lookup Lookup

PAGE 88

75 object ProcedureFactory during the initialization of the prototype according to the definitions specifie d in the object ProcedureDefinition. Users of the system may use a language with simple syntax and grammar to define customized procedures in their system. At run time if a user program need to access shared databases with external processes, a request is generated and sent to the object CoordinationAgent. The object ProcedureFactory handles calls from the object CoordinationAgent in regarding the needs for a transaction. The call is validated at the object ProcedureLibrary against the existing set of pred efined transactions. If it is a valid call, a transaction template is returned to the ProcedureFactory. Figure 4 8. From predefined procedures to system transaction TransGenerator InfoObjectPool ProcedureFactory ProcedureLibrary ProcedureDefinition Initialize a library Read information requirements Return a proper definition Building a procedur e template Read in a predefined procedure Decode steps Validate steps Save steps Decode targets Validate targets Build another Prepare a procedure Validate procedure code Prepare information for the procedure Decode the definition Build a transaction componen t Build a transaction

PAGE 89

76 Project information needs to be provided along with the procedure call For practical purpose the information in the prototype is prepared in the object InfoObjectPool. In realty this step should be completed with the intervention from the system operator. The ProcedureFactory retrieves transaction component from the object TransGenerator according to the transaction template. The transaction is finally assembled at the ProcedureFactory with the transaction components and information objects from the InfoObjectPool. Execution of the Transactions Transactions are executed wit hin a set of classes that form an engine like facility. The activity diagram in Figure 4 9 shows the process of transaction execution. Figure 4 9. Execution of a prepared transaction The execution of the transaction comes after the Coordinati onAgent obtains a transaction object from the ProcedureFactory. The transaction object is sent to the Rollback CorbaAdaptor CoordinationAgent Dispatcher Decoder Build a transaction Execute transaction Identify step Decode steps Identify target Contact info object Execute steps Analyze results Commit Success Fail Decode target Identify target Contact info object Decode target Identify target Contact info object Decode target Inform other actors about the rollback Contact message handler Repeat the transaction

PAGE 90

77 Dispatcher and decoded into steps. A Decoder object needs to be accessed to determine the types of the steps. An identified step is sent to the CorbaAdapt or. Depending on the nature of the step the CorbaAdaptor contacts a remote information objects as indicated as target. The results of steps are returned to the Dispatcher and analyzed. If the transaction is executed successfully, the commit stage begins. O therwise the transaction undergoes a rollback and all traces of the execution will be eliminated through sending messages to any party that has dirty read. The Dispatcher automatically restarts any unsuccessful transactions. Figure 4 10 is a higher lev el diagram about the definition, transformation, and execution of the transactions. The users view shows an example of what could happen in an actual construction project. Project information needs to be used and updated from time to time along with the p roceeding of the physical activity of the construction. Systems View is a general description about what happens in response to the activities in physical world. The system provides support to the user activities transparently by using transactions to con tact remote data source. Figure 4 10. System view and user view Systems View User s View The EPIC system Transaction Access Feedbacks Steps Predefined Procedure Pool Adaptor Transaction Engine Feedbacks Remote Sites Construction Activities (example, build a wall) Read or update shared information Contact Project Databases (product model and other shar ed information) Client Applications (example Primavera)

PAGE 91

78 Interactions among the Actors Interactions occur among the actors as a result of the business operations of each actor and the dispatching of transactions (procedures). A coll aboration diagram as shown in Figure 4 11 is used to demonstrate the interactions between a group of actors. The diagram shows basic operations regarding information access and handling of rollbacks caused by dirty reads. The actors share the same structur e as shown in the figure. However only part of their functions are active for each of them to illustrate a snapshot of the entire collaboration picture. Figure 4 11. Collaborations betwe en actors The collaboration process initiated with steps sent out by the Dispatcher object. The CorbaAdaptor identifies the target and makes a call to it. Before getting to the database, the call has to go through a Lock object. A lock is placed if necessa ry and the Actor 1 CorbaAdaptor Dispatcher MessageHandler Datab ase Lock 1: result = step Reviewer Rollback List Actor 2 CorbaAdaptor Dispatcher MessageHandler Database Lock 4: result = call() Reviewer Rollback List 3: register(reader) Actor 3 CorbaAdaptor Dispatcher MessageHandler Database Lock 6: interrupt(n) Reviewer Rollback List 7: review(n) 2: result or rollbacklist = call() 5: if rollback broadcast(rollback list)

PAGE 92

79 information from the reader are register in case rollback is needed. Afterward the call goes on and accesses the database. The lock is removed if the final result of the transaction is a success. Otherwise a rollback list is returned and a rollb ack process is initiated at the original Dispatcher. A rollback signal is broadcasted to the MessageHandler objects of the actors on the rollback list. The MessageHandler takes the signal and interrupts the progress of the Dispatcher. A review process is s tarted to find out what has to be done to cope with the earlier dirty read. Outstanding Issues and Future Works The prototype developed according to the EPIC model is capable of handling simulation with simple procedure calls and scenarios. Tests have been conducted to verify the potential benefits of using such a system and resolve technical issues. Additional works is needed in various aspects before the system is adopted in actual application. Customized definition of user procedures is an important fun ction that the system should provide. The existing method coded the definitions and the language into the program as a static java object. It is possible to replace the ProcedureDefinition object with a proper user interface and definition tools. Equipped with the knowledge of some simple rules, the system operators will be able to specify customized procedures according to their needs. The operations of the system are eventually assisted with a higher level programming upon the system. The transactions a re designed to operate on java objects that are independent of the local system. It is necessary to provide adaptors that handle the interactions between the information objects and the user programs. Because of the variety of the user

PAGE 93

80 programs that are po tentially involved the adaptors have to be studied and designed using case by case method.

PAGE 94

81 CHAPTER 5 CASE STUDY AND TESTING Tests have been conducted within the EPIC system in order to validate its functionality and benefits as well as to identify any potential research issues. Test methods from previous integration research were analyzed and compared to form a basis for the proper design of the test plan for this study. The test plan consists of three levels of tests targeting issues related to the benefits and technical solutions of the system. The scenarios used in the tests are change procedures that occur during construction stage of a construction project. Assumptions and simplifications have been made to the actual procedures found in construction projects. Review of Test Methods from Previous Studies Soundness of the test methods is critical to t he success of the study. Test methods from similar studies are analyzed and compared in Table 5 1. Many studies have attempted to conduct certain type of testing in accord with the nature of the study. The most common method regarding to testing is proof o f concept with implementation. For example, a unique method called charrette was used during the design process in the CIFEs IFC trial implementations. Many existing integration systems claim the applications of a certain system may bring benefits such a s facilitating the communications between the parties and process optimization. It has become a difficult issue to verify the benefits as claimed without extensive applications on actual projects. Unverified benefits are one of the reasons that the industr y is not willing to accept the various systems that have diligently been

PAGE 95

82 developed. On the other hand the large scale applications are not possible without their acceptance by the construction industry. The catch 22 situation as shown in Figure 5 1 has prevented further progress of the research and development of integration systems. Figure 5 1. Catch 22 that troubles the progress of integration systems Table 5 1. Comparison between test methods Studies Technical Solution Test Scenarios OPIS pr ototype, [FRO92] Object oriented data model, databases Prove of concept NA Building Project Model, [LUI98] Prototype with modeling tools Prove of concept Concrete structures Cross Sector Business Model [YUM98] Reference to distributed facility NA Biddin g and contracting The COMMIT Project [REZ98] Information and document management, and version control. Prove of concept Changes by architect in concurrent context. CIFE IFC Trial Implementation [FRO99a] IFCs, modeling tools, and databases Charrette st yle, prove of concept Represent two walls with IFCs CIFE system Architecture [FRO00] IFCs, and software packages for construction prove of concept Changes during construction Robust Mediation of Construction Supply Chain, [OBR01] Query processing and wra ppers Prove of concept Activity rescheduling EPIC Project Model, H. Lu, 2002 (This study) Rule based, transactions, and distributed facility Comprehensive test including prove of concept, simulation and analysis Changes during construction stage Test Plan The objective of test plan is to study the potential benefits and effectiveness of the technical solutions of the system. A comprehensive test plan with three levels of tests are used to study various issues: Verification of the Benefits Acceptance by Industry Large Scale Applications

PAGE 96

83 Proof of concepts: shows the possibility of building a system based on the implementation of the ideas as presented in the EPIC model Demonstration of Functionality: uses simulations to validate the EPIC systems capability to support the formation of a change order and conduct sensitivity analy sis of the performance variables to study the factors that have impact on the efficiency of the system. Performance of the technical solutions: uses tests of the enforcement system for advanced transactions and the shared database system. Proof of Conce pts The concepts presented in the EPIC model are tested with the implementation of the EPIC system. A prototype system based upon a distributed infrastructure has been developed and provides the following functionalities: Simple syntax and specifications for advanced transactions with two level semantics of the transactions as a tool for the collaboration between the participants A software engine that is able to recognize and execute an expandable set of transactions. Modeling and design of common roles and actors found on construction projects and shared information sources. The development of the prototype shows that it is possible to build a transaction based system for the collaboration task among participants on construction projects. The model an d implementation presented in this study can be adopted as a basis for the further development of a workable system in real world applications. Demonstration of Functionality: A Case Study A case study with a simplified construction project was conducted as part of the test plan for the EPIC model. The validation of the proposed model was conducted from both qualitative and quantitative aspects. The primary objective of the case study was to demonstrate the functionality of the system in support of the bus iness processes on construction projects by using the formulation of a change order as an example. The

PAGE 97

84 contributing factors that have impact on the system functionality were studied from the perspective of the operations on construction projects and a sens itivity analysis was conducted on these variables. Background Construction change orders are used as an example of construction processes that can be supported by the EPIC system. A complex decision needs to be made regarding a significant change on the existing design at the construction stage. The parties involved in the decision making process are the owner, architect, engineer, one contractor, and a number of suppliers. The changes are more complicated in nature than the cases involving a simple mater ial substitution. Additional design work is needed from both the architect and the engineer. The suppliers are involved only to provide availability and pricing information for critical materials. Issues such as the constructability and the availability of key materials have critical impact on the design work and need to be considered during the design. Data about change orders collected from the Rinker Hall project [SMA02] at the University of Florida are used to estimate the turn around time for various types of steps found in typical change order processes. Rinker Hall is the new home of M.E. Rinker Sr. School of Building Construction. The $8 million building is a composite concrete and steel structure with 48,000 square feet. The construction began in November 2001 and will be completed in December 2002. Assumptions Assumptions and simplifications are made based on actual construction projects for the purpose of the case study. Format and ownership of project info as well as basic system requirements fo r the members of the system are described below.

PAGE 98

85 It is assumed that the product model is a viable method to represent the building. Complete architectural and engineering design and specifications for the project is available in the format of a building model and stored at a centralized location. The architect provides the initial design information. The contractor provides updates to the building model with information generated along with the construction activities. It is also the responsibility of the contractor to provide the availability and pricing information of the contractors extra resource, such as labor and equipment. Suppliers provide the availability and pricing information for construction materials. The resource and material information is stored in the format of a shared database so that the other project team member may have access to it. Agreement has to be reached among the members regarding the ownership and uses of the shared information before the initialization of the system. The a rchitect has full control over the building model. The contractor has limited capability of updating the building model. Every party except the supplier has the right to read the relevant content of the building model. The only user of the contractors res ource database is the architect. Both the architect and the contractor may read the suppliers resource databases. It is assumed the project participants have various level of capability to use information technology for the project. The minimum system re quirement is a PC with network connection. An agent application and a database (if needed) need to be installed on every computer. For example, the contractor needs to install a resource database on their computer. However the owner need only an agent appl ication. It is not required that the participants have to use computer applications that are compatible with each other. The only requirement is that the computer applications need to be able to update the

PAGE 99

86 shared database from time to time. The collaborati on activities between the participants are accomplished by a CORBA interface. Therefore a dedicated computer is used to provide naming service to the entire group of users. Simulation The formulation of the change order is accomplished with the assistanc e of the EPIC system. The exercise shows how the participants interact with the system during the process. Hypothetical data sets were used to initialize the shared databases. Figure 5 2 shows a flow chart about the process of making a change. Figu re 5 2. Formulation of a change order The entire process starts with a change of mind by the owner. The owner initiates the process by sending a message to the architect. The message contains a reference to a certain part of the building model that is in question. Before sending the message, the owner has inserted a flag in the building model and made some comments indicating the owners intention. It is assumed that this approach is sufficient to convey the idea of the owners to the architect. In reality the client briefing could be a very complicated process. Extensive activities outside of the system such as phone calls and meetings could be involved. However a flag in the shared building model is able to make all relevant parties aware of the ongoing i ssues with this particular part of the building. Modify the Design Final Review Owner Design Review Contractor Constructability Review Supplier Availability Yes No Owner Ideas Architect Architectural Design En gineer Engineering Design Signed Change Order

PAGE 100

87 The architect acts as a leader of the entire process from then on. As shown in Figure 5 2, architectural design is conducted within the scope of the architects computer system and uploads to a temporary l ocation in the shared building model after completion of the design. The engineer is informed and provides engineering design based on the initial architectural design obtained from the building model. The software applications used by the engineer should be capable of importing data from the building model. A commonly accepted information standard is definitely needed for a rich information exchange like this. After being informed that the entire design is ready, the architect initiates a review process b y sending out messages to the relevant members of the project teams. The owner checks the completed design against the original intentions. The contractor may conduct a constructability review and check if there is any conflict between the new design and t he existing works. At the same time an availability and pricing query will be sent to the suppliers via the system if any critical materials are specified in the design. Each supplier needs to provide to the contractor the availability and best price of th e materials. The contractor places a pre order for the material with the supplier that quotes the best price. The results of the joint review by the owner, the contractor and the suppliers are sent to the architect as shown in Figure 5 2. Simple reasoning is made regarding whether a positive answer has been obtained. If so a signed change order will be produced and sent to the contractor. Otherwise the system will start a rollback process to remove any residual effect. If a preorder has been placed, the sys tem will automatically cancel it. The architect will study the reason for any negative answer and modify the current design for

PAGE 101

88 the change. Another round of the negotiations will begin after completion of the modification. The leader of the process, the a rchitect, defines the process of making changes as a routine with the specification language shown in Chapter 3. The EPIC decodes the predefined "routine" and initiates the collaboration activities among all relevant parties. Table 5 2 is a summary of th e steps of the entire process. Inputs are the information needed for a certain participant to complete a step. Outputs are the results of executing a certain step by a participant. Some steps require the participants make a decision about if the process ca n proceed while others do not. Table 5 2. Steps in the change order procedure Steps Parties Tasks Input Output Decision 1 Owner Suggest a change Read in the current status of the project from the shared project database Upload the description of the r equirements to the shared project database N 2 Architect Architectura l design Get the change requirements from the shared project database Upload the completed architectural design to the shared project database N 3 Engineer Engineering design Get the co mpleted architectural design from the shared project databases Upload the completed engineering design to the shared project database N 4 Owner Design review Read in the completed design from the shared project databases Send an approval or disapproval t o the architect Y 5 Contractor Constructabi lity review Read in the completed design from the shared project databases Send an yes or no answer to the architect Y 6 Suppliers Preorder critical materials Receive an order with type and quantity of the mate rials Send material availability and price to the contractor Y 7 Architect Issue change order or go back to step 2 Receive others decision from previous steps Send A signed change order to the contractor Y The involvement of the EPIC system is more th an facilitating the messaging for the decision process on construction projects. Project information needed for the

PAGE 102

89 decision making process can be acquired from the shared information source directly and instead of being carried along with the paperwork, a s is the case in many actual construction projects. The system also provides simple reasoning and a certain level of automation during the process. No logical error was found within the system through the simulation of the change order generation proces s. The project information can be delivered from one party to another. The messages and decisions are passed and received correctly. The simplified reasoning mechanism works as expected. Sensitivity Analysis of the Performance Variables The simulation show s that the system is able to successfully execute a single case of making a change order. Additional study is needed to investigate the systems capability of handling different kind of procedures under various conditions. Key factors and variations in pro cedures are identified in order to conduct a sensitivity analysis of the performance variables to study the efficiency of request processing within the system. The EPIC system with customized procedures being executed within is a discrete events system (D ES), which is defined as a dynamic system that evolves in time with the occurrence of events at possibly irregular time intervals [ARS02]. A DES often has a large number of control parameters that can have a significant impact on the performance of the sys tem. In this particular case execution time of the procedures is the measurement of the function in question. Initial analysis of variables indicates that the function has multiple parameters within two groups as below. Group 1: duration of individual ste ps. The time for an individual step found in a procedure to finish varies from one instance to another. For example, the time for an architect to finish design for a change order is different from the time for the engineer to finish engineering design. The variation and relative values between the step times has a potential impact on the efficiency of the execution of the entire procedure.

PAGE 103

90 Group 2: rejection rate. The rejection rate is defined as the chances of rejection when the individual decision makers make a single decision. The cumulative rejection rate from each participant can be used as an indication of the complexity of the entire decision problem. Variations also come from the physical structure of the procedures that occurred in the EPIC system Figure 5 3 shows a variation of the change order procedure in Figure 5 2. From this point on these two procedures will be referred as Procedure A as in Figure 5 2, and Procedure B as shown in Figure 5 3. The two procedures are functionally equivalent. Th e primary difference between them is that an additional joint review session was inserted in the middle of the design process of the Procedure B. The new arrangement represents a method to exploit concurrencies in the process. It allows the parties holding stakes in the project to provide early input to the proposed design. Theoretically the chances of discovery of disagreement are split between the two review sessions. Figure 5 3. Variations in the change order procedure A plan for the sensitiv ity analysis of the performance variables was designed with consideration of the duration of steps, rejection rates, and variation of the procedure. Rejection rate plays a central role in the plan. The execution time for each individual step fluctuates wit hin a certain range. The execution times for both Procedure A and Early Review Owner Design Review Contractor Constructability Review Supplier Availability Late Review Owner Design Review Contractor Constructability Review Supplier Availability Owner Ideas Archite ct Architectural Design Engineer Engineering Design Yes No Signed Change Order Yes No Modify the Design

PAGE 104

91 Procedure B are measured under the scenarios produced by the combination of the rejection rate and the step time. The introduction of Procedure B brings another factor into the picture. The ratio between the two review sessions in Procedure B, which will be referred as the E/L ratio, indicates the capability of discovering disagreements in the early review session. For example, an E/L ratio that equals 0.6 means that 60% of the differences between the decision makers can be discovered in the early review session. The E/L ration as used in the analysis is a collection of 6 sample points between 0 and 1.0 inclusive. It is reasonable to assume that key construction material requirements can be identified before the early review. Therefore the rejection rate of the supplier is allocated entirely to the early review. To simplify the situation all participants except the supplier in Procedure B share the same rejection rate in a certain review se ssion. The rejection rate found in the single review session in either procedure is defined as the Primary Rejection Rate. In Procedure B the actual rejection rates of the two review sessions is either the product of the primary rejection rate and the E/L ratio or (1 E/L ratio). The primary rejection rate that ranges from 0% to 50% is able to cover most common cases found in construction project. A 0% means no rejection occurs in any decision made. A 50% rejection across the broad is considered as a ridicul ous high level of disagreement between the decision makers. Table 5 3 shows a combination of the individual rejection rates of all decision makers. The sensitivity analysis of the performance variables was conducted using the data from the table. The exe cution time for individual steps are chosen from computer generated

PAGE 105

92 Table 5 3. Combination of individual rejection rates (%) E/L Ratios Primary Rejection Rate Reviews Reviewers 1.0 0.8 0.6 0.4 0.2 0 R1 All 0 0 0 0 0 0 Supplier 0 0 0 0 0 0 R2 Others 0 0 0 0 0 0 Supplier 0 0 0 0 0 0 0% R3 Others 0 0 0 0 0 0 R1 All 10 10 10 10 10 10 Supplier 10 10 10 10 10 10 R2 Others 10 8 6 4 2 0 Supplier 0 0 0 0 0 0 10% R3 Others 0 2 4 6 8 10 R1 All 20 20 20 20 20 20 Supplier 20 20 20 2 0 20 20 R2 Others 20 16 12 8 4 0 Supplier 0 0 0 0 0 0 20% R3 Others 0 4 8 12 16 20 R1 All 30 30 30 30 30 30 Supplier 30 30 30 30 30 30 R2 Others 30 24 18 12 6 0 Supplier 0 0 0 0 0 0 30% R3 Others 0 6 12 18 24 30 R1 All 40 40 40 40 40 40 Supplier 40 40 40 40 40 40 R2 Others 40 32 24 16 8 0 Supplier 0 0 0 0 0 0 40% R3 Others 0 8 16 24 32 40 R1 All 50 50 50 50 50 50 Supplier 50 50 50 50 50 50 R2 Others 50 40 30 20 10 0 Supplier 0 0 0 0 0 0 50% R3 Others 0 10 20 30 40 50 Note: R1 Final Review as in Procedure A R2 Early Review as in Procedure B R3 Late Review as in Procedure B values. A value range was defined for each step based on the study of the change order cases collected from the Rinker Hall project. A random val ue is generated for each step at run time within the specified range. For example, the design time by the architect ranges from 8 12 days. The computer picks a number between 8 and 12 at each run and uses it in the simulation of the change order procedure. The reason to use this method is that randomized execution time is closer to the situation in the real world. However

PAGE 106

93 because of the variation of the input (execution time of the steps) more simulation runs are needed in order to get a stable average exec ution time. Table 5 4 shows the ranges of execution time for individual steps found in the change order procedures. The review sessions from the two equivalent procedures need the same amount of time because no matter what the general procedure is the same amount of details have to be checked in a review session. What makes a difference is the iteration in the execution of the procedure. It is reasonable to assume that the modification of the design in the iterations following rejections takes less time tha n the original design work. The design work in the iterations other than the first one takes only half amount of time to finish. In the EPIC system, the execution times are represented proportionally with a time unit as defined by the program instead of us ing days ( 1 day = 100ns). The time intervals are simulated with suspension of execution in the program. Table 5 4. Ranges of execution times of individual steps (Days) Activities Time (First Iteration) Time (Other Iterations) Owner: Ideas 4 10 2 5 Architect: Architectural Design 12 20 6 10 Engineer: Engineering Design 10 15 5 7 Joint Review in Procedure A 4 7 2 3 Joint Review (I) (II) in Procedure B 4 7 2 3 Forty (40) instances of procedures with twenty (20) for each type are fed into the EPIC system under scenarios generated by the combinations of the primary rejection rate and the E/L ratio. Execution times of the procedures are measured. Table 5 5 shows the average execution times calculated from the data collected from the simulation for al l the scenarios. Two types of procedures are executed alternatively within the system to reduce any system errors. The program produces a yes or no answer to any decision request

PAGE 107

94 based on a predefined rejection rate. Each actor generates a set of output f iles that records the operations of different parts of the program. The execution time is recorded in the file generated by the EPIC system collaboration agent. Appendix B shows an example of the output files. Figure 5 4 shows the charts generated with t he data collected from the simulation. The sensitivity of the execution time regarding the primary rejection rate and the E/L ratios is demonstrated in six charts. The study found some typical relations between the system efficiency and the variables in q uestion. Table 5 5. Average execution times of Procedure A and Procedure B (Days) E/L Ratios Primary Rejection Rate Procedure Type 0.0 0.2 0.4 0.6 0.8 1.0 A 40.50 42.00 42.00 40.00 40.50 39.00 0% B 58.00 57.50 59.00 57.00 58.00 55.00 A 52.0 0 45.00 48.50 47.00 49.50 49.50 10% B 61.00 59.00 63.00 57.50 54.50 51.50 A 46.00 61.00 60.50 51.50 59.00 48.50 20% B 63.50 64.00 74.00 64.50 67.50 56.50 A 52.50 62.00 58.00 67.50 77.00 73.50 30% B 81.00 78.50 68.50 75.00 77.50 59.50 A 94.50 99.50 119.50 106.50 126.50 110.00 40% B 132.00 109.00 97.00 77.50 85.00 90.00 A 132.50 174.00 156.50 190.00 172.50 195.50 50% B 184.50 132.00 138.50 119.50 134.00 83.50 The rejection rate, which indicates the complexity of the design problem, has significan t impact on the execution time of the procedures regardless of the procedure types and the E/L ratio. All charts show that the execution time increases along with the increase in the rejection ratio although the degree of increases varies in different occa sions. The E/L ratio, which indicates the structural characters of the procedures, also has a certain level of impact on the execution time. A low E/L ratio indicates that the early participants from the relevant parties are not able to discover errors ea rlier in the change

PAGE 108

95 order process. In this case Procedure B almost certainly takes more time to finish than Procedure A does. The benefits increase gradually with the E/L ratio shifting to the higher end. However the disadvantage shown by Procedure B at lo w rejection level has never been able to be compensated with the positive effects brought by high E/L ratio. Figure 5 4. Comparison of the average execution time for Procedure A and B E/L Ratio = 0.0 0 50 100 150 200 0 10 20 30 40 50 Primary Rejection Rate (%) Execution Time (Days) E/L Ratio = 0.2 0 50 100 150 200 0 10 20 30 40 50 Primary Rejection Rate (%) Execution Time (Days) E/L Ratio = 0.4 0 50 100 150 200 0 10 20 30 40 50 Primary Rejection Rate (%) Execution Time (Days) E/L Ratio = 0.6 0 50 100 150 200 0 10 20 30 40 50 Primary Rejection Rate (%) Execution Time (Days) E/L Ratio = 0.4 0 50 100 150 200 0 10 20 30 40 50 Primary Rejection Rate (%) Execution Time (Days) E/L Ratio = 1.0 0 50 100 150 200 0 10 20 30 40 50 Primary Rejection Rate (%) Execution Time (Days) Procedure A: a common procedure to make a change Procedure B: a variation of Procedure A

PAGE 109

96 Conclusions The tests and simulati ons show that the system is able to accomplish a simple task of generating a change order. Change order procedures that involved the collaborations of all relevant parties are successfully executed within the EPIC system. The functionalities of information exchange and simple reasoning were verified through the tests. Further investigation about the factors and conditions regarding the efficiency of the EPIC system were conducted through a sensitivity analysis of the performance variables based on a comp rehensive simulation plan. A limited space of efficient functioning for the EPIC system was found regarding the variables including rejection rates, E/L ratio, and the variance of the procedures. Given the proper configuration and adjustment the EPIC syst em is able to provide efficient support to the collaboration between project participants. Tests for Technical Issues The third level of the test plan is in regards to the technical solutions designed for the EPIC system. Because of the distinct features of the system process such as longer running time, the implementation of the EPIC model requires support of advanced transaction system with a two level semantics. It is necessary to make sure the enforcement mechanism of the advanced transactions works e fficiently. Assumptions The tests are conducted with a simulation of the normal working condition on a construction project with the support of the EPIC system. A group of five actors are included, one instance of each, the owner, architect, estimator, su pplier, and contractor. The tests will be performed under the circumstance where activity flows are generated with certain rules to emulate situations that may occur in an actual construction project.

PAGE 110

97 This simulation is a more comprehensive exercise in com parison to the experiments from the preceding section. The joint execution of activity flows together by all actors creates a scene where a group of users are concurrently accessing and maintaining a group of shared information sources. The efficiency of t he advanced transaction system is closely related to the complexity of the activity flow. Higher occurrence of complex activities may impose pressure on the capability of the system. The execution times of individual activities are measured as in activity flows with various levels of complexity. Another indication of the system efficiency is the level of rollbacks and reviews. As a feature of the proposed technical solution for the enforcement of the transaction system, a dirty read is allowed to avoid lo cking on a certain resource by a single party for an extended long time. The resolution for a dirty read is to conduct a rollback that gives any party that has a dirty read a chance to review any process that may have been affected. However excessive rollb acks significantly reduce the usefulness of the system. The impact of the rejection rate upon the system has been studied extensively [LU02]. For the convenience of the test, the general rejection rate is set to a moderate level, 20%. Design of Activity Flow The activities in a construction project vary in different stages. A stable flow of activities needs to be maintained in order to run the tests against the system. Therefore the simulation uses a certain period of time in the midst of the construction stage. The processes of the startup and closing are not considered in the simulation to avoid unstable activity flow.

PAGE 111

98 A collection of common activities that may incur operations against the shared information sources is identified as shown in Table 5 6. Each activity has a specific meaning in an actual construction project as well as definitions in terms of the system processes that are involved. The notation used here follows the simple language as defined in Chapter 4. The collection of activities was designed for the purpose of the test only and is not intended to cover all possible application scenarios. Users may author additional activities according to the needs of their business operations. Table 5 6. Collection of activities Code Definitions Ac tivities M00 B Idle M01 A(R00, *) D A(S00, *) D S(P04) S(M, OW) D Architect prepares a change M02 S(P01) C(M, OW, C00, ENG) D S(P02) Architect or engineer updates the building model M03 S(P01) S(M, ARCH) D S(P02) Contractors suggest a change M04 S(P04 ) S(M, ARCH) D Owner suggests a change M05 A(S00, *) Contractors reserve materials M06 S(P03) Contractors record progress of the project M07 S(P00) Owner, architect, contractors, or engineer read in building information M08 S(R01) Contractors update th eir resource listings M09 S(S01) Suppliers update their material listings Activity flow is generated for each type of actor by the program according to predefined rules. The activity flows for actors include only activities that they are eligible to ini tiate. For each actor there are activities which occur recurrently and during special events as shown in Table 5 7. The routine activities occur on a daily basis while the special activities happen only according to certain frequencies. Generally special a ctivities contain complex structures and have more significant impact on the system operations when compared to routine activities. The frequencies of occurrence of special activities (complex activities) are used as parameters to create five tests. Assu mptions have been made regarding the occurrences of

PAGE 112

99 various type of activities. Because the activity set used in the tests is limited, the test with frequencies of occurrence at higher end actually represents generally a case with a very heavy workload rat her than a small number of activities occurring at ridiculously high frequencies. Table 5 7. Valid activities for different actors and test schedule Frequencies of Special Activities (times/mo) Actors Routine Special Test 1 Test 2 Test 3 Test 4 Test 5 Architect M07 M01+M02 2 4 8 12 16 Owner M07 M04 1 2 4 6 8 Engineer M07 M02 2 4 8 12 16 M03 2 4 8 12 16 Contractors M06, M07, M08 M05 3 6 12 18 24 Suppliers M09 The activity flows are sequentially executed as if they are incurred by t he business activities of the actors. An idle activity representing a single day is used to adjust the pace of the execution. It is assumed that routine activities, which happen every day, take little time to complete. Special activities, which occur rando mly, take whatever time is needed to complete. The execution time of each step of the transaction needs to be adjusted so that the system events may occur in a fashion similar to those in the real world. The synchronization between transactions and steps are implemented with suspension and resumes in the program. Table 5 8 shows some reasonable assumptions for these suspensions for the purpose of synchronization. Table 5 8. Execution times of system events Stages Activities Actual Time (ns) Time as Repres ented (Days) Initialization Wait before dispatching 5000 Idle procedure 1000 1 Interval between steps 1 0 Execution of Transaction Review rollbacks 1000 1 Decision making time 500 0.5 Servicing time for Remove calls Other remote methods 1 0

PAGE 113

100 Results and Analysis The complexity of activities may have a significant impact on the efficiency of the advanced transaction system. Activity flows with an increasing number of complex activities are generated and executed under observation. The average execution time for each type of complex activity is measured as an indication of the processing capability of the system. Amount and size of rollbacks are measured as an indication of interference between the system activities. Table 5 9 shows the exec ution data for complex activities under various test scenarios. The program randomly decides exactly how many instances of special activities occur in an activity flow. Therefore the occurrences of each type of complex activities generally increase from Te st 1 to Test 5, however they do not exactly equal to the amount computed based on probability. It was also determined that the average execution time for each complex activity used by a certain actor increases along with the increasing occurrence of comple x activities. Table 5 9. Average execution times of special activities Test 1 Test 2 Test 3 Test 4 Test 5 Actors Count Avg. Time Count Avg. Time Count Avg. Time Count Avg. Time Count Avg. Time Architect (M01) 6 0.67 10 1.20 14 1.07 21 1.48 29 1.52 Ar chitect (M02) 6 3.67 10 3.30 14 3.71 21 6.05 29 4.97 Owner (M04) 2 0.50 2 1.00 5 1.60 9 1.56 25 1.88 Engineer (M02) 3 3.33 5 3.6 9 4.89 27 4.67 36 4.5 Contractor (M03) 2 1.00 4 1.25 14 1.79 24 1.83 33 2.70 Contractor (M05) 3 0.00 15 0.00 30 0.00 36 0.0 0 27 0.00 Figure 5 5 shows the relationship between the occurrences of complex activities and average execution time. The primary frequency indicates the occurrence of special

PAGE 114

101 activities for architects. All activity types demonstrate a slight increasing trend along with the increase of frequencies. The detailed line features of a certain type of activity may be explained in associated with the structure and content of the activity. For example, the execution time of M01 and M02, which need to access the b uilding model, shows higher level of variations with the increase of the occurrences. 0 1 2 3 4 5 6 7 0 5 10 15 20 Primary Frequency (times/mo) Execution Time (Days) Architect (M01) Architect (M02) Owner (M04) Engineer (M02) Contractor (M03) Contractor (M05) Figure 5 5. Changes in the average execution time by procedure types Table 5 10 shows data collected about the rollbacks and review time s that occurred for each actor. The number of review sessions that results from rollbacks and the dirty reads are counted and measured. The number of review sessions significantly increases along with the increased presence of complex activities in the ac tivity flow. However the size of the each review session, which indicates the depth of backtracking, does not show significant increases. Figure 5 6 shows the relationship between the occurrences of complex activities and the number of review session that occurred. The tests found that the working conditions of the advanced transaction system have a correlation with the numbers of complex activities concurrently existing within the

PAGE 115

102 system. However the impacts are not as severe as expected. The execution of complex activities does indeed take a longer time to complete when the number of complex activities in the system is increased. But the increase is insignificant considering the fact that the occurrences of special activities have increased many more times Table 5 10. Occurrences and average size of reviews Test 1 Test 2 Test 3 Test 4 Test 5 Actors Count Avg. Size Count Avg. Size Count Avg. Size Count Avg. Size Count Avg. Size Architect 3 3.0 1 3.0 4 3.5 8 3.1 13 3.3 Owner 2 3.0 5 3.6 10 3.4 15 3. 1 20 3.1 Engineer 1 3.0 6 3.3 6 3.3 11 3.6 14 3.3 Contractor 1 4.0 1 4.0 3 5 13 4.6 12 4.0 0 5 10 15 20 25 0 5 10 15 20 Primary Frequency (times/mo) Occurrences (times) Architect Owner Engineer Contractor Figure 5 6. Occurrences of review sessions Prior to the study it was expected that the p rice to be paid for the advanced transacti on system is that the r ollbacks and reviews generate extra workload and delay within the system. However excessive rollbacks may jeopardize the efficiency of the functions of an advanced transaction system. A significant increase in the number of review se ssions has been observed as a result of the increase in complex activities in the activity flow. The level of review sessions has to be kept under a tolerable level

PAGE 116

103 depending on the complexity of the review process. The efforts would in turn impose a limit ation upon the level of complex activities within the system. A surprising finding is that the average depth of each review session does not dramatically increase, which helps to keep the relationship between the review sessions and complex system activiti es under or close to a linear relationship.

PAGE 117

104 CHAPTER 6 CONCLUSION AND RECOMMENDATIONS The initial motivation of this study was is to provide a viable solution to the integration problem that comes from the fragmentation of the c onstruction industry A conceptual model for construction project was proposed bas ed on the study of events, contract conditions and their impacts on the collaborations and interactions between the participants. The system is capable of providing supports to loosely coupled collaboration between the participants in construction projects Basic components of the model include actor, roles, processes and information objects. Events were identified as the major issue that the system needs to consider in order to conduct the collaboration work. An attempt was made to convert contract conditi ons into enforceable rules in the computerized systems. A prototype system as implementation of the EPIC model was built with Java and CORBA technology. A generic construction project with 5 types of participants was used as case study. Each participating actor plays a role either as architect, owner, engineer, contractor or supplier. Shared information objects are maintained at the participating actors according to their specific functionalities. The client side of every actor executes business procedures which in turn incur transactions in the system to interact with shared information objects either at local or remote sites. A set of business procedures and corresponding transactions are designed for each actor according to their roles and operations.

PAGE 118

105 The tests based on the case study have three levels and targets on various issues regarding the implementation system. Simulation of generating a complex change order was used to demonstrate the functionality of the EPIC system. The factors that have impa cts of the efficiency of the system were studied through sensitivity analysis. Improvement to the business procedures on construction project can be achieved with support of the functionality of the system. The efficiency of the technical solutions specifi cally designed for the system was also tested with a comprehensive exercise. Additional works is needed in various aspects before the system is adopted in actual application. Customized definition of user procedures is an important function that the syste m should provide. The existing method was to hard code the definitions and the language into the program as a static java object. It is possible to replace the ProcedureDefinition object with a proper user interface and definition tools. The transactions a re designed to operate on java objects that are independent of the local system. It is necessary to provide adaptors that handle the interactions between the information objects and the user programs. Because of the variety of the user programs that are po tentially involved the adaptors have to be studied and designed with case by case method.

PAGE 119

106 APPENDIX A ANALYSIS OF AIA A201 Article 1 General Provisions 1.1 Basic Definitions 1.1.1 The Contract Documents 1.1.2 The Contract 1.1.3 The Work 1.1.4 The Project 1.1.5 The Drawings 1.1.6 The Specifications 1.1.7 The Project Manual 1 .2 Correlation of the Contract Documents 1.2.1 The intent of the Contract Documents 1.2.2 Allocations of portions of the Work 1.2.3 Common meanings of the words 1.3 Capitalization 1.4 Interpretation 1.5 Execution of Contract Documents 1.5.1 Contract Doc uments need to be signed 1.5.2 Execution of the contract. 1.6 Ownership and use of Drawings, Specifications and others Article 2 Owner 2.1 General 2.1.1 The Owner 2.1.2 Information relevant to mechanics lien rights 2.2 Information and Serv ices Required 2.2.1 Owners financial arrangement 2.2.2 Owners responsibility to secure approvals for construction 2.2.3 Furnishing survey and description of the site 2.2.4 Reasonable promptness to furnishing upon request 2.2.5 Free copies of drawings to the Contractor 2.3 Owners Right to Stop the Work 2.4 Owners Right to Carry out the Work Article 3 Contractor 3.1 General 3.1.1 Definition 3.1.2 Perform the Work 3.1.3 No relief of obligations by the Architects activities 3.2 Review of Contract Documents and Field Conditions 3.2.1 Review contract documents 3.2.2 Contractors responsibilities for review 3.2.3 Liability 3.3 Supervision and Construction Procedures Definitions and Interpretations Simple Notices, Orders, and Reports Respo nsibility (shall, must) Right (may) Procedures Transfer of Project

PAGE 120

107 3.3.1 Supervise and direct the Work 3.3.2 Responsible for t he act of employees, subs and so on. 3.3.3 Contractors inspection of the existing work 3.4 Labor and Materials 3.4.1 Provide labor and materials 3.4.2 Substitutions 3.4.3 Discipline and good order among the employees 3.5 Warranty 3.6 Taxes 3.7 Permi ts, Fees and Notices 3.7.1 Building permit and governmental fees 3.7.2 Notices required by law 3.7.3 Ascertain Contract Document in accordance with law 3.7.4 knowingly perform work in contrary to law 3.8 Allowances 3.8.1 Definitions 3.8.2 The procedure and responsibilities 3.8.3 Selection of equipment and materials (?) 3.9 Superintendent 3.10 Contractors Construction Schedules 3.10.1 Contractors construction schedule 3.10.2 Schedule of submittals 3.10.3 Conform to the schedule 3.11 Documents and Samples at the Site 3.12 Shop Drawings, Product Data and Samples 3.12.1 Shop drawings 3.12.2 Product data 3.12.3 Samples 3.12.4 Not part of Contract Documents 3.12.5 Compliance review and prompt submission by the Contractor 3.12.6 Verified by the Contractor 3.12.7 No action before approval 3.12.8 Responsibility for the deviation 3.12.9 Direct attention to revisions not requested 3.12.10 Professional service by the Contractor 3.13 Use of Site 3.14 Cutting and Patching 3.14.1 Contractors responsibility 3.14.2 Damage to the completed works 3.15 Cleaning Up 3.15.1 Keep the site clean 3.15.2 Fail to clean up 3.16 Access to Work 3.17 Royalties, Patents and Copyrights 3.18 Indemnification 3.18.1 No harm to the Owner and the Architect 3.18.2 Claim by an employee Article 4 Architects Administration of the Contract 4.1 Architect 4.1.1 Definition 4.1.2 Authorities of the Architect 4.2 Architects Administration of the Contract 4.2.1 Act as Owners representative 4.2.2 Inspection of the Work

PAGE 121

108 4.2.3 Not responsible for the Contractors failures 4.2.4 Communications through the Architect 4.2.5 Review and certify payments 4.2.6 Reject Work 4.2.7 Review and approve submittals 4.2.8 Prepare Change Orders and more 4.2.9 Determine the date of Completions 4.2.10 Project representatives 4.2.11 Decision on performance matters upon requests 4.2.12 Interpretations and decisions of the Architect 4.2.13 Final decision on aesthetic matters 4.3 Claims and Disputes 4.3.1 Definition 4.3.2 Time Limits on Claims 4.3.3 Continuing contract performance 4.3.4 Claim for concealed or unknown conditions 4.3.5 Claim for additional cost 4.3.6 Reasons for claim 4.3.7 Claim for additional time 4.3.8 Injury or damage to person or property 4.3.9 Adjustment of unit prices 4.3.10 Mutual waiver 4.4 Resolution of Claims and Disputes 4.4.1 Decision of Architect 4.4.2 Review of claims 4.4.3 Architects consultation 4.4.4 Proper response to the Architects request 4.4 .5 Written decision on claims 4.4.6 Effect of Architects decision 4.4.7 Notification of the Surety 4.4.8 Mechanics Lien 4.5 Mediation 4.5.1 Application of mediation 4.5.2 Applicable rules and filing 4.5.3 Fees and location 4.6 Arbitration 4.5.1 Controversies and claims subject to arbitration 4.5.2 Applicable rules and filing 4.5.3 Time Limits on arbitration 4.5.4 Limitation on consolidation or joinder 4.5.5 Claims and timely assertion of claims 4.5.6 Judgment on final award Article 5 Subc ontractors 5.1 Definitions 5.1.1 Definition Subcontractor 5.1.2 Definition Sub subcontractor 5.2 Award of subcontracts and contracts for portions of the Work 5.2.1 Inform the Owner 5.2.2 Reasonable objections 5.2.3 Adjustments to cost and time results from objections 5.2.4 Change of subcontractor 5.3 Subcontractual Relations 5.4 Contingent Assignment of Subcontracts 5.4.1 Assign subcontract to the Owner

PAGE 122

109 5.4.2 Adjustment compensation to the subcontractor Article 6 Construction by Owner or by Separate Contractors 6.1 Owners Right to Perform Construction and Award Separate Contracts 6.1.1 Owners right 6.1.2 The term Contractor 6.1.3 Coordination of the activities 6.1.4 Same obligations and rights under the contract 6.2 Mutual Responsibi lity 6.2.1 Cooperation from the Contractor 6.2.2 Apparent discrepancies or defects in the Work 6.2.3 Reimbursement of cost 6.2.4 Remedy of damage by the Contractor 6.2.5 Equal responsibilities for cutting and patching 6.3 Owners Right to Clean Up Article 7 Changes in the Work 7.1 General 7.1.1 Use of changes 7.1.2 Basis of changes 7.1.3 Promptly performance of changes 7.2 Change Orders 7.2.1 Definitions 7.2.2 Determining adjustments to the Contract Sum 7.3 Construction Change Directives 7.3.1 Definition 7.3.2 Use of construction change directives 7.3.3 Adjustment to Contract Sum 7.3.4 Execution of the Change 7.3.5 Agreed by the Contractor 7.3.6 Disagreed by the Contractor and Architects decision 7.3.7 Credit resulted from a net decrease in the Contract Sum 7.3.8 Payment before the final determination of the cost 7.3.9 Agreement upon the determination of the Architect 7.4 Minor Changes in the Work Article 8 Time 8.1 Definitions 8.1.1 Contract Time 8.1.2 Date of commencemen t 8.1.3 Date of substantial completion 8.1.4 Day 8.2 Progress and Completion 8.2.1 Contractors acknowledgement 8.2.2 Commencement 8.2.3 Proceed expeditiously 8.3 Delays and Extensions of Time 8.3.1 Extension of the Contract Time 8.3.2 Claim re lated to time 8.3.3 Not preclude recovery of damage under other provisions Article 9 Payments and Completion 9.1 Contract Sum

PAGE 123

110 9.2 Schedule of Values 9.3 Applications for Payment 9.3.1 Applications 9.3.2 Payment on account of materials and equipme nts 9.3.3 Contractors warranty 9.4 Certificates for Payment 9.4.1 Issuance of certificate 9.4.2 Representation of the certificates for payment 9.5 Decisions to Withhold Certificate 9.5.1 Reasons for withhold 9.5.2 Remove of the condition 9.6 Prog ress payments 9.6.1 Owners payment 9.6.2 Payment to the subcontractors 9.6.3 Information requested by subcontractor 9.6.4 No obligation to the payment to subcontractor 9.6.5 Payment to the suppliers 9.6.6 No representation of acceptance 9.6.7 Ha ndling payment to subcontractors by the Contractor 9.7 Failure of Payment 9.8 Substantial Completion 9.8.1 Definition 9.8.2 Application by the Contractor 9.8.3 Architects inspection 9.8.4 Certificate of substantial complete 9.8.5 Acceptance of responsibilities assigned 9.9 Partial Occupancy or Use 9.9.1 Procedure 9.9.2 Inspection before occupancy 9.9.3 Not constitute acceptance of work 9.10 Final Completion and Final Payment 9.10.1 Application by the Contractor 9.10.2 Conditions to final payment 9.10.3 Delayed final payment 9.10.4 A waiver of claim by the Owner 9.10.5 A waiver of claim by the Contractor Article 10 Protection of Persons and Property 10.1 Safety Precautions and Programs 10.2 Safety of Persons and Property 10.2.1 Cont ractors responsibility 10.2.2 Compliance of law and ordinance 10.2.3 Erection and maintenance of safeguard 10.2.4 Proper handling of hazardous materials 10.2.5 Remedy of damage and loss 10.2.6 Personnel for prevention of accidents 10.2.7 Loads of construction and construction site 10.3 Hazardous Materials 10.3.1 Occurrence of personal injuries from hazardous materials 10.3.2 Verification and removal of the hazardous materials 10.3.3 Indemnification 10.4 Responsibility for materials brought t o the site by the Contractor 10.5 Indemnification of the Contractor 10.6 Emergencies

PAGE 124

111 Article 11 Insurance and Bonds 11.1 Contractors Liability Insurance 11.1.1 Protections 11.1.2 Amount and coverage 11.1.3 Certificate of insurance 11.2 Owners Liab ility Insurance 11.3 Project Management Protective Liability Insurance 11.3.1 Purchase and maintenance 11.3.2 Waiver of rights against each other 11.3.3 Additional insured 11.4 Property Insurance 11.4.1 Purchase and maintenance 11.4.2 Boiler and Ma chinery Insurance 11.4.3 Loss of Use Insurance 11.4.4 Contractors request for additional insurance 11.4.5 Waiver of subrogation for separated policies 11.4.6 Availability of insurance policies to the Contractor 11.4.7 Waivers of Subrogation 11.4.8 P ayment of loss 11.4.9 Duties after loss 11.4.10 Adjustment and settlement of loss 11.5 Performance and Payment Bond 11.5.1 Owners rights 11.5.2 Copies of bond upon requests Article 12 Uncovering and Correction of Work 12.1 Uncovering of Work 12.1 .1 Architects written request 12.1.2 Uncovering portions without prior examination 12.2 Correction of Work 12.2.1 Before or after substantial completion 12.2.2 After substantial completion 12.2.3 Removal of non conforming work 12.2.4 Damage to the o ther part of the Work during removing 12.2.5 No limitations to other obligations 12.3 Acceptance of Non Conforming Work Article 13 Miscellaneous Provisions 13.1 Governing Laws 13.2 Successors and Assigns 13.2.1 Binding parties 13.2.2 Assign the Cont ract to a institutional lender 13.3 Written Notice 13.4 Rights and Remedies 13.4.1 Not a limitation to law 13.4.2 Action or failure to act 13.5 Tests and Inspections 13.5.1 Arrangements for tests, inspections and approvals 13.5.2 Arrangements for additional tests, inspections and approvals 13.5.3 Failure of test 13.5.4 Certificate of testing 13.5.5 Architects observation 13.5.6 Conduct tests promptly

PAGE 125

112 13.6 Interest 13.7 Commencement of Statutory Limitation Period Article 14 Termination or Suspension of the Contract 14.1 Termination by the Contractor 14.1.1 Common causes 14.1.2 Termination caused by repeatedly delay by Owner 14.1.3 Notice to the owner 14.1.4 Termination because of the failure of Owner 14.2 Termination by the Owner for Cause 14.2.1 Causes 14.2.2 Notices 14.2.3 No further payment to Contractor 14.2.4 Compensation to the Owner 14.3 Suspension by the Owner for Convenience 14.3.1 Order 14.3.2 Adjustment to the contract sum and contract time 14.4 Termination by the Owner for Convenience 14.4.1 Termination 14.4.2 Contractors actions 14.4.3 Compensation to the contractor

PAGE 126

113 APPENDIX B SAMPLE OUTPUT FROM SIMULATION PROGRAM 17:15:09 500 CoordinationAgent: Processing transactions... M07, M00, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07, M00, M0 7, M00, M07, M00, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07, M01, M02, M07, M01, M02, M07, M01, M02, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07 M01, M02, M07, M00, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07, M00, M07, M00, M07, M00, M07, M00, M07, M00, M07, M01, M02, M07, M00, 17:15:10 015 CoordinationAgent: Transaction code processed... Site ARCH Client Output ===== Details of the Client ========= Owner: OW Architect: ARCH Engineer: ENG Number of Contractors: 1 Number of Suppliers: 1 Number of Procedures: 40 Sequence: Details of Multitransaction Structure: (1) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (2) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (3) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (4) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (5) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S 00)) D S(P02 >ARCH) (6) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (7) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (8) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (9) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (10) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S( MC >S00)) D S(P02 >ARCH) (11) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (12) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (13) M10 S(P01 >ARCH) S(M >ENG ) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (14) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (15) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (16 ) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (17) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (18) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (19) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (20) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 > ARCH) (21) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (22) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (23) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (24) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH)

PAGE 127

114 (25) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (26) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (27) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (28) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC > OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (29) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (30) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (31) M10 S(P0 1 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (32) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (33) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (34) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (35) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (36) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C 00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (37) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (38) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) (39) M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) (40) M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) ================== 17:15:18 53 1 Start dispatching transactions: ************************************ MultiTransaction No. 1 ************************************ Execute: M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) 17:15:18 562 S(P01 >ARCH) 17:15:18 562 SIMULATION: arch design in progress ... for 1700 17:15:20 312 Pre update building component with ref: 0, description: 2298 17:15:20 375 S(M >ENG) 17:15:21 671 Answer: APPROVED, whatever it is ... 17:15:21 687 17:15:21 703 S(MA >OW) 17:15:22 250 Answer: APPROVED, whatever it is ... 17:15:22 250 S(MA >C00) 17:15:22 828 Answer: APPROVED, whatever it is ... 17:15:22 828 S(MA >S00) 17:15:23 484 Answer: APPROVED, whatever it is ... 17:15:23 531 Yes, proceed ... 17:15:23 546 S(P02 >ARCH) 17:15:23 562 Final update (new value) with ref: 0, description: 2298 Commit ... 17:15:23 578 S(P01 >ARCH) 17:15:23 609 S(M >ENG) 17:15:23 625 S(P02 >ARCH) Execution time: 0 hours 0 minutes 5 seconds ************************************ MultiTransaction No. 2 ************************************ Execute: M11 S(P 01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) 17:15:23 640 S(P01 >ARCH) 17:15:23 656 SIMULATION: arch design in progress ... for 1600 17:15:25 281 Pre update building component w ith ref: 0, description: 801 17:15:25 312 17:15:25 328 S(MB >OW) 17:15:25 937 Answer: APPROVED, whatever it is ... 17:15:25 937 S(MB >C00) 17:15:26 562 Answer: APPROVED, whatever it is ... 17:15:26 562 S(MB >S00) 17:15:26 984 Answer: APPROVED, whatever it is ...

PAGE 128

115 17:15:27 000 Yes, proceed ... 17:15:27 031 S(M >ENG) 17:15:28 234 Answer: APPROVED, whatever it is ... 17:15:28 250 17:15:2 8 265 S(MC >OW) 17:15:28 765 Answer: APPROVED, whatever it is ... 17:15:28 765 S(MC >C00) 17:15:29 281 Answer: APPROVED, whatever it is ... 17:15:29 281 S(MC >S00) 17:15:29 906 Answer: APPROVED, whatever it is ... 17:15:29 921 Yes, proceed ... 17:15:29 953 S(P02 >ARCH) 17:15:29 968 Final update (new value) with ref: 0, description: 801 Commit ... 17:15:29 984 S(P01 >ARCH) 17:15:30 031 S (M >ENG) 17:15:30 046 S(P02 >ARCH) Execution time: 0 hours 0 minutes 6 seconds ************************************ MultiTransaction No. 3 ************************************ Execute: M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW) ,S(MA >C00),S(MA >S00)) D S(P02 >ARCH) 17:15:30 062 S(P01 >ARCH) 17:15:30 078 SIMULATION: arch design in progress ... for 1700 17:15:31 796 Pre update building component with ref: 0, description: 5345 17:15:31 828 S(M >ENG ) 17:15:32 843 Answer: APPROVED, whatever it is ... 17:15:32 859 17:15:32 875 S(MA >OW) 17:15:33 281 Answer: APPROVED, whatever it is ... 17:15:33 281 S(MA >C00) 17:15:33 906 Answer: APPROVED, whatever it is ... 17:15:33 906 S(MA >S00) 17:15:34 531 Answer: REJECTED, ... Rollback ... 17:15:34 546 S(P01 >ARCH) 17:15:34 562 Undo pre update building component with ref: 0, description: 5345 17:15:34 593 S( M >ENG) Retry ... Execute: M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) 17:15:34 656 S(P01 >ARCH) 17:15:34 656 SIMULATION: arch design in progress ... for 800 17:15:35 468 Pre update building component with ref: 0, description: 5345 17:15:35 500 S(M >ENG) 17:15:36 015 Answer: APPROVED, whatever it is ... 17:15:36 031 17:15:36 046 S(MA >OW) 17:15:36 250 Answer: APPROVED, whatever it is ... 17:15:36 250 S(MA >C00) 17:15:36 468 Answer: REJECTED, ... Rollback ... 17:15:36 484 S(P01 >ARCH) 17:15:36 500 Undo pre update building component with ref: 0, description: 5345 17:15:36 546 S(M >ENG) Retry ... Execute: M10 S(P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) 17:15:36 609 S(P01 >ARCH) 17:15:36 609 SIMULATION: arch design in progress ... for 800 17:15:37 421 Pre update building component with ref: 0, description: 5345 17:15:37 453 S(M >ENG) 17:15:37 984 Answer: APPROVED, whatever it is ... 17:15:38 000 17:15:38 015 S(MA >OW) 17:15:38 218 Answer: APPROVED, whatever it is ...

PAGE 129

116 17:15:38 218 S(MA >C00) 1 7:15:38 437 Answer: APPROVED, whatever it is ... 17:15:38 437 S(MA >S00) 17:15:38 656 Answer: APPROVED, whatever it is ... 17:15:38 671 Yes, proceed ... 17:15:38 703 S(P02 >ARCH) 17:15:38 718 Final update (new value) with ref: 0, description: 5345 Commit ... 17:15:38 734 S(P01 >ARCH) 17:15:38 765 S(M >ENG) 17:15:38 781 S(P02 >ARCH) Execution time: 0 hours 0 minutes 9 seconds ************************ *********************** *MultiTransaction No. 4 to No. 38 are deleted *********************************************** ************************************ MultiTransaction No. 39 ************************************ Execute: M10 S (P01 >ARCH) S(M >ENG) C(S(MA >OW),S(MA >C00),S(MA >S00)) D S(P02 >ARCH) 17:19:55 546 S(P01 >ARCH) 17:19:55 562 SIMULATION: arch design in progress ... for 1800 17:19:57 375 Pre update building component with ref: 0, description: 5388 17:19 :57 406 S(M >ENG) 17:19:58 421 Answer: APPROVED, whatever it is ... 17:19:58 437 17:19:58 453 S(MA >OW) 17:19:59 062 Answer: APPROVED, whatever it is ... 17:19:59 062 S(MA >C00) 17:19: 59 484 Answer: APPROVED, whatever it is ... 17:19:59 484 S(MA >S00) 17:20:00 109 Answer: APPROVED, whatever it is ... 17:20:00 125 Yes, proceed ... 17:20:00 156 S(P02 >ARCH) 17:20:00 171 Final update (new value) with ref: 0, description: 5388 Commit ... 17:20:00 187 S(P01 >ARCH) 17:20:00 218 S(M >ENG) 17:20:00 234 S(P02 >ARCH) Execution time: 0 hours 0 minutes 5 seconds ******************************** **** MultiTransaction No. 40 ************************************ Execute: M11 S(P01 >ARCH) C(S(MB >OW),S(MB >C00),S(MB >S00)) D S(M >ENG) C(S(MC >OW),S(MC >C00),S(MC >S00)) D S(P02 >ARCH) 17:20:00 265 S(P01 >ARCH) 17:20:00 2 81 SIMULATION: arch design in progress ... for 1700 17:20:01 984 Pre update building component with ref: 3, description: 9188 17:20:02 015 17:20:02 031 S(MB >OW) 17:20:02 640 Answer: APPROVED, whatever it is ... 17:20:0 2 640 S(MB >C00) 17:20:03 062 Answer: APPROVED, whatever it is ... 17:20:03 062 S(MB >S00) 17:20:03 484 Answer: APPROVED, whatever it is ... 17:20:03 500 Yes, proceed ... 17:20:03 531 S(M >ENG) 17:20:04 937 Answer: APPROVED, whatever it is ... 17:20:04 953 17:20:04 968 S(MC >OW) 17:20:05 468 Answer: APPROVED, whatever it is ... 17:20:05 468 S(MC >C00) 17:20:05 890 Answer: APPROVED, wha tever it is ... 17:20:05 890 S(MC >S00) 17:20:06 312 Answer: APPROVED, whatever it is ...

PAGE 130

117 17:20:06 328 Yes, proceed ... 17:20:06 359 S(P02 >ARCH) 17:20:06 375 Final update (new value) with ref: 3, descri ption: 9188 Commit ... 17:20:06 390 S(P01 >ARCH) 17:20:06 421 S(M >ENG) 17:20:06 453 S(P02 >ARCH) Execution time: 0 hours 0 minutes 6 seconds Finish procedure execution. Total execution time: 0 hours 4 minutes 48 seconds No. Type Execution Time 1 M10 5 seconds 2 M11 6 seconds 3 M10 8 seconds 4 M11 11 seconds 5 M10 4 seconds 6 M11 6 seconds 7 M10 4 seconds 8 M11 6 seconds 9 M10 7 seconds 10 M11 6 seconds 11 M10 7 seconds 12 M11 5 seconds 13 M10 4 seconds 14 M11 13 seconds 15 M10 11 seconds 16 M11 11 seconds 17 M10 6 seconds 18 M11 7 sec onds 19 M10 6 seconds 20 M11 6 seconds 21 M10 6 seconds 22 M11 5 seconds 23 M10 5 seconds 24 M11 6 seconds 25 M10 11 seconds 26 M11 6 seconds 27 M10 4 seconds 28 M11 19 seconds 29 M10 4 seconds 30 M11 7 seconds 31 M10 5 seconds 32 M11 6 seconds 33 M10 4 seconds 34 M11 5 seconds 35 M10 6 seconds 36 M11 6 seconds 37 M10 10 seconds 38 M1 1 5 seconds 39 M10 4 seconds 40 M11 6 seconds M10 total exe time (in seconds): 121 average: 6.05 M11 total exe time (in seconds): 148 average: 7.4

PAGE 131

118 REFERENCES [AKI94] Akin, and Z. Anadol. Determining the impact of CADrafting on the building process, International Journal of Construction Information Technology, pages 1 8, Spring 1994. [AMO99] R. Amor, C. J. Anumba. A Survey and Analysis of Integ rated Project Databases, Concurrent Engineering in Construction: Challenges for the New Millennium, M. Hannus, M. Salonen, and A. S. Kazi, eds., Proceedings of the 2nd International Conference on Concurrent Engineering in Construction, CIB Publication 236 pages 217 227, Espoo, Finland, August 1999. [ANU00] C. J. Anumba, A. N. Baldwin, N. M. Bouchlaghem, B. Prasad, A. F. Cutting Decelle, J. Dufau, and M. Mommessin. Integrating Concurrent Engineering Concepts in a Steelwork Construction Project, Concurr ent Engineering: Research and Applications, 8(3), pages 199 212, September 2000. [ANU98] C. J. Anumba, A. F. Cutting Decelle, A. N. Baldwin, J. Dufau, M. Mommessin, and N. M. Bouchlaghem. Integration of Product and Process Models as a Keystone of Concurre nt Engineering in Construction: the ProMICE Project, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., pages 9 20, BRE, Watford, UK, October 1998. [ARS02] H. Arsham. Systems Simulation: The Shortest Path from Learnin g to Applications, 2002, http://ubmail.ubalt.edu/~harsham/ simulation/sim.htm#rnass November 20, 2002 verified. [BEE98] K. Beetz, R. Junge, R. Steinmann. The O.P.E.N. Platform, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., pages 91 100, BRE, Watford, UK, October 1998. [BIL94] A. Biliris, S. Dar, N. Gehani, H.V. Jagadish, and K. Ramamritham. ASSET: A System for Supporting Extended Transactions, Proceedings of the ACM SIGMOD International Conference on Manageme nt of Data, pages 44 54, Minneapolis, Minnesota, May 1994.

PAGE 132

119 [BLE98] L. T. M. Blessing, A. Chakrabati, K. M. Wallance. An Overview of Descriptive Studies in Relation to a General Design Research Methodology, Designers the Key to Successful Product Devel opment, E. Frankenberger, P. Badke Schaub, and H. Birkhofer, eds., pages 42 56, Springer Verlag, 1998. [BJO92] B. C. Bjrk. A unified approach for modelling construction information, Building and Environment, 27(2), pages 173 194, 1992. [BRA97] P. Bra ndon, M. Betts. Creating a Framework for IT in Construction, The Armathwaite Initiative, the Formation of a Global Construction IT Network, Construct IT Centre of Excellence, 1997. [BUC92] A. Buchmann, M. T. Ozsu, M. Hornick, D. Georgakopoulos, and F. A. Manola. A Transaction Model for Active Distributed Object Systems, Database Transaction Models for Advanced Applications, A. K. Elmagarmid, ed., pages 123 158, Morgan Kaufmann, San Mateo, California, 1992. [BUU90] J. Buur. A Theoretical Approach to Me chatronics Design, Institute for Engineering Design, IK publication 90.74 A., 1990. [CAR01] L. Carrabine. A Project Webs View from the Top, CADscope, volume 2, pages 2 7, 2001 [CHR90] P. Chrysanthis and K. Ramamritham. ACTA: A Framework for Specifyin g and Reasoning about Transaction Structure and Behavior, Proceedings of ACM SIGMOD International Conference on Management of Data, pages 194 203, Atlantic City, New Jersey, May 1990. [CHR91] P. Chrysanthis, K. Ramamritham. A Unifying Framework for Trans actions in Competitive and Cooperative Environments, IEEE Office and Knowledge Engineering, 4(1), pages 3 22, February 1991. [CHR94] P. Chrysanthis and K. Ramamritham. Synthesis of Extended Transaction Models Using ACTA, ACM Transactions on Database Sy stems, 19(3), pages 450 491, 1994. [CLO00] R. H. Clough, G. A. Sears, S. K. Sears. Construction Project Management, 4th edition, John Wiley & Sons, New York, 2000. [COM86] Committee on Construction Change Orders. "Construction Contract Modifications: C omparing the Experiences of Federal Agencies With Other Owners," Building Research Board, National Research Council, National Academy Press, Washington, D.C., 1986.

PAGE 133

120 [COV02] R. Cover. The XML Cover Pages: aecXML Working Group Architecture, Engineering an d Construction, 2002, http://xml.coverpages.org/aecXML.html, November 16, 2002 verified. [CUT99] A. F. Cutting Decelle, C. J. Anumba, A. N. Baldwin, J. Dufau, M. Mommessin, and N. M. Bouchlaghem. Integration of Concurrent Engineering Concepts into an Integrated Product and Process Model, M. Hannus, M. Salonen, and A. S. Kazi, eds., Proceedings of the 2nd International Conference on Concurrent Engineering in Construction, CIB Publication 236, pages 217 227, Espoo, Finland, August 1999. [ELM90] A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for Interbase, Proceedings of the 16th International Conference on Very Large Databases, pages 507 518, Brisbane, Australia, August 1990. [ELM92] A. K. Elmagarmid. ed. Database Transaction Models For Advanced Applications, Morgan Kaufmann, San Mateo, CA, March 1992. [FAR99] I. Faraj, and M. Alshawi. A Modularised Integrated Computer Environment for the Construction Industry: SPACE, The Electronic Journal of Informati on Technology in Construction, Vol. 4, pages 37 52, 1999. [FRO92] T. Froese. Integrated Computer Aided Project Management Through Standard Object Oriented Models, Ph.D. Thesis, Dept. of Civil Engineering, Stanford University, 1992. [FRO95] T. Froese. Core Process Models And Application Areas in Construction, Presented at CIB W78/TG10 Workshop, Modeling of Buildings through their Life cycle, pages 427 436, Stanford University, August 21 23 1995. [FRO96] T. Froese. Models of Construction Process Info rmation, Journal of Computing in Civil Engineering, Special section on Data, Product, and Process Modeling, ASCE, 10(3), pages 183 193, July 1996. [FRO99a] T. Froese, M. Fischer, F. Grobler, J. Ritzenthaler, K. Yu, S. Sutherland, S. Staub, B. Akinci, R. Akbas, B. Koo, A. Barron, and J. Kunz. Industry Foundation Classes For Project Management A Trial Implementation, Electronic Journal of Information Technology in Construction, Vol.4, pages 17 36, 1999. [FRO99b] T. Froese, and K. Yu. "Industry Foundatio n Class Modeling For Estimating and Scheduling, Durability Of Building Materials and Components 8, Vol. 4, pages 2825 2835, Vancouver, Canada, May 1999.

PAGE 134

121 [FRO00] T. Froese, K. Yu, K. Liston, and M. Fischer. System Architectures for AEC Interoperability, Proceedings of Construction Information Technology 2000, pages 28 30, Reykjavik, Iceland, June 2000. [FUS02] D. Fuscaldo. Building a Market, Wall Street Journal, R14, April 15, 2002. [GAR90] H. Garcia Molina, D. Gawlick, J. Klein, K. Kleissner, and K Salem. Coordinating Multi transaction Activities, Technical Report CS TR 247 90, Department of Computer Science, Princeton University, February 1990. [GRA96] E. Grasso. An Extended Transaction Service for Real time and Telecom Object Request Brokers, Proceedings of the 2nd International Workshop on Distributed Object Oriented Computing, Frankfurt, Germany, November 1996. [HAN99] M. Hannus, and T. Hemi Tero. Implementing browsing tool for EXPRESS schemata and STEP data, Product Data Technology Euro pe 1999, 8th Symposium, Stavanger Forum, Stavanger, Norway, April 1999. [HAR02] G. Harrod. aecXML and Industry Foundation Classes, 2002 http://www.cadinfo.net/editorial/aecxml.htm, November 16, 2002 verified. [HEM00] T. Hemi. XML Based Product Model Server, Proceedings of Product Data Technology Europe 2000, pages 119 125, ESTEC, Noordwijk, Netherlands, May 2000. [HEM99] T. Hemi, and M. Salonen. Virtual Reality: Human Interface to Product Data, Concurrent Engineering in Construction: Challenges for the New Millennium, M. Hannus, M. Salonen, and A. S. Kazi, eds., Proceedings of the 2nd International Conference on Concurrent Engineering in Construction, CIB Publication 236, Espoo, Finland, August 1999. [IAI97] IAI. IAI and STEP, http://cig.br e.co.uk/iai_uk/iai/page8.htm#The IAI and STEP, May 24, 2002 verified. [JUN97] R. Junge, M. Kthe, K. Schulz, A. Zarli, W. Bakkeren. The VEGA Platform IT for the virtual enterprise, CAAD futures R. Junge, ed., pages 591 616, Kulwer Academic Publi shers, Dordrecht, 1997 [JUR02] J. Jurewicz. Extranet Update, AECVision, Internet Business Systems, Inc., 2002, http://www.aeccafe.com/AECVision/opinion/extranet.php, November 16, 2002 verified. [KAT98] P. Katranuschkov, and J. Hyvrinen. Product Data Server for Concurrent Engineering in A/E/C, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., pages 19 21, BRE, Watford, UK, October 1998.

PAGE 135

122 [LAI01] J. Laiserin. AEC Project Webs Redux, CADscope, volume 1, pages 8 14, 2001 [LEI00] J. Leinonen, K. Khknen, and T. Hemi. New Construction Management Practice Based on the Virtual Reality Technology, 4D CAD Conference, Gainesville, Florida, February 2000. [LU02] H. Lu. Implementation of an Advanced Transaction Model f or an Integrated Computing Environment for Building Construction, Master Thesis, University of Florida, 2002 [LUI93] G. Luiten. An Information Reference Model for Architecture, Engineering, and Construction, Proceeding of 1st International Conference on the Management of Information Technology for Construction, pages 391 406, World Scientific, Singapore, 1993. [LUI98] G. Luiten, F. P. Tolman, and M.A. Fischer. Project modelling in AEC to integrate design and construction, Computers in Industry, 35(1), pages 13 29, Elsevier Science B.V., 1998. [MCK02] G. McKinney, UML Business Modelling Primer, 2002, http://www.night ray.com/resources/UMLBusinessModelling100.pdf November 16, 2002 verified. [MOS87] J. E. B. Moss. Nested Transactions: an Introducti on, Concurrency Control and Reliability in Distributed Systems, B. Bhargava, ed., pages 395 425. Van Nostrand Reinhold, New York, 1987. [NAT02] National Institute of Standards and Technology (NIST). The STEP Project, 2002, http://www.nist.gov/sc4/www/ stepdocs.htm, November 16, 2002 verified. [OBR01] W. OBrien, and J. Hammer. Robust Mediation of Construction Supply Chain Information, Proceedings of the ASCE Special Conference on Fully Integrated and Automated Project Processes in Civil Engineering, V irginia Polytechnic and State University, Blacksburg, VA, September 2001. [ORF97] R. Orfali, and D. Harkey. Client/Server Programming with Java and CORBA, second edition, John Wiley & Sons, New York, 1997. [REI91] K. F. Reinschmidt, F. H. Griffis, and P. L. Bronner. Integration of Engineering, Design, and Construction, Journal of Construction Engineering and Management, ASCE, 117(4), pages 756 772, 1991. [REZ98] Y. Rezgui, G. Cooper, and P. Brandon. Information Management in a Collaborative Multiact or Environment: The COMMIT approach, Journal of Computing in Civil Engineering, ASCE, 12(3), pages 136 144, 1998

PAGE 136

123 [RYA95] N. Ryan, and D. Smith. Database Systems Engineering, International Thomson Computer Press, 1995 [SCH98] R. J. Scherer, A Framework for the Concurrent Engineering Environment, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., pages 449 458, BRE, Watford, UK, October 1998. [SMA02] R. L. Smailes. The Documentation of the Construction of Rinker Hall, 2002, http://web.dcp.ufl.edu/ rsmailes/rinker.htm, November 20, 2002 verified. [STE98] J. Stephens, M. Bhms, M. Kthe, J. Rangnes, R. Steinman, J. Junge, and A. Zarli. Virtual Enterprise using Groupware tools and distributed Architectures, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., pages 459 468, BRE, Watford, UK, October 1998. [TEI94] P. Teicholz, and M. Fischer. Strategy for Computer Integrated Construction Technology, Journal of Construction Engineering and Management, ASCE, 120 (1), pages 117 131, 1994. [TUR99] Z. Turk, B. Lundgren. Communication Workflow Perspective on Engineering Work, M. Hannus, M. Salonen, and A. S. Kazi, eds., Proceedings of the 2nd International Conference on Concurrent Engineeri ng in Construction, CIB Publication 236, pages 217 227, Espoo, Finland, August 1999. [TUR97] Z. Turk, R. Wasserfuhr, P. Katranuschkov, R. Amor, M. Hannus, and R. J. Scherer. Conceptual Modelling of a Concurrent Engineering Environment, First Internation al Conference on Concurrent Engineering in Construction, London, June1997 [WAS98] R. Wasserfuhr. Shared Process Models for Distributed Co operative Engineering, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., BRE, W atford, UK, October 1998. [WEI92] G. Weikum, H. J. Schek. Concepts and Applications of Multilevel Transactions and Open Nested Transactions, Database Transaction Models for Advanced Applications, A.K. Elmagarmid, ed., pages 515 553, Morgan Kaufmann, San Mateo, California, 1992. [YUM98] K K. Yum, and R. M. Drogemuller. A Cross Sector Business Model for Interoperability, Proceedings of 2nd European Conference on Product and Process Modelling, R. Amor, ed., BRE, Watford, UK, October 1998.

PAGE 137

124 [ZAR97] A. Zarl i, P. Poyet, P. Debras, M. Kthe, K. Schulz, W. J. C. Bakkeren, R. Los, R. Junge, R. Steinmann, K. Beetz, and J. Stephens. Integrating Emerging IT Paradigms for the Virtual Enterprise: The VEGA Platform, Proceedings of the 4th International Conference on Concurrent Enterprising ICE '97. Concurrency for Competitiveness: Towards the Concurrent Enterprise in the Age of Electronic Commerce, K.S. Pawar, ed., pages 347 359, University of Nottingham, UK, 1997. [ZHA94] A. Zhang, M. Nodine, B. Bhargava, and O. B ukhres. Ensuring Relaxed Atomicity for Flexible Transactions in Multidatabase Systems, Proceedings of 1994 SIGMOD International Conference on Management of Data, pages 67 78, Minneapolis, Minnesota, 1994

PAGE 138

125 BIOGRAPHICAL SKETCH Huanqing Lu was born in Heilongjiang, China. He received his bachelors degree in civil engineering and his masters degree in project management from Tianjin University, China. He also received a masters degree in computer engineerin g from the University of Florida. He received a Ph.D. in design, construction and planning from the University of Florida in December 2002. His interest is integration research in building construction project delivery systems and transaction systems.


Permanent Link: http://ufdc.ufl.edu/UFE0000565/00001

Material Information

Title: Extended Production Integration for Construction (Epic): An Integration System for Building Construction
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000565:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000565/00001

Material Information

Title: Extended Production Integration for Construction (Epic): An Integration System for Building Construction
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000565:00001


This item has the following downloads:


Full Text











EXTENDED PRODUCTION INTEGRATION FOR CONSTRUCTION (EPIC):
AN INTEGRATION SYSTEM FOR BUILDING CONSTRUCTION



















By

HUANQING LU


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2002




























Copyright 2002

by

Huanqing Lu



































To Hui















ACKNOWLEDGMENTS

I would like to thank my committee chair, Dr. R. Raymond Issa, for his valuable

guidance and support. I greatly appreciate his meticulously going through the entire

manuscript for me. Dr. Dennis Fukai provided valuable input in defining the research

topic and direction. I appreciate his support and motivation. Dr. Ian Flood provided

insightful suggestions concerning methodology and theoretical issues. The

recommendations of Dr. Robert Cox were very helpful in designing scenarios and case

studies. I am also grateful to Dr. Randy Chow, who offered me considerable advice and

direction on technical solutions for the research proposal. I enjoyed working in his

research group. I would like to thank Dr. William O'Brien for his help with the research

method and his valuable suggestions regarding the case study.

I give special thanks to Jarkko Leinonen and others of VTT Building

Technology, Finland, who gave me the inspiration to start this research.
















TABLE OF CONTENTS

Page

A C K N O W L E D G M E N T S .................................................................................................. iv

LIST OF TABLES .................. ....................................................... viii

LIST OF FIGURES ............................... ... ...... ... ................. .x

A B ST R A C T ........................................................................... xii

CHAPTER

1 IN TROD U CTION .................................. ..... ............. .... ............. .

Construction Industry and Information Technology.................................. 1
Surging Needs for an Integrated Computer System for Building Construction............. 5
Introdu action to the R research .............................................. ....................................... 8

2 LITERATURE REVIEW AND PROBLEM STATEMENT..............................10

K ey T e rm s ...................................... ....... ...... ...... ... ................................ 1 0
Early Works and the Establishment of Information Standards............................ 13
Implementations Based on IFC............................................................ 18
Trial Implementation of IFC and System Architecture from CIFE...................... 18
Other IFC Based Prototypes: ToCEE, ProMICE, and VEGA............................. 19
A ltern ativ e M eth o d s .............. ... .......... ........... .................................. ............ .. 2 3
Implementation of Building Project Model (BPM) ........................................... 23
Cross-Sector Business Model for Interoperability................... ... .............. 24
The COM M IT Project.................................... ..... ................ .... ......... 24
Robust Mediation of Construction Supply Chain Information.............................. 24
Industry Efforts: Project Collaboration Networks (PCNs) ......................................... 25
A analysis and D iscussions.......................................................................... .............. 27
Research Objectives and M ethodology................................................................... 30

3 E P IC M O D E L ...................................................... ................. 34

A nalyze C construction Projects..................................................................................... 34
D fine the EPIC M odel............... .. .. ................................. ......................... ..... 36
Needs of Collaboration Support on Construction Projects ......................................... 40
Fitting the EPIC Model into the Existing Model World ........................................ 42









Uniqueness and Value of the EPIC Model ................................................ ............. 44
Relationships and Interactions between Participants.......................... ........... ... 47
Introduce Contract Conditions into the EPIC System................... ... .............. 49
F rom E v ents to P procedures ........................................................................................... 52

4 SYSTEM ARCHITECTURE AND IMPLEMENTATION ...........................................54

Unified Modeling Language and Software Development ............................................ 54
Implementation of the EPIC Model......................................... ............. 56
Comparisons of System Implementations from Previous Studies............................ 56
Sy stem A architecture ......................................................................... .... .. 57
Transaction-based Implementation.................... ...... ........................ 60
Transaction M odels and Transaction D esign ............................................ .............. 61
T transaction B asics ........................ ........ ........................................ .. .. .. ...... 6 1
Com prison of Transaction M odels ................................................ .............. 63
Efforts to Combine Different Transaction Models ............................................ 64
Transaction D design ....................... ........ .... ................ ..... .................. 67
Specification Language for Customized Transactions .......................................... 69
Prototype and Program m ing ................................................ ............................. 72
Structure of the Prototype .......................................................... .............. 72
D eploym ent D iagram ................... ........................................... .......................... 74
D definition of T ran action s ........................................................................................ 74
E execution of the T ransactions............................................................................ ... 76
Interactions am ong the A ctors .............. ......................................................... 78
Outstanding Issues and Future W orks ........................................ ........ .............. 79

5 CASE STUDY AND TESTING......................................................... ............... 81

Review of Test M ethods from Previous Studies................................. .................... 81
T e st P lan ..................................................... 8 2
P ro of of C on cepts ................ .. ........ .... .............................................. ................ .. 83
Demonstration of Functionality: A Case Study...................................... .............. 83
B a c k g ro u n d ............................................................................................................... 8 4
A ssum options ..................................................................................................... 84
Simulation .................................. ............. ........ 86
Sensitivity Analysis of the Performance Variables .................................. 89
C o n clu sio n s ................................................................... 9 6
Tests for Technical Issues.................................. .............. 96
A ssu m p tio n s ........................................................................................... 9 6
D esign of A activity Flow .......................................................... ....... .............. 97
Results and Analysis .......................................... 100

6 CONCLUSION AND RECOMMENDATIONS ................. ................. .........104









APPENDIX

A A N A L Y SIS O F A IA A 201 ............................ .........................................................106

B SAMPLE OUTPUT FROM SIMULATION PROGRAM ................................ 113

R E F E R E N C E S ............................. .. .. .... .. ........ .... .......................................... 1

BIOGRAPHICAL SKETCH ..................................................... 125
















LIST OF TABLES

Table page

2-1 Major components of the VEGA platform ............................. ... .............22

2-2 Research and industry efforts of integration systems..............................................28

2-3 M methods of va lidation ........................................................................ ..................32

3-1 B asic elem ents of construction projects ........................................ .....................35

3-2 Comparisons of models for integration ........................................ ...............45

3-3 Procedures and notices found in AIA A201 ................................... .................51

4-1 V iew s and diagram s in U M L ............................ ...................................................55

4-2 Implem entations of integration models .......................................... ............... 56

4-3 Comparison of transaction models ............................ ...... ........... ........ 64

4-4 List of valid database operations .............. ... ........... ......... ............... .......70

4-5 Code and content for steps........... ............................................. ............... 70

5-1 Com prison betw een test m ethods ........................................ ........................ 82

5-2 Steps in the change order procedure .................................................88

5-3 Combination of individual rejection rates ..................................... ............... 92

5-4 Ranges of execution times of individual steps .............. ...... ...................93

5-5 Average execution times of Procedure A and Procedure B .............................. 94

5-6 C collection of activities ............ ......................................... .. ........ .... 98

5-7 Valid activities for different actors and test schedule....................................99

5-8 Execution tim es of system events........................................ .......................... 99









5-9 Average execution times of special activities............................................. 100

5-10 O ccurrences and average size of review s .............................................................102
















LIST OF FIGURES


Figure page

1-1 Islands of information ............. .... .. ................ ..... ...... ...............

2-1 Relationships between different models for construction projects ......................... 11

2-2 The ToCEE system architecture ........................................ .......................... 20

2-3 D esign research m ethodology......................................................... ............... 31

3-1 Interactions between the basic elements...... .................. .............36

3-2 T he E P IC project m odel ........................................ .............................................39

3-3 The EPIC model in the existing model world ............... ............ .....................43

3-4 Analysis of the Contract Conditions..................................................50

3-5 The causes of system processes ........................... ............... 53

4-1 Sam ple U M L diagram : a class diagram ........................................ .....................55

4-2 Multi-layered structure of the EPIC system...........................................................58

4-3 Road map for the study of transaction models ..................................................63

4-4 Transaction structure of a multitransaction................................65

4-5 Sample business procedure: the architect proposes a change......................... 71

4-6 Class reference diagram of the EPIC system.................................. ...... ............ ...73

4-7 Deployment diagram of the EPIC System..... ................................................. ...........74

4-8 From predefined procedures to system transaction.......................................75

4-9 Execution of a prepared transaction..................................................76

4-10 System view and user view .............................................................................. 77

4-11 Collaborations between actors ............ .... ............................ ............ ... 78









5-1 "Catch-22" that troubles the progress of integration systems .................................82

5-2 Form ulation of a change order........................................................ ............... 86

5-3 Variations in the change order procedure...... ...................... ............90

5-4 Comparison of the average execution time for Procedure A and B........................95

5-5 Changes in the average execution time by procedure types...............................101

5-6 O ccurrences of review sessions ...................................................... ........ ...... 102















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

EXTENDED PRODUCTION INTEGRATION FOR CONSTRUCTION (EPIC):
AN INTEGRATION SYSTEM FOR BUILDING CONSTRUCTION


By

Huanqing Lu

December 2002


Chairman: R. Raymond Issa
Co-Chair: Ian Flood
Major Department: Design, Construction and Planning

The primary goal of this product integration study was to facilitate collaboration

and data exchange among participants on construction projects. The implementations that

are based on information standards have often adopted closely coupled collaborations.

The project participants collaborate at a higher detail level and with fine granularity.

However the diversified construction industry consists of businesses that vary in size and

ability of adapting information technology. It is difficult to take a top down method and

require participants to conform universally accepted standards for the details of their

operation.

The Extended Production Integration for Construction (EPIC) is a loosely coupled

integration system with the support of a viable collaboration mechanism. We examined

the basic elements of construction projects and the typical relationship between project

participants and their proper representation in a computer system. A conceptual model for









construction project was proposed based on the study of events, contract conditions and

their impacts on the collaborations and interactions among participants. Basic

components of the model include actor, roles, processes, and information objects. Events

were identified as the major issue that the system needs to consider in order to conduct

the collaboration work. An attempt was made to convert contract conditions into

enforceable rules in a computer system.

A prototype system based on the proposed model was developed with Java,

CORBA and UML. A case study of making change orders was used to demonstrate the

functionality of the EPIC system. The factors that have impacts of the efficiency of the

system were studied through sensitivity analysis. A comprehensive simulation with

scenarios was designed to discover any potential problems in the technical solutions

specifically designed for the system.














CHAPTER 1
INTRODUCTION

This chapter explains the motivations, historical perspectives and the backgrounds

for this research. The needs for an integrated computer application system for

construction are analyzed in conjunction with the relationship between the unique nature

of the construction industry and the computer applications in the industry.

Construction Industry and Information Technology

It is a well-accepted trait of the traditional construction industry that it is very

fragmented. Because of the magnitude and complexity of construction projects, they are

often divided into work packages according to well-established specialization. Work

packages are assigned to participants in different domains either within the same

organization or from another organization through the practice of subcontracting.

Although specialization brings significant benefits to the industry, it also brings

difficulties in communication and collaboration among participants in construction

projects.

The fragmented nature of the construction industry creates a challenge for the

applications of information technology in the construction industry. Software packages

used by different parties are often independent from each other and have tremendous

difficulties in exchanging information. Although commercial software packages are

widely available for each domain, no mature solution exists to handle the task of

integrating the software system across domains. Communication among independent

systems is limited and sometimes frustrating at best. Paper-based media, such as









drawings and specifications, are still heavily relied on in many cases as a conventional

way to convey information and ideas among domains of construction projects. Confusion

and delays often occur because of their abstract nature and because of constant

reinterpretations by project participants. What makes things worse is that the construction

industry has long been considered slow in its acceptance of new technologies [BRA97] in

comparison to the manufacturing industry. Innovations to the current system often face

enormous hurdles to becoming successful.

The applications of information technology in the construction industry are also

defined by the one-of-a-kind nature of many aspects of the construction product. A

construction project often has unique products: the buildings designed specifically for the

project. From time to time new processes must be devised to suit a unique design. Mass

production is not as common as it is in the manufacturing industry. Most construction

activities must be carried out onsite. Unique project teams and organizations are

established for each construction project through temporary arrangement and dissolve

after the completion of the project. It is often difficult to make the project team run

seamlessly.

Because of its fragmentation and one-of-a-kind nature the construction industry

faces different challenges than the manufacturing industry does. Two types of solutions

from two perspectives were pursued.

* From the perspective of construction management and engineering. Unique
solutions are eliminated with standardizing the construction process, process
reengineering, minimizing onsite product using prefabrication, and using new forms
of project organization that advocate partnership rather than adversaries.

* From the perspective of the information technology. Proven techniques from
manufacturing and other industries are adopted such as product modeling, process
modeling, integration research, workflow management and concurrent engineering.









The concept of Computer Integrated Construction (CIC) comes from the

perspective of information technology and is defined as "a business process that links the

project participants in a facility project into a collaborative team through all phases of a

project" [TEI94]. The process defined covers the entire duration of the project from client

briefing, design, construction, and facility management. The purpose of CIC is to

facilitate information exchanges and collaborative efforts among project participants, or

more accurately the different computer systems used by the project participants. The

objectives of CIC include, rapid production of high-quality design, fast and cost-effective

construction of the facility; and effective facility management.

Figure 1-1 is an interesting analogy that shows the development of information

technology in the construction industry. Computer applications in different engineering

domains are illustrated as "Islands of Information" in order to demonstrate the

fragmented situation of the system.

The natural barriers limit transportation between the "islands" as the independent

status of the computer systems blocks communication among computer applications.

Contour lines represent changes over time and the coastline is the frontiers of present

research efforts. The dropping water level and bridges being built between islands

represents the development of new infrastructures and applications to enable the

communication among computer applications. The coastline of 2010 shows the goal that

the researchers and the industry are trying to achieve in the near future. Eventually a

"unified continent" will come into being, which means an ultimate integration system for

the construction industry. The ideal system will have a combination of both current

technologies and those currently under development.



























60's

70's

80's
'.j '. l i' J -I llj


UjjJ i jjj J J ij *J J



j IJJ jj
11 jj Jjju I j-_-






9 .aJ... .. .

s .... 90 's .. ..


'-- Mdtimedia
SiidJinl PDHM
DKF -' M;0RBA
ISI]STEP 1 I; rlloII
FC









S0's
60 'si ,90's
7O'r "0's / m JJLJJLJj
f.. .' O'

j i I
r" 90'





... ..... ..... .. ...:::: : .. ...
.............ii -u J 'J:J. % .j ....
-' ': '::......,,..... ......... .. .......: .................... ..... ..


Figure 1-1. Islands of information, Matti Hannus, VTT (the Technical Research Center
of Finland building technology), http://cic.vtt.fi/hannus/islands.html, 2002


Figure 1-1 gave a historical view of computer applications in the construction


industry. The very first computer application in this domain was the structural analysis


(Finite Element Method) application. Sophisticated structural analysis theories and


algorithms were developed long before the dawn of the computer era but many of them


could not be implemented without powerful and affordable computer facilities. The


computerization of accounting systems in the 1960s was the first full-scale involvement


of computer applications in business management. The development of computer


hardware in the 1980s boosted graphic processing capability. Computer Aided Design


(CAD) became popular in architectural and engineering design with Autocad as a


successful example. However, CAD in its early days was more like "Computer Aided









Drawing" in most cases rather than "Computer Aided Design." Software that produces

geometric drawings without a proper model cannot exchange information efficiently with

other software packages, such as structural analysis packages. Estimating software, which

is closely related to accounting systems, has become one of the common computer

applications for the construction industry. The CPM method was also computerized and

became the backbone of major construction planning software. Almost all of these

computer applications and systems share similar limits and frustrations in information

exchange.

The landscape of the construction industry was permanently changed in the 1990s

by the accelerating development of the computer technology. CAD evolved from 2D

drawings to 3D modeling and visualization and Virtual Reality. It was realized that the

lack of integration between computer applications could become a major obstacle to any

further development. Different kinds of integration solutions were proposed and tested to

build a viable integrated computer system for the construction industry. The current

active areas related to CIC include the following,

* Developing standards for data exchange, such as STEP, IFC, AECXML, etc.

* Process modeling and optimization for construction.

* 3D modeling and visualizations.

* Developing web based project collaboration: touted as an all-in-one integration
solution.

Surging Needs for an Integrated Computer System for Building Construction

The construction industry has long been considered as reluctant in adopting new

technology. The construction industry "has viewed innovation with suspicions or

attempted to protect new thinking by protectionism [BRA97]. While the productivity and









product quality was improved in the manufacturing industries by leaning production and

applying worldwide manufacturing benchmarking studies of production standards, the

construction industry remained low profile. Although the history of computer aided

project management can be traced back to a few decades ago, the actual development

process was not able to go straight as expected. Changes in the construction industry and

advances in new computer technology have sparkled refreshed needs and have rekindled

the pursuance of integrated systems in the past decade.

The general style of construction project management is changing along with the

evolving of project organization. New forms of project organization were introduced to

achieve higher level of concurrency and optimization at the project level. Because of

these the management style of the new methods is often more integrated and centralized

when compared to the traditional way [CLO00]. An opportunity appears in this

circumstance for the development of an integrated computer system for construction

projects.

The basic method for project organization or project delivery systems is often

referred as the traditional method. The client, architect, and contractor are three

independent parties bonded by contractual or administrative relations. The project is

executed sequentially (design, bid, construction). Construction Management (CM),

Design-Build, and BOT are examples of the new forms of project organization that

emerged in the recent decades and therefore are also called "alternative methods".

Although the traditional method is currently still the primary method for project

organization, the alternative methods are challenging its domination.









When compared to the traditional method, the management style of alternative

methods are more centralized and requires intensive cooperation between the participants

in the project. The CM method introduced a new role to the three major parties in the

project organization as in the traditional method. A construction manager is often

appointed at the beginning of the project and become the head of the project management

team at construction stage. In the Design-Build method the client employs a single party

for the responsibilities of both design and construction. The design-builder, which is in

place of the architect and the contractor as in traditional method, has control over the

project for the entire duration of the project. The BOT (build-operate-transfer) method is

an even more centralized form of project organization than the CM and Design-Build

methods. The financing, operation, and limited time ownership appears in the job list of

the builder/developer.

Traditionally the relationships in a construction project were adversary in natural

rather than collaboration. The alternative methods call for closer associations between

different sections and stages of a construction project. As a result a platform in the

industry is provided for the implementation of an integrated computer system for

construction projects.

The availability of new information technology is another factor that contributes

to the advances of integrated computer system for construction project. The volume of

information involved in a large-scale construction project can be enormous and hard to

manage without the support of a proper computer system. Key technology issues that

have a critical impact on the advances of integration research for building construction

include:









* The computational capability of the computer: 3D graphic and database applications
need higher computational processing capability.

* Availability of low cost hardware: Decreases in hardware price make possible the
extensive usage of computing facility at different levels of the construction industry.

* Advanced database applications: Organized information provides efficiency and
increases productivity.

* The Intemet and computer network: Provide infrastructure for the development of
integrated computer application for building construction.

* Business Modeling and B2B applications: Provide support and methodology for
general business management.

The methods of choice for the professionals that are working on the integration

issues have been expanded along with the flourishing of information technology. The

chances are better than ever for making possible a viable integrated computer system for

construction projects.

Introduction to the Research

Various methods have been proposed in search for a solution to the integration

dilemma. Since late 1980's the most prolific results of the research projects in this area

have been the computer models for construction projects. Different perspectives were

adapted for the models from either the product data or the process view of the

construction project. Some of the research projects went a step further to build prototypes

for the implementation of the proposed models while the others stayed at the conceptual

level discussing the general issues related to the subject. Information standards have been

initiated and widely accepted by the software developers. The recent developments are

tremendous industry effort to bring online project collaboration into reality with existing

technology.









However, the gap between academic research and industry applications still exists

despite of the efforts from both sides. The current models for construction project provide

static descriptions of the project but provide little support for the dynamic features

required by real world systems. The interactions between process model and product

model have been addressed but no sufficient solution has been provided. The

establishment of an integration system should have built-in flexibility so that existing

software applications can easily become a member of it.

This study addressed these issues by providing a new construction project model

with the dynamic features in mind. System architecture and trial implementation was

provided as a solution that includes the results of the current academic research while

accommodating the existing condition of the industry. A prototype was built to

demonstrate the operations of the system. A comprehensive test plan was design to

validate the proposed model and demonstrate the functionality of the implementation

system.














CHAPTER 2
LITERATURE REVIEW AND PROBLEM STATEMENT

This chapter presents a comprehensive review of the integration studies for the

construction industry and states the research objectives and the methodology. Various

solutions to the integration problem have been proposed in the past decade through

various research projects. Recent developments also include the flourishing of online

project collaboration. However a perfect solution is yet to be found. This study proposes

the modeling of a specific component to complement the existing model world for

building construction.

Key Terms

Some terms that are essential to the correct understanding of the subject need to

be defined before getting into any detail about the previous studies. Basic concepts in this

area are changing from time to time. The following are some definitions agreed upon by

the previous works. Figure 2-1 shows relationships between different types of models for

construction project.

Integration research. Integration research is a general concept that covers any

effort that facilitates collaborations between the participants on construction projects

through the use of information technology. Typical works include, establishment of an

information standard, building models for the construction project, and integration

between computer applications across domains to increase productivity and quality of the

construction project.









Data model. A data model is a generic concept from the domain of computer

science. The data model specifies the basic data structure for the relationships and

constraints of the information stored in an information system including integration

systems for building construction [FR092]. The data model provides low-level support to

any information system and in many cases it is not the point of interest for integration

research.


Decided by the
Levels of Details Reference ______ Decided by t
Conceptual Models I P subjects of Mod
Models Models
SType Models
SProduct
Application | Models
Models increasing -
detail levels
SProject
Data Models Models



Figure 2-1. Relationships between different models for construction projects

Conceptual model and application model. Conceptual models specify the

categories of information used in a specific domain or database, such as construction

industry [BJ092]. Reference models and Type models as explained below are two types

of conceptual models. The conceptual model is a higher-level concept as compared to the

application model and the data model. Application models contain details in a specific

domain and are often adopted in a certain computer applications.

Reference model and type model. Reference models, also known as core

models, are designed to be "high-level models that provide a unifying reference for more

detailed application models that will be constructed on top of them." [FR096]. The

details are referred to "Type models", which are "more specific and describe the









information structure for a restricted type or family of objects, such as a road model for

highways [LUI93]. This pair of terms was mentioned extensively during the early days of

the development of computer models for construction projects and it is not referenced as

often any more.

Information standards. Information standards are results of collective research

efforts that intend to standardize the data exchange and representation for the

construction industry. Notable information standards include STEP, IFC, aecXML, and

so on. Many integration systems are built upon prototypes and trial implementations of

the information standards.

Process model and product model. This is a pair of concepts that describes the

same physical world from another dimension as shown in Figure 2-2. A process model

consists of "information (process data) describing the production activities (design,

planning, and production), structured by processes; operations, and paths" [ANU98].

Process models form the basis for reasoning about and modification of existing

processes, which lead to the concept of process reengineering. The product model

provides a formal method of describing a certain type of product and many elements

associated with it. For the construction industry the product refers to the building and

various types of structures. The product model in the construction industry is often

associated with information standards such as IFC. Product model and process model are

generic terms applied to business modeling as well as modeling for construction projects.

Interactions between the product model and the process model are critical aspects of the

descriptions of a complete business model.









Project model. Project model is a general term that provides a comprehensive

description that covers various aspects of construction projects, such as, the building to

be built, participants of the project, construction activities, cost and available resources,

and project documents. A proper project model should include the elements of both the

product model and the process model. Chapter 3 has detailed information on the subject.

Concurrent Engineering (CE). Concurrent engineering is defined as "a

systematic approach to the integrated, concurrent design of products and their related

processes, including manufacturing and support" [TUR97]. The original idea was to

interleave the processes of design and construction in order to take advantage of

parallelism and concurrency. Concurrency is achieved from parallel work-group and

parallel production decomposition, concurrent resource scheduling, and concurrent

processing [ANUOO]. However it is difficult to implement the concept without proper

support of computer systems. The benefits of concurrent engineering also include

considerations of total project life cycle and better communication and information

exchange across the domains and stages of a construction project. Concurrent engineering

has been used as a motivation for the development of integration systems.

Early Works and the Establishment of Information Standards

Integration research started from the modeling efforts for construction projects.

Early studies started from the graphic modeling for the building and were often referred

to as CAD integration. It was soon realized that a common model is needed for

construction projects rather than individual models in different computer applications and

domains [LUI93]. The model should cover technical domains such as design, estimating

and cost analysis, and construction scheduling.









The General Construction Object Model (GenCOM) [FR092] is an early work

that intended to build a standardized object-oriented model for construction projects.

Software models for construction project were defined in three levels, a data model, a

domain model and a project model following the order from the conceptual model to the

applications. Four categories of classes were defined for product, process, resource, and

organization. A prototype called "OPIS" was built to proof the concepts of the GenCOM

model.

The unified approach model [BJ092] was proposed as a generic construction

process information model or framework. An object-oriented conceptual model was used

as well to structure information from different domains and to provide a framework to

explain the relationships between building classification systems and product models.

The scope of the model covers different viewpoints in a construction project from facts,

constraints to knowledge. Each one of the viewpoints was analyzed using the method of

software engineering.

The Information Reference Model for Architecture, Engineering, and

Construction (IRMA) [LUI93] is a combination of the better features of three

conceptual models, the unified approach model, GenCOM, and the Building Project

Model (BPM). IRMA is a framework for data standards that can be used as the core of a

conceptual model for a construction project, or a basis for the implementation of specific

computer application for construction projects. Four subtypes of project objects, namely

products, activities, resources, and contract are defined in the IRMA model.

A proprietary approach that starts from the needs of a specific construction project

was also attempted as a solution to the integration. Stone and Webster Engineering









Corporation and Columbia University conducted a multidisciplinary research in the

integration of computer application for construction project [REI91]. The integration

system was built with two commercial software packages: a relational database (the

project database) and a 3D computer aided design system. The database stores non-

graphical information for the objects in the 3D design model. The hardware used for the

system was workstations and high-speed network connections. The primary functionality

of the system includes constructibility review, construction planning, management, and

progress reporting. The research objective was to investigate the procedures to improve

construction productivity and document the costs and benefits associated with the use of

3D model on a construction site.

Many early works focused on the debates over the proper methodology for the

integration of a construction project. Principles for the modeling of construction project

and related domains were presented at the conceptual level and became the basis for later

research. The establishment and development of the information standards was also

benefits derived from the early studies.

A few information Standards (STEP, IFC, and aecXML) have been developed in

the past decade to standardize the modeling and data exchange for construction projects.

The enacted standards have been widely adopted by many organizations and products in

their solutions for integration systems.

The Standard for The Exchange of Product Model Data (STEP) (ISO 10303)

[NAT02] is an early standard for the computer interpretable representation and exchange

of product data. STEP provides a collection of standards called Application Protocols

(APs) that applies to various industries including building construction. The common









methodology behind APs is comprised of the STEP physical file format, the EXPRESS

data definition language, and shared definitions as common resources. The STEP

Building Construction Core Model (BCCM), which is the part of STEP designed for

construction projects, represents the principles of many models that were developed

previously [FR095].

In 1997 the work of STEP BCCM was merged with the efforts of Industry

Foundation Classes (IFC) through a memorandum of understanding between ISO

TC184/SC4 and the International Alliance for Interoperability (IAI) [IAI97]. IFC is a

cross-system and vendor-neutral data structure developed parallel to STEP by IAI. IFC

represents a data structure for a construction project model and can be used for sharing

data across different domains in a construction project. The definitions of classes

provided by IFC comprise various types of objects encounter in construction projects. A

text-based structure is used for storing the definitions in a data file. IFC classes contain

different categories of information such as physical information about buildings, project

management information and so on.

Basic concepts in the IFC model include usage scenarios, process diagram, object

model (class, attribute, interface, and relationships), and test cases. Usage Scenarios are

written descriptions of the processes that users perform and capture the decisions and

information that are used during each step of the process. A process diagram is a

diagrammatic representation of a usage scenario. The object model is built with the

classes, their interfaces, attributes and relationships in a composite representation. The

test cases are based on the usage scenarios developed along with the IFC information









model and allow software developers to test their application's ability to conform to the

IFC Specification.

IFC classes are capable of enabling interoperability among AEC software

applications. IFC-based objects allow computer applications to share a single project

model, and then allow users to define their own views of the project objects. Applications

that support IFCs allow members of a project team to share project data that evolve after

design, through construction, and occupation of the building. Project information can be

shared in three possible ways with IFCs:

* Physical files that may be shared across a network.

* Databases with a standard interface, for example, the product model server.

* Shared objects with software programming interfaces.

The aecXML for Architecture, Engineering and Construction is a new standard

that will have a potential impact on the future development of IFCs. aecXML is an XML

grammar that represents construction project information and it was designed for the

exchange of AEC-specific business-to-business information [COV02]. aecXML was

initially proposed by Bentley Systems in 1999 and later become a domain of the IAI.

The purpose of aecXML is to enable communications between different software

systems rather than the modeling of the construction project. The aecXML established a

standard way of structuring data for a construction project and for automated data

processing [HAR02]. While the development of IFCs has gone to extensive details in the

modeling of a construction model, aecXML seems to be an easier and sometimes more

practical solution. The fate of these two standards will be eventually decided by their

acceptance from the construction and software industries.









Implementations Based on IFC

Many studies have made contributions to various aspects of the integration

systems. A collection of relevant studies are reviewed and compared in detail below.

Trial Implementation of IFC and System Architecture from CIFE

A trial implementation of IFCs was built at Stanford University's Center for

Integrated Facility Engineering (CIFE) [FRO99a]. The objectives were to determine how

well IFC serves the real world representational needs of a project as in the case of project

management information such as costs, schedules, etc. A charrette-style exercise was

conducted in a workshop. The procedure is shown as below:

* Review of the current status and content of the IFC models

* Present several project scenarios developed in advance.

* Form two groups according to two basic scenarios, for estimating and scheduling.

* Prepare "paper models" of their scenario (each group is to apply IFC on paper)

* Implement the scenarios in a computer system using the IFCs

The study found that information sharing among participants on the project was

difficult without IFCs because of the variety of software used and because the project

management portion of IFCs generally supports the current practice of estimating and

scheduling. It was also suggested that the charrette test method should be done at the

early stage of the model development.

A prototype for a distributed, model-based, integrated information system for

construction project and facility management was developed under similar circumstances

in CIFE [FRO00]. The study presented an integrated 4D-planning tool with commercial

scheduling and estimating applications and a shared model-based project database.









The construction applications integrated in the system include customized 4D

tools (3D presentation with time visualization), Primavera Project Planner, and

Timberline Precision Estimating. The construction applications were used simultaneously

to analyze the effects of changes to construction schedules during the construction stage.

The system provided support for sharing project information among the software

packages. The project information was stored in a shared database built with a schema

based on the simplified IFC 2.0 model.

The distinct feature of the CIFE prototype was to support multi-disciplinary

interaction and decision-making to the project team. A test-case scenario of a schedule

review meeting based on an actual construction project was used to test the system. A

change that causes some complications was discussed in a project meeting with the

support of the integration system.

Other features of the system include three-tier reference architecture, multi-modal

architecture, and transaction based services. The application tier, middle tier and data tier

were defined following the generic concept of distributed systems. To support a wide

variety of data exchange modes, different types of model were enclosed in the system

from file based data exchange to application-to-application data exchange. Transaction-

based integration was discussed as opposed to the model-based integration but it was not

investigated any further.

Other IFC Based Prototypes: ToCEE, ProMICE, and VEGA

ToCEE (Towards a Concurrent Engineering Environment in the Building and

Engineering Structures Industry) [TUR97, KAT98, SCH98, WAS98] was part of the

ESPRIT project, which is a comprehensive information technology program of the

European Commission. The objective of the ToCEE project was to develop an overall









conceptual framework and specific software tools for concurrent engineering support in

construction projects. The conceptual framework represents integration of various

modeling and information management aspects in a construction project that covers

product, process, document, regulations and legal aspect modeling.

The ToCEE system provides a media for project communications with three

server subsystems: an information logistic system (ILS), a product data management

system (PDM), and a document management system (DMS). The ILS answers requests

from the clients and make contact with the other two subsystems. "Information chunks"

are passed along between the subsystems. The system also has a gateway to the web that

supports common Internet technologies. The system architecture of ToCEE as shown in

Figure 2-2 is a simplified version from the original publication [TUR97].

Clients Internet Interface Servers Storage
I I I I I I
E Java Document I
SCAD Interface Information Server Persistence
6 -ow s e i-s 6 E m a ilL o g is tic s S to r a g e I
Web Browsers Web and Loerver Storage
SEmail Clients Emailroduct
I I I I | Server

Figure 2-2. The ToCEE system architecture

The product data management server is another critical component of the ToCEE

system [KAT98]. The implementation of the product data server adopted the IFC project

model and has a layered structure that enables partitioning of product data according to

engineering domains and stages of the construction project. Basic operations are defined

for the product model server to provide specific product data management functionality.

The project data was stored in STEP/SDAI-based repositories to achieve interoperability.

The focus of this research was on the modeling and visualization of product data

for construction projects. IFC classes were implemented in Java and constitute the core of









the system. ProMoTe (Product Model Technology) was a 3D data browser designed for

the product model server [HAN99]. Virtual reality was further discussed as an interface

to product data via product model server [HEM99]. The product model also provided

common programming interfaces such as Java Servlet, RMI, and CORBA. A XML

version of the product model also was implemented [HEMOO]. User applications can be

developed in auxiliary to the product model server. One example is an end user

application that was built for presenting the progress of a construction project with a 3D

interface that can be configured with timeline [LEIOO].

The ProMICE (Product and Process Models Integration for Concurrent

Engineering in Construction) project intended to develop a generic integrated product and

process model for life-cycle design and construction of steelwork structures [ANU98,

CUT99]. The objectives of ProMICE project was, [ANUOO]

* Review and compare the use of product model and process model in the construction
industry in UK and France.

* Develop a generic product and process model for design and construction based on
concurrent engineering principles.

* Investigate the possible support to the generic product and process model in various
software systems such as CAD and virtual reality system.

The focus of the ProMICE project was the integration between the product and

the product model during design stages. Universal Modeling Language [MCK02] was

used as the primary tool for modeling, use cases and other diagrams. The differences in

the process during the design stage between the traditional method and the alternative

methods were studied to discover concurrencies. The research results of the ProMICE

project contributed to the development of international standards include STEP and IFC

[ANUOO].









The VEGA (Virtual Enterprises using Groupware tools and distributed

Architecture) project [ZAR97, BEE98, JUN97, STE98] was a visionary project that

integrates business and technical processes for the Large Scale Engineering industry. The

objectives of the project were to specify and demonstrate a software architecture suited

for a virtual enterprise for sharing information between different companies. The basic

philosophy of the VEGA project was to use primarily existing technical solutions as

components and extend their capabilities as needed to provide a platform that will enable

collaborations in a flexible distributed environment [ZAR97].

The VEGA platform is the software infrastructure established in the VEGA

project. The core of the VEGA platform was a CORBA based facility that support

distributed access to a STEP model. The STEP model stores product model data in the

format of EXPRESS schemata. Additional supporting services included a distributed

workflow system, an interoperability service and the distributed information service.

Table 2-1 shows a list of the basic components of the VEGA platform. Other issues

addressed in the study include neutral specification of information, data conversion from

STEP to common data, distribution of information, control of information flow, and

security of information.


Table 2-1. Major components of the VEGA platform
Component Functionality Technology
PDM Product model for the building IFC, STEP
COAST Middleware that provides product data service CORBA
WFL Workflow management system for process control WfMC framework
DIS Document and message management system SGML, HTML, XML

The VEGA platform offers 3 classes of integration scenarios, ideal scenario, open

scenarios, semi-open scenarios, and closed scenario [STE98]. In the ideal scenario the

client application interacts with the VEGA platform directly via the COAST. The local









storage of data is not necessary except for cache purpose. The open scenario also uses a

direct interaction between the client and the VEGA platform however the format of local

data is different from the common system data. The semi-open scenario applies in the

case that the data format conversion is too complex or not possible. Batch wise

conversion of product data is used in this scenario. In the closed scenario the data

exchange between the client and the VEGA system can only be accomplished with

importing and exporting the entire data model.

Alternative Methods

Many researchers have studied the integration issue independently and have built

computer models for construction project from scratch. This section covers research

projects that use unique models as well as those that address specific issues that are

relevant to the integration problem.

Implementation of Building Project Model (BPM)

An implementation of BPM was attempted with the intention to integrate design

and construction for Design-Build (DB) and Build-Operate-Transfer (BOT) projects

[LUI98]. The study starts with an idea simpler than IFCs called "CA Dfc" (Computer-

Aided Design for Construction" and the communication in construction projects. The

generalized activities and information flow in design and construction was analyzed in

details and represented with IDEF diagrams. Six types of interactions between design and

construction were identified. The concept of product modeling was extended to project

modeling, which comprises two abstraction mechanisms that describe relations between

design and construction. Two case studies were used to test the integration concepts.









Cross-Sector Business Model for Interoperability

The goal of the study was to build an AEC business model that specifies a

framework for business relations between the project members [YUM98]. The key issue

was data ownership modeling from the context of multiple project members. An initial

set of business roles and relationships for a typical construction project was defined and

analyzed in detail. Examples with bidding and contracting involved were used to

demonstrate the concept of the system. Implementation was not sufficiently addressed.

The COMMIT Project

The purpose of the COMMIT project [REZ98] was to define mechanisms to

improve information management and thus support decision-making in collaborative

projects. The work of this project was not construction specific but was carried out within

the context of construction. The primary issues were related to the system supports for a

collaborative system, such as ownership, rights, and responsibilities of the actors, version

control, schema evolution, relations between the decision and contributing factors,

dependencies between information items, and the notification and propagation of

changes. The information model is applicable to a wide range of industries. Industry-

specific concepts such as actor, discipline, and activities need to be added in order to

implement the model. A prototype with facilities for managing roles and activities was

built and a real-life scenario was used to demonstrate the functionalities of the system.

Robust Mediation of Construction Supply Chain Information

The study was motivated by the difficulty in obtaining data from firms in the

decentralized AEC industry [OBR01]. A mediation and wrapping infrastructure was built

to support access to and sharing of semantically heterogeneous process information in the

construction supply chain. This infrastructure was able to collect and share process









related information from legacy systems. The major challenge was to accommodate

heterogeneous data from different firms. The study was an extension to the existing

integration theories and complement to works in data standardization. A wrapper system

that was able to extract and process schedule information from a MS-Project database

and a scenario of activity rescheduling was used to prove the concepts.

Industry Efforts: Project Collaboration Networks (PCNs)

The acceptance of information standards and intensive efforts in related research

along with the dot com boom brought about the flourishing of companies that are

dedicated to online collaboration services for construction projects. At the height of the

dot com boom in early 2000, the number of internet startups that intended to create online

exchanges for construction projects reached 200 and over $1.1 Billion venture capital

was raised [FUS02]. This section was summary based on published reviews. It is not the

task of this study to compare and analyze existing commercial products in details.

Existing commercial products tried to tackle the integration issue from different

perspectives and provided similar products and services in general. Project Collaboration

Networks (PCN), also known as project extranets or project-specific Web sites, is a

specific term coined for these products and services. PCNs are generally Intemet-based

tools for sharing project-specific documents, communications, and workflow [LAI01]. A

certain product often focuses on one or more essential elements of PCNs and fits in the

following categories,

* Comprehensive Collaboration: Citadon (www.citadon.com), Constructw@re
(www.constructware.com), PrimeContract.com (www.primecontract.com),
ProjectTalk (www.projecttalk.com)

* Document management systems: Buzzsaw (www.buzzsaw.com), Cosential
(www.cosential.com), Integration (www.integration.arup.com), PlanDesk
(www.plandesk.com),









* Project-related messaging and workflow: eBuilder (www.ebuilder.net), ProjectEdge,
(www.proj ectedge.com),

* Bidding and procurement networks: Buildfolio (www.buildfolio.com), ProjectGuides
(www.proj ectguides.com),

* Real estate and facility management: Bricsnet (www.buildingcenter.net).

Technology that is involved in PCNs varies [CAROl]. The Entranet and

application servers are the computer technologies that have close relation to PCNs. The

Intemet has evolved from a text-based system with simple interactivity to the object web.

The object web is considered the next wave of Intemet innovation [ORF97]. The web in

the future shall be comprised of not only simple file servers but also application servers

with business objects involved. PCNs should take advantage from the the successes of the

application servers.

Online project collaboration has been taken seriously as a technical solution to the

integration problem in the construction industry. However many of the companies and

products failed along with the bust of the dot com bubble. Many of these companies

shared the same shortcomings with the other dot com startups, such as immature business

models, and adverse economical environments. Additional factors that have contributed

to the failures of many companies are that the customer's requirements for an integration

system were not accurately predicted. For example, many contractors often have a

relatively stable relationship with a certain subcontractor. In this case an online bidding

system may not fit in the picture at all [FUS02]. The conservative nature of the

construction industry with its reluctance of accepting new technology and making

changes, is another important factor that contributed to the failures.

The future of PCNs will largely depend on the maturity of generic Intemet based

technologies such as application server and its acceptance by the construction industry.









Based on the current situation the companies that are most likely to survive include,

Autodesk, Citadon, Primavera Systems, Buildpoint, Meridian Project Systems,

Constructw@re, and Bentley [JUR02, FUS02]. The time of PCNs may finally come after

proper adjustments and tough competitions,

Analysis and Discussions

The objectives, subjects of study, implementation, technical and major

contributions of the literature reviewed are compared in Table 2-2. More detailed side-

by-side comparisons of models, implementations and test issues can be found in Tables

3-2, 4-2, 5-1. Based on their goals and features the previous studies can be divided to the

following groups, early studies, information standards, implementations based on

information standards, alternative methods, and industry efforts.

Early studies are mostly individual efforts such as the OPIS prototype [FR092].

Information standards (STEP and IFCs) were a collective result of these works and

provide low-level support to data representation and sharing between domains. The

establishment of information standards represents a trend showing the shift of computer

applications in construction projects from single machine and independent applications

towards network and collaborative systems. Conceptual frameworks, trial

implementations and software architecture based on the information standards was

designed in various research works, such as the ToCEE project [TUR97, KAT98,

SCH98], the VEGA project [ZAR97, BEE98, JUN97], and CIFE's IFC trial

implementation and system architecture.

On the other hand because of the diversity of the construction industry there are

cases in which the IFC based implementations would not apply. Alternative methods are

sought after to cover these situation. These studies are related to the same integration











Table 2-2. Research and industry efforts of integration systems
Project Objectives Subject of Implementation Technical Prim
modeling contributions
OPIS prototype Build standard form Product, A prototype Object- Early efforts
[FR092] of models for process based on oriented
construction database databases
projects system
Information Provide standards for Process, Used in EXPRESS Widely accepted
standards: data exchange and product applications Modeling information
STEP, IFC, representation developed by language standards
aecXML other parties
The ToCEE Develop a conceptual Product data A system Java, Modeling and
project, framework and supports HTML visualization of
[TUR97, tools for concurrent information CORBA product data
KAT98, engineering support logistic,
SCH98, in construction product data,
WAS98] projects document
management
The VEGA Specify a software Business and A platform that IFC, STEP, The principles of
project, architecture for a technical manage CORBA, open platform
[ZAR97, virtual enterprise in processes product data, WfMC, and integration
BEE98, the Large Scale workflow, and XML scenarios
JUN97] Engineering document.
industry
BPM based Integrate design and Product, A prototype with Proprietary A unique project
implementati construction process modeling tools system: model and
on [LUI98] PMshell implementation
Cross-sector Provide a framework Relationships NA NA Study of
business for business among relationships
model relations between project among project
[YUM98] AEC players members members
The COMMIT Define mechanisms Actors, and A prototype with Rational Study of actors,
project to support project facilities for Rose, roles, and their
[REZ98] information information managing roles C++, interactions.
management and and activities. CORBA
decision-making in
collaborative
projects
CIFE IFC trial Determine how well Building, Representation IFCs Trial and test of
implementati IFCs works for resource, of project data IFCs for
on [FRO99a] project management cost, and in scenarios project
information scheduling management
CIFE System Develop a distributed, Product and A prototype with IFC, ADO, Support of multi-
Architecture model-based, process 4D tools, P3, LDAI, disciplinary
[FRO00] integrated system and Timberline OLE DB interactions
and decision-
making
Robust Propose a mediation Mediations A wrapper Java, SQL, Provide a
mediation for infrastructure for between system that XML, mechanism for
supply chain sharing of process project extracts and MS- interaction
[OBR01] information members processes info Project. between parties
from a database
PCNs, Tackle the integration Document, Various Vary Development of
[CAROl, issue from different process, and commercial commercial
FUS02] perspectives message products products









issues but adopted methods not exactly based on the concepts of the information

standards. Examples include the BPM based implementation [LUI98], the cross-sector

business model, the COMMIT project, and the robust mediation mechanisms for supply

chains [OBR01].

A common goal of the integration study is to facilitate collaboration and data

exchange between the participants on construction projects. The implementations based

on information standards (primarily IFCs), which are found to be the dominating method

for integration, often adopted closely coupled collaborations, which means the project

participants collaborate at high detail level and with fine granularity. As a result

sophisticated software and hardware facilities are often required for a fully functional

system. It is also required that software applications involved in the project conform to a

single information standard in order to work with the collaboration system. A typical

application scenario of existing integration systems was to integrate design and

construction to formulate a basis for concurrent engineering. Applications in Design-

Built and BOT projects were found as part of research initiatives [LUI98].

However the diversified construction industry consists of businesses that vary in

size and in their capability of adapting information technology. Implementations with

closely coupled collaboration are not favorable choices in many cases. The project

participants often affiliate to different organizations and bear their own interests and

agenda beside the common interest vested in the project. The participants need to

maintain a high level of independence and hide the details of their internal operations

from each other. Only those necessary are revealed to each other. The situation is

especially true in the case where the traditional method of project delivery is involved.









Many organizations involved in the project may have their own choice of software

applications or may not have sufficient facilities at all. It is difficult to make it as a

prerequisite to join the system that the member applications have to conform to a single

information standard.

An alternative is to build a loosely coupled system with flexibility that allows

various entities to join. The collaborations between the participants only occur at lower

details and lower frequencies when compared to the existing IFC based implementations.

The participants have safely guarded and clearly defined boundaries between them. The

system should include definitions of rules regarding interactions between users and the

procedures for modifying shared resource and information. The internal operations of

each user are hidden behind the boundary as in many cases in actual construction

projects. The participants have the liberty to use their applications of choice as long as the

minimum requirements for collaboration is fulfilled.

Research Objectives and Methodology

Based on the observation of the existing studies it is found that a system with

flexibility and a collaboration mechanism are needed for the purpose of system

integration for construction projects. The research objectives of this study are to

investigate the possibility of developing a loosely coupled integration system with the

supports of a viable collaboration mechanism for integration system. The relationships

between the collaborating parties are a critical issue for the success of the system.

The following issues are addressed in this study:

* The typical relationship and interactions between project participants and its proper
representation in a computer system









* The development of a computer model for the loosely coupled system that is capable
of enforcing the relationship and interactions between the project participants over
shared project information.

* Implementation of the proposed model that proves the concepts of the system.

* The verification of functionality of the proposed system.

A scientific approach is needed to produce reliable results for design research

such as this one. Numerous factors need to be considered for the design as well as testing

of the solutions during the study. A general design research methodology as shown in

Figure 2-3 was applied to this work. The full research cycle has 4 steps as in Criteria,

Description I, Prescription, Description II, and procedures for feedbacks to the previous

steps.




Observation Assumption and Observation
and Analysis Experience and Analysis
Focus Focus Focus
Focus: Measure Influence Methods Application

Z Result Z Result Z Result Z Result
[ Criteria I [ Descriptions I [ Prescription j [ Descriptions II

Figure 2-3. Design research methodology

The research work follows the general procedure as defined. The criteria or

overall goal for this research project is identified as developing a viable collaboration

mechanism for the integration system. The stage "Description r' contains the observation

and analysis of the existing works related to the subject of integration in construction. A

new model for the representation of the relationships between the project participants is

presented based on the reviews of the existing works and the analysis of the organization

of the actual construction project. A prototype was is to demonstrate the new model and









the operations of the system. Results in this section constitute the stage "Prescription". In

the final stage "Description II' preliminary analysis and tests are conducted through a

comprehensive test plan.

The feedback from the "Description II' stage has contributed to the improvement

of the work. The scope of the literature review was modified as well to focus on more

relevant studies. As a result the concepts represented by the model were fine-tuned to

provide better descriptions of the subjects. It took a few iterations before the final version

of the model and prototype came into being.

Methods of validation are a critical issue to the success of the study. A summary

of the methods of validation presented in the study is shown in Table 2-3. Theoretical

validation (comparison to known problems) and experimental validation (with

applications) are two common forms of validation for software engineering. The

theoretical validation of work was accomplished through side-by-side comparison

between this study and previous work. Comprehensive tests with 3 level testing and

application scenarios were conducted as the experimental validation for the study.


Table 2-3. Methods of validation
Category Method Descriptions
Primary Theoretical Validation Side-by-side comparisons with previous works
Methods Experimental Validation Comprehensive test plan with 3 level of testing
Alternative Logical verification Development of the prototype
Methods Verification by acceptance Reviews and discussions with peers

The validation of new design and methods in practice is difficult because of the

tremendous amount of factors that could have an impact on the design process and the

stochastic nature of the design. Two alternative forms of verifications [BUU90] were

therefore suggested. One was logical verification:

* Consistency: no internal conflicts exist between individual elements in the theory









* Completeness: all relevant phenomena observed previously can be explained or
rejected by the theory

* Coherence: well established and successful methods are in agreement with the theory

* Cases and specific design problems can be explained by means of the theory

The other form was verification by acceptance:

* Statements of the theory are acceptable to experienced practitioners (design
consultants and employees in companies).

* Models and methods derived from the theory are acceptable to experienced
practitioners.

Logical verification of the consistency, completeness, coherency and explanatory

power of the model was accomplished through the development of prototype that is able

to handle the requests and provide support to collaboration. Verification by acceptance

was achieved through reviews and discussions about the research work with the faculty

member and fellow researchers in the process of publications and presentations. The

feedbacks obtained in the process contributed to the improvements implemented in the

study.














CHAPTER 3
EPIC MODEL

The primary goal of the study was to build a proper model for the collaboration

mechanisms for construction projects. This chapter starts with an analysis of construction

projects and then defines the EPIC model in details. The features of the EPIC model are

further discussed by comparing to the existing works.

Analyze Construction Projects

A project model describes the relationship between real life objects in a

construction project and the corresponding information about objects in real-life. A

project model is also defined as a software representation of construction data that

supports the project throughout its life cycle [FAR99].

Previous studies tried to design project models with different methods. Early

efforts start with the object oriented feature and the various views of the model [BJO92,

FRO92, FRO95]. Some took the perspective of the product model and focused on the

description of the building products and related issues. Others started with the processes

that are involved in a construction project. A modularized project model was also defined

to support a wide range of computer applications for construction [FAR99].

A proper project model should capture the organizational structure and

interactions between the basic elements of a construction project. Therefore the analysis

of the structures of construction projects is a basic step of the modeling work for

construction projects.










Table 3-1 shows a list of basic elements of the construction projects identified for

this study. There are three categories for elements as in physical, information, and

temporal elements. Physical elements are with physical forms and include the

"touchable" part of a construction project. Information elements represent the concepts

associated with construction projects such as cost and schedule. Temporal elements are

those related to time, such as the occurrences of events.


Table 3-1. Basic elements of construction projects
Categories Elements Examples
Participants Owner, architect, engineer, contractors, suppliers
Physical Documents Drawings, specifications, project manual, the contract, etc.
Elements Buildings Floors, walls, foundations, etc.
Resources Labor, materials, equipment, tools, construction equipment,
water, heat, etc.
Design Shapes, colors, measurements of the building components,
Information technical specifications, etc.
Elements Schedule Plan of activities, start time, finish time, resource assignment, etc.
Estimate & accounting Cost items, analysis, etc.
Contract conditions Articles and clauses, right and responsibility, procedures.
Temporal Activities Excavation, concrete, painting, tiling, etc.
Elements Events Weather conditions, changes in design, etc.

Figure 3-1 shows the relationship between the elements of construction projects.

The operations of a construction project as a system are essentially the interactions

between the basic elements.

The interactions between the elements happen either within a category or between

categories of elements as shown below.

Type 1 (within a category):

* Participants own and use the resources, generate and used documents, and build the
project.

* Events triggers the activities

Type 2 (between categories):

* Design and estimating provides a description of the project.










* Construction schedule describes predefined activities.

* Contract conditions define relationships among participants.

* Documents carry various information elements of the project.

* Activities refer constantly to the information elements

* Participants initiate activities either in response to events or as planned.




Physical Elements Information
resources ] assign

own documents carry s
Figre -I eli "design schedule
and use generate the project describe siteaco
and use build estimate & accounting
S---- -------------------------------- ---- ---------------
S participants a define contract conditions

reference to describe

iii--- incur
inti activities events
Temporal Elements
EocusofthisStudy-----------------------------------------

Figure 3-1. Interactions between the basic elements

The focus of this study is the relations and interactions between the project

participants with regards to the activities and sharing of information elements. Events are

identified as major causes of deviation in activities and therefore drive the changes in

information elements.

Define the EPIC Model

Rules have to be enforced upon the interactions between the participants using an

integration system on a construction project. A full range of business procedures and

interactions between the participants such as changes, claim, and payment are defined in

contract conditions for various project delivery methods. On many occasions the project

information, which is often stored in a shared database in integration systems, is changed









as the results of these procedures. The basic solution of the EPIC model is to represent

and enforce the common rules of interactions between the project team members

regarding to the modification of the project information.

The design principles of the EPIC model are as follows:

* Build in complement to the systems developed from existing studies including
product model servers and IFCs.

* Provide a loosely coupled collaboration system for the modifications of the shared
project information as a result of the business procedures in construction projects.

* Represent and convert procedures derived from contract conditions into enforceable
rules in the system.

The acronym "EPIC" coined for this study stands for "Extended Production

Integration for Construction". The system has the flexibility to let the project participant

choose their own computer applications as long as an agent application is developed and

installed in their local system. This feature makes it possible that the results and products

from previous efforts towards integration can be included in the EPIC system. For

example, the IFC based product model can be defined as a component in the form of a

shared project database.

The EPIC model is built upon the integration requirements of the computer

applications and systems and the study of the typical organization of construction

projects. Basic system components of the EPIC model include actor, roles, processes and

information objects. The definitions and relations between the components are explained

in detail below.

Actors and roles. Actors represent the entities that are the participants on the

construction project team. The internal operations of an actor in relation to the

construction project are defined as internal processes. For example, an actor playing a









contractor has internal processes such as cost estimate and cost analysis. A certain actor

may play different roles in a single project, for example, an architectural design firm may

act as the designer and the construction manager.

The boundary of an actor is the natural limits of the organization it represents. In

actual construction projects, entities from different institutions coexist within a single

project organization and maintain clearly defined and safely guarded boundaries. Each

entity conducts business operations primarily inside its boundary. The information

exchange and sharing, which however does exist, is accomplished through an external

process that occurs between the participants. The ownership of the information needs to

be considered and rules must be followed through certain mechanism while executing

external processes in the system.

Information objects. The information objects keep project information that needs

to be shared between the actors. Sometime during construction Actors are required to

share certain information with the others in the form of information objects. The

complexity of the information objects varies from one type to another. The building

model from the architect is an example of the information object. It is the responsibility

of the project team to reach agreement regarding the contents and the methods of

information sharing as part of the definition of the project.

Processes. The analysis and modeling of the system processes is one of the goals

of this study. The internal processes represent business activities occur internally within

the actors and are implemented according to the in the computer system used by the

actors, for instance, as workflows or routines. EPIC system requires that the maintenance

of the shared information objects by its owner be accomplished with internal processes. It









is part of the business routines of the actor to access the shared information objects

owned by other actors. The EPIC defines the external processes for this case as vehicles

of information exchange and collaborations between the actors.

Figure 3-2 shows the relations and interactions between the components of the

EPIC model. Each actor has internal functionalities that are represented with internal

process. For example, the in-house estimating and accounting practice is internal

processes of contractors. Shared information objects are setup as required by the business

needs. For example, on a typical construction project we may find a shared information

model for the buildings. The actor also needs to maintain a coordination agent and a

procedure Library for the purpose of providing system functionalities.


WWWWWW entsWWWWWL0L..

Actor 1 Procedure Actor 2 Procedure Actor 3 Procedure
Internal Library Internal Library Internal Library
Functionalities Functionalities Functionalities 1uii1


Maintain Maintain Maintain
A B C D .

---------------------------- EH---[--------


An illustration of the interpretation and execution of the external processes
_______________________________________________See Chapter 4 for details

Internal Processes Shared Information Objects

QJJ External Processes Coordination Agents


Figure 3-2. The EPIC project model

In the case when the shared information objects need to be accessed as required

by internal operations, a request is submitted to the coordination agent from the internal

process. The agent looks up and executes the corresponding procedure in the procedure









library. The predefined procedure contains information about how and where to locate

the information needed. External processes are dispatched as the results of the execution

of the procedures. A single request of the internal processes may lead a multi-step

activity that includes a group of external processes.

The implementation of external processes is major challenge because of the

complex nature of the shared information objects. It is required that the system maintains

the integrity of the data contained in the shared information objects in a dynamic

environment. Another important issue is that the system has to be able to operate

efficiently in regarding to the process execution in order to render acceptable

performance. It is the goal of this study to propose a viable solution for the definition and

implementation of the external processes.

Needs of Collaboration Support on Construction Projects

Many existing integration solutions focus on the capability of representing project

information and information exchange between applications. However the ever-changing

nature of construction project requires integration systems equipped with facilities that

are able to treat project information as a dynamic entity. The project information changes

either because of the normal progress of the project from preplanned activities or caused

by uncertainties. As results of uncertainties, construction change is a proper example to

demonstrate the challenges to collaboration systems in terms of the capability of

providing sufficient support.

Construction changes are categorized with the reasons causing them. One

example of the categorization is: design deficiencies, criteria changes, unforeseen

conditions, changes in scope and other [COM86]. Studies shows that the most frequent

and most costly changes are often related to design, such as design change and design









errors [AKI94]. A case of construction change with design change involved is used to

demonstrate the needs of the support of an integration system.

Change orders are the instrument used to handle construction changes on

construction projects. Suppose in the case of a complicated change, the owner requested a

substantial change to the existing design. Additional design work has to be performed

before issuing a change order. The design provided by the architects and engineer has to

be crosschecked with the existing work and the other participants. A clearance from all

relevant participants needs to be obtained before the change may proceed. Some fairly

uncommon materials have to be preordered before the final decision is made about the

proposed change. The architect needs to check the suppliers to make sure these materials

are available. Challenges and key issues related to the use of change orders are found as

follows.

* Negotiation between the participants presents in preparation of complex change
orders. For a complicated problem extensive communications among the participants
are needed before an agreement can be reach. Turn around time for approval is
significant enough to prevent closer participation of the relevant parties in the design
process.

* Project information needs to be distributed among relevant parties. The proposed plan
for changes need to be made available to the parties for review. The distribution of
project information based traditional document such as drawings and specification
results in reinterpretation and potential problems in accuracy and timeliness. The
distribution of project information is also an important step to present evidence in
order to justify the change orders.

* There are possibilities of obtaining excessive price quote. Although the original
contract is obtained competitively, the costs of most change orders are not determined
through direct competition between bidders. This increases the possibility that a
contractor could quote an excessive price for a change order.

* Documentation of the change orders is necessary and can be used as experience data
for future decision-making. In practice the contractors do not always comply with the
requirements of documentation.









The EPIC system is capable of providing support regarding various aspects of the

change order process. Customized external procedures are used to form flows of

decision-makings and support simple reasoning to the negotiation process. Turn around

time can be reduced through expediting the delivery of message and project information.

The introduction of a shared project model into the system provides a basis for accurate

distribution of the change plan. Pricing and availability of labor and materials can be

stored in shared information among the users so that competitive prices can be obtained.

The system also keeps track of decision-making process and the tracking recording may

become part of the documentation for construction changes.

There are case that the solution provided by the EPIC system may not cover or

may not hold any advantages against the conventional ways. The advantages present only

in the case of change orders with complicated problem where large amount of

negotiations are required. For simple changes the system basically degrades to a message

passing service. Change orders with little or no project information associated are not

able to take advantage of the benefits associated with the shared project information. It is

not possible to obtain competitive prices if the project is too simple that only one

contractor and a single source of materials is involved.

Fitting the EPIC Model into the Existing Model World

The EPIC model is not only in complement with the existing models in regards to

functionalities but also from the perspective of the general landscape of the computer

modeling for construction projects. Figure 3-3 shows a sketch of relations between the

real world and the modeling world for construction.

Extensive studies have been conducted regarding the process model and product

models at both the conceptual level and the application level [TUR99, FRO99b, CUT99].







43


The project (building) and its resources are the primary subjects of modeling for product

models. The content of the product model include the information such as the design, the

schedule and the cost estimate. Process models are generally descriptions of the activities

involved in construction projects. Application models are lower level models used by

software packages and contain a certain type of information elements and often an

implementation of either a product model or a process model.


Real World I Computer World (Models)

activates describe Existing works
fl activities II _
- -events ---- Conc tual Model:
pa-- __ Process
participants Models
- z -I-z z = '
documents ---- interact
S . ..------ n t e r a c
the project I Product
,W describe Product
resources Models

contract conditions

design

schedule i contain
cost estimate describe Applicat


s


" Models I


Figure 3-3. The EPIC model in the existing model world

Some other elements that have yet not been covered are events, document and

participants. The project participants and their relationship need to be analyzed from the

perspectives of project management. As a major cause of the deviations in construction

the events are a subject closely related to the modeling of the relationship between the

project participants. The interactions between the existing models and the missing parts

also need to be studied. The information carried in drawings and specifications has


o
de
a
EE
L~a
o
$';


ment


ion









become part of the product modeling. The project document that has not been well

represented in the computer world is the contractual relations.

The EPIC model presents a solution to the integration project that is associated

with modeling of the events, the relationships between project participants, and the

contract conditions. A collaboration mechanism is built with the proper models of the

missing elements and fits in as one more piece to the puzzle of the modeling world for

construction projects.

Uniqueness and Value of the EPIC Model

The uniqueness and the value of the proposed model are demonstrated with a

side-by-side comparison between the EPIC model and a selection of studies with

significant modeling efforts as chosen from Table 2-3. Table 3-2 shows the results of the

comparison considering the subject of model, its objectives, the presence of collaboration

mechanisms, and the technical solutions.

This selected group of studies shares a common goal of supporting the system

integration between project participants but from different perspectives and with various

methods. The ToCEE project and the CIFE system architecture represent the IFC based

implementations. The Building Project Model and the others took alternative roads that

either start from scratch to build a model for construction projects or address a specific

aspect related to the integration problem.

The method chosen by the EPIC model is significantly different from the one

found in many IFC-based implementations. IFC-based systems use a top down method

and require the participants to follow universally accepted standards at a high level of

details in their operations. As a result, the definition of IFC standards tends to cover

extreme details in every aspect of the construction project. The method often leads to a










closely coupled collaborative system with participants maintaining a close connection

between each other. The practice in actual construction projects is against a method that

compromises too much the independence of the participants. Rather it is in favor of a

method that keeps a distance between project participants while allowing them to

collaborate. This is important because in most cases of the actual construction projects,

the participants of construction need to have control over what type of business

information has been published.


Table 3-2. Comparisons of models for integration
Method of
Studies tegton Subjects of Modeling Collaborations Technical Solution
Integration
The ToCEE project, Closely Product data With no clearly IFC based product data
[TUR97, KAT98, coupled identified roles server system.
SCH98, WAS98]
CIFE System Closely Product, resource, cost, With no clearly IFCs, and software for
Architecture coupled scheduling, and identified roles construction
[FRO99a] organization
[FRO00]
Building Project Closely Product and process With no clearly Prototype with modeling
Model, [LUI98] coupled identified roles tools
Robust Mediation of Loosely Relationship between For roles from Query processing and
Construction coupled parties (contractor different wrappers
Supply Chain, subs) entities
[OBR01]
Cross-Sector Loosely Relationship and For roles from Reference to distributed
Business Model coupled activities between different facility
[YUM98] parties entities
The COMMIT Loosely Actors, and information For roles from Modeling tools,
Project [REZ98] coupled management different notification, and
entities information
management.
The EPIC Model, H. Loosely Relationship between For roles from Rule-based, distributed
Lu, 2002, this coupled parties, events, contract different transactions
study conditions entities

The EPIC model adopts the notion of building a loosely coupled system that

allows the participants to maintain a higher level of independency and the integrity of

their existing computer systems. It acknowledges the differences in the capability

between the potential users of adopting information technology and it provides the









flexibility for the users to select their favorite applications. Only the necessary

interactions between the participants are carried out to provide the functionality of

collaboration. This method actually lowers the bar to joining the system so that a broader

base of users can be reached. The principle of the EPIC model is a departure from the

methods found in the current IFC-based implementations but does not work against the

using of IFC as a universal language for communication.

The subject of the modeling is another matter that separates the EPIC model from

others. In order to design a viable collaboration mechanism for integration systems it is

necessary to study the modeling of the relationship between the participants and the

impact of events as well as the enforcement of contract conditions in the system. The

results of the study make it possible to support a clearly defined boundary between the

users and allow users from different business entities to collaborate without a glitch. The

study of the relationship between the parties was found in a few studies [YUM98,

REZ98] but the impact of events and contract conditions has never been formally

investigated.

The studies that share the most similarities with the EPIC model are the

COMMIT project [REZ98] and the cross sector business model for construction

[YUM98]. The collaboration between the project participants is the primary concern of

this group of studies. What make them different are the proposed technical solutions. The

cross sector business model made reference to distributed facilities such as CORBA and

discussed some concepts but was not able to present an implementation that demonstrated

the concepts as discussed. The COMMIT project focused more on information

management and manipulation of information in fine granularity rather than the actual









relationships between the project participants. In comparison the EPIC model addresses

the events, rules and procedures that are related to the interactions between the

participants.

Because of the difficulties of verifying the benefits that the proposed system may

bring, many previous studies only provide proof-of-concept tests. The EPIC study makes

an attempt to verify the claimed benefits with simulations designed and executed upon

scenarios and prototypes. It was found that the application of the EPIC system provides a

possibility to optimize the existing business procedures during the construction stage.

The value of the EPIC model is summarized as the follows.

* Used an integration method that is in contrast to the top down method represented by
some IFC-based system.

* Conducted study of event and contract conditions and their impacts to the
collaborations in integration systems.

* Provided a unique technical solution to the representations of business relations in
construction projects and the implementation associated with it.

* Attempted to verify the benefits of the proposed system in regarding to the
optimization of the business procedures.

Relationships and Interactions between Participants

Project participants (actors) are the decision makers with regards to the

construction project and at the same time they provide information and services to the

other actors as may be required by their roles on the project team. Only some of the

business activities within the actor's organizations are relevant to a particular project and

need to be considered in the EPIC model. Among the relevant activities only the external

ones, as shown in Figure 3-3, have contact with other actors.

The behaviors of the participants in a collaborative system are regulated with

predefined rules and procedures. It is common to use contracts to define the basic rules of









engagement between the participants on a construction project. The rules and procedures

embedded in a collaborative system should bear the same meanings as defined in the

contract. The existing identifications of the roles in the contract can be used as the basis

for the basic setup of the EPIC implementation. Predefined procedures derived from the

contract conditions can be converted into enforceable rules for the interactions in the

EPIC system.

Different types of contractual relations are available for construction projects and

defined in separate versions of standard contracts, such as, owner architect, owner -

contractor, and general contractor subcontractor. Various types of contractual relations

may coexist on an actual construction project. The complete view of the business

relationship on a construction project can be obtained by decomposing the contractual

relations found on the project.

In this study a concept of Basic Construction Unit (BCU) is defined as part of

the EPIC model and it represents a simple contractual relation between some project

participants. A BCU is generally corresponding to a certain type of contract and contains

the parties, their right and responsibilities, as well as the procedures. For instance, AIA

documents A201 can be use as the framework to build a BCU for a construction project

with traditional delivery method. The owner and the contractor are the primary parties in

the BCU while at the same time the architect has to be involved as a party in the BCU

because of the critical role of the architect as the administrator of the contract.

A model for the entire construction project can be recursively constructed with

BCUs which may include different types of contractual conditions. Such a model is able

to capture the features of the business arrangement and the organizational chart of a









construction project. The implementation of such a model has the potential to provide

strong support for the business operations found on the project.

Construction contracts have different flavors according to which party is

responsible for the construction management services. A typical case involving a

traditional project method will be used in the study. The basic parties are the owner, the

architect, and the contractors. Other common participants are the suppliers and the

engineer. The case contains only one BCU and five participants.

Introduce Contract Conditions into the EPIC System

The contract conditions, which is often called "the bible", define many critical

business procedures in a construction project and need to be examined in details for the

definition of BCUs. The study of the common procedures found in contract conditions

contributes to the design of external processes that represents the interactions and

activities between the project participants. Because of the previous assumption of the

study the AIA Document A201, General Conditions of the Contract for Construction, was

analyzed and used as an example for the implementation of the EPIC model.

The common elements of the standard contract conditions are identified for the

purpose of the study:

* Definitions and interpretations: basics concept and rules

* Right and responsibilities: identified with words like "may", "shall", "must", and
specify the right or responsibility for a certain party to act.

* Procedures: a sequence of activities that contain notices, submission, requests,
approval, and decisions, often specified as routines or solutions to various issues that
may arise during the construction process.

* Simple communications: notices and requests that occurs between the major parties.










The document was studied on a clause-by-clause basis. A notation system as

shown in Figure 3-4 is used to indicate the type of the elements found in the text. A

complete text with the notations is attached as Appendix 1. Titles for the clauses were

inserted in the original text as a method of identification of the clauses rather then

accurate descriptions of the contents.


O Definitions and Interpretations A Simple Notices, Orders, and
Right (may) A Procedures
Responsibility (shall, must) e Transfer of Project Information


Article 2 Owner
2.1 General
002.1.1 The Owner
eAO 2.1.2 Information relevant to mechanic's lien rights
2.2 Information and Services Required
GA 2.2.1 Owner's financial arrangement
02.2.2 Owner's responsibility to secure approvals for construction
E) 2.2.3 Furnishing survey and description of the site
$ A 2.2.4 Reasonable promptness to furnishing upon request
S2.2.5 Free copies of drawings to the Contractor
A 2.3 Owner's Right to Stop the Work
A 2.4 Owner's Right to Carry out the Work

Figure 3-4. Analysis of the Contract Conditions

The definitions, interpretations, rights, and responsibilities as defined in the text

of the contract conditions provide guidelines for the design and setup of the EPIC system.

For example, the types of roles and the setup of shared information objects may follow

the parties and rules as defined in the contract conditions. Procedures and simple

communications are the basis for the design of external processes for the system.

Table 3-3 shows a summary of clauses that contain procedures (P) and simple

communications (SC) in the document AIA A201. The procedures or simple

communications may or may not involve transfer of project information from one party

to another. A certain item could occur in the one or more of following scenarios,










* Initialization: at the beginning of the project
* Upon-request: occur when needed
* Periodical: occur within certain interval or according to a schedule
* Finalization: occur at the end of the project.


Table 3-3. Procedures and notices found in AIA A201

Clause Descriptions Type Occurrence Proj.
Info.
2.1.2, 2.2.1, 2.2.3, 2.2.4 Owner provides info about mechanic's lien, P Initialization Y
financial arrangement, site info, and others.
2.3 Owner sends notice to stop the Work SC Upon-request N
2.4 Owner carries out the Work P Upon-request N
3.2.1, 3.2.2, 3.3.1, 3.7.3, Contractor checks contract document, reports SC Initialization Y
3.17 errors, unsafe procedure, variance with law, or Upon-
infringement of copyright or patent request
3.8.2 Use of allowance P Upon-request Y
3.8.3 Selection of equipment and material by owner SC Upon-request Y
3.10.1, 3.10.2 Contractor submit and update construction P Periodical Y
schedule and schedule of submittals
3.11.1 Contractor keeps a record copy for field ops SC Periodical Y
3.12.5 Contractor reviews and submits submittals P Upon-request Y
3.14.2 Written consent for cutting and patching P Upon-request N
4.1.2 Written consent for authorities of Architect P Initialization N
4.2.11 Architect's decision on performance matters P Upon-request Y
4.3.4, 4.3.5, 4.3.7, 4.3.8, Claims: Filing and review of claim, Architect's P Upon-request Y
4.4.1-4.4.3, 4.4.5 review and decision.
5.2.1 Contractor inform the owner about subs P Initialization N
6.2.2 Contractor report defects by other contractors SC Upon-request Y
7.2.1, 7.3.1, 7.3.3-7.3.6, Changes: Change order and construction change P Upon-request Y
7.3.9, 7.4 directives, minor changes
8.2.2 Contractor's notice of commencement SC Initialization N
9.2 Contractor submits schedule of Values P Initialization Y
9.3.1, 9.4.1, 9.5.1, 9.5.2, Payments: Application, approval, withhold,.... P Periodical Y
9.6.1, 9.6.3, 9.6.5, 9.7
9.8.2-9.8.5, 9.9.1, 9.10.1- Substantial completion, partial occupancy or use P Finalization Y
9.10.3 and final completion.
10.3.1, 10.3.2 Handling of hazardous materials P Upon-request Y
11.4.1, 11.4.10 Property insurance: purchase and maintenance P Initialization N
11.4.10 Property insurance: adjustment of loss P Upon-request Y
11.5.2 Contractor provide copies of bonds P Initialization N
12.1.1, 12.1.2, 12.2 Uncovering of work P Upon-request Y
13.2.1 Written consent to assign contract P Finalization N
13.5.1-13.5.4 Arrangement for test, inspections and approvals P Upon-request N
14.1.3, 14.2.2, 14.2.4, Termination P Finalization N
14.4.2, 14.4.3
14.3.2 Suspension by owner P Upon-request N

This work is an attempt to convert the contract conditions into enforceable rules

in a collaboration system regarding to information sharing. The implementation of the









external process based on a selection of procedures in this table will be discussed in

Chapter 5.

From Events to Procedures

As a common practice the predefined construction schedule is the essential basis

for the routine time control of the project. Before the commencement the entire operation

of the project is decomposed into activities during construction planning. The

dependencies between the activities are analyzed to arrange the activities in a fixed

sequence of works for the construction project. The anticipated date of start and finish for

each activity is computed to formulate a schedule with calendar dates.

The construction schedule made before the start of the project only provides

guidance to the execution of the project and is subject to periodic revisions and

corrections often triggered by events. In this study an event is defined as an occurrence

during the course of the execution of a construction project that causes changes in the

predefined construction schedule. Events are irregularities in the construction process and

are caused by the issues that are not foreseeable during the planning stage of the project,

for example the unforeseeable underground conditions. The events vary from one

construction project to another but it is possible to identify a limited set of common

events and their impact on the project by studying previous construction projects.

The physical activities as defined in the schedule or caused by events are the

sources of the system processes in the EPIC model. The primary function of the EPIC

model is to maintain the dataset of the system in regards to the changes and updates

caused by the physical activities in the project. Figure 3-5 shows the correlation between

the events and the system processes.









Physical construction activities are either defined in the construction schedule or

caused by events. Although the nature of the physical activities may be the same as

shown in the example, the EPIC system needs to handle the planned tasks and on-demand

tasks with different sets of internal and external processes. Extra system processes are

required to modify the original as planned project information. Many of these processes

represent the collaboration and re-negotiations between the parties.


ISources Physical System Processes
Internal External
Normal define : Routine Routine
Operatioschedule Planned Task Procedures Contacts Set rules
S1I Update the for
Cases a fo Excavation Daly cost shared DB contract
as excavation Excavation update and notify Conditions

Variance cause Special Special
l ....Ie On-demand
events Ond Procedures Contacts
I Change in -Exa wk Draft \ Approval
ases qualities change and update
I I I I

Figure 3-5. The causes of system processes

Only the external processes make contacts with other actors to access shared

information or for the purposes of collaboration. The design of external process is

included as part of the EPIC system while at the same time the implementation of the

internal processes is left to the users. The rules embedded in the contract conditions need

to be enforced through the design of the external process. The external processes need to

be represented with a set of procedures in the form of a library at the initialization stage

of the system. The procedure library is different from one project to another although the

method of its design is the same.














CHAPTER 4
SYSTEM ARCHITECTURE AND IMPLEMENTATION

The EPIC system as described in this chapter is basically an implementation of

the proposed EPIC model. The software prototype developed is used as a platform and

infrastructure for the testing and verification of the EPIC model. An engine is available to

process predefined procedures and enforce the rules upon the access to certain types of

shared information objects. A transaction-based implementation is chosen as the

underlining technical solution.

Unified Modeling Language and Software Development

Unified Modeling Language (UML) has been used as a tool in many works during

the development of the EPIC implementation system. Basics about UML are included

below to help in the understanding of the content of this chapter.

UML is a relatively new modeling language created as notations for object-

oriented design and analysis methodology by Grady Booch, James Rumbaugh, and Ivar

Jacobson and later adopted by Object Management Group, Inc. (OMG) as a standard in

1997. Soon UML become the standard modeling language for software development and

is supported by all major software-modeling tools.

A notable feature of UML is that UML uses geometrical symbols to visually

represent the functions and relationships of a software system. The application of UML is

highly flexible and varied according to the features of the area of applications as well as

the preference of the developers. A collection of concepts and modeling tools is available










for the definition and description of the work with different natures. Various diagram

types as shown in Table 4-1 are used to describe specific aspects of a software system.


Table 4-1. Views and diagrams in UML
Views Diagrams Contents Usage
Class diagram Relationships between classes defined Common
Static Component diagram Relationships between software components Rare
Deployment diagram How the software deployed Rare
Sequence diagram Interactions between objects Common
Dyn c Collaboration diagram An alternative presentation of sequence diagram Rare
Dynamic
Activity diagram Procedures Common
State diagram State transition of the system Rare
Use Case Use case diagram How the system interaction with outside world Common

Figure 4-1 shows an example of UML diagrams. The diagram describes the

relationship between design document classes and other classes in a project model.

Similar diagrams can be prepared for other applications. The design document is

composed of 3D model, drawings, and specifications. Architects are the providers of the

design documents. The design document provides a general description of the proposed

construction project. The owner needs to approve the design document and in the end

own it. Contractors are the users of the design document.

Project Owner
Notations: A
SC..ls d b approve and own
SClass describe .. 1..
provide use
Compose of Architect proviDesign Document Contracts
1..* 1..* 1..
S Association and
direction
0..* 0..* 0..*
0..* 0ormore
3D Model Drawings Snecs


Figure 4-1. Sample UML diagram: a class diagram










Implementation of the EPIC Model

The EPIC system is basically an implementation of the proposed EPIC model.

The principles behind the system design are stated before the development work. A

system architect is defined to provide an overview of the implementation system. The

features of the proposed model require a technical solution with a transaction-based

system.


Table 4-2. Implementations of integration models
Presence of A Granularity of
Studies uiing Moel Colabortios Components and Facilities Case Study
Building Model Collaborations
The ToCEE project, IFC Full Fine Information Logistics Not Found
[TUR97, KAT98, Implementations Server, Document
SCH98, WAS98] Management Server,
Product Management
Server
CIFE System IFC Full Fine User Applications, A hypothetic
Architecture Implementations Adaptors, Common schedule review
[FRO99a] project database meeting
[FRO00]
Building Project Non-IFC Full Fine GUI, Project-Modeling Design and assembly
Model, [LUI98] Implementations Environment of precast concrete
structure
Robust Mediation of None Coarse Mediator, wrapper, and Resource balancing
Construction user databases.
Supply Chain,
[OBR01]
The COMMIT Not Found Fine Interfaces for managing Making changes to a
Project [REZ98] project actors, roles, and wall
activities, project
information manager and
document manager.
The EPIC Model, H. Simple Coarse Procedure Definition, Collaborations
Lu, 2002, this Representations Transaction Execution, regarding a change.
study Distributed Database.

Comparisons of System Implementations from Previous Studies

The information about implementations from previous studies is compared side

by side with the implementation efforts in this study. In Table 4-2 many studies placed

their focus on the implementation of the building model either in IFC format or

independent format. Because the primary focus of this study was not on the









representation aspect of the building model simple java objects are used to present an

abstract view of the building model. A loosely coupled system that features a coarse level

of collaboration is promoted in the EPIC model in contrast to the fine granularity of

collaborations as seen in many studies.

The components and case study of each study are in accord with the functionality

and technical solutions found in their implementation system. Many studies have

included graphic user interface in their implementation, which provides better

presentation and is also what is lacking in this study. A detailed comparison between the

case studies is presented in Chapter 5.

System Architecture

Some notions have to be kept in mind while thinking about designing an

implementation system. It is important that the system be designed as a loosely coupled

distributed system that consists of autonomous components, as opposed to a monolithic

system with close ties between different parts within the system. The organization of

construction projects, which is often temporary and customized for a particular

construction project, requires loose control and flexibility. An implementation system of

integration model should allow new members to join in and the current members to

regroup for any new construction project. Because of the variety of computer systems

involved in construction project the implementation should be able to take advantage of

common modeling paradigm and common meta model while at same time keeping an

open door for other model such as the document model. When implementing solutions

with existing technologies one has to guard against losing contact with the reality of the

construction processes.






58


The application system based on the EPIC model, which will be referred to the

EPIC system in this study, maintains a group of shared information between the

participants of a construction project. The EPIC system has a multi-layer structure from

users to data layers as shown in Figure 4-2.




!Resource Material Building Others
Data Layer t s
.ata Layer Listings Listings Model

-,--------- ------- :f--------^ --- [ -------
Middleware
Layer Collaboration Mechanisms
Layer
-----------------------------
Agents -
.. .------. -.- 1 -----.-.
Construction CAD Engineering
User Software Packages Software
Applications

Decision -
Makers ^^/t hV r (


Legend

I | Boundary of I I Local Functionalities EPIC System
EPIC System L---- of the Parties Components


Figure 4-2. Multi-layered structure of the EPIC system

The data layer consists of a group of databases that store consistent project

information such as a building model, resource listings of the contractors, and materials

availability listings from the suppliers. The agent layer contains gateway facilities that

enable user applications (in the user layer) to make contact with the system. The

computer applications used by the participants on the project are represented in the EPIC

system with agents. The agents are developed particularly for the unique functionalities

of the user applications. Between the agent layer and the data layer is the middleware

that handles the requests invoked by the operations of the user applications. The









middleware layer contains critical components that enable collaborations between the

parties of the project. The middleware layer can be implemented as a transaction system

that is capable of handling advanced transactions.

The nature of the EPIC system is a dynamic work environment for project data

and document management. During the construction stage the EPIC system acts as a run-

time system maintaining a set of consistent storage of project data. The system provides

different views of the project to members of the construction team that carry out different

tasks. The software applications used by decision makers from different parties act as

clients to the EPIC system and access project data subject to the coordination of the

system.

The operations of the EPIC system are driven by events that have impact on the

project and the decisions made by the members of the project team. During the

construction the effect of any events and the information generated by the normal

construction process are constantly recorded by altering the dataset in the user

applications used by the decision makers. The user applications send update requests to

the data layer so that the other user applications may share the changed view. Data from

different parties is reconciled in the middleware layer according to certain predefined

rules before being saved into the consistent data storage.

The EPIC system was implemented as a distributed application system over a

computer network with Java and CORBA as enabling technology. Team members are

able to work at different locations in a collaboration environment provided by the system.

The system bears the potential to exploit concurrency in the construction process by

increasing the accuracy and timeliness of information delivery.









The key technical issue of the system design is the collaboration mechanism that

represents the business arrangement between the participants on the construction project.

Because of some unique features of the construction industry, file locking mechanisms as

seen in document management system or standard transactions as widely used in database

systems cannot meet the requirements of the task in EPIC system. Advanced transaction

models are used as a technical solution to develop the collaboration layer for the EPIC

system.

Transaction-based Implementation

Traditional transaction service has been shown to be sufficient technology for the

concurrency control for common database systems [ELM92]. However a traditional

transaction system does not apply in the case of the EPIC model because of the unique

requirements brought by the following features of the construction industry and

construction projects,

* The organizations of a construction project are temporary and customized according
to a specific project.

* A complex information entity, the building, is the center of constant information
exchange among participants in the project.

* More human involvement is required than in a generic workflow system, such as
office automation.

The EPIC system has to be designed to consider these issues. The feature of

temporary organization requires a framework that enables flexible regrouping of different

types of business entities for new projects. A data model for buildings such as IFCs has to

be part of the system for the purpose of project information management. Constant

human interventions imply that the system has difficulty in achieving a higher level of

automation and the processes workfloww, activities) may run for long extended times.









Advance transaction systems, which are developed to accommodate long running

activities and distributed objects are a viable technical solution to the EPIC system. A

preliminary study [LU02] has been conducted to compare in general the difference

between a traditional transaction system and an advanced transaction system. Further

investigations are needed to test the system in the context of actual construction projects.

Transaction Models and Transaction Design

Basics about transaction and transaction models are reviews in this section to

provide a basis for the development of a transaction-based implementation for the EPIC

system. Principles and methods of transaction design are also discussed in details.

Transaction Basics

A transaction is a sequence of read and write actions that are grouped together to

form a database access [RYA95]. The functionalities of transactions require it has

properties commonly referred to as the ACID properties:

* Atomic: the transaction either completes or fails as one unit
* Consistent: resources (database) must maintain a consistent state
* Isolated: no interface is allowed between transactions
* Durable: the result of the transaction is not lost even in the presence of failure

However in many cases of applications the properties of traditional transactions

do not apply. Advanced transaction models were motivated by complex applications like

office automation, CAD/CAM and software engineering. The tasks in these systems are

characterized with the following features:

* Long duration, could run for hours or even days
* Cooperative tasks
* Operate on heterogeneous systems

It is no longer feasible to implement these tasks with the traditional transaction

model. New transaction models, which are referred to in general terms, as extended









transaction models or advanced transaction models, are developed for these special

tasks [MOS87, GAR90, ELM90, WEI92, BUC92, ZHA94]. Key features of these

models include

* complex transaction structure
* non-serializable correctness criterion
* capability of running against both transactional and transactionless object

Transaction models can be characterized by transaction structure, object structure

on which the transactions operate against, and correctness criterion. Figure 4-3 is a road

map showing how a transaction model is characterized.

The physical structure of transaction varies as a result of making extensions to the

original transaction model. A flat transaction has a single start point and end point, and

was studied extensively for database management system. A nested transaction may

contain subtransactions which may recursively contain other subtransactions. Closed

nestings are actually nested transactions with traditional transaction semantics [GRA96].

Open nestings relax the rule of isolation in ACID properties by making the effect of the

transactions visible to other transactions running concurrently. Some transaction models

try to cover both open nesting and close nesting and therefore are called combinations

[ELM90].

The object structure becomes relevant because complex applications for which

advanced transaction models are designed often contain more than simple objects. An

example of a simple object is a physical page in a database. Operations on a simple object

do not consider the semantics of the object. Complex objects could encapsulate a set of

objects and often have a set of inheritance relations with other objects. Sharing of state

and/or behavior among objects may be involved. A transaction operating on one object










may spawn additional transactions on component objects. An active object is able to

respond to events by triggering actions for certain condition.


Transaction
Model


Transaction Object Correctness
Structure Structure Criterion


Flat Transaction Simple Objects Serializability
Closed Nesting Complex Objects Non-Serializability
Open Nesting Active Objects
Combinations

Figure 4-3. Road map for the study of transaction models

Serializability is a common correctness criterion for database systems. It sets

conditions to make sure the execution of transactions does not incur any conflictions

within the database system. Any non-serializable correctness criterion, which is not as

restrictive, leads to an advance transaction model.

Comparison of Transaction Models

Some notable works regarding advanced transaction models include, nested

transactions [MOS87], sagas [GAR90], multi-level transactions [WEI92], flexible

transactions [ELM90, ZHA94], and multitransactions [BUC92]. The transaction

structure, object structure and correctness criterion are three dimensions of the concept

space of transaction models. Different transaction models can be described using the

combinations of the values from these dimensions. For example, the original transaction

concept uses flat transactions operating on simple objects and use serializability as

correctness criterion. Sagas use open nesting transactions on simple object with non-

serializability as correctness criterion. Multitransaction goes to the other end of the










spectrum, with combination transactions on active objects using non-serializable

correctness criterion. Table 4-3 is a comparison of the transaction models.


Table 4-3. Comparison of transaction models
Transaction Transaction Object Correctness Recovery
Models Structure Structure Criterion Mechanisms
Traditional Model Flat Transaction Simple Object Serializable
Nested Transaction Closed Nesting Simple Object Serializable
Multi-level Transaction Open Nesting Simple Object Non-serializable Commutativity
Saga Open Nesting Simple Object Non-serializable Log-based
Flexible Transaction Combinations Simple Object Non-serializable Retry and
Compensating
Multitransaction Combinations Active Object Non-serializable Compensating
Transaction

The technical solution adopted in the EPIC system is a transaction system with

open nested transactions and non-serializable correctness criterion that operates on

complex objects.

The basic logic about relaxing the ACID properties of transactions is that the

semantic information about the transaction and its objects can be used to achieve a higher

level of concurrency. Transactions are decomposed into smaller steps and non-

serializable correctness criteria are used. Some key research issues include, failure

recovery, correctness and dependency issues, and partitioning and granularity of objects.

Efforts to Combine Different Transaction Models

Efforts have been made to unify various existing advanced transaction models.

Some of them have been successful in one aspect or another but a perfect solution has yet

to be found. An overview of some of these studies is presented below.

DOM [BUC92] is a result of early studies on advanced transaction models.

Multitransactions are defined as a concept of the general transaction structure for flat

transactions, nested transactions, sagas, flexible transactions, and multi-level transactions.

Figure 4-4 is an illustration of the structure of a Multitransaction. Toptransaction is a









closed nested transaction with a complex transaction structure but it appears as an atomic

transaction to peers. A Multitransaction is a combination of Toptransactions with global

transaction semantics but it permits partial results to become visible outside of a

Multitransaction. In order to accommodate the requirement of saga, a compensating

transaction is designed to remove already committed partial results in the situation when

a rollback occurs. A compensating transaction needs to be defined for each member

Toptransaction of a Multitransaction. The concept of contingency transaction comes from

the study on Flexible Transactions [ELM90, ZHA94]. It gets executed if the primary

transaction fails.


Contingency transaction

Multitransaction Toptransaction



A A A
II II II I I I
jI I--- ---I I L--- ,- I Ij -- -,i

Compensating transaction

Figure 4-4. Transaction structure of a multitransaction

Depending on the requirements of the application and the transaction design, the

DOM transaction model may behave as a traditional flat transaction, a transaction model

that allows for closed nesting and the execution, or combinations of closed and open

nesting. DOM provides a good method in capturing transaction structure, however it does

not address sufficiently the correctness criterion issues, which are critical to the success

of an advanced transaction model.

The ACTA framework [CHR90, CHR91, CHR94] is a tool to analyze and

formally specify different transaction models especially regarding the criterion issues.









According to the study, the flexibility of a transaction model depends on the

combinations of four notions [CHR91]:

* Visibility: the ability of a transaction to see the result of another transaction while
executing

* Performance: the ability of a transaction to write to a database

* Recovery: the ability to keep the database in a correct state in case of failure

* Consistency: the correctness of the state of the database produced by a committed
transaction.

The ACTA framework captures not only the interactions between transactions but

also the effects of transactions on objects. Each object has a state and a status associated

with it. The state is represented by the content of the object and the status contains

synchronization information. Each transaction has a View Set containing the object set

potentially visible to the transaction and an Access Set containing objects already

accessed by the transaction.

A transaction may transfer an object in its Access Set to another transaction via

"delegation." The activity of delegation makes the state and partial results of the

delegator become visible to the delegate.

The ACTA framework presents a simple way to define dependencies between

transactions for the reasoning of the behaviors of the transaction. Commit-Dependency

and Abort-Dependency are known as completion dependencies. If Transaction A

develops a commit-dependency on Transaction B, Transaction A cannot commit until

Transaction B either commits or aborts. If Transaction A develops an Abort-dependency

on Transaction B, and if Transaction B aborts, Transaction A should also abort.

ASSET [BIL94] is a flexible transaction facility based on a set of transaction

primitives. These primitives are designed according to the principle of ACTA, and can be









used to define customized transaction models for specific applications. Many of the

existing advanced transaction models can be specified with ASSET. It is also possible to

use ASSET to specify activities or workflows that normally has transaction-like

properties. ASSET is actually an implementation of ACTA.

Basic primitives in ASSET include, initiated, begin, commit, wait, abort0,

self, and parents. Special primitives are setup for the functions of ACTA including

delegates, permit, and form dependency. These primitives can be used for the

description and execution of transactions.

In research incorporating DOM model, CTM [GE096] addressed the issues about

application specific transaction model in the circumstances when distributed object

system are involved. The primary value of CTM is to provide a framework about

handling objects in heterogeneous, autonomous, and/or distributed (HAD) systems and

detailed descriptions and reasoning about correctness criteria.

CTM provides facilities to ensure the correctness and reliability of distributed

applications by supporting customized transaction model according to the specific

requirement of each application. The CTM framework can handle not only transactional

objects but also transactionless objects with no transactional support at the local systems.

Transaction Design

The first step to build a transaction based implementation for the EPIC model is to

transform business procedures on construction projects into transactions. Common

business procedures are identified through extensive study of the practice of construction

project management. The system processes and transactions are designed based on the

analysis of the basic elements of the business procedures and their interactions with the

project information. Customized transactions are needed to cope with the various impacts









to project information brought by the business procedures. Multi-level hierarchy and

ACTA properties are the two primary features of the advanced transaction model

incorporated in the design of the transaction system for the EPIC system.

The transaction design for the EPIC system adopted from the DOM study the

transaction structure with two levels of hierarchies. A multitransaction contains three

types of steps, subtransaction, decision and message. Subtransactions carry out

activities that need to access remote databases. The Message is simply a step that a

communication needs to be sent to a remote site and an answer is required. Decision steps

are the checkpoint in the transaction where decisions are made regarding if the

transaction is successful.

Multitransactions, which are combinations of subtransactions and messages in a

certain way, are representations of business procedures in the EPIC system. The

occurrence of a certain event requires a business procedure to be initiated and in turn

triggers a corresponding multitransaction in the EPIC system. Multitransactions behave

either as a flat transaction or advanced transaction with steps depending on the nature of

the business procedure the transaction represents.

During the execution a multitransaction has three states, execution, commit or

rollback. Multitransactions at execution state read, modify the shared project information,

or send collaboration messages as may be required by the business procedure. A

multitransaction at commit state simply removes all locks and finalizes the modifications

made to the shared project information. In the case of rollback more complicate

operations are required within the system. Compensating transactions are used to

eliminate the effects of the partially executed multitransaction during rollbacks. Details









and the reasons for the rollback are sent back to the initiator of the transaction. So the

initiator is able to modify the parameters of the previous transaction and to try to execute

again after receiving the information carried with a rollback.

The concepts from the ACTA framework are implemented within the distributed

database and the transaction design. The strategy of handling failed transactions is

through rollbacks and reviews. The lock mechanism for the distributed database is

specifically designed with the notions of ACTA framework. An ACTA lock allows any

users to read the locked information however has to register with the user ID and the

execution status. If a rollback ever occurs any readers with dirty read will be informed

accordingly.

Specification Language for Customized Transactions

The design of a multitransaction for a business procedure is based on the actual

practice on a construction project and may vary from one project to another. The users of

the EPIC system should have a certain level of flexibility in designing multitransactions

with predefined rules. A simple language is designed in EPIC for the users to specify

transactions based on the needs of their business operations.

A scenario is used to show how the language represents a business procedure in

the format of transaction. The EPIC system maintains two types of distributed databases,

a simple database for currently available materials and resource, and a building model

with higher-level complexities. Five types of actors exist in the EPIC system, owner,

architect, engineer, contractors, and suppliers.

The operations on the distributed databases are represented with subtransactions

in the transaction format. A complete list of possible operations against the distributed

databases is shown in Table 4-4. The operations on distributed databases as well as the










actors are coded as part of the specification of the language. Other two basic elements of

the transactions are message (M) and decision (D).


Table 4-4. List of valid database operations
Code Database Description Valid User
P00 Building Model Read in product model information ARC, C, ENG, OW
P01 Building Model Pre-update of product model ARC, C
P02 Building Model Final update of product model ARC, C
P03 Building Model Direct update of product model C, ENG
P04 Building Model Mark the product model OW, C
ROO Resource Listing Reserve resource ARC
R01 Resource Listing Update resource list C
S00 Material Listing Reserve materials ARC, C
S01 Material Listing Update materials list S
Note: Owner(OW), Architect(ARC), Engineer(ENG), Contractor(C), Supplier(S)

Transactions are composed of steps, which are container of the basic elements,

namely, subtransaction, message, and decision. Steps can be simple or composite as

shown in Table 4-5.


Table 4-5. Code and content for steps
Type Code Content Meaning
Composite A Steps Alternative, successful if any member step is successful
Composite C Steps Concurrent, successful if only all member steps are successful
Simple S Subtransaction, or A simple step equal to its content
message
Simple D Decision A simple decision step.

Figure 4-5 shows an example of a business procedure to check and determine

whether there are enough resources available to make the changes proposed by the

architect. The procedure shown in Figure 4-5 is one of the possible scenarios that could

occur when an architect is proposing a change to the project.

The architect needs to check the availability of critical materials from suppliers

and labor and equipment from the contractors. If all the prerequisite conditions with

regards to the materials and resources are met, a request will be sent to the owner for

approval. The architect proceeds to the design stage upon approval of the owner.










Alternative procedures are available to check the contractor's resources and the

supplier's materials for availability. It is assumed that the resources and materials could

be obtained from different sources. If the first attempt to get a resource or material from a

certain contractor or supplier fails, another attempt will be made towards another

contractor or supplier. The failure of either of the first two stages will result in the failure

of the entire procedure. Another cause of failure occurs when the owner rejects the

change request.


Transaction fails, rollback, restart

Y N
Start Check Y Y
Cl Check N
S1 Y
N Upload
Y N N
Check C Y
C2 Check
S2 Msg Review
Y I I

Cn Check
n Design Starts

Check Contractor's Resource Check Supplier's Materials Update Owner's Review


=- Start > Decision = Process
Cl, C2, ... Cn are contractors; S1, S2, ... Sn are suppliers.


Figure 4-5. Sample business procedure: the architect proposes a change

The specification language designed for this study can be applied in this case. The

procedure as shown in Figure 4-5 can be represented with simple code like this:

A(ROO, *)-D-A(SOO, *)-D-S(P04)-S(M, OW)-D

Steps of transaction are delimited with "-". A single content code is specified for

either a composite or simple step. The second code within the bracket indicate the target

of the content code, which could be the receiver of a message or the location of the









database to which the subtransaction should be sent. In the case where no target code is

present, the target uses a default value. For example the scenario presented above has

only one building model, so the default target code of"S(P04)" is "ARC". A target code

"*" means all targets that the specific content code may apply to. For example, "ROO" is a

subtransaction for checking resource of the contractors, "*" means all contractors.

Prototype and Programming

The section provides programming details about the prototype. UML diagrams

are used to illustrate the structure of the prototype as well as the functionality and

dynamic aspects of the system.

Structure of the Prototype

The efforts of implementing the EPIC model results in a distributed software

system that is capable of providing functionality as specified in the model. The primary

technology used in the development is Java and CORBA.

Figure 4-6 is a class reference diagram showing the relationships between the

components of the prototype system. Procedure definitions component contains syntax of

a simple language that allows the users to define procedures according to their needs.

Some predefined procedures have been provided and used in the tests. Procedure

execution component actually is a software engine that is capable of interpreting and

executing the user defined procedures. A substantial amount of the steps in the

procedures incur activities that access the shared database system. The synchronization

and data integrity of the database is maintained with an advanced transaction system.

Other type of activities that are involved in the execution of the procedures is message

passing and decision making. This part of the functionality is accomplished through

sending system calls to the coordination and control component.







73




Message Resource Material BuildingComponeni
com.hlu.information com.hlu.information com.hlu.information co .hlu.information

-1 -------------------------------- -
SProcedure CorbaAdaptor STransaction Procedure InfoObjectPool
Theu. emcom.hlu.client com.hlu.transaction com.hlu.client
i Execution > -- Definitions ,mu
SDecorder i Dispatcher Step TransGenerator ProcedureFactory
com.hlu.client com.hlu.client com.hlu.transaction com.hlu.client com.hlu.client


Scom.hlu.transaction
S. com.hlu.client
,*----------- ---------'------ -- ^ --
Coordination MessageHandler CoordinationAgent I i
i i sProcedureDefinition
and Control com.hlu.client com.hlu.client i: ProcedureDefiitio
S: I com.hlu.client

Actor ProjectInf(
com.hlu.starter com.hlu.inf
....................... .... --- ......--. .. ......- .
Shared DBs ShareInfoObject
com.hlu.starter

Building ACIDLock ACTALock Catalogue
com.hlu.server com.hlu.server com.hlu.server com.hlu.server

Catalogue Lock Reservation
com.com.hlu.sercom.hlu.server com.hlu.server



Figure 4-6. Class reference diagram of the EPIC system

The entire system that contains multiple copies of the actor classes is started

simultaneous with a single starter program. Each actor will initialize and start up the

client side (procedure definition and handling) and the server side (shared information

objects).

Classed for various types of information are defined in the system. Project

information such as the members of the project team and the parameters for initialization

of the shared databases are stored in a ProjectInfo class. Both client side and the server

side of the actor read in project information during the initialization process. Information

objects identified in the prototype include message, materials, resources, and building









components. A transaction system with two level semantics is used for the

implementation of the procedures.



Actor 1 (Architect)
Client side: Server side: Message
Coordination Agent Distributed DB Handler

Lookupi ;R
Look Register

List of Remote Other I
Communication Links NamingService Objects I Actor





SClient side: i Server side: ot Message
I coordination Agent Distributed DB E~ Handler


Figure 4-7. Deployment diagram of the EPIC System

Deployment Diagram

The deployment diagram of the prototype shows the physical view of the system.

The relationship between software components and the layout of hardware is illustrated

in Figure 4-7. The system can be deployed on a group of computers that are connected

with a network. The CORBA naming service is the basic facility that enables the actors

find out the existence and location of other actors. Each actor registers a message handler

and a distributed database if required with the CORBA system. The coordination agent,

which is the client side of the actor, looks up the location of other actors by name in order

to make contact with them.

Definition of Transactions

The activity diagram in Figure 4-8 shows how a predefined procedure is

converted to a transaction in the prototype. Transaction templates are prepared in the










object ProcedureFactory during the initialization of the prototype according to the

definitions specified in the object ProcedureDefinition. Users of the system may use a

language with simple syntax and grammar to define customized procedures in their

system.

At run time if a user program need to access shared databases with external

processes, a request is generated and sent to the object CoordinationAgent. The object

ProcedureFactory handles calls from the object CoordinationAgent in regarding the needs

for a transaction. The call is validated at the object ProcedureLibrary against the existing

set of predefined transactions. If it is a valid call, a transaction template is returned to the

ProcedureFactory.



TransGenerator! InfoObjectPool ProcedureFactory ProcedureLibrary ProcedureDefinition
I I I I I
I m nInitialize a Building a
I library procedure Read in a
Template predefined
Decode -procedure
i steps Validate
I-- steps
Decode
targets Validate
~ I Itargets
Save steps

Build another I
Prepare a Validate Return a proper
procedure procedure code definition

Prepare Read
information for information the procedure requirements

Build a- I Decode the
Build a transaction I I
I component 1 Build a ]
transaction


Figure 4-8. From predefined procedures to system transaction










Project information needs to be provided along with the procedure call. For

practical purpose the information in the prototype is prepared in the object

InfoObjectPool. In realty this step should be completed with the intervention from the

system operator. The ProcedureFactory retrieves transaction component from the object

TransGenerator according to the transaction template. The transaction is finally

assembled at the ProcedureFactory with the transaction components and information

objects from the InfoObjectPool.

Execution of the Transactions

Transactions are executed within a set of classes that form an engine like facility.

The activity diagram in Figure 4-9 shows the process of transaction execution.


CoordinationAgent Dispatcher Decoder CorbaAdaptor

S Build a Execute
transaction transaction

Decode steps Identify
SI- step
Execute steps
SDecode target
naly Identify target
Analyze resultsContact info object
Success
SCommit \ Decode target
Fail Identify target
x ii Contact info object
SI Rollback Decode target
Identify target ,I. -
Inform other Contact info object
I actors about theI I
rollback Contact message
S, handler
Repeat the I r
transaction


Figure 4-9. Execution of a prepared transaction

The execution of the transaction comes after the CoordinationAgent obtains a

transaction object from the ProcedureFactory. The transaction object is sent to the










Dispatcher and decoded into steps. A Decoder object needs to be accessed to determine

the types of the steps. An identified step is sent to the CorbaAdaptor. Depending on the

nature of the step the CorbaAdaptor contacts a remote information objects as indicated as

target. The results of steps are returned to the Dispatcher and analyzed. If the transaction

is executed successfully, the commit stage begins. Otherwise the transaction undergoes a

rollback and all traces of the execution will be eliminated through sending messages to

any party that has dirty read. The Dispatcher automatically restarts any unsuccessful

transactions.

Figure 4-10 is a higher-level diagram about the definition, transformation, and

execution of the transactions. The user's view shows an example of what could happen in

an actual construction project. Project information needs to be used and updated from

time to time along with the proceeding of the physical activity of the construction.

System's View is a general description about what happens in response to the activities in

physical world. The system provides support to the user activities transparently by using

transactions to contact remote data source.

Client Applications (example Primavera) Construction Activities
Ai (example, build a wall)
Transaction
Feedbacks
The EPIC system
Transaction
Predefined Engine Read or update shared
Procedure I information
Pool Fe Steps

Feedbacks _
I I I I I Contact Project Databases
Remote Sites Access Adaptor (product model and other
I I I I shared information)
L__----____------------------____---____------ ---- ----
System's View i User's View

Figure 4-10. System view and user view









Interactions among the Actors

Interactions occur among the actors as a result of the business operations of each

actor and the dispatching of transactions (procedures). A collaboration diagram as shown

in Figure 4-11 is used to demonstrate the interactions between a group of actors. The

diagram shows basic operations regarding information access and handling of rollbacks

caused by dirty reads. The actors share the same structure as shown in the figure.

However only part of their functions are active for each of them to illustrate a snapshot of

the entire collaboration picture.



Actor 1 I MessageHandler

Dispatcher 1: result = step CorbaAdaptor
Database Lock

Reviewer Rollback List 2: result or 5: if rollback,
Srollbacklist = broadcast(rollback
call() list)
Actor 2 MessageHandler

Dispatcher CorbaAdaptor
Database 4: result = call Lock
Reviewer Rollback List -- 3: register(reader)


Actor 3 6:interrupt(n) MessageHandler

Dispatcher CorbaAdaptor
S7: review(n) Database Lock

Reviewer Rollback List


Figure 4-11. Collaborations between actors

The collaboration process initiated with steps sent out by the Dispatcher object.

The CorbaAdaptor identifies the target and makes a call to it. Before getting to the

database, the call has to go through a Lock object. A lock is placed if necessary and the









information from the reader are register in case rollback is needed. Afterward the call

goes on and accesses the database. The lock is removed if the final result of the

transaction is a success. Otherwise a rollback list is returned and a rollback process is

initiated at the original Dispatcher. A rollback signal is broadcasted to the

MessageHandler objects of the actors on the rollback list. The MessageHandler takes the

signal and interrupts the progress of the Dispatcher. A review process is started to find

out what has to be done to cope with the earlier dirty read.

Outstanding Issues and Future Works

The prototype developed according to the EPIC model is capable of handling

simulation with simple procedure calls and scenarios. Tests have been conducted to

verify the potential benefits of using such a system and resolve technical issues.

Additional works is needed in various aspects before the system is adopted in actual

application.

Customized definition of user procedures is an important function that the system

should provide. The existing method coded the definitions and the language into the

program as a static java object. It is possible to replace the ProcedureDefinition object

with a proper user interface and definition tools. Equipped with the knowledge of some

simple rules, the system operators will be able to specify customized procedures

according to their needs. The operations of the system are eventually assisted with a

higher-level programming upon the system.

The transactions are designed to operate on java objects that are independent of

the local system. It is necessary to provide adaptors that handle the interactions between

the information objects and the user programs. Because of the variety of the user






80


programs that are potentially involved the adaptors have to be studied and designed using

case-by-case method.














CHAPTER 5
CASE STUDY AND TESTING

Tests have been conducted within the EPIC system in order to validate its

functionality and benefits as well as to identify any potential research issues. Test

methods from previous integration research were analyzed and compared to form a basis

for the proper design of the test plan for this study. The test plan consists of three levels

of tests targeting issues related to the benefits and technical solutions of the system. The

scenarios used in the tests are change procedures that occur during construction stage of a

construction project. Assumptions and simplifications have been made to the actual

procedures found in construction projects.

Review of Test Methods from Previous Studies

Soundness of the test methods is critical to the success of the study. Test methods

from similar studies are analyzed and compared in Table 5-1. Many studies have

attempted to conduct certain type of testing in accord with the nature of the study. The

most common method regarding to testing is proof of concept with implementation. For

example, a unique method called charrette was used during the design process in the

CIFE's IFC trial implementations.

Many existing integration systems claim the applications of a certain system may

bring benefits such as facilitating the communications between the parties and process

optimization. It has become a difficult issue to verify the benefits as claimed without

extensive applications on actual projects. Unverified benefits are one of the reasons that

the industry is not willing to accept the various systems that have diligently been










developed. On the other hand the large-scale applications are not possible without their

acceptance by the construction industry. The "catch 22" situation as shown in Figure 5-1

has prevented further progress of the research and development of integration systems.


Acceptance by
Industry

/>
Verification of Large Scale
the Benefits Applications


Figure 5-1. "Catch-22" that troubles the progress of integration systems


Table 5-1. Comparison between test methods
Studies Technical Solution Test Scenarios
OPIS prototype, [FRO92] Object-oriented data model, Prove-of-concept NA
databases
Building Project-Model, Prototype with modeling Prove-of-concept Concrete structures
[LUI98] tools
Cross-Sector Business Reference to distributed NA Bidding and
Model [YUM98] facility contracting
The COMMIT Project Information and document Prove-of-concept Changes by architect in
[REZ98] management, and version concurrent context.
control.
CIFE IFC Trial IFCs, modeling tools, and Charrette-style, prove- Represent two walls
Implementation databases of-concept with IFCs
[FRO99a]
CIFE system Architecture IFCs, and software packages prove-of-concept Changes during
[FRO00] for construction construction
Robust Mediation of Query processing and Prove-of-concept Activity rescheduling
Construction Supply wrappers
Chain, [OBR01]
EPIC Project Model, H. Rule based, transactions, and Comprehensive test Changes during
Lu, 2002 (This study) distributed facility including prove-of- construction stage
concept, simulation
and analysis

Test Plan

The objective of test plan is to study the potential benefits and effectiveness of the

technical solutions of the system. A comprehensive test plan with three levels of tests are


used to study various issues:









* Proof of concepts: shows the possibility of building a system based on the
implementation of the ideas as presented in the EPIC model

* Demonstration of Functionality: uses simulations to validate the EPIC system's
capability to support the formation of a change order and conduct sensitivity analysis
of the performance variables to study the factors that have impact on the efficiency of
the system.

* Performance of the technical solutions: uses tests of the enforcement system for
advanced transactions and the shared database system.

Proof of Concepts

The concepts presented in the EPIC model are tested with the implementation of

the EPIC system. A prototype system based upon a distributed infrastructure has been

developed and provides the following functionalities:

* Simple syntax and specifications for advanced transactions with two level semantics
of the transactions as a tool for the collaboration between the participants

* A software engine that is able to recognize and execute an expandable set of
transactions.

* Modeling and design of common roles and actors found on construction projects and
shared information sources.

The development of the prototype shows that it is possible to build a transaction-

based system for the collaboration task among participants on construction projects. The

model and implementation presented in this study can be adopted as a basis for the

further development of a workable system in real world applications.

Demonstration of Functionality: A Case Study

A case study with a simplified construction project was conducted as part of the

test plan for the EPIC model. The validation of the proposed model was conducted from

both qualitative and quantitative aspects. The primary objective of the case study was to

demonstrate the functionality of the system in support of the business processes on

construction projects by using the formulation of a change order as an example. The









contributing factors that have impact on the system functionality were studied from the

perspective of the operations on construction projects and a sensitivity analysis was

conducted on these variables.

Background

Construction change orders are used as an example of construction processes that

can be supported by the EPIC system. A complex decision needs to be made regarding a

significant change on the existing design at the construction stage. The parties involved in

the decision making process are the owner, architect, engineer, one contractor, and a

number of suppliers. The changes are more complicated in nature than the cases

involving a simple material substitution. Additional design work is needed from both the

architect and the engineer. The suppliers are involved only to provide availability and

pricing information for critical materials. Issues such as the constructability and the

availability of key materials have critical impact on the design work and need to be

considered during the design.

Data about change orders collected from the Pinker Hall project [SMA02] at the

University of Florida are used to estimate the turn around time for various types of steps

found in typical change order processes. Rinker Hall is the new home of M.E. Pinker Sr.

School of Building Construction. The $8 million building is a composite concrete and

steel structure with 48,000 square feet. The construction began in November 2001 and

will be completed in December 2002.

Assumptions

Assumptions and simplifications are made based on actual construction projects

for the purpose of the case study. Format and ownership of project info as well as basic

system requirements for the members of the system are described below.









It is assumed that the product model is a viable method to represent the building.

Complete architectural and engineering design and specifications for the project is

available in the format of a building model and stored at a centralized location. The

architect provides the initial design information. The contractor provides updates to the

building model with information generated along with the construction activities. It is

also the responsibility of the contractor to provide the availability and pricing information

of the contractor's extra resource, such as labor and equipment. Suppliers provide the

availability and pricing information for construction materials. The resource and material

information is stored in the format of a shared database so that the other project team

member may have access to it.

Agreement has to be reached among the members regarding the ownership and

uses of the shared information before the initialization of the system. The architect has

full control over the building model. The contractor has limited capability of updating the

building model. Every party except the supplier has the right to read the relevant content

of the building model. The only user of the contractor's resource database is the architect.

Both the architect and the contractor may read the suppliers' resource databases.

It is assumed the project participants have various level of capability to use

information technology for the project. The minimum system requirement is a PC with

network connection. An agent application and a database (if needed) need to be installed

on every computer. For example, the contractor needs to install a resource database on

their computer. However the owner need only an agent application. It is not required that

the participants have to use computer applications that are compatible with each other.

The only requirement is that the computer applications need to be able to update the









shared database from time to time. The collaboration activities between the participants

are accomplished by a CORBA interface. Therefore a dedicated computer is used to

provide naming service to the entire group of users.

Simulation

The formulation of the change order is accomplished with the assistance of the

EPIC system. The exercise shows how the participants interact with the system during the

process. Hypothetical data sets were used to initialize the shared databases. Figure 5-2

shows a flow chart about the process of making a change.


Final Review

Design Review
SArchitectural Engineering I I
L{d Designesign I Yes Signed
1onstructability Change
Review No Order
Modify the
Design a ii
Availability I



Figure 5-2. Formulation of a change order

The entire process starts with a change of mind by the owner. The owner initiates

the process by sending a message to the architect. The message contains a reference to a

certain part of the building model that is in question. Before sending the message, the

owner has inserted a flag in the building model and made some comments indicating the

owner's intention. It is assumed that this approach is sufficient to convey the idea of the

owners to the architect. In reality the client briefing could be a very complicated process.

Extensive activities outside of the system such as phone calls and meetings could be

involved. However a flag in the shared building model is able to make all relevant parties

aware of the ongoing issues with this particular part of the building.









The architect acts as a leader of the entire process from then on. As shown in

Figure 5-2, architectural design is conducted within the scope of the architect's computer

system and uploads to a temporary location in the shared building model after completion

of the design. The engineer is informed and provides engineering design based on the

initial architectural design obtained from the building model. The software applications

used by the engineer should be capable of importing data from the building model. A

commonly accepted information standard is definitely needed for a rich information

exchange like this.

After being informed that the entire design is ready, the architect initiates a review

process by sending out messages to the relevant members of the project teams. The

owner checks the completed design against the original intentions. The contractor may

conduct a constructability review and check if there is any conflict between the new

design and the existing works. At the same time an availability and pricing query will be

sent to the suppliers via the system if any critical materials are specified in the design.

Each supplier needs to provide to the contractor the availability and best price of the

materials. The contractor places a pre-order for the material with the supplier that quotes

the best price.

The results of the joint review by the owner, the contractor and the suppliers are

sent to the architect as shown in Figure 5-2. Simple reasoning is made regarding whether

a positive answer has been obtained. If so a signed change order will be produced and

sent to the contractor. Otherwise the system will start a rollback process to remove any

residual effect. If a preorder has been placed, the system will automatically cancel it. The

architect will study the reason for any negative answer and modify the current design for