Citation
Developing a Framework to Support Data Exchange from Heterogeneous Data Sources Via Industry Foundation Classes (IFC) and Web Services

Material Information

Title:
Developing a Framework to Support Data Exchange from Heterogeneous Data Sources Via Industry Foundation Classes (IFC) and Web Services
Creator:
DANSO-AMOAKO, MARK OWUSU ( Author, Primary )
Copyright Date:
2008

Subjects

Subjects / Keywords:
Architectural models ( jstor )
Cost allocation ( jstor )
Cost estimates ( jstor )
Data models ( jstor )
Database models ( jstor )
Mile markers ( jstor )
Modeling ( jstor )
Scheduling ( jstor )
Web services ( jstor )
XML ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Mark Owusu Danso-Amoako. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
12/31/2011
Resource Identifier:
659330590 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

1 DEVELOPING A FRAMEWORK TO SU PPORT DATA EXCHANGE FROM HETEROGENEOUS DATA S OURCES VIA INDUSTRY FO UNDATION CLASSES (IFC) AND WEB SERVICES By MARK OWUSU DANSO-AMOAKO A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2006

PAGE 2

2 Copyright 2006 by Mark Owusu Danso-Amoako

PAGE 3

3 Dedicated to my family.

PAGE 4

4 ACKNOWLEDGMENTS My sincere gratitude goes to Dr. Raymond I ssa, whose constant advice, encouragement, patience and dedication to my gra duate studies has resulted in th is dissertation. He has been my advisor/mentor since I set foot at University of Florida. He was the committee chair for both my master’s thesis and doctoral dissertation, and his kindness and inspiration have sustained me throughout my studies. Dr. Issa provided outstanding academic and professional guidance during my doctoral studies and gave me wonderful opportunities to excel academically and professionally. My thanks also go to members of my docto ral committee Dr. Robert Cox, Dr. Ian Flood and Dr. Randy Chow, whose immense contributions ha ve resulted in the success of this project. I am grateful to the faculty and staff at the Ri nker School of Building Construction for providing a stimulating environment for my graduate studies. I am utterly grateful to God for all the wonderful blessings in my life. I am very grateful to my parents for all the sacrifices they made to s ee me to such great heights and for their constant support. I am grateful to my siblings who suppor ted and expanded my dreams. I am grateful to my wife, Lucy, for her support and encouragemen t. I wish to thank my children, David and Anna, for their patience while I wa s completing this research work.

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS...............................................................................................................4 LIST OF TABLES................................................................................................................. ..........8 LIST OF FIGURES................................................................................................................ .........9 ABSTRACT....................................................................................................................... ............12 CHAPTER 1 INTRODUCTION..................................................................................................................13 The Construction Industry – An Overview............................................................................13 Problem Statement.............................................................................................................. ....14 Research Program............................................................................................................... ....15 Aims and Objectives............................................................................................................ ...16 Scope and Methodology.........................................................................................................17 Layout of Research............................................................................................................. ....17 2 LITERATURE REVIEW.......................................................................................................19 Introduction................................................................................................................... ..........19 Modeling – Basic Concept......................................................................................................19 Product Modeling............................................................................................................20 Process Modeling............................................................................................................20 Project Modeling.............................................................................................................20 Pioneering AEC Models.........................................................................................................20 The Standard for the Exchange of Product Model Data (STEP).....................................21 Construction Object Model (GenCOM)..........................................................................22 The AEC Core Model......................................................................................................22 Contemporary AEC Models...................................................................................................24 CIMSteel Integration Standards (CIS/2).........................................................................24 Industry Foundation Classes IFC....................................................................................25 Resource Layer................................................................................................................25 Core Layer..................................................................................................................... ..26 Interoperabi lity Layer......................................................................................................27 Domain Layer..................................................................................................................28 IFC – Level of Detail.......................................................................................................28 Data Exchange Technologies.................................................................................................31 Global View of Data Inte gration in AEC Industry..........................................................31 Centralized Project Database Model........................................................................31 Distributed Project Database....................................................................................32 Neutral Format Model..............................................................................................32 Extensible Markup Language XML................................................................................34

PAGE 6

6 Web Services...................................................................................................................34 The Architecture and Key Co mponents of Web Services........................................36 Simple Object Acce ss Protocol (SOAP)..................................................................37 The SOAP Grammar................................................................................................38 Web Services Description Language (WSDL)........................................................39 Other Data Exchange Technologies.......................................................................................41 Stub/Skeleton Based Architectures.................................................................................41 Sample XML and Web Services Projects in AEC Industry...................................................43 IFC Model Server Development Project.........................................................................43 The Electronic Project Informati on Management System (EPIMS)...............................43 Analysis and Discussion..................................................................................................46 Summary........................................................................................................................ .........49 3 PROPOSED FRAMEWORK: SY STEM ARCHITECTURE AND IMPLEMENTATION.............................................................................................................51 Introduction................................................................................................................... ..........51 System Principles.............................................................................................................. ......51 System Architecture............................................................................................................ ....51 Step One....................................................................................................................... ...54 Steps Two and Three.......................................................................................................54 Step Four and Five...........................................................................................................54 Step Six....................................................................................................................... .....54 Structure of the IFC Converters......................................................................................54 System Implementation..........................................................................................................55 Option 1: Stand-alone Translator....................................................................................55 Option 2: Web Services Translation Service...................................................................55 Summary........................................................................................................................ .........56 4 CASE STUDY..................................................................................................................... ...57 Heterogeneity of Data Sources...............................................................................................57 Types of Schedules............................................................................................................. ....57 Bar Chart or Gantt Chart.................................................................................................57 Program Evaluation and Re view Technique (PERT)......................................................59 Network Development in Scheduling.....................................................................................60 Key Components of a Schedule..............................................................................................62 Activities..................................................................................................................... .....62 Temporal or Sequencing Logic.......................................................................................62 Scheduling Applications and Access to Their Internal Data Structure..................................63 Internal data representation................................................................................................... ..65 IFC Support for Scheduling....................................................................................................66 Process Extensions..........................................................................................................66 IfcProcedure.............................................................................................................66 IfcRelAssignsTasks..................................................................................................67 IfcScheduleTimeControl..........................................................................................67 IfcTask......................................................................................................................67

PAGE 7

7 IfcWorkControl........................................................................................................68 IfcWorkPlan.............................................................................................................68 IfcWorkSchedule......................................................................................................68 Case Study Scenario............................................................................................................ ...72 Summary........................................................................................................................ .........74 5 RESULTS AND DISCUSSIONS...........................................................................................76 Access to Application Data....................................................................................................76 Documentation on Internal Data Structure.............................................................................76 IFC Support for Schedule-Related Application Data.............................................................77 Uncommon Denominator.......................................................................................................78 IFC Support for Application-Specific Data............................................................................79 Incomplete Data Dave d to Imported File...............................................................................80 Software Engineering........................................................................................................... ..81 Different Concepts...........................................................................................................81 Different Data Representation.........................................................................................82 Cross Domain Data Sharing............................................................................................82 Conclusion..................................................................................................................... .........83 6 CONCLUSIONS AND RECOMMENDATIONS FOR FUTURE WORK..........................84 Conclusions.................................................................................................................... .........84 Recommendations for Future Work.......................................................................................85 APPENDIX A GLOSSARY OF SCHEDULING TERMS............................................................................87 B MICROSOFT PROJECT 2003 (XML) FILE.........................................................................91 C PRIMAVERA PM/MM (XER) FILE...................................................................................116 D IFCPROCESSEXTENSION ENTITIES SCHEMA..........................................................120 E SCREEN SHOTS OF PROPOSED STYSTEM’S PROTOTYPE.......................................129 F SAMPLE IFC CODE OUTPUT GENERATED BY MODEL............................................132 LIST OF REFERENCES.............................................................................................................141 BIOGRAPHICAL SKETCH.......................................................................................................144

PAGE 8

8 LIST OF TABLES Table page 2-1: Comparison of Stub/Skeleton Based Architectures...............................................................42 2-2: Proposed Research in Relation to Existing and Current Related Projects.............................49 4-1. Entities and Enumerations in the IfcProcessExtension ..........................................................68

PAGE 9

9 LIST OF FIGURES Figure page 1-1. Construction Is Multiparty in Nature......................................................................................15 2-1. Data Modeling Architecture................................................................................................ ...21 2-2. Model Architecture of GenCOM............................................................................................23 2-3. Elements of the AEC core Model...........................................................................................24 2-4. IFC Model Architecture.................................................................................................... ......26 2-5. IfcDateAndTime Resource................................................................................................... ..27 2-6. IFC Model in Relation to the AEC World..............................................................................29 2-7. EXPRESS Specification for IFC Window.............................................................................29 2-8. Centralized Project Database.............................................................................................. ....32 2-9. Distributed Project Model................................................................................................. .....33 2-10. Neutral Format Model..................................................................................................... .....33 2-11. Sample XML Document...................................................................................................... .35 2-12. Simple Website Technol ogy Using HTTP Protocol.............................................................35 2-13. The Web Service Architecture and the Ro le of the Internet Open Standards......................37 2-14. Communication Using S OAP over the Internet...................................................................38 2-15. SOAP Formatted XML....................................................................................................... ..38 2-16. Sample WSDL Document....................................................................................................40 2-17. Stub/Skeleton Based Architectures......................................................................................42 2-18. The IFC Model Server (IMSVR)..........................................................................................44 2-19. The System Architecture of the EPIMS model....................................................................44 2-20. Concept of the Hybrid Database in EPIMS..........................................................................45 2-21. Complexity of creating translators (A ) without models and (B) with models.....................47 2.22 Complexity Analysis of Developing Translators...................................................................47

PAGE 10

10 3-1. One-to-one Application Conversion.......................................................................................52 3-2. Principle Behind Proposed Model..........................................................................................52 3-3. Reduction in Number of Translators......................................................................................53 3-4. Proposed System Architecture.............................................................................................. ..53 3-5. Proposed Converter in Action.............................................................................................. ..55 3-6. Option1 Pure Translator Service......................................................................................... .56 4-1. A Typical Gantt Chart..................................................................................................... .......58 4-2. One-to-one Application Conversion.......................................................................................59 4-3. A PERT Chart.............................................................................................................. ...........60 4-4. Activity-on-thearrow networks............................................................................................ .61 4-5. Introduction of a “Dummy” Activity in to an Activity-on-the-Arrow Network.....................61 4-6. Activity-on-the-Node Network.............................................................................................. .62 4-7. Different Types of Re lationships in Scheduling.....................................................................63 4-8. Relationship with a Lag................................................................................................... .......63 4-9. “Save As” Dialog in Microsoft Project 2003.........................................................................64 4-10. Export formats for Primavera Project Planner.....................................................................65 4-11. A Simple schedule........................................................................................................ ........65 4-12. Overview of Some IFC Cl asses that Support Scheduling....................................................67 4-13. IfcTask Schema........................................................................................................... .........69 4-14. IfcProcessExtension Entities – Diagram1............................................................................70 4-15. IfcProcessExtension Entities – Diagram2............................................................................71 4-16. IfcProcessExtension Entities– Diagram3.............................................................................72 4-17. Proposed Model Showing the Converters............................................................................73 4-18. Screen shot of the developed model.....................................................................................74 5-1. Code Snippet for a PM/MM .XER Primavera File................................................................77

PAGE 11

11 5-2. Primavera Project Planner Repr esentation of 8-Hour Work Day...........................................78 5-3. Microsoft Project Representa tion of 8-Hour Work Day........................................................79 5-4. Data Loss in a Series of Data Translation..............................................................................80 5-5. Some Additional Formatting Data is Not Saved with Exported File.....................................81

PAGE 12

12 Abstract of Dissertation Pres ented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy DEVELOPING A FRAMEWORK TO SU PPORT DATA EXCHANGE FROM HETEROGENEOUS DATA S OURCES VIA INDUSTRY FO UNDATION CLASSES (IFC) AND WEB SERVICES By Mark Owusu Danso-Amoako December 2006 Chair: R. Raymond Issa Major Department: Design, Construction and Planning The nature and complexity of projects in the architectural, engin eering and construction (AEC) industry makes the industry very fragme nted. This is because these complexities necessitate the use of specialized firms to perf orm the mechanical, electr ical, structural steel, networking and heating, ventilat ion and air-conditioning work needed to complete projects. Although specialization in general is a good concept, it comes with a price. The downside of this multiparty concept is the problem of coordina tion, data and information sharing among the various parties. Standards and models have been developed to minimize the adverse effects of fragmentation. One such model is the Industr y Foundation Classes (IFC) developed by the International Alliance for Interoperability (IAI). Unfortunately most AEC application software packages do not comply with these standards a nd models. This study repo rts on the research and development of a system to translate non-IFC co mpliant AEC applications into IFC and then share the data in real time with other parties over the Internet with the us e of web services.

PAGE 13

13 CHAPTER 1 INTRODUCTION The Construction Industry – An Overview For the last decade the total spending on th e architectural, engineering and construction (AEC) industry in the United States has been st eadily increasing with 490 billion dollars in 1993 to approximately one trillion dol lars in 2004 representing an average of 6-10 percent of the United States’ Gross Domestic Product (GDP) (U.S. Census Bureau 2005). The U.S. construction industry employed 8.4 million people in 2001 and an additional one million people worked in architecture and engineering (C onstructionweblinks 2005). This picture is representative globally, because in most countries in the world, the built environment normally constitutes more than half of the total national capital investment, and c onstruction represents as much as 10% of GDP (CICA, 2000). The fi gures above underscore the importance of construction on national economies. Despite these encouraging figures, a lot of problems have been identified in the AEC industry that make the industry less competitive compared to other industries. One of the major problems, data exch ange and information shar ing, is the subject of this research proposal. The construction industry in gene ral is highly fragmented with the degree of fragmentation unparalleled to any other sector, even the manufacturing industry (Dawood et al. 2002). Gone are the days of the “master builder” who took char ge of the entire proj ect from inception to completion. The complexity of current projects ha s increased in multiple folds over the years and has necessitated the use of specialized firms such as mechanical, electrica l, structural steel, networking and heating, ventilat ion and air-conditioning to complete projects. This makes the AEC industry multiparty in nature with a high nu mber of stakeholders, each of whom has to contribute significantly to the successful realiz ation of the project (D eng et al. 2001). The

PAGE 14

14 downside of this multiparty concept is the proble m of coordination, data and information sharing among the various parties. This increase in complexity and conse quent fragmentation has rendered current conventional technologies, which include paper-based and electro nic data interchange (EDI), highly inadequate. This inadequacy shows the critical need for new methods that will effectively link the various stakeholders and make coordi nation of their tasks eas ier and hence instant decision making a success. To overcome these ch allenges a framework for real time data exchange and information sharing between AEC industry applications, by means of Industry Foundation Classes (IFC) and web services technology is proposed Problem Statement Fragmentation is one of the distinct characte ristics of the construc tion industry (Howard 1989). A typical constructi on project involves many stakeholders that include owners, general and sub-contractors, suppliers, project managers, architects and engineers spread over sometimes mutually exclusive work sections. To illustrate this, Figure 1-1 shows the parties involved in structural steelwork, which is just one of the numerous work sections in a typical construction project. By expanding the other work sections to show the number of pa rties involved and the cross-firm relationships between them, one can easily envision the likely difficulties that will be encountered in coordinating and exchanging data between the vari ous parties. Furthermore the extent of this fragmentation is compounded by th e fact that the various parties use different computer applications resulting in incompatible data format (Zhu and Issa 2003). This current high level of fragmentation and the subsequent lack of adequate m easures to help in coordination have resulted in low productivit y, cost and time overruns, conflic ts and disputes, claims and time-consuming litigation (Dawood et al. 2002, Deng et al. 2001). It has been reported that about

PAGE 15

15 two-thirds of the construction problems are a re sult of inadequate coordination and inefficient means of communication of project in formation and data (Cornick 1990). Figure 1-1. Construction Is Multiparty in Nature Research Program In a quest to minimize the adverse effect of fragmentation in the AEC industry many software applications, data models and standards have been developed and tried within the past two to three decades. One such standard which is quickly becoming a de facto standard of the AEC industry is the Industry Foundation Classes (IFC) developed by the International Alliance for Interoperability (IAI). The primary goal of IFC is to enable interoperability between AEC and facilities management appl ications from different soft ware developers (IAI 2000). The

PAGE 16

16 fundamental idea and concept of IFC is a grea t one and if implemented by all AEC industry software developers and used by all construction companies will totally eliminate data exchange and information sharing problems. Unfortunately th is is not the case even after about ten years since the inception of IFC. The construction indu stry has always been relatively slow to accept technological change compared to its competito rs like the manufacturing industry (Alshawi and Ingirige 2003, Brandon and Betts 1997). Although currently the IAI can boast of a number of applications that are IFC-compliant, there are more AEC applications out there that have not yet seen the IFC light. The search for real time data and information sharing solutions especially between non-IFC compliant applications (legacy a pplications) is the motivating factor for this research. A translator system is developed and validated that ma ps native application data from non-IFC standard to IFC and then shares that information in r eal time over the Internet through the use of web services. IFC was chosen because of its scalability and maturity in terms of development and testing. Almost all construction da ta can be represented in the IFC format. As a result the data from a given application can be reduced to IFC compliant format and then accessed by another application with little loss in semantics. Aims and Objectives As discussed in the previous section data in tegration will be seamless if all application developers and users conform to one data exchange standard. This is an ideal case and is far from achievable in the AEC industry because of the re asons discussed above. The main objectives of this research work are to explore the Possibility of the development of IFC translators for AEC app lications, especially legacy systems that are currently heavily in use but do not comply with contemporary data exchange model (legacy systems). Use of web services to transport the tran slated data between firms in real time.

PAGE 17

17 With this combination it is envisioned that data integration between AEC applications can be achieved. Scope and Methodology The AEC industry as described in preceding s ection is diverse in nature with domains spanning from computer aided design (CAD), estimating, project management, scheduling to facilities management. The scope of this resear ch is the development of a prototype of the proposed service. A typical project is broken down to several manageable views or work sections and then handled one at a time. In order to fully develop, implement and test a proof of concept, this research limits itself to the data excha nge and sharing of scheduling information. Key components to be developed in clude the web service engine and IFC wrappers/translators. Scheduling data can be obtained from companies and then tested in a simulated environment. Layout of Research Chapter two discusses data sharing and inte gration problems and efforts made to solve them from both historical and contemporary point of view. Models, both earlier and current ones and data exchange technologies are also di scussed. Finally the chap ter concludes with a summary of the existing related projects and the anticipated contribu tions of the proposed research to the cons truction industry. Chapter three discusses the in details the prin ciples, architecture and implementation of the proposed system. With the model ready, there is the need to test and show the proof of the concept developed. This research uses a case stu dy approach to implement this testing. Chapter four outlines in detail the approach used in the case study including test cases that was run used a developed prototype of the model. The developmen t of the prototype and re sults of the tests are discussed in chapter five.

PAGE 18

18 Finally chapter six concludes the research fi ndings and further lists and discusses some recommendations for future work.

PAGE 19

19 CHAPTER 2 LITERATURE REVIEW Introduction For the past three decades or more, many integr ation research efforts, from within the AEC industry itself, academia and other emerging strategies from the ma nufacturing sector have been carried out. A study of those stra tegies and their successful app lications in manufacturing and other industries has provided re searchers in the co nstruction industry w ith inspiration for adoption of those initiatives (Zhi liang et al. 2004). In the subse quent sections a comprehensive view of the principles behind both old and cont emporary data integration and exchange models are outlined. Data integration consists mainly of three parts namely an information standards, product/process models and integration between co mputer applications and domains. The early works in the AEC industry in this area concentr ated mainly on establishing acceptable standards and also building process and product models while contempora ry research is focused on information sharing, that is sharing data from existing models. The world of AEC modeling and data integration in general is dominated by a lot of standards a nd acronyms that makes it difficult to get a global understanding of th e subject matter in its entirety. As a result the basi c concepts of modeling and integration are init ially discussed and emerging tec hnologies are added in order of importance to this research work. In addition typi cal samples of such existing integration models are discussed with respect to their limitation an d contribution to AEC integration in general. Modeling – Basic Concept In order to store information about AEC object s, that information must first be wellstructured or modeled. The subject matter “modeling” per se is not the object of this research. However in order to fully understand data sharin g and integration one must first understand the basic concepts of modeling. Data modeling ca n be defined as that which deals with

PAGE 20

20 “relationships between information about real-lif e objects in a project an d the real-life objects themselves” (Luiten 1993). Modeling in general is divided into two major sections namely product modeling and process modeling. These terms are generic business model terms that have been adapted for the AEC industry. Product Modeling Product modeling focuses on the articles being ma nufactured or construc ted in the case of the AEC industry. It provides geometric and topological information of the product of construction. Most of the early works in c onstruction modeling focused on product modeling and through extensive research, produc t modeling has been well suppor ted, tested and implemented in the construction industry. Process Modeling Process modeling examines the procedural cont exts in which the products are constructed, including construction processes, resources and participants i nvolved in the process (Froese, 1995). Project Modeling Those models that try to combine both produc t and process models are referred to as project models (Froese 1995). Figure 2-1 shows th e internals (break-down) of a typical model showing three distinct levels of abstraction that are common to al most every AEC model, be it a process or product model. Pioneering AEC Models The Architectural, Engineering and Construction (AEC) industr y has for the most part of the last two millennia depended on paper-based dr awings and documents for project execution. The last two decades have witnessed tremendous movement of the AEC industry towards the digital paradigm and most importantly, recent year s have seen the maturation of data integration

PAGE 21

21 models. In this section some of the major models will be outlined. The evolution of such models makes the possible realization of long held vi sions for computer integrated-construction (CIC) via shared integrated data models and information management a reality. Figure 2-1. Data Modeling Architecture The Standard for the Exchange of Product Model Data (STEP) Technically speaking STEP is not an AEC-sp ecific model but its contribution to current AEC models is so immense that it is worth menti oning in this context. STEP is the result of the international community’s (Inte rnational Standard Organizati on, ISO) effort to develop a mechanism for the exchange and sharing of engi neering data from many industries and domains. The main aim of STEP is to develop neutral industrial data defin itions, representation, and language that support life cycle functions (N IST 1999). The methodology used by STEP is to develop standard product models for the various domains called application protocols (AP). The building construction industry is represented in STEP by the Building Construction Core Model (BCCM). In 1997 under a Memorandum of Unde rstanding between ISO TC184/SC4 and IAI avoid duplication of efforts, ISO’s BCCM within STEP merged with Inte rnational IAI’s Industry Foundation Classes (IFC) (IAI 1997). A large am ount of work already done and experience gained was carried over to continue with IFC. IFC is discussed in details later in this chapter.

PAGE 22

22 Construction Object Model (GenCOM) As part of an effort to improve integrati on of construction project management and also part of a larger project, Stanford Univer sity between 1989 and 1992 developed the General Construction Object Model (GenCOM) (Froese 1992). The main object was to investigate how standardized object-oriented models will enhance the integration of computer applications and data exchange. The entire model c onsists of thirty-six entities/ cl asses organized in a hierarchical manner Figure 2-2. For testing purposes a pr ototype called “Object-model-bases Project Information System” (OPIS) was implemented. The AEC Core Model (Froese 1996) describes from a historic point of view, numerous attempts that have been made towards achieving data standards. He ma kes a comparative analysis of some of these conceptual models which includes: Information Reference Model for AEC (IRMA) Building Product Model (BPM) Information/Integration for construction (ICON) Unified Approach Model General construction object model (GenCOM) ATLAS Large-Scale Engineer ing Project Type Model Combine Model for the Building Industry in Europe (COMBINE), Standard for the Exchange of Product Model Data (STEP) For more on literature of the models above see (Eastman 1999)

PAGE 23

23 Figure 2-2. Model Architecture of GenCOM Froese points out that the explicit objective of all the above-listed models is to provide an all-in-one core model that will address both AEC products (buildings) and AEC processes. However the focus of AEC product and process models is quite distinct. As a result it is better to separate product from process models. He then proposes the use of AEC core models (a hybrid

PAGE 24

24 of all the above-listed models) to do this separation. This model comprises the facility itself, system components, resources us ed, material, people, organiza tion and information such as contracts, schedule and RF I as shown in Figure 2-3. Figure 2-3. Elements of the AEC core Model Contemporary AEC Models CIMSteel Integration Standards (CIS/2) CIMsteel Integration Standards, an outcome of the Eureka EU120 CI MSteel Project, is a set of formal computing specifications that allo ws software vendors to make their engineering applications compatible. The CIS standards are based upon a formal product model known as Logical Product Model (LPM) whic h defines a logical structure fo r data in terms of entities, attributes and relationships between th ese entities (Crowley and Watson 2000a).

PAGE 25

25 Within CIS/2 there are three different views in which a structure can be represented. These are the analysis, design assemblies and manufact uring assemblies that map onto the viewpoints of the analyst, designer and manufacturer respectively. With respect to implementation, CIS/2 is divided into 17 major subject areas. These subj ect areas which include loading, geometry and structural response are all product-centered excep t for process definition and data management subject areas which deal with process modeling. As stated in the standards, CIS/2 provides a limited coverage for contractual organization, project planning, and project scheduling and costing (Crowley and Watson 2000). Industry Foundation Classes IFC The Industry Foundation Classes (IFC) is perhaps the largest and most ambitious effort that is being undertaken to de velop an integrated building m odel (Eastman 1999) with the hope of achieving the goal of Computer Integrated Construc tion (CIC). The development of the IFC was based on all the experience and successes of earlier projects especially Standard for the Exchange of Product Model Data (STEP) (R nneblad and Olofsson 2003). The IFC model architecture (IAI 2000) is built up of data model schemata organized in four main layers namely, resource layer, core layer, interoperab ility layer and domain layer (Figure 2-4). Resource Layer The lowest layer contains the resource classe s that used by classes in the upper layers. These classes are general, lowlevel, domain-independent and ev en not AEC-specific such as date and time (See Figure 2-5).

PAGE 26

26 Figure 2-4. IFC Model Architecture Core Layer The core layer comprises the kernel and co re extensions (contr ol, product and process extensions). The kernel provides th e basic abstract part within the IFC architecture. Similar to the resource layer the concepts in the kernel ar e general and non-AEC-specific such as object, property and relationship but they are required for all other higher level models. The purpose of the core extensions is to serve as the first line of specialization of the kernel objects towards AEC specific constructs. For instance the core process extension provides information that

PAGE 27

27 supports the concept of process in the AEC c ontext and the core produc t extension helps to define the properties of the product (building component). Figure 2-5. IfcDateAndTime Resource Interoperability Layer There are some objects that are shared by multiple domains. Such objects are captured by the interoperability layer. Major building elemen ts like wall, beam, colum n, slab, roof and stair

PAGE 28

28 are not unique to any one part icular domain and thus are captured by the “shared building elements” data model. Domain Layer The final and topmost layer is the domain layer. As a result of successive refinements, the model at this layer provides domain specific suppor t. The models that are currently contained in the domain layer of IFC2.x are HVAC, electrical, architecture, constr uction management and facilities management. IFC – Level of Detail The IFC standards are constantly being upda ted to include key missing items within AEC/FM Industry. In the current version IFC2x2, four new items have been added to the domain layer namely, Building Controls, Plumbing, Fire Pr otection, Structural Elements and Structural Analysis Domains. Within the AEC there are many thousands of both physical and intangible object definitions. As stated in the IFC technical guide it is not the aim of the IFC model to provide a class for every type of object that can be encountered as this will result in a highly complex structures that will be difficult to understand and impossible to implement (IAI 2000). Instead the strategy taken by IFC is to use high le vel description for gene ralization to provide a compact model. Figure 2-6 shows the IFC Model in relation to the universal set of information world. Let us consider the AEC object “window”. Within the IFC model a window is represented by the class “ifcWindow”. Figure 2-7 shows th e EXPRESS definition of “ifcWindow”. This class represents the point at which IFC model te rminates (leaf node) and after which we enter the AEC information world.

PAGE 29

29 IFC MODEL Figure 2-6. IFC Model in Re lation to the AEC World Figure 2-7. EXPRESS Specifi cation for IFC Window It can be observed that there are many t ypes of windows, each normally described by its fire-rating, acoustic rating, security rating, whether it is place d in exterior or interior walls, infiltration level, thermal transmittance, glazi ng area fraction, smoke stop and a whole lot more. Physically representing all this properties in the IFC model will make the model huge and too complex to deal with. Secondly, proper ties do change. New Scope and Methodology

PAGE 30

30 The AEC industry as described in preceding s ection is diverse in nature with domains spanning from computer aided design (CAD), estimating, project management, scheduling to facilities management. The scope of this resear ch is the development of a prototype of the proposed service. A typical project is broken down to several manageable views or work sections and then handled one at a time. In order to fully develop, implement and test a proof of concept, this research limits itself to the data excha nge and sharing of scheduling information. Key components to be developed incl ude the web service engine and IFC wrappers/translators. For the purposes of developing and te sting the proposed system, a stru ctural steel fabricator along with his supporting team will be used as a case study. As seen in Figure 1 the number of actors in the steel supply chain is relatively large, sugge sting that such tools for information exchange could provide a valuable service to this sector of the AEC industry. Scheduling data can be obtained from companies and then test ed in a simulated environment. Windows properties such as ener gy star levels are added periodi cally and constantly to the AEC world. If this “ifcWindow” had a fixed rigid set of attributes then it will imply that any time there is a new window property defined in the AE C world there should be a version change and update for the IFC model.To overcome this size a nd scalability problems the IFC model uses the concept of “Property Set Definitions” re presented by IfcPropertySetDefinition and IfcPropertySet. The class holds a collection of us er defined properties and is defined externally to the IFC model in the EXPRESS data definiti on language. In a real a pplication a number of these property sets are defined for objects and di stributed with the IFC model. This approach makes the IFC model compact and less difficult to handle compared to othe r earlier construction models.

PAGE 31

31 Data Exchange Technologies The models described above and many other early pioneering models focused on how to store AEC data in a well-structured format. Typi cal examples are IFC, STEP, CIS/2 files. With the advent of the Internet and the World Wide We b, researchers soon came to the realization that in addition to the data being stored in a well-struct ured format and shared by file transfer, there is the need to effectively exchange the data in a seamless manner with other parties, sometimes over a wide geographical area and in real time. The following secti ons give a global view of data integration in the AEC industry and then discuss some of the new innovation in the area of data exchange over the internet. Global View of Data Integration in AEC Industry Anumba and Amor (1999) examined the funda mental and commonly used concepts of integrated project database and integration efforts in the AEC industry as well as the various approaches to its development. Three major deve lopmental approaches that have been used for existing models are outline below: Centralized Project Database Model With this method there is a single centralized da tabase that all member s of the project team subscribe to (Figure 2-8). Although this method is widely used, th ere are a number of limitations that make it very difficult to use on big and co mplex projects. First of all the database could become very large and hence make maintenance difficult to handle. Secondly security becomes difficult to implement as the number of users increases.

PAGE 32

32 Application Application Client / Application Client / Application Application Project Data Server Figure 2-8. Centralized Project Database Distributed Project Database Unlike the Centralized Project Database Model, there is no centralized repository for data access. Instead applications communicate with the various databases through a standard interface such as Common Object Request Broker Arch itecture (CORBA), Java Remote Method Invocation (RMI) or Microsoft’s Distributed Common Object Model (DCOM) Figure 2-9. This approach requires that the different applic ations used support the standard interface. Neutral Format Model In this approach, data exchange is ini tiated by individual applications exporting information in a neutral format such as the STEP , IFC or CIS/2 format wh ich can then be read by other applications. This approach is an ideal form of informati on exchange between parties since the process is both platform and application-i ndependent. However as can be seen in Figure 210, it requires that all applications used be neut ral format compliant (example IFC-compliant) for

PAGE 33

33 the bi-directional transfer of information (Anumba and Amor 1999). The Industry Foundation Classes (IFC), CIMSteel Integration Standards (CIS/2) and STEP models are two such data exchange standards that can be cla ssified as neutral format model. Client / Application Common Interface (DCOM or CORBA) Client / Application Project Data Project Data Project Data Figure 2-9. Distributed Project Model Neutral Format -IFC -CIS/2 Application Application Client / Application Client / Application Application Figure 2-10. Neutral Format Model

PAGE 34

34 Extensible Markup Language XML Extensible Markup Language (XML) as the na me implies is a markup language. It is a simple, human-readable and very flexible text format derive d from SGML (ISO 8879). It was designed to meet the challenges of large-scale electronic publis hing and had the following design goals: XML shall be straightforwardl y usable over the Internet. XML shall support a wide variety of applications. XML shall be compatible with SGML. It shall be easy to write progr ams which process XML documents. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. XML documents should be human-legible and reasonably clear. The XML design should be prepared quickly. The design of XML shall be formal and concise. XML documents shall be easy to create. Terseness in XML markup is of minimal importance. Currently XML (see Figure 2-11) and other fl avors of it have become a standard of preference for data storage and transfer over the internet. Web Services Most of today’s websites are designed to provi de a response to a reque st made directly by a user. The user types in the global address (Uniform Resource Locator (URL)) of documents or resources to make such request (Figure 2-12). Th is message in the form of a text document containing simple instructions for the server is sent from the brow ser over the inte rnet using the Hypertext Transfer Protocol (HTTP). The content of the instructions is normally limited to the name of the document to be retu rned or a call to a server-side program. On receiving the request the server checks to find the appropriate documen t or the program to ex ecute, processes it and then bundles the HTML in the form of an HTTP response.

PAGE 35

35 Figure 2-11. Sample XML Document Figure 2-12. Simple Website Te chnology Using HTTP Protocol The World Wide Web as it cu rrently exists today is de signed around humans browsing pages through a web browser. The only way to pres ent information is to build pages that are to be consumed by human eyes. However in ma ny situations, exposing information to an application (the objective of th is research) makes more sense than exposing it to human eyes (Walther 2003). Fortunately the in ternet is quickly evolving from today's Web sites that just

PAGE 36

36 deliver user interface pages to browsers to a next generation of programmable Web sites that directly link organizations, a pplications, services, and devi ces with one another. These programmable Web sites unlike their traditional sta tic partners become reusable, intelligent Web Services (GotDotNet 2005). Web services (sometimes referred to as XML Web services) are software components that provide some type of service over the intern et. The major similarity between conventional websites and a web service is that they are both reachable through a public URL and are subject to the same security restrictions of an HTML-based web site (Esposito 2003). However there are a number of properties that ma ke this exciting new technolog y different from conventional websites. Web services are different from conven tional web pages that can also provide access to applications across the internet by using technologies such as ASP.NET, PHP, JSP, PERL and other web-based scripting languages. Web page s are targeted at human users whereas web services are developed mainly for access by other a pplications. In plain words, Web services are about machine-to-machine communication whereas web pages are about human-to-machine communication (Papazoglou and Dubray 2004) The Architecture and Key Comp onents of Web Services The infrastructure of Web services makes use of existing ubiquitous open internet standards and transport protocols such as Hype rtext Transfer Protocol (HTTP), Extensible Markup Language (XML), Simple Object Acce ss Protocol (SOAP) as well as Web Services Description Language (WSDL) and Universal Di scovery Description Integration (UDDI) Figure 2-13. It is the combination of such standards that make web services platform-independence, accessible and consumable from any client or internet-enabled device (Esposito 2003).

PAGE 37

37 Figure 2-13. The Web Service Architecture and the Role of the Internet Open Standards Simple Object Access Protocol (SOAP) A web service client sends an XML document formatted in accordance with SOAP specification. SOAP is a XML-based specifica tion that provides the necessary syntax for exchanging structured and typed information between peers in a distributed environment (Esposito 2003). In the context of web services, SOAP is an encoding mechanism that combines with transport protocols to create a link betw een distributed systems. Communication between systems using SOAP goes through a series of laye rs as shown in Figure 2-14. To initiate the process the client program sends a request to the web service. The request is first processed through the SOAP engine and the result, an XML formatted document, is then transported by the internet layer using th e HTTP protocol. At the web servic e end, the XML-formatted document is processed by the SOAP engine a nd the instruction it contains is sent to the web service program in the form of a method call. The Web service pr ocesses the instruction a nd creates a response in a form the can be read by the client program. Th is response is the wrapped as an XML format using the SOAP specification and then delivered b ack to the client computer over the internet

PAGE 38

38 layer. The client computer recei ves the XML file and once again the SOAP engine processes the file and passes it back to the client program that made the initial request. Figure 2-14. Communication Usi ng SOAP over the Internet The SOAP Grammar To summarize the preceding section, i nvoking a method on a Web service is simply sending a SOAP-formatted XML to the service us ing the HTTP protocol. In this section the content of a SOAP formatted message is carefu lly analyzed. Figure 2-15 shows a typical SOAPformatted XML message sent to a server “localhost”, which conve rts temperature in Fahrenheit for degrees Celsius. Figure 2-15. SOAP Formatted XML A SOAP message is composed of three parts:

PAGE 39

39 The SOAP header, which contains processi ng information such as where the document originated and where it shall be sent. The SOAP envelop, which serves as a wra pper of the XML document being transported and secondly to augment the content of the message with additional information necessary to get it to its destination. The SOAP body located inside the envelop ta gs. It carries the a pplication specific XML data commonly referred to as th e payload, which is being exchanged. Web Services Description Language (WSDL) After a Web service is written potential client s who may want to consume it, need to know the features of the service. One of the major advantages of Web serv ices is that these features can be described formally in an XML-formatted document known as the Web Services Description Language (WSDL). The World Wide Web Consortiu m (W3C), an organization that develops interoperable technologies and manages SOAP, XML, WSDL and other related specifications define WSDL as: “an XML format for describing Web services. WSDL enables one to separate the description of the abstract f unctionality offered by a service from concrete details of a service description such as “ how” and “where” that functionality is offered.” (W3C 2002) By examining a WSDL description poten tial clients learn about the exposed methods/functions, the signatures and the return values. In addition it describes how the various internet protocol and encoding schemes can be used in order to format the message in accordance with the provider’s specification. These f eatures are described in an abstract way that make it independent of the platform and programming language used on both the Web service and the consuming client. Figure 2-16 shows a sample of a WSDL document.

PAGE 40

40 Figure 2-16. Sample WSDL Document

PAGE 41

41 Other Data Exchange Technologies Prior to the advent web services there were many other technologies . One such architecture is the stub/skeleton based architecture. Web servi ce is actually an evolution and refinement of this architecture. Stub/Skeleton Based Architectures The main aim of this architecture is to provi de a client’s local pr ogram access to a remote program or service as if that remote program was local to the client. This architecture takes cares of the bidirectional data transfer between the client and the remote service. The first component of this architecture is th e interface for the procedure. This is defined using an interface definition language (IDL). This interface provides an abstr act view of the methods/procedure available on the remote server, the name, input parameter and return parameters. Each procedure defined in the IDL file results in a client-side stub. The stub is a piece of c ode that resides in client side. It main purpose is to identify the available resour ces (methods/ objects/ pro cedures) on the remote service and marshals (format appropr iately) all the data from the clie nt and then send it in a form of a message to the server. The stub makes the call to the procedure appear as a normal local procedure. It is also responsible for “unmarshalli ng” the data that is sent as a response from the server to the client. The skeleton performs a simila r function as the stub but resides on the remote service/program. Figure 2-17 shows a diagram of this architecture. Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI) and Microsoft’s Distributed Common Object Model (DCOM) (Alonso et al. 2004) ar e the main members of this architecture category. Table 2-1 shows a compar ison of some of the popular Stub/Skeleton based architecture and web services.

PAGE 42

42 Figure 2-17. Stub/Skeleton Based Architectures Table 2-1: Comparison of Stub/Sk eleton Based Architectures CORBA RMI Web Service Underlying Network Protocol TCP/IP UDP TCP/IP UDP TCP/IP UDP Kind of data transferred Common Data Representation Java Marshaled Objects SOAP Type system IDL Java objects XML schemas Transport means Internet inter-orb protocol Remote method protocol HTTP Service Description CORBA IDL Java interface WSDL (web service description language) How services are located CORBA naming/trading service RMI Naming Service UDDI (Universal Description, Discovery and Integration) Language Any language with IDL binding C, C++, Cobol etc. Java only Any language Java, .NET, Perl etc. Remote reference Proxy reference Proxy object URL State Stateful Stateful Stateless

PAGE 43

43 Sample XML and Web Services Projects in AEC Industry This research is not the first attempt at usi ng XML and web services for some kind of data integration in the AEC. Rather it parallels and complements both exis ting and ongoing research in this relatively young area. Two typical projects aimed at inte gration are described below. IFC Model Server Development Project The IFC Model Server (IMSVR) project was initiated jointly by SECOM Intelligent Systems Lab, Japan and VTT Building and Constr uction, Finland in 2001. It was collaborative project aimed at developing a framework to store IFC object models within an Internet-enabled database system and the running it over the inte rnet with the use of we b services. The model allows the sharing of data by IFC compliant appli cations in real time ove r the internet. This was to avoid the limitation of file-bas ed exchange of IFC at that time. The architecture for IMSVR is shown in Figure 2-18. IMSVR model converts/transl ate native IFC model f iles into a database schema to be stored on database systems such as Microsoft’s SQL Server or Oracle. The advantage here in such a move was that by st oring IFC data on a full database management system DBMS data can easily be handled and manipulated. Clients can the access data by means of web services. The Electronic Project Informatio n Management System (EPIMS) Zhiliang et al. (2004) observed the fact that, for the past decade not much has change in the area of inter-firm data and information sharing. This is done the “old-fashion” way of hardcopy submittals. The aim of the EPIMS project is to de velop a system for data sharing by the various parties in a construction projec t. The system architecture of the EPIMS project is shown in Figure 2-19.

PAGE 44

44 Figure 2-18. The IFC Model Server (IMSVR) Figure 2-19. The System Arch itecture of the EPIMS model

PAGE 45

45 The EPIMS architecture builds on the centralized project database sy stem described above under the section “Global View of Data Integrati on in AEC Industry” First of all the system is web-based and clients access the database through an internet browser. In addition to compensate for heterogeneity of data to be stored, a hybrid da tabase was used. This hybrid database consists of the relational, XML and attachments parts (Fi gure 2-20). The relational part is use to store data related common information of forms such the headers. The contents of a typical construction form document do vary and the XML por tion takes care of this problem. Finally the attachment part of the database stores rela ted files such as attachments or appendices. Figure 2-20. Concept of the Hybrid Database in EPIMS

PAGE 46

46 Analysis and Discussion The preceding sections in this review starts with the basic concepts of modeling. Early attempts at building the right model for the AE C industry were outlined. Most of these early models attempted to provide a core all-one-model for the AEC that address both the AEC products and the AEC processes (Froese 1996). Thes e leads to models that are very huge and difficult to analyze when populated with real life data and hence led to the abandonment of many of the projects. IFC, CIS/2 and other contemporar y models are redesigned offshoot of these early models taking into account the limitation that made earlier models unsuccessful. Prior to the use of models it was impossible fo r heterogeneous applications to effectively share data and information. For instance a schedu ling application A had no way to share the data produced by another scheduling application B si nce the files were incompatible. Where access could be made to the files, translators had to be provided for each application’s link to the other as shown in Figure 2-21A. This means for n numb er of heterogeneous app lications there is the need for n*(n-1) or (n2-n) number of translators to be develo ped. This is a function of the square of the number of applications. An industry with say fifty heterogene ous applications (which is an under-estimate in the AEC industry) that must share data applica tion will require 2450 translators to be developed while five hundred a pplications will require 9900 translators. This is a very laborious task if not impossible to achieve. With the advent of data exchange models such as IFC and CIS/2 the number of translators drops to 2n. This function is a linear function of the number of applications. For each application two translators are required (one to encode to model and the othe r to decode model) (see Figure 2-21B): The first translator to convert the data from the native application data structure to the model (neutral) format

PAGE 47

47 A second one to read the neutral format a nd reconvert to the native application data structure. These computational complexiti es are shown in Figure 2-22. Figure 2-21. Complexity of cr eating translators (A) without models and (B) with models Complexity Analysis0 10 20 30 40 50 60 70 80 90 100 12345678910 # of applications# of translat o With models Without models Figure 2.22 Complexity Analysis of Developing Translators

PAGE 48

48 If all construction application developers agree to make th eir products compliant with a given data model standard say “X ” and all construction applicati on users agree to purchase this new application which is X-compliant, then we are guaranteed to ha ve a lower bound of the number of translators which is 2n. From experien ce especially in the construction industry we know this may take an infinite long period of time to materialize. The industry is slow to adopt technological changes relative to other industries like the manufact uring industry. In this modern day paper based transactions are still a norm. It is not uncommon to hear companies claim they have advanced in technology when in actual fact they are sending email attachments of documents that have been scanned. Most of th e time these documents must be printed out and the manually inputted at the receiving end into a similar application bu t from a different vendor (Zhiliang et al. 2004). Taking sche duling as an example the comm on practice is to post or hand deliver hard copies of the sc hedule to another party to be manually entered into another scheduling application. The so-ca lled hi-tech companies email thes e schedules, but its intended use is just like that of a hard paper copy. The development of model facilitates data in tegration but the models in isolation do not provide a silver bullet for the problem. The early AEC models GenCOM, ATLAS, ICON, AEC Core Model and even contemporary ones like IF C and CIS all depend on file-based data exchange which normally limits real time data and information sharing. Secondly in order to share data with these model syst ems, all the applications involv ed should be in compliance with that specific standard. The thought of writing, testing and implementing a new system to replace one that already works is a t ough sell to any company’s manageme nt irrespective of the industry in question (Potts and Kopack 2003). Compounded by the fact that AEC indus try has a history of reluctance in accepting technological change and de pends heavily on legacy systems that do not

PAGE 49

49 comply with current data standards it is reasonabl e to say that in one wa y or the other, legacy system must be accounted for when considering data exchange and information integration. The IFC Model Server (IMSVR) attempts to solve the real-time and seamless integration by use of databases and web serv ices but does not tackle the legacy problem. With the IFC Model Server (IMSVR), applica tions need to be IFC compliant. The EPIMS model uses XML for data integration but that approach faces the n-square (n2) problem. For a given set of applications the system works but new translators and coding will have to be developed for other sets of applications. Table 2-2 summarizes the contribution of the proposed research towards existing and current on-going efforts to wards data sharing and integration, Table 2-2: Proposed Research in Relation to Existing and Cu rrent Related Projects Project / Model Concept / comments Support For RealTime Sharing Support for Legacy (Generate Model Code?) IRMA BPM ICON GenCOM ATLAS COMBINE Early project models. (Mostly superseded by IFC and CIS/2) See Froese 1996, Eastman 199 Not Applicable. Not Applicable. IFC Model Server (IMSVR) Use of IFC. Centralized data repository. Yes. Through use of web services No. Supports only applications that are already IFC-compliant. Electronic Project Information Management System (EPIMS) Centralized database. Does not use a standard model. Access to database No. Proposed Model Use of IFC. Centralized data repository. Automatic file generation. Yes. Through use of web services. Yes. Generates IFC code onthe-fly. Summary This chapter discussed data sharing and inte gration problems and efforts to solve them from both historical and contem porary point of view. The next chapter outlines a proposed

PAGE 50

50 model, its architecture and implem entation. This model is not the so lution to all the problems in data sharing and integration but rather a piece of the overall jigsaw puzzle.

PAGE 51

51 CHAPTER 3 PROPOSED FRAMEWORK: SYSTEM ARCHITECTURE AND IMPLEMENTATION Introduction Currently data sharing between construction applications is done on a one-to-one basis (Figure 3-1). This means for n number of applicat ions there is the need for (n-1) translators at each application in order to effectively share data , bringing the total number of translators to be created as n * (n-1). As can be seen this num ber which is proportional to the square of the number of applications (n) grows very fast as (n) increases. Th is section describes the proposed system for real-time data integration between heterogeneous (legacy) AEC applications that reduces considerable, the number of translators to be developed. System Principles The idea is of this model is based on the fact that current AEC models, specifically Industry Foundation Classes (IFC), is matured a nd can implement most if not all common AEC concepts. The fundamental principle behind this model as shown in Figure 3-2 is to map data from construction applications to and from a common base, the IFC model. The current IFC model supports various domains in the c onstruction industry in cluding construction management, architecture, facilities manage ment, heating ventila tion and air-conditioning, electrical, structural element and analysis, build ing controls and plumbing. With such a system there is the need for onl y two translators per ap plication reducing consid erable, the number of translators to be developed (Figure 3-3). System Architecture The architecture of the model is directly based on the princi ples described above. Figure 34 will be used to describe the detail stages and steps of the model. The overall aim is to share data between applications with the ai d of an intermediary model, (IFC).

PAGE 52

52 Figure 3-1. One-to-one Application Conversion Native Data Native Data Native Data Native Data Industry Foundation Classes (IFC) APPLICATIONS ABC D Figure 3-2. Principle Behind Proposed Model

PAGE 53

53 Figure 3-3. Reduction in Nu mber of Translators Native Data-to-IFC Mapper/Converter IFC-to-Native Data Mapper/Converter NATIVE OR EXPORTED DATA NATIVE OR EXPORTED DATA Industry Foundation Classes (IFC) STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 STEP 6Proposed converter / mapper Application Data Level PROPOSED MODEL Figure 3-4. Proposed System Architecture

PAGE 54

54 Step One Every application stores its information in so me structured format make it accessible and navigable when it is opened. In some application the native file da ta or file format gives this structure and access. In other applications the native file do not give such access and must be exported or saved as another format to enable access by a third party. Such formats include comma, tab and space delimited files, extended markup language file, and database files. Step 1 in Figure 3-4 shows this data transformation. Steps Two and Three This two combined steps forms the bulk half of the proposed model. In step two the native data or exported format of an application in imported into a mapper / converter described separately below. This converter processes the information and automatically generates an IFC code as shown in step 3. Step Four and Five These other two steps constitute the other bulk half of the proposed model. In step 4, a previously generated IFC code fr om the proceeding steps is fed in the converter to produce the native data or an importable file format of a previously specified application. Step Six Step six which is not part of the actual mode l shows the importing of a file generated by the proposed model into an application. Structure of the IFC Converters This is the heart of the proposed system. It ta kes as input raw data fr om the application in questions and then translates/maps it to IFC fo rmat. Figure 38 shows raw XML (partial) file generated by using the “save as” function in Microsoft Project.

PAGE 55

55 Figure 3-5. Proposed C onverter in Action System Implementation Option 1: Stand-alone Translator With this approach the service is an i ndependent one which does only translation on request (Figure 3-6). You supply as input, a file you want to translate stating its properties (name, application from which it was generated) and also supply the final application format properties you want it translated t o. The disadvantage of this method is that, first of all files must obtained manually and this reduces the level of seamlessness. Secondly, as files are passed around there are the problems of concurrency and consistency Option 2: Web Services Translation Service With option 2, multiple Web Services are used (Figure 3-7). There are Web Services available to each party. The service is responsibl e for translating data to IFC format and then publishing it on a central repository. In addi tion, the service provide s “import from IFC” functionality. With this approach, additional functionalities for real time data sharing can be

PAGE 56

56 added. A typical example will be the immediate notif ication of one party if new data is added or if data is updated. That is by clicking the “publ ish button” all affected parties will be notified. Web service provider Service 1: Primavera MS Service 2: MS Primavera Service 3: ACAD Timberline Service 4 Service 5... Registry Internet http://www.abc.com/ S e r v i c e D i s c o v e r y Application A Application B S e r v i c e D i s c o v e r y Internet http://www.abc.com/OPTION 1 Figure 3-6. Option1 Pure Translator Service . Application A Application BOPTION 2 Web service provider Web service provider R E T R E I V E I F C D A T A P U B L I S H R E T R E I V E I F C D A T A P UB L I S H Data Data Central Repository Ifc / ifcXML Data Figure 3-7. Option2 – Multi-Web Services with Central Repository Summary This chapter discussed in details the arch itecture and implementation of the proposed model. Next in chapter four, a case study approach is used to test and show proof of the concepts of the proposed model. A construction area is sel ected and the fundamental principles outlined.

PAGE 57

57 CHAPTER 4 CASE STUDY Heterogeneity of Data Sources As shown in Fig 1-1, there are many sectors in the Construction i ndustry, and at some point in time these sectors share information (normally common data) with each other through various computer applications. One major advantage of computer applications is their ability to transport data quickly from one place to the ot her. However the proliferation of computer applications in the constructi on industry and correspondi ng heterogeneity (in terms of usage and internal data structure) of these applications bl ocks the effective sharing of data that computer applications are required to address. These applic ations simply do not “talk” to each other. A list of areas that are affected by th is barrier to data sharing are scheduling, computer aided design, estimating, safety, cost control, structural work (design, detailing and erection) and many more. For this research, in order to prove the concept of the framework developed, scheduling is used as a case study. Planning and schedul ing is a vital and integral part of every sector in the national economy including the construction i ndustry. The concepts of schedu ling have been used in the past century or more in the construction industry and the advent of computers have facilitated its rigorous use. This section briefl y explains the major concepts in scheduling in relation to the framework proposed Types of Schedules Bar Chart or Gantt Chart The bar chart (Figure 4-1) commonly referred to as Gantt chart is the most popular form used to visually present a schedule in the cons truction industry. This is because it is easy for everyone including the non-technical personnel to grasp and menta lly process the information it contains. The horizontal axis of the Gantt chart is a time scale, expressed either in absolute time

PAGE 58

58 or in relative time referenced to the beginning of the project. Th e unit of the axis depends on the project but it is normally in te rms of days, weeks, or months. Every row in the bar chart shows the start and finished date of th at individual task in the project. Activity 1 Activity 2 Activity 3 Activity 4 Activity 5Activity 53 wks 3 wks 3 wks 3 wks 3 wks 3 wks Activity MarcrApril May June Duration Figure 4-1. A Typical Gantt Chart The major set back here with the traditional Ga ntt chart is that it does not show temporal relationship between various tasks, but enhanced versions of the Gantt chart (Figure 4-2) now include such information as: A marker (line) used to mark the present point in time. Link lines to show dependencies between tasks. Resource allocation can be specified for each task. Flags for milestones. Shading of bar to represent the progression of each activity.

PAGE 59

59 Figure 4-2. One-to-one Application Conversion Program Evaluation and Re view Technique (PERT) Another commonly used schedule is the Program Evaluation and Review Technique commonly referred to as PERT, developed by the US Navy in the 1950s as part of the Polaris mobile submarine-launched ballistic missile project. The distinct characteristic of PERT is the incorporation of risk analysis into schedule development to handle uncertainties. Variable durations are assigned to activit ies since for example some activities have a higher degree of uncertainty about their duration than others. The result of a PERT an alysis is the probability that a job will be completed by a certain date rather than on a deterministically exact date. Figure 4-3 shows an example of a PERT chart generate by SureTrak Project Manager. The major disadvantage of PERT chart on the jobsite compared to Gantt chart is the difficulty in visualization. The activities are represen ted on the node which has a fixed size. As a result it is difficult to look at the chart and easily visualize the durations as compared to the Gantt chart.

PAGE 60

60 Figure 4-3. A PERT Chart Network Development in Scheduling The purpose of networking in scheduling is to help identify sequences, concurrency and dependencies between activities. There are two main approaches to schedule network development namely: Activity-on-the-arrow networks and Precedence (Activity-on-the-node) networks In the activity-on-the-arrow network approach an activity is represented with an arrow that move from left to right and place between two node s that serves as events (Figure 4-4). These nodes represent an instant in time such as the st art time or finish time of an activity. Activity-onthe-arrow network can be time scaled (relative length of arrows) to e ffectively communicate durations and flow of work pr oject visually. One major setback of the activity-on-the-arrow network approach is the need for dummy activi ties. Most contemporary scheduling applications use the nodes of an activity (sta rt and finish) to identify them . Using the activity-on-the-arrow network approach, in instances where two activit ies start or finish on the same event, the

PAGE 61

61 schedule in subject to ambiguous interpretation (Figure 4-5). The introduction of a “dummy” activity solves the problem but also introduces unnecessary activities into the network (Figure 45). Lastly this approach limits schedu les to only finish-to-start relations. Figure 4-4. Activity-on-the-arrow networks i j A B i j A B k Figure 4-5. Introduction of a “D ummy” Activity into an Activity-on-the-Arrow Network In the activity-on-the-node network approach an activity is represented as a node connected by an arrow to other activity nodes to depict dependencies (Figure 4-6). Since the activities are connected to other activities that they are logically tied to, there are no logical constraints and hence the elimination on dummy ac tivities described above. The major advantage of this approach is that it is si mpler to learn, represent and draw.

PAGE 62

62 Figure 4-6. Activity-on-the-Node Network Key Components of a Schedule Every schedule irrespective of the format in which it is represented has some key components in common. These components include activities and temporal/sequencing logic and resource allocation. Activities Projects are made of smaller number of individual units of tasks each of which must be completed for the successful realization of a proj ect. The units are simply referred to as task or activities. Every activity must have a start and fi nish time as well as durations. There is a special type of activity called a milestone , which do not necessarily have duration but rather depicts an event that highlight a special or turning point in a project. Exampl es include “Notice to proceed”, “Foundation complete” and “Project complete”. Ev ery activity has a unique identifier normally referred to as activity ID and also descriptions of the activity. Other attributes of an activity include actual start date, early start date, late star t, schedule start date, actual finish date, early finish date, late finish date, schedule finish date, schedule du ration, actual duration, remaining time, free float, total float. See Appendix A for more terms and their definition. Temporal or Sequencing Logic Individual activities are connected by means of relationship to form the entire schedule. There are four types (Fig ure 4-7) of such sequential relationships namely: Finish-to-start FS, Finish-to-finish FF Start-to-start SS

PAGE 63

63 Start-to-finish SF A B A B A B A B FS SS FF SF Figure 4-7. Different Types of Relationships in Scheduling Modifications can be made to this relationship by the use of a lag. By definition a lag is “A modification of a logical relati onship which directs a delay in the successor task” (see Appendix A). Figure 4-7 shows a lag of seven time units betw een the finish of activity A and the start of B. A B FS (7) Figure 4-8. Relationship with a Lag Scheduling Applications and Access to Their Internal Data Structure Having discussed the principles and concepts behind scheduling, it is time to show how they are represented internally by computer applications. There are many scheduling applications available to th e construction industry, which include Microsoft Project 2003, Primavera Project Planner, Schedule One Pro, Vi rtual Boss and SureTrak Project Manager. The proposed model depends main one key item, access to a structured data, to function properly. The data behind the schedule must be accessible. This accessibility may be through a saved file,

PAGE 64

64 database or even an entry point into the progr am to obtain such access. The most common format is a saved file such as comma or tab delim ited and Extensible Mar kup Language (XML) type. Database file such as Microsoft SQL Server, Oracle, MySQL, Microsoft Access and other types are also available for some applications. The em phasis here is that all scheduling applications irrespective of the underling concepts, store their data in some structured format so that the same application can reopen the schedul e after it has been closed. Th e major problem is that some applications shield or encapsulate their data form third-party access. In such instances the proposed framework will be rendered unusable an d only the program that created the file or database can have access. Two of the most popul ar scheduling applications Microsoft Project 2003 and Primavera Project Planner, were selected for this pr oject. Microsoft Project 2003 has multiple formats into which its internal data can be saved. Figure 4-9 show the “Save as” dialog in Microsoft Project 2003 with multiple choices of format whiles Figure 4-10 shows the export formats for Primavera Project Planner. Figure 4-9. “Save As” Dialog in Microsoft Project 2003

PAGE 65

65 Figure 4-10. Export formats for Primavera Project Planner Internal data representation As described previously each of the vari ous application have a different way of representing the same information. For this re search the Extensible Markup Language (.xml) format of Microsoft Project and the Primavera PM/ MM (.xer) file were used as sources for data exchange and sharing. In the cas e of Microsoft Project 2003 each of the formats shown in Figure 4-9 could have been equally used. See Appendi x B for an Extensible Markup Language (.xml) format from Microsoft Project and Appendix C for a Primavera PM/MM (.xer) format all for the simple schedule shown in Figure 4-11. Figure 4-11. A Simple schedule

PAGE 66

66 IFC Support for Scheduling The Industry Foundation Classes have extens ive support for many construction related activities including planning and scheduling. All the fundamental principles of scheduling described above can easily be handled by the rich classes provided by IFC. This section provides illustrations to how some of the concep ts in scheduling are supported by IFC. A majority of these concepts in schedu ling are handled by the process extensions ( IfcProcessExtension ) class in the core layer that further calls the ( DateTime) and ( Cost) classes in the resources layer (see Figure 4-12). The core layer comprises the kern el and core extensions (control, product and process extensions). Process Extensions As of IFC 2x Edition 3, IfcProcessExtension contains 7 entities and 2 enumerations (See Table 4-1). Just as product models use classes to express information, IfcProcessExtension uses these classes, entities and attributes to layout process information. By definition, the IfcProcessExtension schema provides the primary information that expands one of the key ideas of the IFC Model. The IfcProcessExtension presesents the idea of “process” which captures ideas about the planning and scheduling of work a nd the tasks and procedures required for its completion. Below are brief definitions of the seven entities of entity IfcProcessExtension as described by the International Alliance for Intero perability (IAI). Full schema definition of these entities can be found in Appendix D. IfcProcedure An IfcProcedure is an identifiable step to be taken with in a process that is considered to occur over zero or a non-measurable period of time.

PAGE 67

67 Figure 4-12. Overview of Some IF C Classes that Support Scheduling IfcRelAssignsTasks An IfcRelAssignsTasks is a relationship class that assigns an IfcTask to an IfcWorkControl . The assignment is further qualified by attaching an IfcScheduleTimeControl to the assignment to give the time constraints of the work task, when assigned to a work plan or schedule. IfcScheduleTimeControl The IfcScheduleTimeControl captures the time-related inform ation about a process including the different types (i.e. actual, or sc heduled) of starting and ending tim es, duration, float times, etc. IfcTask An IfcTask is an identifiable unit of work to be carri ed out independently of any other units of work in a construction project. Figure 4-13 shows the schema of entity ifcTask together with its inherited graph

PAGE 68

68 IfcWorkControl An IfcWorkControl is an abstract supertype which captu res information that is common to both IfcWorkPlan and IfcWorkSchedule IfcWorkPlan An IfcWorkPlan represents work plans in a constructi on or a facilities management project. IfcWorkSchedule An IfcWorkSchedule represents a task schedule in a work pl an, which in turn can contain a set of schedules for different purposes. Figures 4-14, 4-15 and 4-16 show diagrams for th e above described entites. For full definitions of partial list of the sc hemas used, see Appendix D. Table 4-1. Entities and Enumerations in the IfcProcessExtension Entities Enumerations IfcProcedure IfcProcedureTypeEnum IfcRelAssignsTasks IfcWorkControlTypeEnum IfcScheduleTimeControl IfcTask IfcWorkControl IfcWorkPlan IfcWorkSchedule

PAGE 69

69 ENTITY IfcTask; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcProcess ; INVERSE OperatesOn : SET OF IfcRelAssignsToProcess FOR RelatingProcess; IsSuccessorFrom : SET OF IfcRelSequence FOR RelatedProcess; IsPredecessorTo : SET OF IfcRelSequence FOR RelatingProcess; ENTITY IfcTask ; TaskId : IfcIdentifier ; Status : OPTIONAL IfcLabel ; WorkMethod : OPTIONAL IfcLabel ; IsMilestone : BOOLEAN ; Priority : OPTIONAL INTEGER ; END_ENTITY ; Figure 4-13. IfcTask Schema

PAGE 70

70 Figure 4-14. IfcProcessExten sion Entities – Diagram1

PAGE 71

71 Figure 4-15. IfcProcessExten sion Entities – Diagram2

PAGE 72

72 Figure 4-16. IfcProcessExten sion Entities– Diagram3 Case Study Scenario For this case study four converters were deve loped (shown in shaded box in Figure 4-17). These converters were developed using Microsof t Visual Studio and the .NET framework. Two versions of the program, a) A stand-alone versio n and b) A Internet web service version were developed. As the names imply, the stand-alone version r uns on a local computer while the Internet web service version is run as a service on the internet and acc essible anywhere. See Figure 4-18 for a screen shot of the program developed. S ee Appendix E for more screen shots. For both versions there are two options to run the program:

PAGE 73

73 Silent mode and Interactive mode In the silent mode the user supplies the source application data and then specifies the format (application) into which this source must be converted. With a click of the button the output file is generated. For ex ample if you specify that your s ource in a Microsoft Project 2003 (.xml) file and want it for be converted to Prim avera Project Planner file (.xer), it does all the computation in the background and then output th e desired file. There is no user-intervention during computation. In the interactive mode, the in termediate IFC (.ifc) ge nerated can be viewed and edited if need be before the actual output fi le is created. Appendix F shows an intermediate IFC file generated by the program developed. i mp ort “.if c ” Figure 4-17. Proposed Model Showing the Converters

PAGE 74

74 Figure 4-18. Screen shot of the developed model. Summary In this chapter a case study approach was used to test the model. First a construction area was selected and principle and concepts of the area was briefly discussed. Sample applications were also selected to help in the test. A protot ype was developed to run data from the selected applications. Development of the prototype, discussions of the test and results are all outline in the next chapter.

PAGE 75

75

PAGE 76

76 CHAPTER 5 RESULTS AND DISCUSSIONS Access to Application Data The major problem encountered in this resear ch was that some applications shield or encapsulate their data form third-party access. This makes proposed framework non-functional since only the program that created the file or database can have access. A typical example is SureTrak Project Manager. The major reason for th is is that some application vendors try to shield their product from malicious access a nd also to protect the product copyright. Documentation on Internal Data Structure Although some products provide multiple formats into which the application data can be saved, no documentation on the data structure is provided. In most cases the intention of the saved data is to be opened by the same applicatio n that created it. Let us take Primavera PM/MM (.xer) file for the purpose of illustration. See Fi gure 5-1 for a code snippet and Appendix C for a sample Primavera PM/MM (.xer) file format. Alt hough it is structured data it is very difficult for an application developer to understand what all th e fields and records mean. Fields like task_id, “proj_id”, “wbs_id”, “early_start_date”, “act _start_date” and “act_end_date” can easily be interpreted. However fields such as “tmpl_guid” , “allow_complete_flag” and records such as “CP_Drtn”, “TT_Task”, “DT_FixedDrtn” and “RV_OK” cannot be interpreted without the necessary supporting documentation from the appli cation vendor. Even for fields that are easily identifiable like “pred_type” which describes the relationship of an activity to its predecessor, a third party developer has to manually create test projects to allow him/he r to know that it takes the values such as “PR_FS”, “PR_SS” and “PR_FF” for finish-to-start, star t-to-start and finishto-finish relationships respectivel y. This problem also applies to the XML file used for Microsoft project.

PAGE 77

77 Figure 5-1. Code Snippet for a PM/MM .XER Primavera File IFC Support for Schedule-Related Application Data During the development of the converters it wa s found out that the IFC classes handle all the fundamental concepts of scheduling (date and time, units, sequencing logic, duration, work breakdown structure (WBS), co st, resources and more).

PAGE 78

78 Uncommon Denominator The “uncommon denominator” problem is an unavoidable problem in the world of data translation and semantic integration. Technically they are referred to as heterogeneity conflicts. Sheth and Kashyap (1992) provi de a good and in-depth discussi ons on these problems and how they can be handled. Taking a scheduling applic ation for instance, activity duration could be measured in hours or days. Further more a day could be 8-hour day or 10-hour day. These specifications are either fixed or user defined. In either case, th ey are represented in the data structure of the file to which it is saved (see Figures 5-2 and 5-3 for comparisons of how Primavera Project Planner and Microsoft Projec t represent work time). The purpose of this proposed translator service is to convert one data format (source application) to another data format (destination application) without interferi ng with the semantics or business logic. In our example an 8-hour day at the source remains an 8-hour day at the destin ation application after translation. Figure 5-2. Primavera Project Planner Representation of 8-Hour Work Day

PAGE 79

79 Figure 5-3. Microsoft Project Repr esentation of 8-Hour Work Day IFC Support for Application-Specific Data During the case study it was found out that there were some data fields that were not necessarily application specific that do not have corresponding values in th e other application. IFC classes make provisions for saving such data with the use of the IfcPropertySetDefinition and IfcPropertySet The class holds a collection of us er defined properties and is defined external ly to the IFC model in the EXPRESS data definition la nguage. In a real a pplication a number of these property sets are defined for objects and distri buted with the IFC model. This approach makes the IFC model more compact and less complex to handle as comp ared to other earlier construction models. But the real problem comes in when doing a series of conversions. Consider the scenario in Figure 54 of converting application X to application Z with application Y as intermediate. The extra data

PAGE 80

80 from X can be exported with the IFC data as shown. During conversion to application Y (stage D), there is no place to store extra data from X. If application Y edits the data (say a schedule) and then passes it on to application Z. At stage F the extra data from application Y can be added to the IFC data but extra data from application X will be lost. B C D E F G H A J M Figure 5-4. Data Loss in a Se ries of Data Translation Incomplete Data Daved to Imported File Microsoft Project’s native file is the (.mpp) file. The .mpp f ile does not give access to third parties without them using Microsoft proprieta ry Component Object Model (COM) components. The .mpp file saves the complete project including all schedule-re lated data, layouts, bar styles, formatting and any other additional data. However the exported XML file does not include all of these supplementary data. Figure 5-5 shows all the bar styles formatting dialog in Microsoft Project 2003. Changes made here are not included in the XML expor ted file. As a result this formatting will be lost while making such conversions.

PAGE 81

81 Figure 5-5. Some Additional Formatting Da ta is Not Saved with Exported File Software Engineering From the software engineering point of view , it is always best to test for all boundaryconditions and if possible for all possible combinations of the i nput set. A high percentage of errors in application design are a result of the boundary condition. Ho wever, this is economically not feasible especially when the input set is large and time for development is limited. With respect to this research, “all boundary -conditions” may mean one of three things the concepts upon which the applicat ions are based differ drastically data representation differ enormously Cross domain data sharing Different Concepts A typical example in the case of scheduling is activity-on-the-arrow and activity-on-thenode representation. For graphical reports and representations ther e is a vast difference between

PAGE 82

82 these to concepts. But production of reports is not the case here. The underlying data however remains the same or similar irrespective of th e concept used. There is an activity which has duration, planned start date, actual start date and all the other te mporal constraints and resource allocation. These concepts are well represented by the IFC model. Different Data Representation The second case of extremity is that of data representation. All applications that want to share data store their data in some sort of stru ctured format. It could be comma or tab delimited text files, spread sheet, relational database , WebPages (HTML), extensible markup language (XML) files and a lot more as described previous ly. The key objective of the proposed translator is to scan these files, identify the elements n eeded and then map this into a corresponding IFC format. Since IFC files have a unique representati on, data representation is already thrown into the case of “extreme ends of the application spec trum”. This is because data is not shared directly between applications in the proposed sy stem. So for instance even if two applications both use a relational database and similar schema , there is the need to go through the IFC phase before data is passed fr om one to the other. Cross Domain Data Sharing Cross domain data sharing is when the aim is to share data between two or more domains in the construction industry, such as betw een an HVAC application and an estimating application. This last case may contain elemen ts of the first two described above. As an illustration, let us assume an estimating package wants to use a CAD package’s file for direct quantity take-off. In the past this was impossible or limited to specially de signed cases. With IFC this is no longer a unique case, but rather its main objective. IFC covers the entire Building model and it is not domain-specific. It contains the placeholders for “everything” that can be

PAGE 83

83 represented in construction. It is the responsibility of various app lications to extract from this model what it needs to function properly. Conclusion Generally the prototype rev ealed that IFC classes are adequate enough to handle all schedule related data exchange and transfer. Th e major problems encountered were the effective transfer of application-specific da ta and access to applications’ intern al data. In a real life project data transfer, recipients of a data transfer do not normally care about formatting and layout but rather relevant data such as act ivity lead times, start times, fini sh times, project completion date and critical activities and path. The next chapter concludes the research and further lists and discusses some recomme ndation for future work.

PAGE 84

84 CHAPTER 6 CONCLUSIONS AND RECOMMENDATIONS FOR FUTURE WORK Conclusions This study is part of an ongoing research to support communications between construction computer applications with the use of the I ndustry Foundation Classes (IFC). The goal of this study was to provide a viable solution to the data sharing problems that comes from the fragmentation of the construction industry. A translator system is was developed to map native application data from constructi on applications to IFC code and then share that information in real time over the Internet through the use of we b services. IFC was chosen due its scalability and maturity in terms of deve lopment and testing. Almost all construction data can be represented in the IFC format. As a result a give n application’s data can be reduced to IFC and then accessed by another applica tion with little loss in semantics. A prototype system was developed in this study as a proof of this concept. The prototype model for this study was develo ped and tested using the Microsoft “.NET” framework. Since construction is composed of many sectors, this study focused on project scheduling to test the developed model. Within the scheduling domain there are multiple applications packages available. For this diss ertation, two applications were used Microsoft Project and Primavera Project Planner with IFC serving as the common denominator. It must be emphasized that the aim of this dissertation wa s not to create a converter between these two specific applications, but rather to show that if this proposed model is adopted, effective data sharing will be possible in th e construction industry with a fewer number of translators developed compared with cu rrent strategies used. This study found that the Industry Foundation Cla sses (IFC) was adequate to serve as the common denominator. IFC classes were able to handle almost all cases of the principles and

PAGE 85

85 concepts scheduling. The major problem encount ered during this study was with how the IFC classes handled application-specifi c data. Some application-specific data were lost in transition during conversions. In other for models like this proposed one to work, it should have access to the internal data structure of the application data. Some application vendors deliberately shield their data for third party access for fear of malicious access and also to protect proprietary work. Without such access there can be no data sharing an d proposed model will be useless. Recommendations for Future Work To enhance future development of these mode ls application vendors should be encouraged to include documentation about the data structur e of the files to which their applications are saved. The availability of documentation fo r Microsoft Project 2003’s extensible markup language (.xml) and Primavera (.xer) files will ea se the amount of work to be done in such development as in this dissertation and also reduce the guesswork for unknown data fields. As stated earlier, construction is a big and diverse field. This research work focused on one of the many functions in the construction industry, scheduling. To facilitate a wider application of this model, tests should be ex tended to other areas such as estimating, project management and documentation, cost analysis , structural engineering and analysis. Although the concept of scheduling was well handl ed by IFC, application specific data was not. There are some application specific data such as formatting that are common to most applications. IFC is constantly undergoing deve lopment and a study into IFC support for such data should be conducted to provide proposed extensions. For this dissertation the conve rters were manually develope d. Although the data came from two sources they were closely related. It is po ssible to have to have some portions of the converter generalized so that th ere is not the need to start fr om scratch any time one wants to

PAGE 86

86 develop a new translator. This can be achieve d when a number of these models have been developed to find their common similarities.

PAGE 87

87 APPENDIX A GLOSSARY OF SCHEDULING TERMS Source : http://www.yancy.org/research/project_management/time.html Activity An element of work performed during the course of a project. (It normally has duration, cost, and resource requirements.) Baseline The original plan plus or minus approved changes. Arrow Diagram Method (ADM) A network diagramming technique in which activities are represented by arrows. The tail of the arrow represents the start and the head of the a rrow represents the end of the activity. Activities are connected at points called nodes to illustrate th e sequence in which activities are expected to be performed. Also called Activity-On-Arrow (AOA). Backward Pass The calculation of late finish and start date s for the uncompleted portions of all network activities. Determined by working backwards th rough the network logic from the project's end date. Concurrent Engineering Generally speaking, an approach to project staffing that calls for the implementers to be involved in the design phase. (sometimes confused with fast tracking.) Crashing Taking action to decrease the total project duration after analyzing a number of alternatives to determine how to get the maximum durat ion compression for the least cost. Critical Activity An activity on a critical path. Critical Path The series of activities which determines the earli est completion of the project. The critical path is usually defined as those activit ies with float less than or equa l to a specified value (usually zero). Critical Path Method (CPM) A network analysis technique used to predict project duration by analyzing which path has the least amount of scheduling flexibil ity. Early dates are calculated us ing a forward pass; late dates are calculated using a backwards pass. Data Date (DD) The point in time that separates actual (historical) data from future (scheduled) data. Also called as-of date.

PAGE 88

88 Dummy Activity An activity of zero duration used to show a logical relationship in the arrow diagramming method. Dummy activities are used when logical re lationships cannot be completely or correctly described with regular activity arrows. Dummies ar e shown graphically as a dashed line headed by an arrow. Duration (DU) The number of work periods (not including holid ays and other non-working periods) required to complete an activity or other project element. Early Finish Date (EF) In the critical path method, the earliest possibl e date in which the uncompleted portions of an activity or project can complete (this can change as the project progresses). Early Start Date (ES) In the critical path method, the earliest possibl e date in which the uncompleted portions of an activity or project can start (this can change as the project progresses). Effort The number of labor units required to complete an activity or other project element. This should not be confused with duration. Event-on-Node A network diagramming technique in which events are represented by boxes (or nodes) connected by arrows to show the sequen ce in which the events are to occur. Fast Tracking Compressing the project schedule by overlapping activities that woul d normally be done in sequence (such as design and construction). Float The amount of time that an activity may be dela yed from its early start without delaying the project finish date. (Also called slac k, total float, and path float). Forward Pass The calculation of the early star t and early finish dates for th e uncompleted portions of all network activities. Free Float (FF) The amount of time an activity can be delaye d without delaying the early start of any immediately succeeding activities. Gantt Chart A graphic display of schedule-re lated information using bars.

PAGE 89

89 Hammock An aggregate or summary activity. Hanger An unintended break in a netw ork path. Hangers are usually caused by missing activities or missing logical relationships. Lag A modification of a logical relationship whic h directs a delay in the successor task. Late Finish Date (LF) In the critical path method, the latest possible date that an activity may be completed without delaying a specified milestone (usua lly the project finish date). Late Start Date (SF) In the critical path method, the latest possible da te that an activity may begin without delaying a specified milestone (usually the project finish date). Lead A modification of a logical relationship which a llows an acceleration of the successor task. For example, in a FS relationship with a 10 day lead, the successor can start 10 days prior to the completion of the predecessor. Level of Effort (LOE) Support type activity (e.g., vendor or customer li aison) that does not readily lend itself to measurement of discrete accomplishment. Generally characterized by a unif orm rate of activity over a specific period of time. Logical Relationship A dependency between two project activities or between an activity and a milestone. Four possible types: FS, FF, SS, and SF. (see logical relationships under concepts). Master Schedule A summary level schedule which identifies the major activities and milestones. Milestone A significant event in the pr oject, usually completion of a major deliverable. Milestone Schedule A summary level schedule which identifies the major milestones. Path Convergence In mathematical analysis, the te ndency of parallel paths of appr oximately equal duration to delay the completion of the milestone where they meet.

PAGE 90

90 Precedence Diagram Method (PDM) A network diagramming technique in which activ ities are represented by nodes. Activities are linked by precedence relationships to show the sequence in which the activities are to be performed. Program Evaluation and Re view Technique (PERT) An event-oriented network analys is technique used to estimate pr oject duration when there is a high degree of uncertainty with the individual activity dur ation estimates. Project Network Diagram Any schematic display of the logical relationships of project activities. Always drawn from left to right to reflect project ch ronology. Often incorrectly referr ed to as a "PERT chart". Remaining Duration (RDU) The time needed to complete an activity. Resource Leveling Any form of network analysis in which start and finish dates are driven by resource management concerns. Resource-Limited Schedule A project schedule whose start and finish dates re flect expected resource availability. The final project schedule should alwa ys be resource limited. Scheduled Finish Date (SF) The point in time work was scheduled to finish on an activity. The scheduled finish date is normally within the range of dates delimited by the early finish date and the late finish date. Scheduled Start Date (SS) The point in time work was scheduled to start on an activity. The scheduled start date is normally within the range of dates delimited by the early start and late start dates. Slack Synonymous with float. Time-Scaled Network Diagram Any project network diagram drawn is such a wa y that the positioning and length of the activity represents its duration. Essentially, it is a bar chart that includes network logic. Total Float Synonymous with float. Work Item Synonymous with activity.

PAGE 91

91 APPENDIX B MICROSOFT PROJECT 2003 (XML) FILE < Project xmlns =" http://schemas.mic rosoft.com/project "> < Name > Project1.xml < Company > UF < Author > Mark < CreationDate > 2006-11-02T10:57:00 < LastSaved > 2006-11-02T11:12:00 < ScheduleFromStart > 1 < StartDate > 2006-10-31T08:00:00 < FinishDate > 2006-11-28T17:00:00 < FYStartDate > 1 < CriticalSlackLimit > 0 < CurrencyDigits > 2 < CurrencySymbol > $ < CurrencySymbolPosition > 0 < CalendarUID > 1 < DefaultStartTime > 08:00:00 < DefaultFinishTime > 17:00:00 < MinutesPerDay > 480 < MinutesPerWeek > 2400 < DaysPerMonth > 20 < DefaultTaskType > 0 < DefaultFixedCostAccrual > 3 < DefaultStandardRate > 0 < DefaultOvertimeRate > 0 < DurationFormat > 7 < WorkFormat > 2 < EditableActualCosts > 0 < HonorConstraints > 0 < InsertedProjectsLikeSummary > 1 < MultipleCriticalPaths > 0 1 < NewTasksEstimated > 1 < SplitsInProgressTasks > 1 < SpreadActualCost > 0 < SpreadPercentComplete > 0 < TaskUpdatesResource > 1 < FiscalYearStart > 0 < WeekStartDay > 0 < MoveCompletedEndsBack > 0 < MoveRemainingStartsBack > 0 < MoveRemainingStartsForward> 0 < MoveCompletedEndsForward > 0 < BaselineForEarnedValue > 0 < AutoAddNewResourcesAndTasks > 1 < CurrentDate > 2006-11-02T08:00:00

PAGE 92

92 < MicrosoftProjectServerURL > 1 < Autolink > 1 < NewTaskStartDate > 0 < DefaultTaskEVMethod > 0 < ProjectExternallyEdited > 0 < ExtendedCreationDate > 1984-01-01T00:00:00 < ActualsInSync > 1 < RemoveFileProperties > 0 < AdminProject > 0 < OutlineCodes /> < WBSMasks /> < ExtendedAttributes /> < Calendars > < Calendar > < UID > 1 < Name > Standard < IsBaseCalendar > 1 < BaseCalendarUID > -1 < WeekDays > < WeekDay > < DayType > 1 < DayWorking > 0 < WeekDay > < DayType > 2 < DayWorking > 1 < WorkingTimes > < WorkingTime > < FromTime > 08:00:00 < ToTime > 12:00:00 < WorkingTime > < FromTime > 13:00:00 < ToTime > 17:00:00 < WeekDay > < DayType > 3 < DayWorking > 1 < WorkingTimes > < WorkingTime > < FromTime > 08:00:00 < ToTime > 12:00:00 < WorkingTime > < FromTime > 13:00:00 < ToTime > 17:00:00

PAGE 93

93 < WeekDay > < DayType > 4 < DayWorking > 1 < WorkingTimes > < WorkingTime > < FromTime > 08:00:00 < ToTime > 12:00:00 < WorkingTime > < FromTime > 13:00:00 < ToTime > 17:00:00 < WeekDay > < DayType > 5 < DayWorking > 1 < WorkingTimes > < WorkingTime > < FromTime > 08:00:00 < ToTime > 12:00:00 < WorkingTime > < FromTime > 13:00:00 < ToTime > 17:00:00 < WeekDay > < DayType > 6 < DayWorking > 1 < WorkingTimes > < WorkingTime > < FromTime > 08:00:00 < ToTime > 12:00:00 < WorkingTime > < FromTime > 13:00:00 < ToTime > 17:00:00 < WeekDay > < DayType > 7 < DayWorking > 0

PAGE 94

94 < Tasks > < Task > < UID > 0 < ID > 0 < Type > 1 < IsNull > 0 < CreateDate > 2006-11-02T10:57:00 < WBS > 0 < OutlineNumber > 0 < OutlineLevel > 0 < Priority > 500 < Start >2006-10-31T08:00:00 < Finish > 2006-11-28T17:00:00 < Duration > PT168H0M0S < DurationFormat > 21 < Work > PT0H0M0S < ResumeValid > 0 < EffortDriven > 0 < Recurring > 0 < OverAllocated > 0 < Estimated > 0 < Milestone > 0 < Summary > 1 < Critical > 1 < IsSubproject > 0 < IsSubprojectReadOnly > 0 < ExternalTask > 0 < EarlyStart > 2006-10-31T08:00:00 < EarlyFinish > 2006-11-28T17:00:00 < LateStart > 2006-10-31T08:00:00 < LateFinish > 2006-11-28T17:00:00 < StartVariance > 0 < FinishVariance > 0 < WorkVariance > 0 < FreeSlack > 0 < TotalSlack > 0 < FixedCost > 0 < FixedCostAccrual > 3 < PercentComplete > 0 < PercentWorkComplete > 0 < Cost > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < ActualDuration > PT0H0M0S < ActualCost > 0 < ActualOvertimeCost > 0 < ActualWork > PT0H0M0S

PAGE 95

95 < ActualOvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingDuration > PT168H0M0S < RemainingCost > 0 < RemainingWork > PT0H0M0S < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < ACWP > 0 < CV > 0 < ConstraintType > 0 < CalendarUID > -1 < LevelAssignments > 1 < LevelingCanSplit > 1 < LevelingDelay > 0 < LevelingDelayFormat > 8 < IgnoreResourceCalendar > 0 < HideBar > 0 < Rollup > 0 < BCWS > 0 < BCWP > 0 < PhysicalPercentComplete > 0 < EarnedValueMethod > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < Task > < UID > 1 < ID > 1 < Name > AAAAA < Type > 0 < IsNull > 0 < CreateDate > 2006-11-02T10:57:00 < WBS > 1 < OutlineNumber > 1 < OutlineLevel > 1 < Priority >500 < Start > 2006-10-31T08:00:00 < Finish > 2006-11-03T17:00:00 < Duration > PT32H0M0S < DurationFormat > 7 < Work > PT0H0M0S < ResumeValid > 0 < EffortDriven > 1 < Recurring > 0 < OverAllocated > 0 < Estimated > 0 < Milestone > 0 < Summary > 0 < Critical > 1

PAGE 96

96 < IsSubproject > 0 < IsSubprojectReadOnly > 0 < ExternalTask > 0 < EarlyStart > 2006-10-31T08:00:00 < EarlyFinish > 2006-11-03T17:00:00 < LateStart > 2006-10-31T08:00:00 < LateFinish > 2006-11-03T17:00:00 < StartVariance > 0 < FinishVariance > 0 < WorkVariance > 0 < FreeSlack > 0 < TotalSlack > 0 < FixedCost > 0 < FixedCostAccrual > 3 < PercentComplete > 0 < PercentWorkComplete > 0 < Cost > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < ActualDuration > PT0H0M0S < ActualCost > 0 < ActualOvertimeCost > 0 < ActualWork > PT0H0M0S < ActualOvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingDuration > PT32H0M0S < RemainingCost > 0 < RemainingWork > PT0H0M0S < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S 0 < CV > 0 < ConstraintType > 0 < CalendarUID > -1 < LevelAssignments > 1 < LevelingCanSplit > 1 < LevelingDelay > 0 < LevelingDelayFormat > 8 < IgnoreResourceCalendar > 0 < HideBar > 0 < Rollup> 0 < BCWS > 0 < BCWP > 0 < PhysicalPercentComplete > 0 < EarnedValueMethod > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < Task >

PAGE 97

97 < UID > 2 < ID > 2 < Name > BBBBB < Type > 0 < IsNull > 0 < CreateDate > 2006-11-02T10:58:00 < WBS > 2 < OutlineNumber > 2 < OutlineLevel > 1 < Priority > 500 < Start > 2006-11-06T08:00:00 < Finish > 2006-11-13T17:00:00 < Duration > PT48H0M0S < DurationFormat > 7 < Work > PT0H0M0S < ResumeValid > 0 < EffortDriven > 1 < Recurring > 0 < OverAllocated > 0 < Estimated > 0 < Milestone > 0 < Summary > 0 < Critical > 1 < IsSubproject > 0 < IsSubprojectReadOnly > 0 < ExternalTask > 0 < EarlyStart > 2006-11-06T08:00:00 < EarlyFinish > 2006-11-13T17:00:00 < LateStart > 2006-11-06T08:00:00 < LateFinish > 2006-11-13T17:00:00 0 < FinishVariance > 0 < WorkVariance > 0 < FreeSlack > 0 < TotalSlack > 0 < FixedCost > 0 < FixedCostAccrual > 3 < PercentComplete > 0 < PercentWorkComplete > 0 < Cost > 0 < OvertimeCost> 0 < OvertimeWork > PT0H0M0S < ActualDuration > PT0H0M0S < ActualCost > 0 < ActualOvertimeCost > 0 < ActualWork > PT0H0M0S < ActualOvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingDuration > PT48H0M0S

PAGE 98

98 < RemainingCost > 0 < RemainingWork > PT0H0M0S < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < ACWP > 0 < CV > 0 < ConstraintType > 0 < CalendarUID > -1 < LevelAssignments > 1 < LevelingCanSplit > 1 < LevelingDelay > 0 < LevelingDelayFormat > 8 < IgnoreResourceCalendar > 0 < HideBar > 0 < Rollup > 0 < BCWS > 0 < BCWP > 0 < PhysicalPercentComplete > 0 < EarnedValueMethod > 0 < PredecessorLink > < PredecessorUID > 1 < Type > 1 < CrossProject > 0 < LinkLag > 0 < LagFormat > 7 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < Task > < UID > 3 < ID > 3 < Name > CCCCC < Type > 0 < IsNull > 0 < CreateDate > 2006-11-02T10:58:00 < WBS > 3 < OutlineNumber > 3 < OutlineLevel > 1 < Priority >500 < Start > 2006-11-14T08:00:00 < Finish > 2006-11-20T17:00:00 < Duration > PT40H0M0S < DurationFormat > 7 < Work > PT0H0M0S < ResumeValid > 0 < EffortDriven > 1 < Recurring > 0 < OverAllocated > 0

PAGE 99

99 < Estimated > 0 < Milestone > 0 < Summary > 0 < Critical > 1 < IsSubproject > 0 < IsSubprojectReadOnly > 0 < ExternalTask > 0 < EarlyStart > 2006-11-14T08:00:00 < EarlyFinish > 2006-11-20T17:00:00 < LateStart > 2006-11-14T08:00:00 < LateFinish > 2006-11-20T17:00:00 < StartVariance > 0 < FinishVariance > 0 < WorkVariance > 0 < FreeSlack > 0 < TotalSlack > 0 < FixedCost > 0 < FixedCostAccrual > 3 < PercentComplete > 0 < PercentWorkComplete > 0 < Cost > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < ActualDuration > PT0H0M0S < ActualCost > 0 < ActualOvertimeCost > 0 < ActualWork > PT0H0M0S < ActualOvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingDuration > PT40H0M0S 0 < RemainingWork > PT0H0M0S < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < ACWP > 0 < CV > 0 < ConstraintType > 0 < CalendarUID > -1 < LevelAssignments > 1 < LevelingCanSplit > 1 < LevelingDelay> 0 < LevelingDelayFormat > 8 < IgnoreResourceCalendar > 0 < HideBar > 0 < Rollup > 0 < BCWS > 0 < BCWP > 0 < PhysicalPercentComplete > 0 < EarnedValueMethod > 0

PAGE 100

100 < PredecessorLink > < PredecessorUID > 2 < Type > 1 < CrossProject > 0 < LinkLag > 0 < LagFormat > 7 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < Task > < UID > 4 < ID > 4 < Name > DDDDD < Type > 0 < IsNull > 0 < CreateDate > 2006-11-02T10:58:00 < WBS > 4 < OutlineNumber > 4 < OutlineLevel > 1 < Priority >500 < Start > 2006-11-06T08:00:00 < Finish > 2006-11-14T17:00:00 < Duration > PT56H0M0S < DurationFormat > 7 < Work > PT0H0M0S < ResumeValid > 0 < EffortDriven > 1 < Recurring > 0 < OverAllocated > 0 < Estimated > 0 < Milestone > 0 < Summary > 0 < Critical > 0 < IsSubproject > 0 < IsSubprojectReadOnly > 0 < ExternalTask > 0 < EarlyStart > 2006-11-06T08:00:00 < EarlyFinish > 2006-11-14T17:00:00 < LateStart > 2006-11-10T08:00:00 < LateFinish > 2006-11-20T17:00:00 < StartVariance > 0 < FinishVariance > 0 < WorkVariance > 0 < FreeSlack > 19200 < TotalSlack > 19200 < FixedCost > 0 < FixedCostAccrual > 3 < PercentComplete > 0

PAGE 101

101 < PercentWorkComplete > 0 < Cost > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < ActualDuration > PT0H0M0S < ActualCost > 0 < ActualOvertimeCost > 0 < ActualWork > PT0H0M0S < ActualOvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingDuration > PT56H0M0S < RemainingCost > 0 < RemainingWork > PT0H0M0S < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < ACWP > 0 < CV > 0 < ConstraintType > 0 < CalendarUID > -1 < LevelAssignments > 1 < LevelingCanSplit > 1 < LevelingDelay > 0 < LevelingDelayFormat > 8 < IgnoreResourceCalendar > 0 < HideBar > 0 < Rollup > 0 < BCWS > 0 < BCWP > 0 < PhysicalPercentComplete > 0 < EarnedValueMethod > 0 < PredecessorLink > < PredecessorUID > 1 < Type > 1 < CrossProject > 0 < LinkLag > 0 < LagFormat > 7 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < Task > < UID > 5 < ID > 5 < Name > EEEEE < Type > 0 < IsNull > 0 < CreateDate > 2006-11-02T10:58:00 < WBS > 5 < OutlineNumber > 5

PAGE 102

102 < OutlineLevel > 1 < Priority > 500 < Start > 2006-11-21T08:00:00 < Finish > 2006-11-28T17:00:00 < Duration > PT48H0M0S < DurationFormat > 7 < Work > PT0H0M0S < ResumeValid > 0 < EffortDriven > 1 < Recurring > 0 < OverAllocated > 0 < Estimated > 0 < Milestone > 0 < Summary > 0 < Critical > 1 < IsSubproject > 0 < IsSubprojectReadOnly > 0 < ExternalTask > 0 < EarlyStart > 2006-11-21T08:00:00 < EarlyFinish > 2006-11-28T17:00:00 < LateStart > 2006-11-21T08:00:00 < LateFinish > 2006-11-28T17:00:00 < StartVariance > 0 < FinishVariance > 0 < WorkVariance > 0 < FreeSlack > 0 < TotalSlack > 0 < FixedCost > 0 < FixedCostAccrual > 3 < PercentComplete > 0 0 < Cost > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < ActualDuration > PT0H0M0S < ActualCost > 0 < ActualOvertimeCost > 0 < ActualWork > PT0H0M0S < ActualOvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingDuration> PT48H0M0S < RemainingCost > 0 < RemainingWork > PT0H0M0S < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < ACWP > 0 < CV > 0 < ConstraintType > 0 < CalendarUID > -1

PAGE 103

103 < LevelAssignments > 1 < LevelingCanSplit > 1 < LevelingDelay > 0 < LevelingDelayFormat > 8 < IgnoreResourceCalendar > 0 < HideBar > 0 < Rollup > 0 < BCWS > 0 < BCWP > 0 < PhysicalPercentComplete > 0 < EarnedValueMethod > 0 < PredecessorLink > < PredecessorUID > 3 < Type > 1 < CrossProject > 0 < LinkLag > 0 < LagFormat > 7 < PredecessorLink > < PredecessorUID > 4 < Type > 1 < CrossProject > 0 < LinkLag > 0 < LagFormat > 7 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < Resources > < Resource > < UID > 0 < ID > 0 < Type > 1 < IsNull > 0 < WorkGroup > 0 < MaxUnits > 1 < PeakUnits > 0 < OverAllocated > 0 < CanLevel > 1 < AccrueAt >3 < Work > PT0H0M0S < RegularWork > PT0H0M0S < OvertimeWork > PT0H0M0S < ActualWork > PT0H0M0S < RemainingWork > PT0H0M0S < ActualOvertimeWork > PT0H0M0S < RemainingOvertimeWork > PT0H0M0S < PercentWorkComplete > 0

PAGE 104

104 < StandardRate > 0 < StandardRateFormat > 2 < Cost > 0 < OvertimeRate > 0 < OvertimeRateFormat > 2 < OvertimeCost > 0 < CostPerUse > 0 < ActualCost > 0 < ActualOvertimeCost > 0 < RemainingCost > 0 < RemainingOvertimeCost > 0 < WorkVariance > 0 < CostVariance > 0 < SV > 0 < CV > 0 < ACWP > 0 < CalendarUID > 2 < BCWS > 0 < BCWP > 0 < IsGeneric > 0 < IsInactive > 0 < IsEnterprise > 0 < BookingType > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < CreationDate > 2006-11-02T10:57:00 < Assignments > < Assignment > < UID > 1 < TaskUID > 1 < ResourceUID > -65535 < PercentWorkComplete > 0 < ActualCost > 0 < ActualOvertimeCost > 0 < ActualOvertimeWork > PT0H0M0S < ActualWork > PT0H0M0S < ACWP > 0 < Confirmed >0 < Cost > 0 < CostRateTable > 0 < CostVariance > 0 < CV > 0 < Delay > 0 < Finish > 2006-11-03T17:00:00 < FinishVariance > 0 < WorkVariance > 0 < HasFixedRateUnits > 1

PAGE 105

105 < FixedMaterial > 0 < LevelingDelay > 0 < LevelingDelayFormat > 7 < LinkedFields > 0 < Milestone > 0 < Overallocated > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingCost > 0 < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < RemainingWork > PT0H0M0S < ResponsePending > 0 < Start > 2006-10-31T08:00:00 < Stop > 2006-10-31T08:00:00 < Resume > 2006-10-31T08:00:00 < StartVariance > 0 < Units > 1 < UpdateNeeded > 0 < VAC > 0 < Work > PT0H0M0S < WorkContour > 0 < BCWS > 0 < BCWP > 0 < BookingType > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < CreationDate > 2006-11-02T10:57:00 < TimephasedData > < Type > 1 < UID > 1 < Start > 2006-10-31T08:00:00 < Finish > 2006-11-01T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 1 < Start > 2006-11-01T08:00:00 < Finish > 2006-11-02T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 1 < Start > 2006-11-02T08:00:00

PAGE 106

106 < Finish > 2006-11-03T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 1 < Start > 2006-11-03T08:00:00 < Finish > 2006-11-03T17:00:00 < Unit > 2 < Value > PT8H0M0S < Assignment > < UID > 2 < TaskUID > 2 < ResourceUID > -65535 < PercentWorkComplete > 0 < ActualCost > 0 < ActualOvertimeCost > 0 < ActualOvertimeWork > PT0H0M0S < ActualWork > PT0H0M0S < ACWP > 0 < Confirmed >0 < Cost > 0 < CostRateTable > 0 < CostVariance > 0 < CV > 0 < Delay > 0 < Finish > 2006-11-13T17:00:00 < FinishVariance > 0 < WorkVariance > 0 < HasFixedRateUnits > 1 < FixedMaterial > 0 < LevelingDelay > 0 < LevelingDelayFormat > 7 < LinkedFields > 0 < Milestone > 0 < Overallocated > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingCost > 0 < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < RemainingWork > PT0H0M0S < ResponsePending > 0 < Start > 2006-11-06T08:00:00 < Stop > 2006-11-06T08:00:00

PAGE 107

107 < Resume > 2006-11-06T08:00:00 < StartVariance > 0 < Units > 1 < UpdateNeeded > 0 < VAC > 0 < Work > PT0H0M0S < WorkContour > 0 < BCWS > 0 < BCWP > 0 < BookingType > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < CreationDate > 2006-11-02T10:58:00 < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-06T08:00:00 < Finish > 2006-11-07T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-07T08:00:00 < Finish > 2006-11-08T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-08T08:00:00 < Finish > 2006-11-09T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-09T08:00:00 < Finish > 2006-11-10T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-10T08:00:00

PAGE 108

108 < Finish > 2006-11-11T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-11T08:00:00 < Finish > 2006-11-12T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-12T08:00:00 < Finish > 2006-11-13T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 2 < Start > 2006-11-13T08:00:00 < Finish > 2006-11-13T17:00:00 < Unit > 2 < Value > PT8H0M0S < Assignment > < UID > 3 < TaskUID > 3 < ResourceUID > -65535 < PercentWorkComplete > 0 < ActualCost > 0 < ActualOvertimeCost > 0 < ActualOvertimeWork > PT0H0M0S < ActualWork > PT0H0M0S < ACWP > 0 < Confirmed >0 < Cost > 0 < CostRateTable > 0 < CostVariance > 0 < CV > 0 < Delay > 0 < Finish > 2006-11-20T17:00:00 < FinishVariance > 0 < WorkVariance > 0 < HasFixedRateUnits > 1 < FixedMaterial > 0 < LevelingDelay > 0

PAGE 109

109 < LevelingDelayFormat > 7 < LinkedFields > 0 < Milestone > 0 < Overallocated > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingCost > 0 < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < RemainingWork > PT0H0M0S < ResponsePending > 0 < Start > 2006-11-14T08:00:00 < Stop > 2006-11-14T08:00:00 < Resume > 2006-11-14T08:00:00 < StartVariance > 0 < Units > 1 < UpdateNeeded > 0 < VAC > 0 < Work > PT0H0M0S < WorkContour > 0 < BCWS > 0 < BCWP > 0 < BookingType > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < CreationDate > 2006-11-02T10:58:00 < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-14T08:00:00 < Finish > 2006-11-15T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-15T08:00:00 < Finish > 2006-11-16T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-16T08:00:00 < Finish > 2006-11-17T08:00:00 < Unit > 2

PAGE 110

110 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-17T08:00:00 < Finish > 2006-11-18T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-18T08:00:00 < Finish > 2006-11-19T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-19T08:00:00 < Finish > 2006-11-20T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 3 < Start > 2006-11-20T08:00:00 < Finish > 2006-11-20T17:00:00 < Unit > 2 < Value > PT8H0M0S < Assignment > < UID > 4 < TaskUID > 4 < ResourceUID > -65535 < PercentWorkComplete > 0 < ActualCost > 0 < ActualOvertimeCost > 0 < ActualOvertimeWork > PT0H0M0S < ActualWork > PT0H0M0S < ACWP > 0 < Confirmed >0 < Cost > 0 < CostRateTable > 0 < CostVariance > 0 < CV > 0 < Delay > 0

PAGE 111

111 < Finish > 2006-11-14T17:00:00 < FinishVariance > 0 < WorkVariance > 0 < HasFixedRateUnits > 1 < FixedMaterial > 0 < LevelingDelay > 0 < LevelingDelayFormat > 7 < LinkedFields > 0 < Milestone > 0 < Overallocated > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingCost > 0 < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < RemainingWork > PT0H0M0S < ResponsePending > 0 < Start > 2006-11-06T08:00:00 < Stop > 2006-11-06T08:00:00 < Resume > 2006-11-06T08:00:00 < StartVariance > 0 < Units > 1 < UpdateNeeded > 0 < VAC > 0 < Work > PT0H0M0S < WorkContour > 0 < BCWS > 0 < BCWP > 0 < BookingType > 0 PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < CreationDate > 2006-11-02T10:58:00 < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-06T08:00:00 < Finish > 2006-11-07T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-07T08:00:00 < Finish > 2006-11-08T08:00:00 < Unit > 2 < Value > PT8H0M0S

PAGE 112

112 < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-08T08:00:00 < Finish > 2006-11-09T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-09T08:00:00 < Finish > 2006-11-10T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-10T08:00:00 < Finish > 2006-11-11T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-11T08:00:00 < Finish > 2006-11-12T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-12T08:00:00 < Finish > 2006-11-13T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 4 < Start > 2006-11-13T08:00:00 < Finish > 2006-11-14T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 4

PAGE 113

113 < Start > 2006-11-14T08:00:00 < Finish > 2006-11-14T17:00:00 < Unit > 2 < Value > PT8H0M0S < Assignment > < UID > 5 < TaskUID > 5 < ResourceUID > -65535 < PercentWorkComplete > 0 < ActualCost > 0 < ActualOvertimeCost > 0 < ActualOvertimeWork > PT0H0M0S < ActualWork > PT0H0M0S < ACWP > 0 < Confirmed >0 < Cost > 0 < CostRateTable > 0 < CostVariance > 0 < CV > 0 < Delay > 0 < Finish > 2006-11-28T17:00:00 < FinishVariance > 0 < WorkVariance > 0 < HasFixedRateUnits > 1 < FixedMaterial > 0 < LevelingDelay > 0 < LevelingDelayFormat > 7 < LinkedFields > 0 < Milestone > 0 < Overallocated > 0 < OvertimeCost > 0 < OvertimeWork > PT0H0M0S < RegularWork > PT0H0M0S < RemainingCost > 0 < RemainingOvertimeCost > 0 < RemainingOvertimeWork > PT0H0M0S < RemainingWork > PT0H0M0S < ResponsePending > 0 < Start > 2006-11-21T08:00:00 < Stop > 2006-11-21T08:00:00 < Resume > 2006-11-21T08:00:00 < StartVariance > 0 < Units > 1 < UpdateNeeded > 0 < VAC > 0 < Work > PT0H0M0S < WorkContour > 0

PAGE 114

114 < BCWS > 0 < BCWP > 0 < BookingType > 0 < ActualWorkProtected > PT0H0M0S < ActualOvertimeWorkProtected > PT0H0M0S < CreationDate > 2006-11-02T10:58:00 < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-21T08:00:00 < Finish > 2006-11-22T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-22T08:00:00 < Finish > 2006-11-23T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-23T08:00:00 < Finish > 2006-11-24T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-24T08:00:00 < Finish > 2006-11-25T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-25T08:00:00 < Finish > 2006-11-26T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-26T08:00:00

PAGE 115

115 < Finish > 2006-11-27T08:00:00 < Unit > 2 < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-27T08:00:00 < Finish > 2006-11-28T08:00:00 < Unit > 2 < Value > PT8H0M0S < TimephasedData > < Type > 1 < UID > 5 < Start > 2006-11-28T08:00:00 < Finish > 2006-11-28T17:00:00 < Unit > 2 < Value > PT8H0M0S .

PAGE 116

116 APPENDIX C PRIMAVERA PM/MM (XER) FILE ERMHDR 4.1.1000 2006-10-31 Project admin Primavera Admin PMDB Project Management USD %T CURRTYPE %F curr_id decimal_digit_cnt curr_symbol decimal_symbol digit_group_symbol pos_curr_fmt_type neg_curr_fmt_type curr_type curr_short_name group_digit_cnt base_exch_rate %R 1 2 $ . , #1.1 (#1.1) Dollar USD 3 1 %R 10 2 Arg$ . , #1.1 (#1.1) Argentine Peso ARS 3 3.56974 %R 11 2 $A . , #1.1 (#1.1) Australian Dollar AUST 3 1.7964 %R 13 2 R$ . , #1.1 (#1.1) Brazilian Real BRL 3 2.481 %R 14 2 . , #1.1 (#1.1) British Pound UK 3 0.685097 %R 15 2 Can$ . , #1.1 (#1.1) Canadian Dollar CAD 3 1.53818 %R 16 2 Y . , #1.1 (#1.1) Chinese Yuan CNY 3 8.2769 %R 17 2 . , #1.1 (#1.1) Euro EUR 3 1.08702 %R 20 2 HK$ . , #1.1 (#1.1) Hong Kong Dollar HKD 3 7.7992 %R 21 2 Rs . , #1.1 (#1.1) Indian Rupee INR 3 48.9697 %R 23 2 . , #1.1 (#1.1) Japanese Yen JPY 3 124.03 %R 25 2 Mex$ . , #1.1 (#1.1) Mexican Peso MXN 3 9.49004 %R 26 2 Rb . , #1.1 (#1.1) Russian Rouble RUB 3 31.27 %R 28 2 Sk . , #1.1 (#1.1) Swedish Krona SEK 3 9.97013 %R 29 2 SwF . , #1.1 (#1.1) Swiss Franc CHF 3 1.57656 %T OBS %F obs_id parent_obs_id guid seq_num obs_name obs_descr %R 565 0 Enterprise %T UMEASURE %F unit_id seq_num unit_abbrev unit_name %R 100 100 cu yd Cubic yards %R 101 200 ea Each %R 102 300 hr Hour %R 103 17560 lf lf %T PROJECT %F proj_id fy_start_month_num chng_eff_cmp_pct_flag rsrc_self_add_flag allow_complete_flag rsrc_multi_assign_flag checkout_flag project_flag step_complete_flag cost_qty_recalc_flag sum_only_flag batch_sum_flag name_sep_char def_complete_pct_type proj_short_name acct_id orig_proj_id base_type_id clndr_id sum_base_proj_id task_code_base task_code_step priority_num wbs_max_sum_level

PAGE 117

117 risk_level strgy_priority_num last_checksum critical_drtn_hr_cnt def_cost_per_qty last_recalc_date plan_start_date plan_end_date scd_end_date add_date sum_data_date last_tasksum_date fcst_start_date def_duration_type task_code_prefix guid def_qty_type add_by_name web_local_root_path proj_url def_rate_type add_act_remain_flag act_this_per_link_flag def_task_type act_pct_link_flag critical_path_type task_code_prefix_flag def_rollup_dates_flag rem_target_link_flag reset_planned_flag allow_neg_act_flag loaded_scope_level export_flag next_data_date trsrcsum_loaded %R 432 1 N Y Y Y N Y N N N Y . CP_Drtn BCNIFC 597 1000 10 10 2 3 500 0 0.00 2006-10-31 00:00 2006-10-31 00:00 2006-11-28 17:00 2006-10-31 00:00 DT_FixedDUR2 A ncO6SYhwXESjqiCl4geGoR QT_Hour admin COST_PER_QTY N Y TT_Task Y CT_TotFloat Y Y Y N N 7 Y %T CALENDAR %F clndr_id default_flag clndr_name proj_id base_clndr_id last_chng_date clndr_type clndr_data %R 597 Y Standard 5 Day Workweek 2000-04-26 14:11 CA_Base (0||CalendarData()( (0||DaysOfWeek()( (0||1()()) (0||2()( (0||0(s|08:00|f|12:00)()) (0||1(s|13:00|f|17:00)()))) (0||3()( (0||0(s|08:00|f|12:00)()) (0||1(s|13:00|f|17:00)()))) (0||4()( (0||0(s|08:00|f|12:00)()) (0||1(s|13:00|f|17:00)()))) (0||5()( (0||0(s|08:00|f|12:00)()) (0||1(s|13:00|f|17:00)()))) (0||6()( (0||0(s|08:00|f|12:00)()) (0||1(s|13:00|f|17:00)()))) (0||7()()))) (0||Exceptions()()))) %T PROJWBS %F wbs_id proj_id obs_id seq_num est_wt proj_node_flag sum_data_flag status_code wbs_short_name wbs_name phase_id parent_wbs_id ev_user_pct ev_etc_user_value orig_cost indep_remain_total_cost ann_dscnt_rate_pct dscnt_period_type indep_remain_work_qty anticip_start_date anticip_end_date ev_compute_type ev_etc_compute_type guid tmpl_guid plan_open_state %R 4264 432 565 203 1 Y N WS_Open BCNIFC TEST IFC 3693 6 0.88 0.00 0.00 EC_Cmp_pct EE_Rem_hr QPb7IV0maU+3IZop8BStKR %T SCHEDOPTIONS %F schedoptions_id proj_id sched_outer_depend_type sched_open_critical_flag sched_lag_early_start_flag sched_retained_logic sched_setplantoforecast sched_float_type sched_calendar_on_relationship_lag sched_use_expect_end_flag sched_progress_override level_float_thrs_cnt level_outer_assign_flag level_outer_assign_priority level_over_alloc_pct level_within_float_flag level_keep_sched_date_flag level_all_rsrc_flag LevelPriorityList %R 1 432 SD_Both N Y Y N FT_FF rcal_Predecessor Y N 0 N 5 25 N Y Y priority_type,ASC %T TASK %F task_id proj_id wbs_id clndr_id est_wt phys_complete_pct rev_fdbk_flag lock_plan_flag auto_compute_act_flag complete_pct_type task_type duration_type review_type status_code task_code task_name rsrc_id

PAGE 118

118 total_float_hr_cnt free_float_hr_cnt remain_drtn_hr_cnt act_work_qty remain_work_qty target_work_qty target_drtn_hr_cnt target_equip_qty act_equip_qty remain_equip_qty cstr_date act_start_date act_end_date late_start_date late_end_date expect_end_date early_start_date early_end_date restart_date reend_date target_start_date target_end_date review_end_date rem_late_start_date rem_late_end_date cstr_type priority_type guid tmpl_guid cstr_date2 cstr_type2 driving_path_flag act_this_per_work_qty act_this_per_equip_qty old_restart_date old_reend_date old_remain_drtn_hr_cnt %R 38524 432 4264 597 1 0 N N N CP_Drtn TT_Task DT_FixedDUR2 RV_OK TK_NotStart A1000 Activity AAAAA 0 0 32 0 0 0 32 0 0 0 2006-10-31 08:00 2006-11-03 17:00 2006-10-31 08:00 2006-11-03 17:00 2006-10-31 08:00 2006-11-03 17:00 2006-10-31 08:00 2006-11-03 17:00 2006-10-31 08:00 2006-11-03 17:00 PT_Normal GaBwSz/KREaL2VvHLasu+R Y 0 0 2006-10-31 08:00 2006-11-03 17:00 32 %R 38525 432 4264 597 1 0 N N N CP_Drtn TT_Task DT_FixedDUR2 RV_OK TK_NotStart A1010 Activity BBBBB 0 0 48 0 0 0 48 0 0 0 2006-11-06 08:00 2006-11-13 17:00 2006-11-06 08:00 2006-11-13 17:00 2006-11-06 08:00 2006-11-13 17:00 2006-11-06 08:00 2006-11-13 17:00 2006-11-06 08:00 2006-11-13 17:00 PT_Normal iRuDncA+lUGdwZHnbw+JFR Y 0 0 2006-11-06 08:00 2006-11-13 17:00 48 %R 38526 432 4264 597 1 0 N N N CP_Drtn TT_Task DT_FixedDUR2 RV_OK TK_NotStart A1020 Activity CCCCC 0 0 40 0 0 0 40 0 0 0 2006-11-14 08:00 2006-11-20 17:00 2006-11-14 08:00 2006-11-20 17:00 2006-11-14 08:00 2006-11-20 17:00 2006-11-14 08:00 2006-11-20 17:00 2006-11-14 08:00 2006-11-20 17:00 PT_Normal u3X172pDB0e8GIiNLZuMMx Y 0 0 2006-11-14 08:00 2006-11-20 17:00 40 %R 38527 432 4264 597 1 0 N N N CP_Drtn TT_Task DT_FixedDUR2 RV_OK TK_NotStart A1030 Activity DDDDD 32 32 56 0 0 0 56 0 0 0 2006-11-10 08:00 2006-11-20 17:00 2006-11-06 08:00 2006-11-14 17:00 2006-11-06 08:00 2006-11-14 17:00 2006-11-06 08:00 2006-11-14 17:00 2006-11-10 08:00 2006-11-20 17:00 PT_Normal CXRAi5V7hEmRWDGdpiCoLh N 0 0 2006-11-06 08:00 2006-11-14 17:00 56 %R 38528 432 4264 597 1 0 N N N CP_Drtn TT_Task DT_FixedDUR2 RV_OK TK_NotStart A1040 Activity EEEEE 0 0 48 0 0 0 48 0 0 0 2006-11-21 08:00 2006-11-28 17:00 2006-11-21 08:00 2006-11-28 17:00 2006-11-21 08:00 2006-11-28 17:00 2006-11-21 08:00 2006-11-28 17:00 2006-11-21 08:00 2006-11-28 17:00 PT_Normal RnQXkGIb6E+UG3SqwoIyMR Y 0 0 2006-11-21 08:00 2006-11-28 17:00 48 %T TASKNOTE %F task_id proj_id task_notes %R 38527 432 %T TASKPRED %F task_pred_id task_id pred_task_id proj_id pred_proj_id pred_type lag_hr_cnt

PAGE 119

119 %R 4867 38525 38524 432 432 PR_FS 0 %R 4868 38526 38525 432 432 PR_FS 0 %R 4869 38527 38524 432 432 PR_FS 0 %R 4870 38528 38526 432 432 PR_FS 0 %R 4871 38528 38527 432 432 PR_FS 0 %E.

PAGE 120

120 APPENDIX D IFCPROCESSEXTENSION ENTITIES SCHEMA Inheritance graph ENTITY IfcProcedure; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcProcess ; INVERSE OperatesOn : SET OF IfcRelAssignsToProcess FOR RelatingProcess; IsSuccessorFrom : SET OF IfcRelSequence FOR RelatedProcess; IsPredecessorTo : SET OF IfcRelSequence FOR RelatingProcess; ENTITY IfcProcedure ; ProcedureID : IfcIdentifier ; ProcedureType : IfcProcedureTypeEnum ; UserDefinedProcedureType : OPTIONAL IfcLabel ; END_ENTITY ; Inheritance graph ENTITY IfcRelAssignsTasks; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcRelationship ; ENTITY IfcRelAssigns ; RelatedObjects : SET [1:?] OF IfcObjectDefinition ; RelatedObjectsType : OPTIONAL IfcObjectTypeEnum ;

PAGE 121

121 ENTITY IfcRelAssignsToControl ; RelatingControl : IfcControl ; ENTITY IfcRelAssignsTasks ; TimeForTask : OPTIONAL IfcScheduleTimeControl ; END_ENTITY ; Inheritance graph ENTITY IfcTask; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcProcess ; INVERSE OperatesOn : SET OF IfcRelAssignsToProcess FOR RelatingProcess; IsSuccessorFrom : SET OF IfcRelSequence FOR RelatedProcess; IsPredecessorTo : SET OF IfcRelSequence FOR RelatingProcess; ENTITY IfcTask ; TaskId : IfcIdentifier ; Status : OPTIONAL IfcLabel ; WorkMethod : OPTIONAL IfcLabel ; IsMilestone : BOOLEAN ; Priority : OPTIONAL INTEGER ; END_ENTITY ;

PAGE 122

122 Inheritance graph ENTITY IfcScheduleTimeControl; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcControl ; INVERSE Controls : SET OF IfcRelAssignsToControl FOR RelatingControl; ENTITY IfcScheduleTimeControl ; ActualStart : OPTIONAL IfcDateTimeSelect ; EarlyStart : OPTIONAL IfcDateTimeSelect ; LateStart : OPTIONAL IfcDateTimeSelect ; ScheduleStart : OPTIONAL IfcDateTimeSelect ; ActualFinish : OPTIONAL IfcDateTimeSelect ; EarlyFinish : OPTIONAL IfcDateTimeSelect ; LateFinish : OPTIONAL IfcDateTimeSelect ; ScheduleFinish : OPTIONAL IfcDateTimeSelect ; ScheduleDuration : OPTIONAL IfcTimeMeasure ; ActualDuration : OPTIONAL IfcTimeMeasure ; RemainingTime : OPTIONAL IfcTimeMeasure ; FreeFloat : OPTIONAL IfcTimeMeasure ; TotalFloat : OPTIONAL IfcTimeMeasure ; IsCritical : OPTIONAL BOOLEAN ; StatusTime : OPTIONAL IfcDateTimeSelect ; StartFloat : OPTIONAL IfcTimeMeasure ; FinishFloat : OPTIONAL IfcTimeMeasure ; Completion : OPTIONAL IfcPositiveRatioMeasure ; INVERSE ScheduleTimeControlAssigned : IfcRelAssignsTasks FOR TimeForTask;

PAGE 123

123 END_ENTITY ; Inheritance graph ENTITY IfcWorkControl; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcControl ; INVERSE Controls : SET OF IfcRelAssignsToControl FOR RelatingControl; ENTITY IfcWorkControl ; Identifier : IfcIdentifier ; CreationDate : IfcDateTimeSelect ; Creators : OPTIONAL SET [1:?] OF IfcPerson ; Purpose : OPTIONAL IfcLabel ; Duration : OPTIONAL IfcTimeMeasure ; TotalFloat : OPTIONAL IfcTimeMeasure ; StartTime : IfcDateTimeSelect ; FinishTime : OPTIONAL IfcDateTimeSelect ; WorkControlType : OPTIONAL IfcWorkControlTypeEnum ; UserDefinedControlType : OPTIONAL IfcLabel ; END_ENTITY ;

PAGE 124

124 Inheritance graph ENTITY IfcWorkPlan; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcControl ; INVERSE Controls : SET OF IfcRelAssignsToControl FOR RelatingControl; ENTITY IfcWorkControl ; Identifier : IfcIdentifier ; CreationDate : IfcDateTimeSelect ; Creators : OPTIONAL SET [1:?] OF IfcPerson ; Purpose : OPTIONAL IfcLabel ; Duration : OPTIONAL IfcTimeMeasure ; TotalFloat : OPTIONAL IfcTimeMeasure ; StartTime : IfcDateTimeSelect ; FinishTime : OPTIONAL IfcDateTimeSelect ; WorkControlType : OPTIONAL IfcWorkControlTypeEnum ; UserDefinedControlType : OPTIONAL IfcLabel ; ENTITY IfcWorkPlan ; END_ENTITY ;

PAGE 125

125 Inheritance graph ENTITY IfcWorkSchedule; ENTITY IfcRoot ; GlobalId : IfcGloballyUniqueId ; OwnerHistory : IfcOwnerHistory ; Name : OPTIONAL IfcLabel ; Description : OPTIONAL IfcText ; ENTITY IfcObjectDefinition ; INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcObject ; ObjectType : OPTIONAL IfcLabel ; INVERSE IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects; ENTITY IfcControl ; INVERSE Controls : SET OF IfcRelAssignsToControl FOR RelatingControl; ENTITY IfcWorkControl ; Identifier : IfcIdentifier ; CreationDate : IfcDateTimeSelect ; Creators : OPTIONAL SET [1:?] OF IfcPerson; Purpose : OPTIONAL IfcLabel ; Duration : OPTIONAL IfcTimeMeasure ; TotalFloat : OPTIONAL IfcTimeMeasure ; StartTime : IfcDateTimeSelect ; FinishTime : OPTIONAL IfcDateTimeSelect ; WorkControlType : OPTIONAL IfcWorkControlTypeEnum ; UserDefinedControlType : OPTIONAL IfcLabel ; ENTITY IfcWorkSchedule ; END_ENTITY ;

PAGE 126

126

PAGE 127

127

PAGE 128

128

PAGE 129

129 APPENDIX E SCREEN SHOTS OF PROPOSED STYSTEM’S PROTOTYPE

PAGE 130

130

PAGE 131

131

PAGE 132

132 APPENDIX F SAMPLE IFC CODE OUTPUT GENERATED BY MODEL /* Mark Danso-Amoako */ /*11/24/2006 5:38:57 PM*/ ISO-10303-21; HEADER; ENDSEC; DATA; #1=IFC(*,.TIMEUNIT.,$,.SECOND.); #2=IFCUNITASSIGNMENT((#1)); #3=IFCPERSON($,'Danso-Amoako',Mark',('O.'),('Mr.'),$,$,$); #4=IFCORGANIZATION($,'Mark Systems Inc.',$,$,(#5)); #5=IFCPOSTALADDRESS(.OFFICE.,$,$,$,'303 Park Avenue #18',$,'Gainesville','FL','32603','USA'); #6=IFCACTORROLE(.CONSULTANT.,$,'Project Engineer'); #7=IFCPERSONANDORGANIZATION(#3,#4,(#6)); #8=IFCORGANIZATION($,'MICROSOFT CORPORATION',$,$,$); #9=IFCAPPLICATION(#8,'9.0','Microsoft Office Project', $); #10=IFCOWNERHISTORY(#8#9.READWRITE.,.NOCHANGE,8#9); #11=IFCPROJECT($#,10'PhD Exam Demo','MS PROJECT TO PRIMAVERA CONVERSION',$,$,$,$ #1); #12=IFCWORKSCHEDULE('abcdefgh',#11,'Test Schedule',$,$,); ENDSEC; #13=IFCTASK($,#10,1,$,$,0,1,$,0,500); #14=IFCSCHEDULETIMECONTROL($,#10,$,$,$obj,#19,#24,#29,#34,#39,#4 4,#49,#54,#55,#56,#57,#58,#59,TRUE,$,$,$,$); #15=IFCCALENDARDATE(#16,#17,#18); #16=IFCDAYINMONTHNUMBER(31); #17=IFCMONTHINYEARNUMBER(10); #18=IFCYEARNUMBER(2006); #19=IFCDATETIMESELECT(#15,$,$); #20=IFCCALENDARDATE(#21,#22,#23); #21=IFCDAYINMONTHNUMBER(31); #22=IFCMONTHINYEARNUMBER(10); #23=IFCYEARNUMBER(2006); #24=IFCDATETIMESELECT(#20,$,$); #25=IFCCALENDARDATE(#26,#27,#28); #26=IFCDAYINMONTHNUMBER(31);

PAGE 133

133 #27=IFCMONTHINYEARNUMBER(10); #28=IFCYEARNUMBER(2006); #29=IFCDATETIMESELECT(#25,$,$); #30=IFCCALENDARDATE(#31,#32,#33); #31=IFCDAYINMONTHNUMBER(31); #32=IFCMONTHINYEARNUMBER(10); #33=IFCYEARNUMBER(2006); #34=IFCDATETIMESELECT(#30,$,$); #35=IFCCALENDARDATE(#36,#37,#38); #36=IFCDAYINMONTHNUMBER(28); #37=IFCMONTHINYEARNUMBER(11); #38=IFCYEARNUMBER(2006); #39=IFCDATETIMESELECT(#35,$,$); #40=IFCCALENDARDATE(#41,#42,#43); #41=IFCDAYINMONTHNUMBER(28); #42=IFCMONTHINYEARNUMBER(11); #43=IFCYEARNUMBER(2006); #44=IFCDATETIMESELECT(#40,$,$); #45=IFCCALENDARDATE(#46,#47,#48); #46=IFCDAYINMONTHNUMBER(28); #47=IFCMONTHINYEARNUMBER(11); #48=IFCYEARNUMBER(2006); #49=IFCDATETIMESELECT(#45,$,$); #50=IFCCALENDARDATE(#51,#52,#53); #51=IFCDAYINMONTHNUMBER(28); #52=IFCMONTHINYEARNUMBER(11); #53=IFCYEARNUMBER(2006); #54=IFCDATETIMESELECT(#50,$,$); #55=IFCTIMEMEASURE(604800); #56=IFCTIMEMEASURE(0); #57=IFCTIMEMEASURE(604800); #58=IFCTIMEMEASURE(0); #59=IFCTIMEMEASURE(0); #60=IFCRELASSIGNSTASKS($,$,$,$,#13,$,#12,#14); #61=IFCTASK($,#10,AAAAA,$,$,1,0,$,0,500); #62=IFCSCHEDULETIMECONTROL($,#10,$,$,$obj,#67,#72,#77,#82,#87,#9 2,#97,#102,#103,#104,#105,#106,#107,TRUE,$,$,$,$);

PAGE 134

134 #63=IFCCALENDARDATE(#64,#65,#66); #64=IFCDAYINMONTHNUMBER(31); #65=IFCMONTHINYEARNUMBER(10); #66=IFCYEARNUMBER(2006); #67=IFCDATETIMESELECT(#63,$,$); #68=IFCCALENDARDATE(#69,#70,#71); #69=IFCDAYINMONTHNUMBER(31); #70=IFCMONTHINYEARNUMBER(10); #71=IFCYEARNUMBER(2006); #72=IFCDATETIMESELECT(#68,$,$); #73=IFCCALENDARDATE(#74,#75,#76); #74=IFCDAYINMONTHNUMBER(31); #75=IFCMONTHINYEARNUMBER(10); #76=IFCYEARNUMBER(2006); #77=IFCDATETIMESELECT(#73,$,$); #78=IFCCALENDARDATE(#79,#80,#81); #79=IFCDAYINMONTHNUMBER(31); #80=IFCMONTHINYEARNUMBER(10); #81=IFCYEARNUMBER(2006); #82=IFCDATETIMESELECT(#78,$,$); #83=IFCCALENDARDATE(#84,#85,#86); #84=IFCDAYINMONTHNUMBER(03); #85=IFCMONTHINYEARNUMBER(11); #86=IFCYEARNUMBER(2006); #87=IFCDATETIMESELECT(#83,$,$); #88=IFCCALENDARDATE(#89,#90,#91); #89=IFCDAYINMONTHNUMBER(03); #90=IFCMONTHINYEARNUMBER(11); #91=IFCYEARNUMBER(2006); #92=IFCDATETIMESELECT(#88,$,$); #93=IFCCALENDARDATE(#94,#95,#96); #94=IFCDAYINMONTHNUMBER(03); #95=IFCMONTHINYEARNUMBER(11); #96=IFCYEARNUMBER(2006); #97=IFCDATETIMESELECT(#93,$,$); #98=IFCCALENDARDATE(#99,#100,#101); #99=IFCDAYINMONTHNUMBER(03); #100=IFCMONTHINYEARNUMBER(11); #101=IFCYEARNUMBER(2006); #102=IFCDATETIMESELECT(#98,$,$);

PAGE 135

135 #103=IFCTIMEMEASURE(115200); #104=IFCTIMEMEASURE(0); #105=IFCTIMEMEASURE(115200); #106=IFCTIMEMEASURE(0); #107=IFCTIMEMEASURE(0); #108=IFCRELASSIGNSTASKS($,$,$,$,#61,$,#12,#62); #109=IFCTASK($,#10,BBBBB,$,$,2,0,$,0,500); #110=IFCSCHEDULETIMECONTROL($,#10,$,$,$obj,#115,#120,#125,#130,# 135,#140,#145,#150,#151,#152,#153,#154,#155,TRUE,$,$,$,$); #111=IFCCALENDARDATE(#112,#113,#114); #112=IFCDAYINMONTHNUMBER(06); #113=IFCMONTHINYEARNUMBER(11); #114=IFCYEARNUMBER(2006); #115=IFCDATETIMESELECT(#111,$,$); #116=IFCCALENDARDATE(#117,#118,#119); #117=IFCDAYINMONTHNUMBER(06); #118=IFCMONTHINYEARNUMBER(11); #119=IFCYEARNUMBER(2006); #120=IFCDATETIMESELECT(#116,$,$); #121=IFCCALENDARDATE(#122,#123,#124); #122=IFCDAYINMONTHNUMBER(06); #123=IFCMONTHINYEARNUMBER(11); #124=IFCYEARNUMBER(2006); #125=IFCDATETIMESELECT(#121,$,$); #126=IFCCALENDARDATE(#127,#128,#129); #127=IFCDAYINMONTHNUMBER(06); #128=IFCMONTHINYEARNUMBER(11); #129=IFCYEARNUMBER(2006); #130=IFCDATETIMESELECT(#126,$,$); #131=IFCCALENDARDATE(#132,#133,#134); #132=IFCDAYINMONTHNUMBER(13); #133=IFCMONTHINYEARNUMBER(11); #134=IFCYEARNUMBER(2006); #135=IFCDATETIMESELECT(#131,$,$); #136=IFCCALENDARDATE(#137,#138,#139); #137=IFCDAYINMONTHNUMBER(13); #138=IFCMONTHINYEARNUMBER(11);

PAGE 136

136 #139=IFCYEARNUMBER(2006); #140=IFCDATETIMESELECT(#136,$,$); #141=IFCCALENDARDATE(#142,#143,#144); #142=IFCDAYINMONTHNUMBER(13); #143=IFCMONTHINYEARNUMBER(11); #144=IFCYEARNUMBER(2006); #145=IFCDATETIMESELECT(#141,$,$); #146=IFCCALENDARDATE(#147,#148,#149); #147=IFCDAYINMONTHNUMBER(13); #148=IFCMONTHINYEARNUMBER(11); #149=IFCYEARNUMBER(2006); #150=IFCDATETIMESELECT(#146,$,$); #151=IFCTIMEMEASURE(172800); #152=IFCTIMEMEASURE(0); #153=IFCTIMEMEASURE(172800); #154=IFCTIMEMEASURE(0); #155=IFCTIMEMEASURE(0); #156=IFCRELASSIGNSTASKS($,$,$,$,#109,$,#12,#110); #157=IFCTASK($,#10,CCCCC,$,$,3,0,$,0,500); #158=IFCSCHEDULETIMECONTROL($,#10,$,$,$obj,#163,#168,#173,#178,# 183,#188,#193,#198,#199,#200,#201,#202,#203,TRUE,$,$,$,$); #159=IFCCALENDARDATE(#160,#161,#162); #160=IFCDAYINMONTHNUMBER(14); #161=IFCMONTHINYEARNUMBER(11); #162=IFCYEARNUMBER(2006); #163=IFCDATETIMESELECT(#159,$,$); #164=IFCCALENDARDATE(#165,#166,#167); #165=IFCDAYINMONTHNUMBER(14); #166=IFCMONTHINYEARNUMBER(11); #167=IFCYEARNUMBER(2006); #168=IFCDATETIMESELECT(#164,$,$); #169=IFCCALENDARDATE(#170,#171,#172); #170=IFCDAYINMONTHNUMBER(14); #171=IFCMONTHINYEARNUMBER(11); #172=IFCYEARNUMBER(2006); #173=IFCDATETIMESELECT(#169,$,$); #174=IFCCALENDARDATE(#175,#176,#177);

PAGE 137

137 #175=IFCDAYINMONTHNUMBER(14); #176=IFCMONTHINYEARNUMBER(11); #177=IFCYEARNUMBER(2006); #178=IFCDATETIMESELECT(#174,$,$); #179=IFCCALENDARDATE(#180,#181,#182); #180=IFCDAYINMONTHNUMBER(20); #181=IFCMONTHINYEARNUMBER(11); #182=IFCYEARNUMBER(2006); #183=IFCDATETIMESELECT(#179,$,$); #184=IFCCALENDARDATE(#185,#186,#187); #185=IFCDAYINMONTHNUMBER(20); #186=IFCMONTHINYEARNUMBER(11); #187=IFCYEARNUMBER(2006); #188=IFCDATETIMESELECT(#184,$,$); #189=IFCCALENDARDATE(#190,#191,#192); #190=IFCDAYINMONTHNUMBER(20); #191=IFCMONTHINYEARNUMBER(11); #192=IFCYEARNUMBER(2006); #193=IFCDATETIMESELECT(#189,$,$); #194=IFCCALENDARDATE(#195,#196,#197); #195=IFCDAYINMONTHNUMBER(20); #196=IFCMONTHINYEARNUMBER(11); #197=IFCYEARNUMBER(2006); #198=IFCDATETIMESELECT(#194,$,$); #199=IFCTIMEMEASURE(144000); #200=IFCTIMEMEASURE(0); #201=IFCTIMEMEASURE(144000); #202=IFCTIMEMEASURE(0); #203=IFCTIMEMEASURE(0); #204=IFCRELASSIGNSTASKS($,$,$,$,#157,$,#12,#158); #205=IFCTASK($,#10,DDDDD,$,$,4,0,$,0,500); #206=IFCSCHEDULETIMECONTROL($,#10,$,$,$obj,#211,#216,#221,#226,# 231,#236,#241,#246,#247,#248,#249,#250,#251,FALSE,$,$,$,$); #207=IFCCALENDARDATE(#208,#209,#210); #208=IFCDAYINMONTHNUMBER(06); #209=IFCMONTHINYEARNUMBER(11); #210=IFCYEARNUMBER(2006); #211=IFCDATETIMESELECT(#207,$,$);

PAGE 138

138 #212=IFCCALENDARDATE(#213,#214,#215); #213=IFCDAYINMONTHNUMBER(06); #214=IFCMONTHINYEARNUMBER(11); #215=IFCYEARNUMBER(2006); #216=IFCDATETIMESELECT(#212,$,$); #217=IFCCALENDARDATE(#218,#219,#220); #218=IFCDAYINMONTHNUMBER(10); #219=IFCMONTHINYEARNUMBER(11); #220=IFCYEARNUMBER(2006); #221=IFCDATETIMESELECT(#217,$,$); #222=IFCCALENDARDATE(#223,#224,#225); #223=IFCDAYINMONTHNUMBER(06); #224=IFCMONTHINYEARNUMBER(11); #225=IFCYEARNUMBER(2006); #226=IFCDATETIMESELECT(#222,$,$); #227=IFCCALENDARDATE(#228,#229,#230); #228=IFCDAYINMONTHNUMBER(14); #229=IFCMONTHINYEARNUMBER(11); #230=IFCYEARNUMBER(2006); #231=IFCDATETIMESELECT(#227,$,$); #232=IFCCALENDARDATE(#233,#234,#235); #233=IFCDAYINMONTHNUMBER(14); #234=IFCMONTHINYEARNUMBER(11); #235=IFCYEARNUMBER(2006); #236=IFCDATETIMESELECT(#232,$,$); #237=IFCCALENDARDATE(#238,#239,#240); #238=IFCDAYINMONTHNUMBER(20); #239=IFCMONTHINYEARNUMBER(11); #240=IFCYEARNUMBER(2006); #241=IFCDATETIMESELECT(#237,$,$); #242=IFCCALENDARDATE(#243,#244,#245); #243=IFCDAYINMONTHNUMBER(14); #244=IFCMONTHINYEARNUMBER(11); #245=IFCYEARNUMBER(2006); #246=IFCDATETIMESELECT(#242,$,$); #247=IFCTIMEMEASURE(201600); #248=IFCTIMEMEASURE(0);

PAGE 139

139 #249=IFCTIMEMEASURE(201600); #250=IFCTIMEMEASURE(69120000); #251=IFCTIMEMEASURE(69120000); #252=IFCRELASSIGNSTASKS($,$,$,$,#205,$,#12,#206); #253=IFCTASK($,#10,EEEEE,$,$,5,0,$,0,500); #254=IFCSCHEDULETIMECONTROL($,#10,$,$,$obj,#259,#264,#269,#274,# 279,#284,#289,#294,#295,#296,#297,#298,#299,TRUE,$,$,$,$); #255=IFCCALENDARDATE(#256,#257,#258); #256=IFCDAYINMONTHNUMBER(21); #257=IFCMONTHINYEARNUMBER(11); #258=IFCYEARNUMBER(2006); #259=IFCDATETIMESELECT(#255,$,$); #260=IFCCALENDARDATE(#261,#262,#263); #261=IFCDAYINMONTHNUMBER(21); #262=IFCMONTHINYEARNUMBER(11); #263=IFCYEARNUMBER(2006); #264=IFCDATETIMESELECT(#260,$,$); #265=IFCCALENDARDATE(#266,#267,#268); #266=IFCDAYINMONTHNUMBER(21); #267=IFCMONTHINYEARNUMBER(11); #268=IFCYEARNUMBER(2006); #269=IFCDATETIMESELECT(#265,$,$); #270=IFCCALENDARDATE(#271,#272,#273); #271=IFCDAYINMONTHNUMBER(21); #272=IFCMONTHINYEARNUMBER(11); #273=IFCYEARNUMBER(2006); #274=IFCDATETIMESELECT(#270,$,$); #275=IFCCALENDARDATE(#276,#277,#278); #276=IFCDAYINMONTHNUMBER(28); #277=IFCMONTHINYEARNUMBER(11); #278=IFCYEARNUMBER(2006); #279=IFCDATETIMESELECT(#275,$,$); #280=IFCCALENDARDATE(#281,#282,#283); #281=IFCDAYINMONTHNUMBER(28); #282=IFCMONTHINYEARNUMBER(11); #283=IFCYEARNUMBER(2006); #284=IFCDATETIMESELECT(#280,$,$); #285=IFCCALENDARDATE(#286,#287,#288); #286=IFCDAYINMONTHNUMBER(28);

PAGE 140

140 #287=IFCMONTHINYEARNUMBER(11); #288=IFCYEARNUMBER(2006); #289=IFCDATETIMESELECT(#285,$,$); #290=IFCCALENDARDATE(#291,#292,#293); #291=IFCDAYINMONTHNUMBER(28); #292=IFCMONTHINYEARNUMBER(11); #293=IFCYEARNUMBER(2006); #294=IFCDATETIMESELECT(#290,$,$); #295=IFCTIMEMEASURE(172800); #296=IFCTIMEMEASURE(0); #297=IFCTIMEMEASURE(172800); #298=IFCTIMEMEASURE(0); #299=IFCTIMEMEASURE(0); #300=IFCRELASSIGNSTASKS($,$,$,$,#253,$,#12,#254); #301=IFCRELSEQUENCE($,$,$,$,#109,#61,0,#FINISH_START); #302=IFCRELSEQUENCE($,$,$,$,#157,#109,0,#FINISH_START); #303=IFCRELSEQUENCE($,$,$,$,#205,#61,0,#FINISH_START); #304=IFCRELSEQUENCE($,$,$,$,#253,#157,0,#FINISH_START); #305=IFCRELSEQUENCE($,$,$,$,#253,#205,0,#FINISH_START); ENDSEC;

PAGE 141

141 LIST OF REFERENCES Alonso, G., Casati, F., Kuno, H., Machiraju, V. (2004), Web Services, Concepts, Architecture and Applications, Springer, Berlin Alshawi, M., Ingirige, B. (2003), “Web Enabled Project Management: An Emerging Paradigm in Construction” Automation in Construction 12(4): 349-364. Anumba, C.J., Amor, R. (1999) “A Survey and Analysis of Integrated Project Databases,” Proceedings of Concurrent Engineering in Construction'99, Espoo, Finland, 25-27 August, pp. 217-228 Brandon, P., and Betts, M. (1997). “Creating a Framework for IT in Construction.” The Armathwaite Initiative, The Formation of a Globa l Construction IT network, Construct IT Centre of Excellence, Salford, U.K. "Industry as a Partner for Su stainable Development: Constr uction", Confederation of International Contractors' Association. http://alcor.concordia.ca/~raojw /crd/reference/reference001380.html Date accessed, 4/4/2005 Constructionweblinks (2005). U. S. Construction, Architecture and Engineering Industry: An Overview for International Investors http://www.constructionweblinks.com/Resour ces/Industry_Reports__N ewsletters/Feb_2_2004/u s_investors.htm , Date accessed, 4/4/2005 Crowley, A.J., Watson, A.S. (2000). “Volume 1Overview” CIMsteel In tegration Standards Release 2, Steel Constructi on Institute, Berkshire. Dawood N., Akinsola A., and Hobbs B. (2002). “Development of Automa ted Communication of A System for Managing Site Information us ing Internet Technology” Automation in Construction, 11 (5) 557-572 Deng, Z. M., Li H., Tam C. M., Shen, Q. P., Love, P. E. D. (2001). “An Application of the Internet-based Projec t Management System”, Automati on in Construction, 10 (2) 239-246 Eastman, C.M. (1999). Building Product Models : Computer Environments Supporting Design and Construction, CRC Press, Boca Raton. Esposito, D. (2003), Programm ing Microsoft ASP.NET, Microsoft Press, Redmond Froese, T. (1992), “Integrated Computer-Aided Project Management through Standard ObjectOriented Models,” Ph.D. Thesis, Dept. of Ci vil Engineering, Stanford University, 1992. Froese, T. (1995), “Core Process Models and Application Areas in Construction”, Presented at CIB W78/TG10 Workshop, "Modeling of Buildings through Their Life-cycle," Stanford University, August 21-23 1995. Pages 427-436.

PAGE 142

142 Froese, T. (1996). “Models of Construction Proce ss Information,” Journal of Computing in Civil Engineering, 10(3), 183-193. GotDotNet (2005), Introducing XML Web services, http://samples.gotdotnet.com/quickstar t/aspplus/doc/webse rvicesintro.aspx , Date accessed January 5, 2006. Howard, H.C., Levitt, R.E., Paulson, B.C., Pohl, J.G., Tatum, C.B., (1989) “Computer Integration: Reducing Fragmentation in the AE C Industry,” Journal of Computing in Civil Engineering 3, 18– 31. IAI. (2000). “IFC Technical Guide” Intern ational Alliance for Interoperability. < http://www.iaiinternational.org /iai_international/T echnical_Documents/documentation/IFC_2x_ Technical_Guide.pdf > Date accessed 09 April 2004. IAI. (1997). “IAI and STEP,” http://cig.bre.co.uk /iai_uk/iai/page8.htm# The IAI and STEP, Date accessed January 5, 2006. Potts, S., Kopack M., (2003) “SAMS Teach Y ourself Web Services in 24 Hours,” Sams Publishing, Indianapolis, Indiana. Lachmi, K., (2003) “The IFC Build ing Model: A Look Under the Hood,” http://www.aecbytes.com/f eature/2004/IFCmodel.html Date accessed, January 5, 2006. Luiten G., Froese T., Bjoerk B-C., Junge R., Ka rstila K. and Oxman R. (1993). “An information reference model for architecture, engineering an d construction,” In Mathur K.S., Betts M.P., Tham K.W. edts. Management of Information Technology for Constructi on, World Scientific & Global Publication Serv ices, Singapore, 391-406. NIST., (1999) “What is STEP,” http://cic.nist.gov/plantstep/stepinfo/step_def.htm Date accessed, January 5, 2006. Papazoglou, M. P., Dubray, J., (2004) A Survey of Web Service Technologies, White Paper Rnneblad A and Olofsson T (2003) Applicatio n of IFC in design and production of precast concrete constructions, ITcon Vol. 8, Special I ssue IFC Product models for the AEC arena, pg. 167-180 Sheth and Kashyap, (1992). “So Far Sche matically yet So Near Semantically, ” Proceedings of the IFIP TC2/WG2.6, pp. 283-312, 1992 T. Cornick(1990), Quality Management for Building Design, Butterworth Architecture Management Guides, 1990 U.S. Census Bureau (2005). http://www.census.gov/const/C30/total.pdf , Date accessed, April 4, 2005.

PAGE 143

143 W3C., (2002). "Web Services Description Lang uage (WSDL) Version 1 .2, W3C Working Draft" http://www.w3.org/TR/2002/ WD-wsdl12-20020709/#intro Date accessed August 9, 2006. Walther S., (2003). ASP.NET Unleashed, Sa ms Publishing, Indianapolis, Indiana

PAGE 144

144 BIOGRAPHICAL SKETCH Mark O. Danso-Amoako is an internationa l student from Ghana in West Africa. He received his Bachelor of Scien ce degree in building technology at the University of Science and Technology in Ghana. After graduati on he served as a junior lectur er at this university for one year where he lectured in strength of materials and theory of structures. He then went on to work in the construction industry for a multinational comp any for 2 years as a site engineer/estimator. During his involvement with the construction of a 400-million-dollar thermal power project, his interest in a better day-to-day management of construction proj ects with computer application developed. In his quest to provi de much-needed expertise in computer application in managing projects, he decided to pursue a dvanced studies in this area. It was a dream come true when he was offered admission to the M.E. Rinker Sr. Sch ool of Building Construction at the University of Florida to pursue a master’s degree in building construction. After receiving a master’s degree in building construction, he al so pursued two concurrent degrees, a Ph.D. in construction management and a masters in computer science. Th e years spent at the University of Florida has fulfilled his dream, and he is now in a better position to apply his knowledge effectively to Ghana’s young construction industry when he returns home