Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Computer Integrated Construction based on Total Project Systems Framework Yu, Kevin Qiang 2002

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

Item Metadata

Download

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

Full Text

C O M P U T E R INTEGRATED CONSTRUCTION B A S E D ON TOTAL P R O J E C T S Y S T E M S F R A M E W O R K BY KEVIN QIANG Y U B.E., Northern JiaoTong University, 1987 M A . S c , The University of British Columbia, 1995 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE R E Q U I R E M E N T S FOR THE D E G R E E OF D O C T O R OF PHILOSOPHY in THE F A C U L T Y OF G R A D U A T E STUDIES D E P A R T M E N T OF CIVIL ENGINEERING, CONSTRUCTION ENGINEERING AND M A N A G E M E N T We accepM=ti^jiisseTtaTi»n as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA March 21, 2002 ©Kevin Qiang Yu, 2001 In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of The University of British Columbia Vancouver, Canada Abstract The AEC/FM industries are characterized as having many sectors of different disciplines that are involved in different domain phases throughout the lifecycle of construction projects. In these projects, many participants from different firms use different types of computer applications to design and manage the projects. These applications generate and utilize an enormous amount of project information at different abstraction and detail levels. Computer Integrated Construction (CIC) is a vision of computer tools interoperating freely with the capability to access, share and exchange project information, to invoke or request domain services, and to send notifications across all stages of AEC/FM projects. This research is of interest in the field of CIC and is intended to provide solutions of information technologies (IT) for CIC. To date, various information technologies have been developed for AEC/FM, while each is at a different stage and they are not integrated. To push these IT tools to a point of "critical mass", this research proposes the idea of "Total Project Systems (TOPS)". TOPS represent a class of computer systems that are intended to streamline the IT approaches by interoperating various AEC/FM applications and integrating project information towards the goal of CIC. TOPS-based systems are defined by the following characteristics: comprehensive and interoperable applications, extensive data integration, and extensive system flexibility. TOPS call for five fundamental elements, each dealing with a set of technologies: Comprehensive Applications, Systems Architectures, Information Models, Information Content, and Work Practices. The goal of this thesis is to contribute to establishing two of the cornerstone TOPS technologies -Systems Architectures and Information Models. The research deliverables include: • TOPS Reference Architectural Framework: including a set of conceptual system components for designing and implementing integrated and distributed systems. • A set of conceptual implementation models: representing common data requirements and support data exchanges for various AEC/FM applications. • Prototype computer systems using TOPS technologies: involving various AEC/FM applications that access, exchange and share common project information. It is believed that this research makes considerable contributions to future research and development of IT solutions for the AEC/FM industries. UBC Page ii Yu, K TABLE OF CONTENTS Abstract ; i i Table of Contents iii List of Figures viii List of Tables xi Acronyms xii Acknowledgement xiii Chapter 1: Introduction 1 1.1. The CIC Vision 2 1.2. IT in Construction - Past, Present, and Future 2 1.3. Goals and Objectives 5 1.4. Research Scope 5 1.5. Research Premises 6 1.6. Research Methodology .7 1.7. Reader's Guide ....••9 Chapter 2: Points of Departure 10 2.1. Computer Integrated Construction 10 2.2. Information Models for A E C / F M 11 2.2.1. International Alliance for Interoperability 11 2.2.2. ISO-STEP 11 2.2.3. Various A E C / F M Information Models 12 2.3. System Architectures 12 2.3.1. The ICC System 12 2.3.2. CIFE's Sequus Project 14 2.3.3. Microsoft Repository 15 2.3.4. Microsoft Windows DNA Architecture 16 2.3.5. RosettaNet 17 2.3.6. ProjectBank DGN 19 2.4. Chapter Conclusion 20 Chapter 3: Total Project Systems Framework 21 3.1. Total Project Systems (TOPS) 21 3.1.1. T O P S Philosophy 21 3.1.2. T O P S Characteristics 22 3.1.3. T O P S Elements 23 3.1.4. T O P S Data Integration Scenarios 24 UBC Page iii Yu, K 1 3.1.5. T O P S Application Interoperability Scenarios 26 3.2. T O P S Reference Architectural Framework (RAF) 30 3.2.1. Reference Architectural Framework (RAF) 30 3.2.2. Design Considerations 31 3.2.3. T O P S RAF Overview 34 3.2.4. T O P S RAF Layers 36 3.2.4.1. Project Model Serv ices Layer 36 3.2.4.2. Domain Serv ices Layer 38 3.2.4.3. Project Model Proxy Serv ices Layer 40 3.2.4.4. Project Maintenance Serv ices Layer 41 3.2.4.5. Appl icat ions Layer 41 3.2.5. T O P S RAF Threads 42 3.2.5.1. Standard Information Mode ls 42 3.2.5.2. Standard Software Interfaces 43 3.2.5.3. Adapters 43 3.2.6. Design Principles 44 3.2.7. Configuration Variations 44 3.3. Chapter Conclusion 45 Chapter 4: Information Models for AEC/FM 46 4.1. Context of Information Modeling 46 4.1.1. Modeling Object Aspects 47 4.1.2. Modeling Conceptual Models 51 4.1.3. Modeling Large-Scale Domain Conceptual Models 53 4.1.4. Modeling Processes and Domain Transactions 55 4.2. Domain Conceptual Models for A E C / F M 56 4.2.1. Challenges for Modeling A E C / F M Objects 56 4.2.2. Industry Foundation Classes (IFCs) 56 4.2.3. ISO-STEP 57 4.2.4. Various A E C / F M Conceptual Models 58 4.2.5. A E C / F M Standard Process Models 59 4.2.6. A E C / F M X M L Schemas 60 4.3. Industry Foundation Classes (IFCs) 61 4.3.1. Introduction to IAI 61 4.3.2. IFC Architecture and Development Methodology 61 4.3.3. IFC Models for Project Management 64 UBC Page iv Yu, K 4.3.4. Product and Cost Estimating Integration 64 4.3.5. Cost and Scheduling Integration 70 4.3.6. Project Management Related Classes in IFC 2x 75 4.3.7. Current Status of IFCs 79 4.4. Chapter Conclusion 80 Chapter 5: Data Integration and Application Interoperability 81 5.1. Data Integration 81 5.1.1. Application Data Scheme 82 5.1.2. Direct Data Exchange 83 5.1.3. Standard Project Exchange Data ...84 5.1.4. Shared Project Data Store 86 5.1.5. Data Mapping Schemes 89 5.1.6. Meta-models 93 5.2. Application Interoperability 96 5.2.1. Direct Service Request 96 5.2.2. Service Provider Server 96 5.2.3. Service Broker and Registration 97 5.2.4. Message-based APPI 97 5.2.4.1. M e s s a g e Server and Dispatch 98 5.2.4.2. M e s s a g e Server and Container 98 5.2.5. Transaction-based APPI 99 5.2.5.1. Server -based Transact ions 100 5.2.5.2. Distributed Application Transact ions 100 5.3. Chapter Conclusion 101 Chapter 6: TOPS Framework Components 102 6.1. Project Model Services 102 6.1.1. Project Data Storage 103 6.1.2. Project Data Services 104 6.1.3. Meta-data Storage 105 6.1.4. Meta-data Services 106 6.1.5. Project Model Servers 106 6.2. Domain Functional Services 108 6.2.1. Domain Transactional Process Services 108 6.2.2. Domain Message Control Services 110 6.2.3. Domain Application Services 110 UBC Page v Yu, K 6.2.4. Domain Functional View Services 111 6.3. Project Model Proxy Services 112 6.3.1. Proxy Manager 113 6.3.2. Proxy Project Model 113 6.3.3. Proxy Data Adapters 113 6.4. Project Maintenance Services 114 6.4.1. Project Session Services 114 6.4.2. Project Registration Services 114 6.4.3. Presentation Services 115 6.5. Applications and Adapters 115 6.5.1. Project Model-based Integration 115 6.5.2. File-based Data Integration 117 6.5.3. Application-based Data Integration 118 6.5.4. Transaction-based Interoperability 118 6.5.5. Message-based Interoperability 119 6.5.6. Direct API Interoperability 119 6.5.7. Web Applications 120 6.6. Chapter Conclusion 120 Chapter 7: Implementation and Validation 121 7.1. Overall Process 121 7.2. Application Implementation 122 7.2.1. IWPM Prototype 122 7.2.1.1. IWPM Architecture 122 7.2.1.2. IWPM Applications 123 7.2.1.3. IWPM Components 123 7.2.1.4. IWPM Usage Scenario 123 7.2.2. Jigsaw Project 124 7.2.2.1. Jigsaw Architecture 124 7.2.2.2. Jigsaw Components..: 125 7.2.2.3. Jigsaw AEC/FM Applications 127 7.2.3. T O P S Prototype (TOPSPro) 128 7.2.3.1. TOPSPro Functionality 128 7.2.3.2. TOPSPro Architecture 129 7.2.3.3. TOPSPro Usage Scenario 131 7.2.4. Precision Estimating CAD 134 UBC Page vi Yu, K 7.2.4.1. PECAD Functionality 134 7.2.4.2. PECAD Architecture 135 7.2.4.3. PECAD Usage Scenario 136 7.3. Validation 142 7.3.1. Validation Criteria 142 7.3.2. Validation Results 142 7.4. Chapter Conclusion 145 Chapter 8: Conclusions 146 8.1. Summary 146 8.2. Contributions 147 8.3. Future Work 148 References 149 Appendix A: Functional Categories for Project Management 154 Appendix B: Project Documents 155 Appendix C: Data Topics for Project Management 156 Appendix D: TOPS RAF 157 UBC Page vii Yu, K LIST OF FIGURES Figure 1: IT in Construction 3 Figure 2: TOPS Research Threads 7 Figure 3: The ICC System Architecture 13 Figure 4: Sequus Software Tools and Integration Processes 14 Figure 5: MS Repository Architecture 15 Figure 6: Windows DNA Architecture 16 Figure 7: RosettaNet Scope 18 Figure 8: RosettaNet Architecture 18 Figure 9: TOPS Elements 23 Figure 10: TOPS Element Relationships 24 Figure 11: Interactive Workspace (Froese, et al 2000) 27 Figure 12: Cost Estimating Transaction Example 29 Figure 13: File-based Data Exchange ,.31 Figure 14: Project Model-based Integration 32 Figure 15: Domain Transactional Process Integration 33 Figure 16: Conceptual View of TOPS 34 Figure 17: TOPS RAF Layers 36 Figure 18: Project Model Services Layer 37 Figure 19: Domain Services Layer 38 Figure 20: Domain Functional View Example 40 Figure 21: Project Model Proxy Services Layer 40 Figure 22: Project Maintenance Services Layer 41 Figure 23: TOPS RAF Threads 42 Figure 24: Generic Object Interfaces 43 Figure 25: Data Representation Scheme 47 Figure 26: Object Aspects 48 Figure 27: Conceptual Model Language Support 52 Figure 28: STEP Development Methodology 57 Figure 29: IFC Architecture 62 Figure 30: IFC Development Steps 63 Figure 31: Cost Estimating Process 66 UBC Page viii Yu, K Figure 32: Basic IFC Cost Model 67 Figure 33: IFC Object Cost Model 69 Figure 34: Schedule Process Model 70 Figure 35: Process for Estimating and Scheduling Integration (abridged process)71 Figure 36: IFC Process and Work Plan Model 72 Figure 37: IFC Process Nesting Model 73 Figure 38: IFC Model for Process and Product Association 74 Figure 39: IFC Construction Resource Model 74 Figure 40: Resource Usage 75 Figure 41: Project Management Classes in IFC 2.X 76 Figure 42: Application Data Scheme (ADS) 82 Figure 43: Direct Data Exchange (DDE) 83 Figure 44: Direct Data Exchange Components 83 Figure 45: Standard Project Exchange Data (SPED) 85 Figure 46: Shared Project Data Store (SPDS) 86 Figure 47: Shared Project Data Store Components 87 Figure 48: Data Mapping based on Same Model 90 Figure 49: Data Mapping Based on Same PDFL 91 Figure 50: Data Mapping based on Same Modeling Language and PDFL 92 Figure 51: Basic Meta-model Scheme 94 Figure 52: Meta-model Mapping Implementation Sample 95 Figure 53: Direct Service Request 96 Figure 54: Service Provider Server 96 Figure 55: Service Broker and Registration 97 Figure 56: Message Server and Dispatch (MSD) 98 Figure 57: Message Server and Queue (MSQ) 99 Figure 58: Server-based Transactions (SBT) 100 Figure 59: Distribute Application Transactions (DAT) 100 Figure 60: Project Model Server 102 Figure 61: Project Data Storage and Data Services 103 Figure 62: Meta-data Storage and Meta-data Services... 105 Figure 63: Project Model Servers 106 Figure 64: Project Model Utility 106 Figure 65: Domain Object Server 107 UBC Page ix Yu, K Figure 66: Domain Transactional Process Services 108 Figure 67: Domain Message Control Services 110 Figure 68: Domain Application Servers 111 Figure 69: Domain Functional View Services 112 Figure 70: Project Model Proxy Services 112 Figure 71: Project Maintenance Services 114 Figure 72: Applications and Adapters 116 Figure 73: Project Model-based Integration 116 Figure 74: File-based Data Integration 117 Figure 75: Application-based Data Integration 118 Figure 76: Transaction-based Interoperability 118 Figure 77: Message-based Interoperability 119 Figure 78: Direct API Interoperability 120 Figure 79: IWPM Architecture 122 Figure 80: Jigsaw Architecture 124 Figure 81: Jigsaw APIs 124 Figure 82: Jigsaw Components 126 Figure 83: TOPSPro Architecture 129 Figure 84: TOPSPro and PECAD Usage Scenario 131 Figure 85: 4D-Enabler Usage Scenario 132 Figure 86: IPB Usage Scenario 133 Figure 87: PECAD Architecture 135 Figure 88: PE Mapper Usage Scenarios 136 Figure 89: PE Mapper Details 137 Figure 90: PECAD Usage Scenario 139 Figure 91: PECAD Object Takeoff 140 Figure 92: PECAD Object Cost Items 141 UBC Page x Yu, K LIST OF TABLES Table 1: TOPS Functional Scope Examples 25 Table 2: Understanding The TOPS RAF 35 Table 3: A Sample For Object Aspects 50 Table 4: Computer Language Support For Object Aspects 50 Table 5: IFC Project Management Models 65 Table 6: IfcProcessExtension Schema 78 Table 7: ADS Example 82 Table 8: Data Mapping Example 90 Table 9: Domain Applications Supported 143 Table 10: Application Types Supported 143 UBC Page xi Yu, K Acronyms Common Acronyms AEC: Architecture, Engineering and Construction Management. B2B: Business-to-Business B2C: Business-to-Consumers E-Commerce: Electronic Commerce. E-Business: Electronic Business. CIC: Computer-integrated Construction CM: Construction Management COM: Component Object Model COM+: Component Object Model Plus CORBA: Common Object Reference Broker Architecture FM: Facilities Management I Al: International Alliance for Interoperability IFC: Industry Foundation Classes IT: Information Technologies ISO: International Standard Organization MS DNA: Microsoft Distributed interNet Application PM: Project Management SOAP: Simple Object Access Protocol SDAI: Standard Data Access Interfaces STEP: Standard for the Exchange of Product Model Data XML: Extensible Markup Language Thesis Specific Acronyms ADS: Application Data Schema APPI: Application Interoperability DAS: Domain Application Services DBCM: Domain-based Conceptual Model DDE: Direct Data Exchange DEAS: Data Exchange, Access, and Sharing Dl: Data Integration DMC: Domain Message Control DTP: Domain Transactional Process LSDCM: Large-Scale Domain Conceptual Model PDAF: Physical DAta Format PDFL: Physical DAta Format Language PMP: Project Model Proxy RAF: Reference Architectural Framework SIM: Standard Information Model SPDS: Shared Project Data Store SPED: Standard Project Exchange Data TOPS: TOtal Project Systems UBC Page xii Acknowledgement This thesis is the culmination of nearly six years of effort combined with industry experiments and commercial software developments. I have received support in my work from many people whom I can never thank enough. First of all, I wish to express my sincerest gratitude to my supervisor, Thomas Froese. From the day he picked me as his first Ph.D. student, fortune has seemed to follow me all the way throughout my journey of AEC/FM technology adventures. I feel so fortunate to have received his guidance and teaching. His exceptional research experience and expertise in the area have provided sources of knowledge and streams of ideas. His visions have broadened and enlightened my thinking. His dedication to career, approaches, and contagious zeal for scholarship set the standard for academics. Thomas has also provided superb mentorship for me, not only for the work we do together, but also in life. Thank you, Tom! One of the finest professors that I have ever had the pleasure of learning from, Alan Russell, defines the context of research, which ensures the quality of the work I have done. I would also like to thank two other members of my supervisory committee, Prof. Carson Woo and Prof. Hugues Rivard. Their willingness to spend their time reviewing my work inspired me to finally complete the program. They provided invaluable contributions to this research work through their detailed comments and sources of references. I would like to express additional appreciation to other examiners of my Ph.D. program, including Prof. Ghassan Aouad, Prof. Laks Lakshmanan, Prof. Richard Anstee, and Prof. Siegfried Stiemer. Also, many thanks to my friends at the University of British Columbia and many colleagues around the world in the industry. I feel fortunate to have met a very diverse group of individuals, collaborate with some, reflect with others, and learn from all. Specific thanks to Mike Cole, my colleague at Timberline Software, who has provided moral support and has been a true friend. He contributed a great deal to my research work including his expertise in software engineering, his managerial support for my work, and his reviews of my thesis drafts. I also wish to acknowledge the absolute support of my mother and father and thank them for always being proud of me and for always asking me how things are progressing. To my little sister, Luna, thanks for having never doubted me in my ability to accomplish this and for never questioning that I would be a Ph.D. one day - it was invaluable encouragement. Finally, my most special appreciation goes to my wife, Ying, who has always supported and encouraged me in whatever adventure I decided to take. Her never complaining about the countless weekends we have missed has been a big part of my success in this endeavor. Now, we'll have more time to have fun, I hope. Thank You Al l ! UBC Page xiii Yu, K Chapter 1: Introduction The research of this dissertation is of interest in the field of applied information technologies (IT) in the architecture, engineering, construction, and facilities management (AEC/FM) industries, namely Computer Integrated Construction (CIC). CIC is a generally accepted term used to convey the notion that all software applications interoperate to access, exchange, and share project information across all stages of A E C / F M projects. The A E C / F M industries are characterized as having many sectors of multiple disciplines that are involved in different phases throughout the lifecycle of construction projects. In these construction projects, there are many different types of computer tools used by many project participants from different firms to assist in project design and management processes. These processes generate and utilize an enormous amount of project information from different sources at different abstraction and detail levels. Logically, the efficiency and integrity of these processes rely on the capabilities of the software tools to manage, access, exchange, and share the project information, and to supply, request, and employ domain functional services. Supported by the software tools with these capabilities, CIC can become a reality. Numerous CIC related research and development efforts have resulted in implementation proposals and commercial applications. Various general computing technologies are advancing faster the ever before. Nevertheless, to date, no practical solutions for CIC exist and the general implementation direction of CIC is covered in cloud. Various A E C / F M technologies seem to be approaching a "critical mass", but each is at a different stage and they are not connected or integrated. The degree of application fragmentation today for the A E C / F M industries is still significant. To push the computer tools advance towards this critical mass, Froese, Rankin, and Y u (1997a) proposes Total Project Systems (TOPS) that are intended to streamline all of the approaches and applications to interoperate and integrate construction project information towards the goals of CIC. TOPS represent a class of integrated and distributed A E C / F M computer systems that enable all of the computer tools to operate with the capability of data integration and application interoperability supporting the CIC environment. TOPS-based systems are defined by the following characteristics: comprehensiveness - they include a suite of sophisticated applications that support a broad range of domain functions; Extensive Data Integration - a state in which all applications both contribute to and draw from a common pool of project information represented as shared project models; Application Interoperability - applications can be "plugged in and play" at any time, and they can easily invoke and request services by directly sending messages and notifications; Extensive Flexibility - they operate, interface, communicate, and install in a highly flexible, open, modular, dynamic, and distributed environment rather than in a restrictive and prescriptive manner (Froese et al. 1997a, 1997b). TOPS call for five fundamental elements: Comprehensive Applications, Systems Architectures, Information Models, Information Content and Work Practices. Each of these elements deals with a set of technologies required to build TOPS-based applications. This research adopts the idea of Total Project Systems (TOPS) and strives to contribute to building up two of the cornerstone technologies—Information Models and Systems Architectures. The research introduces the idea of a Reference Architectural Framework (RAF) that supports the systems architectural design and development of TOPS applications, and it explores various relevant technological issues in these fields. UBC Page 1 Yu, K 1.1. The CIC Vision Computer Integrated Construction (CIC) employs information technologies (IT) applied to the architecture, engineering, construction and facilities management (AEC/FM) industries. IT have been the predominant driving forces for improving the A E C / F M industries by their influence on the work practices of design and project management processes. The following aspects characterize the vision of CIC: • A l l applications used by all project participants exchange and share project information, which is persisted on storage implemented using different and distributed devices. • The project information is comprehensive, including complete building product models, product costs, construction resources, processes, and methods, and project control documents such as schedules, estimates, and change orders, as well as data outside of projects, e.g. libraries of product types. • A l l applications communicate to invoke and request domain functional services (i.e. domain design, management, or business processes) from other applications. • A l l applications reside at different places in a distributed environment, running on different platforms. 1.2. IT in Construction - Past, Present, and Future During the past two decades, IT in A E C / F M has progressed through many different technological stages and application areas. Today, the industries are at a point where widely available technical approaches and applications are at different stages and are fragmented, yet great opportunities for CIC solutions exist. Froese (1999) presents a recent history and near future prediction of trends in IT technologies for the A E C / F M industries, as illustrated in Figure 1. A E C / F M IT Solutions Established technologies specifically for A E C / F M functions include 2D (i.e. 2 Dimensional) C A D , 3D (i.e. 3 Dimensional) C A D , and other typical construction management applications such as cost estimating and scheduling. The object-oriented implications of 3D C A D have established the role of "building product models" for design and management in building projects. These models, once implemented appropriately, can serve as data sources for multiple applications to share and exchange product information. Application integration is also recognized as one main trend of improved use of A E C / F M programs and project information. However, most of these integrations of commercial applications are two-way integrations, which typically involve proprietary solutions between two software vendors. Since CIC calls for the integrations among all A E C / F M applications, the two-way integrations are essentially temporary solutions. This requires that complete project information, rather than only the product models, be represented in a neutral data format. This, in turn, calls for a new trend of emerging technology - Project Model Standards, such as the International Alliance for Interoperability's (IAI's) Industry Foundation Classes (IFCs), are structured based on, and extend beyond the scope of, Product Model Standards. These standards are commonly accepted software object representations or programming interfaces, and they can be adopted and supported by domain software applications for the purpose of representing real-world objects and exchanging domain information between the applications. These standards could be de facto technologies invented by certain but usually a major domain application. They could also be developed or recommended by a high level organization such as ISO (ISO 1991) or IAI. While these technologies are maturing significantly, and some innovators have started implementing them in commercial systems, they have not become mainstream CIC solutions due to many unresolved technical obstacles. UBC Page 2 Yu, K UBC Page 3 Yu, K Related AEC/FM Trends Other industry-related trends include process improvements for construction projects, such as total quality management, lean construction, process re-engineering, and so on. While these technologies are not information technologies, they generally require formalized definitions of construction processes, which are manifested in an IT perspective as process modeling. Once process models are incorporated with the project models in a formal approach, they can lead to an exciting new application area, Process Design Tools. These tools assist construction process designs involving detailed information about the buildings being constructed, and so on by allowing users to explore and interlink a wide variety of construction project information. General IT Solutions The past decade has seen an explosion of general IT including general database management systems, software component technologies such as COM (Rogerson 1997) or CORBA (Vinoski 1997), and the Internet. These technologies profoundly influence the IT uses in developing AEC/FM solutions forming the fundamental technologies for distributed systems. The most noticeable deployments of these technologies are the Web-based construction management systems, namely "dot.COM's". The latest advancement of Internet applications calls for generic data representation standards, for example, X M L . These standards, in conjunction with standard project information models, will lead to more interoperable and easier-to-implement industry-specific data formats. Status of AEC/FM IT Solutions Many of the technologies discussed above keep advancing in functionality following their threads. However, none of them alone provides a complete solution for the objectives of CIC. Additionally, these applications do not exchange or share project data in a seamless manner, nor do they interoperate in a highly dynamic fashion. The different stages, disconnections, and various proprietary approaches of these applications manifest the challenges of today's IT uses in construction. Future IT Solutions It is believed that at some point, some integrated systems capable of linking all these applications using standard technological foundations such as standard project models will emerge. Such systems are called "Total Project Systems (TOPS)" in our research. TOPS are an attempt to push computer tools past the point of "critical mass" where broadly applicable computational models become the primary vehicle for practicing construction management. As presented previously, TOPS are defined by the characteristics of comprehensiveness, extensive data integration, application interoperability, and extensive flexibility. UBC P a g e 4 Yu, K 1.3. Goals and Objectives The research of this dissertation is directed by the goals and objectives as stated in this section. These goals and objectives are determinative for the scope of the research. Goals The ultimate goal is to push computer tools used in A E C / F M projects past the point of "critical mass" of different IT stages towards the state of CIC. The immediate goal of this research is to provide solutions for key technologies (namely system architectures and information models) required by Total Project Systems (TOPS) that are proposed for enabling all A E C / F M applications to implement advanced technologies and to take part in highly integrated, distributed, and dynamic CIC environment. Objectives The following are several objectives for this research: • Contribute to the TOPS approach by developing required technological elements and characteristics. • Extensive research and development of the Reference Architecture Framework (RAF) as a major contribution to one of the primary technological elements of TOPS and to the general field of distributed computer systems architectures. • Extensive research and development of A E C / F M information models as a major contribution to one of the primary technological elements of TOPS and to the general field of A E C / F M information models and modeling. 1.4. Research Scope To achieve the goals and fulfill the objectives, the deliverables of the research are as follows: • A comprehensive Reference Architecture Framework (RAF) consisting of a set of conceptual system components for designing and implementing integrated and distributed systems. • A set of conceptual Implementation Models that represent common data requirements and support data exchanges for various A E C / F M applications. • A prototype computer system using TOPS technologies that involve various A E C / F M applications, accessing, exchanging and sharing common project information and interconnecting and communicating with each other to request and utilize functional services and pass project related messages. As stated earlier, the scope of TOPS research is a large one. Some technical issues related to establishing TOPS are not covered in this research. The subjects that are considered out of scope in the context of this research are listed below: TOPS Technological Elements: • Specific functionality of A E C / F M domain applications • Work practices for TOPS technologies • Information content for TOPS technologies UBC Page 5 Yu, K Network Issues: • Generic network and client-server architectures (e.g. network protocols, etc.) • Generic network and client-server system issues (e.g. security, scalability, etc.) • Generic data transactions General System Issues: • Installation servers (e.g. software engines that enable automatic installations of add-on components at runtime.) • Data driver (e.g. software components that serve for connecting different types of runtime data through standard API or Ul , such as ODBC drivers.) • Security control components (e.g. software components that provide data or functional access controls to other components or users.) Software Programming Issues: • Database management systems (DBMS) • General application programming interfaces (API) issues • Specific implementation approaches, mechanisms, or tools 1.5. Research Premises This research is built upon previous work in which the research premises are established. Figure 2 illustrates these research threads. Previous CIC Research The earliest research efforts for CIC primarily focus on domain information models (Froese 1996). These research efforts produced a large knowledge base including many good example AEC/FM models and modeling methodologies. However, most of the information models developed are implemented in highly simplified systems as 'proof of concept' prototypes. As a result, these models only demonstrate partial solutions for CIC. While they provide foundations for further research in this arena, substantial research work is needed to achieve the objectives of CIC. Understanding the CIC Challenges Russell and Froese (1997) refine the context of CIC and identify implementation challenges of CIC. In that research, in addition to information models, systems architectures and comprehensive AEC/FM applications are recognized as essential elements for the goal of CIC. This work suggests further research directions founded on the research work on information models. The TOPS Approach Based on these efforts, Froese, Rankin, and Yu (1997) propose the idea of Total Project Systems (TOPS) supporting various CIC system characteristics and all three identified technological elements: information models, systems architectures, and applications. This work sets the starting point for the research in this dissertation. UBC Page 6 Yu, K This Ph.D. Scope l Future Research Figure 2: TOPS Research Threads The Research Focus The actual research focuses of this dissertation are given to information models and systems architectures contributing to TOPS. For the information modeling work, we have also participated in the largest standardization effort for domain information models, the IAFs IFCs, to ensure general adoption of our research results to real software implementations. Our research in the TOPS architecture is initially proposed in Froese and Yu (2000), in which a preliminary architecture framework is presented. This dissertation explores the architecture issues for TOPS in full detail. Future Research Our recent research also identifies two more essential elements for TOPS: Information Content (at the project, company, and industry level) and Work Practices, as they relate to TOPS systems. Although detailed research in these areas is not conducted in this dissertation, they suggest future research directions in achieving the ultimate goal of CIC. 1.6. Research Methodology The methodologies for this research are established based on the logic implied in the research premises, fulfilling the research goals and objectives. UBC Page 7 Yu, K General Research Methodologies As a starting point, the goal of CIC is defined. This includes the clear vision that AEC/FM applications are able to access, exchange, and share project information (i.e. Data Integration, or DI) and to operate, communicate, interconnect, request and execute domain functional services (i.e. Application Interoperability, or APPI) in a highly flexible, dynamic and distributed computing environment. The second step taken is to propose a class of computer systems directly fulfilling the requirements and objectives of CIC. Unlike other research efforts that target on some specific technologies (such as information models), providing partial remedies to CIC, this approach intends to offer a thorough and corporeal solution that can be directly implemented to enable existing AEC/FM applications to achieve the goal of CIC. The systems proposed are entitled "Total Project Systems (TOPS)" and are characterized by the capabilities to support a variety of comprehensive AEC/FM applications, extensive data integration, application interoperability, and extensive system flexibility. In the TOPS proposal, the objectives of supported DI and APPI modes are stated. The next step is to identify the key technological elements required to design and implement TOPS-based applications. The interdependencies of these elements are specified, providing a logical research and development roadmap for these technologies. In the TOPS research, the following five elements are specified: Applications, Architectures, Information Models, Information Content and Work Practices. Once the key technologies required are recognized, research and development strategies can be determined, in which the targets for the specific research efforts can be identified. Particularly in the research of this dissertation, the TOPS Architectures and Information Models are selected as the primary focuses. Having determined the targets of the research, a thorough literature review of related research efforts and technologies is performed. As a result, the points of departure for the fully extended and detailed research towards the targets are identified. Consequently, directions of the research are pointed out. Specific Methodologies. Furthermore, our research effort in Information Models and Modeling is aligned with our participation in the development of the IAI IFCs. We intend to ensure that our modeling approaches are consistent with industry data modeling efforts in order to maximize the contributions of our research work to the industries. The research for the TOPS architecture in this dissertation seeks an approach to establish a RAF to support various existing and new applications through different architectural configurations. Unlike system specific architecture technologies that tend to provide restrictive or proprietary technical solutions, the reference approach emphasizes conceptual and logic system components that can be implemented using any specific methodologies. These reference components are also high-level functional units based on which different design and implementation configurations can be applied. Validation The 'proof of concepts' for this research is performed through software prototypes that are designed and implemented using TOPS RAF based on the information models developed. These prototypes validate the results of the research with different design configurations supporting both existing and new types of AEC/FM applications. They also demonstrate the CIC data integration and application interoperability features intended to achieve the objectives of TOPS. Additionally, the development of the prototypes reveals the requirements for future research and developments in this field. UBC Page 8 Yu, K 1.7. R e a d e r ' s G u i d e Chapter 2: Points of Departure Chapter 2 identifies the most relevant previous research and development work, which TOPS builds upon. The fields of research work addressed are Computer Integration Construction (CIC), information models for AEC/FM, and systems architectures for integrated applications. The chapter points out the departing points for the research. Chapter 3: Total Project Systems Framework Chapter 3 introduces the notion of Total Project Systems (TOPS) by defining their scope, functionality, and characteristics. It also identifies the TOPS fundamental technologies and introduces the concept of Reference Architecture Framework (RAF). This chapter lays the foundation for further detailed research conducted in the following three chapters. Chapter 4: Information Models for AEC/FM Information Models for AEC/FM are a main perspective of TOPS. They represent a major architecture thread for TOPS RAF. This chapter develops a set AEC/FM conceptual models that are used to support TOPS. Using examples, it shows how these models can be" used to support data integration for AEC/FM applications. Chapter 4 provides a key knowledge base for the discussions in Chapter 5 and Chapter 6. Chapter 5: Data Integration and Application Interoperability Data Integration (DI) concerns approaches for electronic data being represented and used in computers supporting streamlined data access, exchange, and sharing among multiple computer applications. In contrast, Application Interoperability (APPI) deals with the mechanisms of how software programs interconnect, invoke, and communicate with other programs. The essence of TOPS RAF is extensive DI and APPI. This chapter provides a comprehensive review on various general DI and APPI mechanisms that provide foundations for designing TOPS RAF. This chapter is essential to understand Chapter 6. Chapter 6: TOPS Functional Components Detailed TOPS RAF components and their relationships are exposed in this chapter, based on the knowledge base provided in the previous chapters. Chapter 6 explains how these components are related and how they support Data Integration (DI) and Application Interoperability (APPI) for TOPS. Chapter 7: Validation A prototype approach is used for the validation of this research, and a validation strategy is prepared in chapter 7, including a set of validation criteria. The prototype is developed at the Computer Integrated Construction lab at the Civil Engineering Department of University of British Columbia. A thorough description of the prototype system is provided, including use scenarios. The prototype's systems architecture supports different design configurations of TOPS RAF. The prototype is also developed based on the information models developed supporting several new and existing AEC/FM applications. The validity of research is clearly demonstrated in the prototype. Chapter 8: Conclusions This chapter summarizes the overall research contributions to CIC, specifically in the development of large-scale integrated software systems that support industry-wide applications. The final chapter points out future research areas required in accomplishing TOPS' goal, which will, as believed, be of great benefit to the entire AEC/FM industries. UBC Page 9 Yu, K Chapter 2: Points of Departure Chapter Abstract: As stated in Chapter 1, the goal of this research is Computer Integrated Construction (CIC) and the approach is Total Project Systems (TOPS). TOPS, given their ambitious objectives, require voluminous research and development work as foundations. This research intends to contribute to two technological areas for TOPS: Information Models and Systems Architectures. This chapter is aimed at identifying the departing points in these two areas for this research. In summary, Froese and Russell (1997) investigate CIC challenges and identify the requirements for CIC systems. Many research efforts have acknowledged the importance of standard information models for integrating various AEC/FM applications and consequently many information models are developed supporting AEC/FM applications to share and exchange common project information. Additionally, various general computer systems architectures technologies are widely available for developing software systems. Systems architectures used in existing AEC/FM applications also provide advisable references for designing TOPS architecture framework. This chapter points out the directions for this research. This research is built upon a series of past and ongoing research and development work. Therefore, a thorough review of relevant technologies is essential to understand the premises of this research. As noted in Chapter 1, TOPS are the focus of this research. Since the overall scope of TOPS is large, TOPS elements are related to various technologies in the areas of general computing technologies, AEC/FM specific IT technologies, building construction design, engineering, and project management processes and theories, and so on. To ensure that the TOPS research focuses on key issues, it is imperative to examine various existing technologies and identify the departure points for further exploration so that full research threads can unfold. The general goal of this research is in the field of CIC, while two TOPS technological elements, i.e. Information Models and Architectures, are the primary focuses in this dissertation. This chapter presents an overview of a selected set of commercial and research references. While these are of particular relevance to the research, they are also, to some degree, a representative selection of a wide range of previous and ongoing relevant work. Additional details of these references will be addressed throughout the dissertation for different subjects. In short, this chapter identifies the departing points of research in these arenas. 2.1. Computer Integrated Construction The industrial goal of this research is CIC. While the vision of CIC is generally characterized as a state in which many applications exchange and share project information, early research efforts mainly contributed to the area of standard information models for multiple AEC/FM domains. Nevertheless, information representation is not the only technology required to lead towards CIC, and the barriers for industry-wide application integration are significant. Russell and Froese (1997) discuss the challenges for the construction industries in adopting advanced information technologies in consideration of CIC. The discussion calls for broader and deeper employment of existing applications, abilities to use work expertise and systems intelligence, and the integration of all applications. Many researchers propose strategies for implementing information technologies successfully and contribute them towards CIC (Teicholz and Fischer 1994; Ahmad et al. 1995, Leslie 1996). In general, standard data representations are identified as a central requirement for achieving CIC in supporting these applications by providing common and rich project datasets. While not providing final solutions, all these researches contribute to the IT applications for AEC/FM industries leading to CIC. UBC Page 10 Yu, K 2.2. Information Models for AEC/FM Conceptual information models are generally accepted approaches to represent common requirements for different domain applications for AEC/FM (Froese 96). The goals of AEC/FM conceptual models are also set to provide unified datasets in supporting data sharing and exchange among different types of applications. It is believed that a standard set of conceptual models can improve interoperability of the AEC/FM applications, including CAD design programs, scheduling and work plan software, cost estimating systems, budget control applications, databases of product libraries and unit prices, document management systems, and so on. As mentioned in Chapter 1, the term 'standard' in the context of this thesis referes to commonly accepted software object representations or programming interfaces, and they can be adopted and supported by domain software applications for the purpose of representing real-world objects and exchanging domain information between the applications. While these standards could be de facto technologies invented by a major domain application, they could also be developed and/or recommended by a high level organization such as ISO (ISO 1991) or IAI. Various research efforts are undertaken in this arena, and as a result many different types of domain information models are developed. There are also industry-wide efforts that attempt to develop model standards. Modeling approaches implied in these efforts are advisory to further developments. Work on AEC/FM information models is highly relevant to our research since TOPS' goal is to support the integration of many different AEC/FM applications. This section introduces several major information modeling efforts for the industries that provide starting points for the developments of information models for TOPS. 2.2.1. International Alliance for Interoperability The International Alliance for Interoperability (IAI) is a global consortium with members from industry firms, software vendors, and researchers for the Architecture, Engineering, Construction and Facilities Management (AEC/FM) industries (IAI 1996). The IAI, is to date, the largest effort for developing electronic data standards for the AEC/FM industries. The IAI develops the Industry Foundation Classes (IFCs) - a set of classes that represent information of AEC/FM projects and objects (Froese and Yu 1998, 1999). Those classes are developed to support data exchange between different software applications used in an AEC/FM project. Their mission is to enable interoperability among industry processes of all professional domains in AEC/FM projects by allowing the computer applications used by all project participants to share and exchange project information. The IAI's scope is the entire lifecycle of a building project from strategic planning, design and engineering, construction, to building operation. Not only do the IAI development approaches provide advisable references for this research, but also this research directly contributes to the IAI initiatives and specific IPC developments. 2.2.2. ISO-STEP The ISO standard 10303 or STEP (Standard for the Exchange of Product Model Data) defines exchange data standards for applications to exchange building product information. STEP produces numerous standards (i.e. STEP parts) including domain objects and data modeling methodologies (e.g. EXPRESS or SDAI). These standards describe lifecycle product data using neutral mechanisms independent of specific application systems. Of particular interest is the product data representation for building construction. STEP applies the following development methodologies: Application Activity Model (AAM), Application Reference Model (ARM), Application Interpreted Model (AIM), and Application Protocol (AP), which have vital contributions to data modeling for AEC/FM. More discussions about information modeling especially ISO-STEP models and approaches will be covered in Chapter 4. UBC P a g e 11 Yu, K 2.2.3. Various AEC/FM Information Models In addition to the IFCs and STEP models, numerous conceptual model developments for AEC/FM applications have been ongoing since the late 70's. Froese (1996) summarizes several significant efforts. Some of these models attempt to cover multiple project development phases. Others, however, focus on a more specific domain such as design or construction management. X M L schemas are newcomers in standard data modeling for the AEC/FM industries. Major software companies are defining X M L schema standards that are published to public schema repositories such as www.biztalk.org sponsored by Microsoft (Biztalk 2000). An attempt to develop industry wide X M L standards for AEC/FM, aecXML, has also been initiated and is now part of the IAI organization. The aecXML is a consortium of AEC/FM software companies. Most X M L schemas for AEC/FM that have been published are immature, while the initiatives are strategically important to data exchange and application interoperability among AEC/FM applications. 2.3. System Architectures TOPS suggest a new class of software systems that are distributed and integrated based on a shared project model supporting various application interoperability modes. One challenge for TOPS systems is to develop a comprehensive architecture that supports all of the TOPS objectives. While most existing architectures for integrated or distributed systems are restricted to specific implementation technologies or proprietary to software vendors, they provide beneficial references for developing technologies for TOPS architecture since they represent different design configurations for supporting applications to exchange common project data. This section reviews some architectural technologies that are relevant to this research. 2.3.1. The ICC System The Information, Communication, and Collaboration (ICC) system is a research project conducted by Lottaz, Stouffs, and Smith (2000) under a funding program by the Swiss National Science Foundation. The goal of this research is to develop a system framework for representing and visualizing integrated AEC project information in supporting project collaboration and resolving conflicts. The ICC environment is designed to support the management and representation of distributed but related project data and their exchange in the context of a collaborative building project. The ICC is a web-based system, and it implements a set of tools supporting collaborative processes, decision making, and visualizing project information. To establish the project data support, the AEC project information is classified into four aspects: Projects with hierarchical data, Cubes that are areas, time, or types of the project information, linked Documents that represent different classifications of the project data, and Partners who are project participants and who are also users and authors of project data and documents. U B C Page 12 Yu, K The ICC System Architecture The ICC system is multi-tier architecture as illustrated in Figure 3. Figure 3: The ICC System Architecture • Application Server, this tier serves as a system facilitator. It contains the SQL-based project database as well as database service engines, which are used to expose data. The database is however not a central repository for project documents; instead, the database contains references to URLs or HTTP directories on the server. • Webtop Server: this is an optional middle-tier that supports a web-server accessed by client applications through the Internet. The Webtop server can be installed on any client computer, and it can be used to support project data cached as proxies of the server project data. The database proxies provide the same services to access project data as if they are on the Application Server. • Clients: the clients represent user interfaces that are developed to access application services supplied by the two mentioned servers. In ICC, the clients are developed using HTML or Web scripting languages such as JavaScript. Significance to This Research The ICC architecture is a useful reference for our research in the following aspects. First, the feature that the Webtop Server can be installed on any client computer is a valid idea to support a distributed environment. Most AEC construction projects involve many different companies that do not necessarily use a single Web server for design and project management services. This architectural feature allows them to use their own Web and data servers. Second, the concept of database proxy services at each Webtop server is also an interesting approach to handle project data access for distributed applications. Because the proxies support the same application interfaces, cache project data at a local machine, and handle the data access to the central project database server, the client applications can access different types and amount of project data at any time. It may also be an approach that removes the implementation complexity from client programs to deal with data access performance, data availability, data access rights, network conditions, and so on, which are all critical issues in a distributed computing environment. UBC Page 13 Yu, K 2.3.2. C IFE 's Sequus Project The Sequus was a real world construction project in which a pilot plant of total space 20,000 square feet was to be built in 1998 on a site in Menlo Park, California (Staub and Fischer 2000). The researchers at the Center for Integrated Facility Engineering (CIFE) of Stanford University were involved to explore the use of commercial software tools to leverage 3D models for design coordination, cost estimating, and construction planning. In this project, some major project data exchange scenarios were performed using off-the-shelf AEC software applications. Sequus Software Tools Architecture Figure 4 shows the software applications used in the Sequus project to create each discipline's the design information that was exchanged between the applications. C A D / C A M Fabrication Building Services (Autodesk) Component Dimensions" Multi-pipe (QuickPen) Component Geometry AutoCAD (Autodesk) ["Component w Geometry Component Geometry > .Quantities ArchT (Ketiv) Precision Estimating (Timberline) Schedule Simulator (Bentley) Activities MS Project (Microsoft) Figure 4: Sequus Software Tools and Integration Processes Two main integration scenarios were performed through these tools in the project as follows: • Design-cost Integration: the design-cost integration was accomplished through the link between Timberline's Precision Estimating software (Timberline 1995) and Ketiv Technology's ArchT architectural design software (Note: this software is no longer available at the market when this dissertation is being written). The quantities of the data object (represented as AutoCAD blocks) can be extracted from ArchT and imported into Precision Estimating for cost estimating. • Design-schedule Integration: the design-schedule integration was accomplished with Bentley's Schedule Simulator software (Bentley 2000), which can import design object geometry from AutoCAD (Autodesk 2000) and tasks from Microsoft Project (Microsoft Project 2000). Then, information about the design objects and work tasks can be associated in the Schedule Simulator, and the information can be used to create a 4D (3D product model + time information) model of the facility designed. Significance to This Research The real-world multi-disciplinary integration scenarios presented in the Sequus project indicate the requirements for any integrated AEC systems. Therefore they provide valuable foundational information in supporting the overall research goal for this dissertation. The Sequus project also involves many kinds of AEC software tools. The integration of design and project management information among these tools was performed through direct application-to-application communications, in which both file-based and software-engine-based data exchange approaches were intensively used. As reported in Staub and Fischer 2000, these approaches offered partial solutions for AEC project information integration, as both their advantages and disadvantages were exposed in the project. Nevertheless, they provide good references for designing sophisticated integrated systems supporting multi-disciplinary AEC applications. UBC Page 14 Yu, K 2.3.3. Microsoft Repository Microsoft Repository (Microsoft 2000) provides a common store to persist object data. Object data is stored in a relational database, i.e. MS SQL Server or MS Access, which the underlying data structure is dynamic and extensible. This means that database tables and columns are added as new models are defined, and as existing models are extended. A layered architecture is used that separates the underlying persistent data formats from the object model layer, which is represented as a conceptual object model specified by the repository's meta-model. Objects are structured using object-oriented methodology so that information regarding both object relationships and properties is supported. Software interfaces are used to expose object information. MS Repository provides a set of standard interfaces for software applications to use object data. To support software programs, MS Repository allows specific information requirements to be modeled in the repository as an information model, which is stored as a Repository Type Library (or meta-model). Meta-data technologies are used in MS Repository to support mappings from any external data source to repository object types. This enables any software application to be modeled in the Repository at runtime. It also enables a user to extend existing models. MS Repository can support multiple applications sharing project data through object interfaces. A set of development tools is also available in MS Repository for software development vendors to deploy specific information models to the repository in order to support software applications. MS Repository is provided by and restricted to a series of Microsoft proprietary technologies including MS SQL Server and COM. MS Repository provides a useful reference for this research, especially the use of a meta-model for incorporating various information models into a system at runtime. MS Repository targets applications by using open information models to support the development, deployment, and reuse of component software. MS Repository Features MS Repository supports the following features: • Use of proven relational databases for underlying data persistence • Objects are organized using object-oriented methodologies • Meta-data supports object modeling information to be accessed and used at runtime • Support for both COM and Automation programming • Support for object identifications, versioning, and object sessions (i.e. workspace) • Support for object transactions MS Repository Architecture The MS Repository architecture consists of five basic components as shown in Figure 5: Repository Database, Repository Engine, Information Model, and Application. Application Application Information Model Information Model 3=1 Repository Engine lepository Database Figure 5: MS Repository Architecture UBC Page 15 Yu, K • Repository Database: is a relational database, e.g. MS SQL Server or MS Access database that is accessed by the Repository Engine to save or retrieve data. • Repository Engine: a software engine that manages the data in the Repository. It provides functions to store and retrieve Repository objects and their relationships. • Information Model: A domain object model that specifies the information of interest to the domain. Object information is exposed through a set of generic interfaces. • Type Information Model: A meta-model that specifies the information types of domain information models (i.e., the schema). This model is used to define domain information models. The information about the Type Information Model is also exposed through a set of generic Repository objects. • Application: Software programs that use domain object models and, more importantly, that share the same set of domain objects. Significance to This Research MS Repository provides a valuable reference to this research. The implication of separating underlying persistent data and information objects is a contribution to supporting object-oriented applications. The use of meta-models for specifying domain information models at runtime and for exposing object information and its meta-data through generic object interfaces offers great object accessibility. 2.3.4. Microsoft Windows DNA Architecture Microsoft Windows Distributed interNet Application (DNA) (Microsoft 1999) Architecture is a Microsoft strategy to enable its various software technologies to support distributed computing environments, especially Web-based applications. Windows DNA is a specific architecture that supports distributed applications accessing common data using a set of Microsoft technologies. The design objectives of the DNA can be summarized using the following metaphors: Autonomy, Reliability, Availability, Scalability, and Interoperability. DNA endorses the notion of organizing software components into several major tiers each providing functions useful for supporting DNA objectives. Similar to MS Repository, DNA emphasizes the heed for separating underlying persistent data from domain objects, and to user interfaces. The DNA architecture supports different types of client programs ranging from Web browser (i.e. thin client) to sophisticated applications. It also allows legacy systems to be attached, serving as data sources. DNA Architecture As noted above, DNA uses a mechanism of software component tiers to define different sets of functions and to apply certain Microsoft technologies at each tier. The goal of the tiered architecture is to separate the business logic from a client and server system by moving it to a middle tier. There are fundamentally three tiers, Presentation, Business Logic, and Data, as illustrated in Figure 6. Presentation Business Logic j Data Figure 6: Windows DNA Architecture UBC Page 16 Yu, K • Presentation: the presentation tier represents all kinds of client programs including web-browsers, devices (e.g. palm PCs), and traditional applications. These applications can share the common data sources from the Data tier through business objects implemented at the business logic tier. • Business Logic: the business logic tier contains software components for objects that support object data access, object relationships, and business logic and rules. One design configuration is to support data-centric objects and Ul-centric objects, where the former are to handle data communications to the data tier and the later are for supplying data for the presentation programs. In DNA, objects at this tier are developed using COM and COM+ technologies. • Data: the data tier provides primary and common data sources for the entire system. Different types of data supplies can be implemented such as MS SQL Server or Oracle through Microsoft standard data access interfaces OLE DB or Open Database Connectivity (ODBC). Due to the employment of the standard data access interfaces, there are no restrictions on what kinds of data sources can be supported. For example, other than traditional database systems, legacy systems or external applications can also be used as data sources. Significance to This Research The clear separation of software component layers, each handling a certain set of services, makes a constructive contribution for developing distributed computing systems. Although Windows DNA is designed specifically for using Microsoft technologies, its basic idea of component layering can be applied to a broader design consideration for general distributed systems. 2.3.5. RosettaNet RosettaNet (www.rosettanet.org) is an initiative to define computer business interfaces for the electronics industry. RosettaNet's goal is to define and lead the implementation of open and standard electronic business processes through the use of the Internet. These business processes support the computer business interfaces, namely "Partner Interface Process (PIP)", between participating supply chain partners. RosettaNet implementation framework specifications allow participants and solution providers to implement computer solutions that can collaboratively execute RosettaNet-compliant PIPs according to strictly defined protocols. These protocols specify application message formats, message exchange sequences, authentication and authorization aspects, etc. RosettaNet defines standards for not only the data exchange dictionaries, but also implementation frameworks and eBusiness dialogues, i.e. PIPs, which make up individual steps of an overall eBusiness process. The RosettaNet approach intends to support distributed applications to interoperate and interchange messages over the Internet based on standard transactional processes. They can be applicable in supporting application interoperability for the AEC/FM industries. RosettaNet Scope The RosettaNet scope is shown in Figure 7, which draws a parallel between human-to-human business exchange and server-to-server electronic business exchange. UBC Page 17 Yu, K Human-to-human Business Exchange Telephone Business Process Dialog Grammar Words Alphabet Sound eCom Applications eBusiness Process PIP ^ Framework Dictionaries HTML/XML Internet System-to-system E-business Exchange RosettaNet Figure 7: RosettaNet Scope The RosettaNet scope supports e-commerce applications based on the standard business processes defined using a standard process modeling language, in this case, UML activity diagrams (Rumbaugh, Jacobson, and Booch 1999). These processes provide requirements for defining PIPs that perform the processes between the business partners. The PIP guidelines comprise both human-readable and machine-readable specifications. The RosettaNet Implementation Framework ensures that appropriate components must be implemented in order to monitor the compliance of partner e-business transactions and rules specified in PIP. Business messages communicated through the PIPs are structured using standard data syntax (i.e. XML), while message data semantics are defined in the Dictionaries. The PIP communications take place across the Internet networks. RosettaNet Architecture RosettaNet's networked application architecture undertakes a layered approach as shown in Figure 8. Action Layer Transaction Layer Process Layer Service Layer Agent Layer Message Handling Layer Transfer Layer Security Layer Figure 8: RosettaNet Architecture The basic functions each layer provides are listed as follows: Action Layer: that supports business behaviors acting on or with accompanying data. Transaction Layer: that monitors transactions and sequences of message exchanges. Process Layer: that encapsulates transactions for executing a partner interface process. Service Layer: that provides network resources for network and business related functions. Agent Layer: that provides communication interfaces for user and machine agents. Message Handling Layer: that handles message deliveries. Transfer Layer: that transfers data between uniquely named network resources. Security Layer: that provides a secure communication channel (connection) that implements authorization and authentication using digital signature techniques. UBC Page 18 Yu, K Significance to This Research A significant contribution of the RosettaNet approach to our research is that it does not require a common shared database for applications to exchange project information. While the shared project model approach is much needed for AEC/FM projects to CIC, design-construction business involves transactional processes between participating firms. During a construction project, there is project information that is common to all participants and can be shared among them. On the other hand, there is also data that is only transferred between certain parties. To enable AEC/FM applications to perform e-commerce processes using messaging data, RosettaNet architecture sets a good example of which some technologies and development methodologies can be adopted into the AEC/FM industries. Especially, the standardization of domain processes is required for transactional processes between applications. 2.3.6. ProiectBank DGN Bentley's ProjectBank DGN (Bentley 2000) allows different building designers to work at different sites, sharing the same project design information. It is a client/server software program for managing design project data changes, and it is capable of recording changes made by designers. A project manager can track and review changes made by every member of the design team at any time. ProjectBank manages engineering project information at the component level rather than the file level. ProjectBank sets a live example for using shared project information among different project participants, and it supports the following features: Project Tracking, Change Merging, Dependency Tracking, and Multi-format Data Storage & Exchange. ProjectBank DGN Architecture ProjectBank DGN introduces a component architecture named "component bank", which is used on both the server and client side. On the server, the component bank provides archival server design storage. The sever design data can be imported from Bentley's MicroStation's design files. For each project, there is one server component bank containing all project data permanently. On the client, the local component bank is called a briefcase, which is always initially derived from the server storage. Each ProjectBank DGN client has as least one briefcase active during the design process. Once downloaded to the briefcase, the client generates a working copy of the drawing's components as a design file, based on which design changes can be made. The changes can then be committed to the server. The commit operation triggers a comparison between the briefcase version of the design and the working copy. Any changes made during the working session are identified and the briefcase's components are updated. Additionally, the server storage and the briefcase share the same internal component architecture. Therefore, the synchronizations of design changes and the data traffic between the server and client are efficient. Significance to This Research ProjectBank is a commercial example of client-server software program that supports complex design information being shared by multiple participants using a commercial design package. The idea of using the same data representation for a local copy of a complete design is valid. The capability of importing a physical file as a shared project model is an important and practical data integration utilization mode. UBC Page 19 Yu, K 2.4. Chapter Conclusion This research acknowledges challenges of CIC and derives the notion of Total Project Systems (TOPS). It acknowledges the TOPS' five fundamental technological elements: Applications, Architecture, Information Models, Information Content, and Work Practices. This research intends to make significant contributions to Architecture and Information Models. Various past research work on developing AEC/FM information models provides invaluable experiences and recorded expertise in this field. ISO-STEP sets formal development methodologies and tools for information modeling. The International Alliance for Interoperability (IAI) is engaged in the largest effort ever to develop a global standard object information model for AEC/FM, the IFCs. This research intends to contribute to the development of the IFCs and to utilize them in developing TOPS technologies. Detailed development work on information models unfolds in the following chapters of the dissertation. This research also focuses on systems architecture as a major contribution to TOPS. Microsoft Repository sets an example of using object-oriented domain models based on traditional database management systems as its underlying data persistency mechanism. It also provides unique technologies in utilizing meta-data in supporting domain objects. Microsoft Windows DNA architecture clearly separates data, objects, and presentation layers, supporting highly modular and distributed system configurations. RosettaNet's architecture provides one possible implementation solution for handling application-to-application process transactions; this capability is not supported by the shared model approach. Bentley's ProjectBank demonstrates a live example of supporting complex AEC/FM project information to be shared by commercial applications used by different project participants. The ProjectBank's approach of using local copies of complete project data suggests a unique approach for dealing with large volume of project data in a client-server environment. All these technologies make significant contributions to the development of TOPS architecture framework. Details of the TOPS architecture are built using the quintessence of these existing technologies. In summary, the chapter provides an overview of a selected set of commercial and research references specifically relevant to the research of this dissertation. Further details of these efforts will be discussed and related to our research throughout the dissertation for different subjects. Al l these technology development efforts however provide points of departure for this research. UBC Page 20 Yu, K Chapter 3: Total Project Systems Framework Chapter Abstract: It is believed that the idea of Total Project Systems (TOPS) holds the best promise for achieving the state of Computer Integrated Construction (CIC). The TOPS Reference Architecture Framework (RAF) provides a foundation for developing large scale, integrated, and distributed systems supporting project models and domain transactional processes passing project related messages. A TOPS-based system has the characteristics of comprehensiveness, extensive data integration, full application interoperability, and flexibility. The developments of TOPS-based systems call for five major elements: a broad range of comprehensive AEC/FM Applications, System Architecture, Information Models, Information Content and Work Practices. A layered and threaded approach is used in designing the architectural framework for TOPS, laying out the basic components and their relationships. The establishment of the TOPS RAF is a major contribution of this research. It is believed that the evolution of information technologies (IT) and computing for the Architecture, Engineering, Construction, and Facilities Management industries (AEC/FM) will inevitably lead towards tools that collaborate through shared collections of information (i.e. project models) about AEC/FM projects. The vision of CIC is a state of computer tools interoperating freely with the capability to access, share and exchange project information. The idea of TOPS is aimed at supporting these applications operating in such an information usage state. TOPS-based systems are distributed and integrated, and they support both project models and domain transactional processes passing project related messages. This chapter provides a thorough overview of the TOPS functionality including its characteristics. It also introduces the concept of the TOPS Reference Architecture Framwork (RAF), and then it presents its basic architectural layers, threads and logical components. Some design principles for developing TOPS-based systems based on the RAF are also recommended. 3.1. Total Project Systems (TOPS) The approach of Total Project Systems (TOPS) is proposed in Froese, Rankin and Yu (1997a). TOPS are aimed to integrate various computer tools to support construction management and increase the overall efficiency of construction operations. Several basic characteristics and functionality of TOPS are also identified in this paper. Further research on the architecture and functional scope of TOPS has been reported in Froese and Yu (2000). This Ph.D. research is largely built upon this body of work and has extended the details in several aspects. This section provides an overall introduction to TOPS. 3.1.1. TOPS Philosophy The following facets constitute the philosophy behind TOPS: • The central focus of all AEC/FM projects is the physical artifact (i.e. the building) and its environment. • The information about the projects (or project data) in all its forms comprises models that act as abstractions of the physical projects. A significant portion of the project data can be structured retaining real world object properties and object relationships. • Most design, engineering, and management processes operate on the project information models, rather than on the physical project itself. The intelligence of domain processes and reasoning is generally left to human users at this stage. Intelligent computer systems require highly integrated project data, as well as interoperable sophisticated applications. U B C Page 21 Yu, K 3.1.2. TOPS Characteristics TOPS can be elucidated as a distributed, model-based, and domain-transaction-based large-scale system supporting all data integration and application interoperability scenarios among all the applications used by different project participants throughout the lifecycle of AEC/FM projects. In Froese, Rankin, and Yu (1997a), three basic characteristics of TOPS are specified: Comprehensiveness, Integration, and Flexibility. Our continued research further enhances the TOPS characteristics as follows: Comprehensiveness There is a large suite of applications that support a comprehensive range of design and project management tasks including traditional programs such as CAD, scheduling, cost estimating, and advanced engineering analytical programs, as well as new and emerging applications such as dot.COMs, project management, 4D project simulators, client-server systems, devices, Internet clients, and generic project information browsers. The comprehensiveness of TOPS also dictates the system scope. That is, TOPS are intended to support a large-scale networked system through which the different applications operate across the lifecycle of AEC/FM projects. While continued and extensive research and development of the applications are required for TOPS, this Ph.D. research does not focus on specific domain application developments. Extensive Data Integration "Extensive Data Integration" is a state in which all applications both contribute to and draw from a common pool of project information represented as shared project models. Project data can be freely exchanged among all applications through various modes. All these call for extensive research or investigations on technologies for data integration (DI). In this research, Section 3.2.3 provides some sample scenarios that illustrate the need for various data integration scenarios in CIC, while Chapter 5 provides a thorough summary on various DI schemes based on our investigation in this area. Application Interoperability Application Interoperability (APPI) regards the abilities of all applications to invoke, request and provide functional services, sending and receiving messages, and participate in domain transactional processes. This characteristic also suggests the notion of allowing any applications to plug in and play by declaring exactly how they intend to interact with other applications in the system through standard interfaces. This research investigates various APPI schemes covered in Chapter 5 and Chapter 6. Extensive Flexibility That is a state of systems being able to operate, interface, communicate, and install in a highly flexible, dynamic, and distributed environment. This characteristic is manifested in the following features: • Openness: in that the central data representation for the entire system is not dependent on specific implementation technologies (i.e. use of standard information models). • Modularization: such that a variety of specific component applications developed by different vendors can be 'adapted' to the system sharing project information and interoperating with other applications. • Distributiveness: in that data sources, applications, and participants can be widely distributed in a manner analogous to the Internet, and they work both online and off. • Dynamic Deployment: such that software releases and updates can be installed at runtime seamlessly without breaking the current systems or requiring re-installation of the entire systems. UBC Page 22 Yu, K 3.1.3. TOPS Elements The target subjects of TOPS are various computer tools and technologies available for supporting AEC/FM lifecycle project management, while the TOPS' focus is on the integration of the project data involved and the interoperability of the applications used. In Russell and Froese (1997), Applications and Tools, Standard Data Representations, and Systems Architectures are identified as three main research thrusts to achieve the goal of CIC. Our further research in this area has discovered two more aspects, Information Content and Work Practices (see Figure 9). The goal of TOPS RAF is to establish an architectural framework for developing systems that can respond to all these five major areas. Figure 9: TOPS Elements These slices represent TOPS in the following context: • Applications: a large range of AEC/FM software programs running on different platforms, either client-server or standalone, used during the entire lifecycle of AEC/FM projects by all kinds of project participants. These applications access, exchange, and share a pool of project information, they inter-operate, and send and receive messages. • Architectures: the logic of conceptual software components, their roles, and functional relationships that build up the entire systems connecting software applications. • Information Models: formal and highly structured representations in computer formats about project information, including building product information, construction process and resource information, management and document information, costs, specifications, and so on, generated and used by the AEC/FM applications during the lifecycle of a construction project. • Information Content: the data and data types involved or related to the construction projects, such as the project information, the information regarding the construction companies, data from other companies such as suppliers or manufacturers, information from government agencies (e.g. regulations, codes and standards), and information regarding industry standards. The relations, usages, procurements, regulations, and related policies regarding the information are also issues concerned in this regard. • Work Practices: concerned with the impact of information technologies to the AEC/FM design and construction processes, working conventions, and professional practices, and vice versa (Rivard 2000). For example, the information flows implied in integrated computer systems impact, or are impacted by, the workflows of construction project management. Issues involved in this area will rise in adopting large-scale industry-wide systems supported by TOPS RAF, and a good understanding of these issues will be crucial in implementing and endorsing the TOPS RAF systems to the AEC/FM towards CIC. UBC Page 23 Yu, K TOPS Element Relationship A building-block view of these TOPS elements, as illustrated in Figure 10, represents their conceptual inter-relationships, upon which the CIC can be realized through the industry-wide adoption of TOPS. Specifically, "Work Practices" set fundamental requirements for designing and developing the systems. "Architecture" implies the "Information Models" and provides support for implementing "Applications". "Information Models" also serve as technology foundations for "Information Content", which is generated and utilized by "Applications". Once "Applications" are well supported by the entire system, they represent the roles of IT uses that impact, and are simultaneously impacted by, "Work Practices". When all these elements are widely implemented in TOPS-based systems supporting real-world AEC/FM projects, they provide a massive infrastructure for comprehensive application usages, effective application interoperability, as well as project data access, sharing, and exchange among all AEC/FM applications. Al l of these computer IT utilizations as a whole supporting TOPS represent the vision of CIC. TOPS Work Practice Information Content Work Practice Applications Information Models Work Practice Architecture Figure 10: TOPS Element Relationships TOPS Fundamental Scope The functional scope of TOPS covers all of the engineering and business functions (PMI 1996) supported by all types of computer tools used by all types of participants in AEC/FM. These functions span the entire lifecycle of the building projects and involve all types of project participants. To give a general idea of the TOPS scope, Table 1 in the next page shows some examples of the application types and project participant types for each project stage. Appendix A, B, and C (Froese, Rankin, and Yu 1997b) also show the scope of general construction management functions from different perspectives, which TOPS are intended to support. 3.1.4. TOPS Data Integration Scenarios The vision of the data integration in TOPS is that all applications both contribute to and draw from a common pool of project information that is stored as project models. Therefore, TOPS also need to support many variations and alternatives data integration models for each of the functional components. Not only are they possible, but also we contend that it is necessary for a distributed AEC/FM system to support a wide variety of data modes. This section presents a series of typical AEC/FM data exchange scenarios (i.e. use cases) to illustrate the need for a multi-model solution. File-based Data Exchange File-based data exchange is a scenario in which two applications share project data through computer files. Most of the current IFC implementations use file based data exchange mechanisms. For example, a building product model is exported as an IFC file from the CAD system in which it was created. An IFC file representing a building product model is read as input to a cost estimating application, which in turn writes object cost information and other related data (such as materials and construction resources) to the IFC file. This file can be further passed to a scheduling program for generating construction task plans. Although the notion of distributed and integrated systems nominally involves "on-line" access to a shared project model, the most common mechanisms for importing and exporting project data today uses file-based data exchange. UBC Page 24 Yu, K Table 1: TOPS Functional Scope Examples Architecture Engineering Construction F M Application Types CAD, Specifications CAD, Specifications, Engineering Analysis CAD, Specifications, Cost Estimating, Scheduling, Project Management, 4D Viewer, Internet Portals (e.g. bid process), Project Information Browser, CAD, Asset Management, Inventory, Space Planning, Maintenance Management, Scheduling Participant Types Architect HVAC Engineer, Electrical Design Engineer, Mechanical Design Engineer General Contractor, Subcontractor, Project Manager, Estimator, Scheduler, Bid Manager, Purchase Manager, Bid Manager, Owner, Supplier, Manufacturer Owners, Facilities Manager, Construction Manager, Furniture Manufacturer, Maintenance Engineer Coarse-grained Data Exchange The coarse-grained data exchange scenario involves transforming a large amount of data to or from the shared project model through a network connection, e.g. the Internet. For instance, a complete building product model is exported from the CAD system, in which it was created, across an Internet connection, into a shared project database, where it is available for other use by other applications. The entire product model may need to be downloaded to a local machine in order to generate a complete project task plan. This data exchange mode apparently involves applications accessing data in "large chunks" (e.g., complete models), and is associated with relatively large data sets and/or slow connections. This scenario requires that the user explicitly selects and configures a data source, as well as loads and commits portions of an overall project repository to and from the local project model dataset (see Section 3.3.2) through a user interface. Fine-grained Data Exchange As its name suggests, the fine-grained data exchange involves exchanging a small amount of data among applications. There can be many scenarios requiring such data exchange mode. The following are several examples: 1. A change-order management tool reviews the status of change orders stored within a shared project database. 2. When an object is selected in a CAD application, it can show the object's cost data drawn from a remote project database. 3. A "project explorer" interface allows a construction manager to browse and selectively edit any specific information stored in a shared project model. 4. A building component is sent from the architect to a cost estimating system for pricing. Unlike the coarse-grained data exchange, in this scenario, applications access data in "small chunks" (i.e. individual objects or small collections of objects). This data exchange mode is suitable for relatively small datasets and/or fast connections. It also supports both traditional applications and "thin-clients", or applications that provide little more than user interface functionality, as in the third use case above. UBC Page 25 Yu, K Off-Line or Message-Based Data Exchange In a large distributed system, applications can reside on computers that are not all connected to the project model server machine or simply temporarily off-line from the Internet or the entire network. In this situation, users can still require "data exchange" through the applications they use. For example, an engineer might choose to send a set of design changes to the architect as an e-mail (or similar type of) message. Some device-based applications are likely to be off-line while in service. For instance, in inspector records inspection results go into an application on a palm computer, and the results are incorporated into the project database when the device is docked on the inspector's desktop. These scenarios imply a data exchange mode in which applications send datasets as messages to be delivered to a recipient at some future time. Web Applications Web-based applications provide a remarkable generation of a new type of software. This type of application is becoming popular in the AEC/FM industries and provides the basis for a new business model, e.g. the Internet portal sites (i.e. a construction dot.COM company). One typical usage scenario is that a construction manager uses a Web browser to review the status of a project's subcontract packages on an Internet portal site's project management system, which typically maintains a database of project information and directory of files. The Web applications are naturally Internet-server-based, and the data exchange occurs between the server data source and the Web browser. Application-To-Application Data Exchange Application to application data exchange concerns one application exchanging project data directly with another application. For example, an estimating system interacts directly with a CAD program to retrieve objects for quantity takeoff and pricing. This exchange mode stresses the need for data from one application to be available to another, meaning that the called application serves as a data server for the calling application. 3.1.5. TOPS Application Interoperability Scenarios In addition to supporting extensive data integration scenarios that emphasize providing and using the content of project data, TOPS also call for the needs for effective Application Interoperability (APPI), which focuses on the initiations, connections, supplying and uses of services provided by the applications. While most (but not all) of software interactions involve data being transferred between the interacting applications, the term Application Interoperability (APPI) introduced in the context of this research emphasizes the mechanisms and paradigms of how software applications interact with each other. That is, the focus of the issue is not on the payload of the interactions, such as content of the data, its underlying structure (i.e. information models), the format (i.e. file or binary), or the type (e.g. granularity) of the data transferred. In other words, APPI is concerned with how applications communicate, but not what they communicate about. This distinction helps identifying and understanding different base technical issues in designing TOPS systems. To demonstrate the implication of DI and APPI to TOPS, Figure 11, from Froese, Yu, Liston, and Fischer (2000), presents a typical scenario where a project meeting is occurring where questions and issues regarding project status and construction plan conflicts need to be resolved. This is a typical collaborative working environment that TOPS are intended to support. This scenario involves different participants such as project manager, scheduler, cost estimator, architect, client, etc. using different tools (4D visualization, scheduling, cost estimating, document management, CAD design, and so on). UBC Page 26 Yu, K One requirement for this scenario is the rich representation of the project information. The capabilities of software tools used to visualize rich project data from different perspectives (Russell and Udaipurwala 2000) are essential to ensure the effectiveness of decision making process in this scenario. Additionally, questions like those in the picture require extensive interactions directly between the applications. This information transfer among applications can be project information, e.g. construction schedule or information not directly related to the project such as a company's organizational chart. In this scenario, many analytical processes may occur that involve information that is generated temporarily from an idea or new proposal for a solution, which is not yet logged as project information. This type of information is not stored in the project model. Additionally, in a distributed and loosely organized virtual organization environment for a construction project, much information is proprietary, meaning that it can only be exchanged between certain parties and is not supposed to be shared or stored on the shared project server. Consequently, shared information does not guarantee communication, coordination, & understanding among applications and their users. In many cases during an AEC/FM project, it is also not always desired. Hence the support of these application interactions is needed. In TOPS, the different application interaction modes can be supported. The rest of this section describes these scenarios of these modes. 1 I I , J , I I » m i * h I I i i i i I I •. -JLI irujf: O H I I 1 II 1 I I JSU 1, .1 ii i r i I I I I I • i i 1II I I I * i i i T • * - I I J I I I i ri i I I WJU ; . ; J C M : i xjtit: rocurement schedule construction schedule Figure 11: Interactive Workspace (Froese, et al 2000) UBC Page 27 Yu, K Invoking Applications In an interactive application environment, a user using one application might want to invoke another application to utilize its functions by sending necessary instructions. For example, an estimator using a cost estimate system might want to visualize the physical appearance of the object to which a quantity takeoff process is being performed. The estimator might need to, through APIs, invoke a CAD program and pass an instruction containing a "view" command with the unique id of the object to the application. The same operation can also be used in an interactive workspace environment where an architect is viewing the object and discusses design alternatives with the estimator. While this scenario may seem to be similar to some of the data integration mode, the emphasis in this case is not on the content of the message data but on the actions required on the other application and communication status between the applications. Based on this simple APPI mechanism, a comprehensive system can also be developed that supports dynamic application interactions such as event or behavior controls. Using the same example, if the architect using the CAD program makes changes to the object, the quantities taken-off can be updated automatically in the cost application; as a result, the cost information for the object can be adjusted accordingly. It is important to note that in a distributed environment, this application communication does not require that both applications reside on the same machine. They can be distributed on a local network or the Internet where the architect and the estimator are located at different places. Request Domain Function Services In a typical AEC/FM project involving many participants from different sources, different firms using specialized applications can provide different services. Using TOPS, these services can be registered on the project server and any applications can utilize these services by sending a request. Standard services can also be defined at software level and any software vendors can choose to implement the standard services and plug in their service components to the project server. For instance, a quantity takeoff service can be published on the project server (e.g. a typical construction dot.COM, or a specialized service provider's server machine). Additionally, multiple services providers can register their support for the published service. To use the service, a client (e.g. a building owner) needs to send a request from a computer program containing essential information required for the service, in this case, a physical building component with or without its specification data. To complete the service, the service provider needs to return the expected result, in this case, a report of quantity takeoff, to the client. It is also important to note that the essence of this APPI mode is not on the content of the information passed between the service requester and provider. It is the mechanism in which application services can be supplied and used based on the entire system architecture using software APIs. Moreover, the message passed during the service request and completion process is not necessarily a specific project object. For example, the object unique identifier can be passed, based on which the requested application can retrieve detailed information regarding the object from any data source available. Again, the key in this mode is not the data content but the fact that services can be used through the same basic application environment. UBC Page 28 Yu, K Request Domain Transactional Process Services Domain Transactional Processes (or transactions) are computing operations that perform some domain functions. To understand the context of the terminology "transaction" herein, an example of a cost estimating process, which includes several transactions, is given in Figure 12. This scenario involves three project participants, the building owner, the architect, and a cost estimator. In this scenario, the building owner uses a project information browser to view project status, the architect uses a CAD program to design the building by defining component objects, and the cost estimator uses a cost estimating system for object pricing. The initial transaction is a request for pricing object cost initiated by the building owner. After the owner has selected some project objects, he sends a request (i.e. Request_For_Cost_Categories) to the cost estimator, while passing on the object type (i.e. Object_Type) information. The estimator, starting another transaction, uses the object type information to retrieve relevant cost categories (i.e. CostCategories) and returns it back to the owner, who then sends another request (i.e. a transaction) with a message containing the objects and the cost categories to the architect for object quantity takeoff service. The architect then performs the quantity takeoff based on the object and cost category information and passes back the resulting quantity takeoff (i.e. Object_Quantity_Takeoff). After that, a new request is initiated from the owner to the estimator for final pricing, while the object quantity takeoff is provided. Finally, the cost estimating system does the cost calculation and generates the cost estimate. The entire process is completed upon the owner's receiving the cost estimate (i.e. CostEstimate). Project Information y Browser y Requet_For_CostCategories (Object_Type) - (Cost_Categories) -Request_For_Takeoff (Objects, Cost_Categories) I (Quantity Takeoff) Requet_For_Pricing (Object_Quantity_Takeoff) (Cost_Estimate)-Figure 12: Cost Estimating Transaction Example UBC Page 29 Yu, K 3.2. TOPS Reference Architectural Framework (RAF) The idea of a TOPS-based reference architecture, which is named the TOPS Reference Architectural Framework (RAF), is proposed to support TOPS' system architecture element. In order to support the various DI and APPI scenarios discussed above, the Architecture of TOPS must be able to support various configurations of applications and their integration mechanisms. This section introduces the concept of the RAF and provides an overview of the TOPS RAF 3.2.1. Reference Architectural Framework (RAF) It is believed that a significant contribution needs to be made in the area of system architecture in TOPS to support all applications running on different platforms in a way that represents the state of CIC. A system-restricted architecture is not capable of supporting the TOPS' ambitious objectives. Given that the scope of the problem concerned is the entire breadth of AEC/FM industries in which all kinds of software applications are required to interoperate in the most integrated fashion, the RAF is considered to be a key ingredient for achieving the TOPS goal. Context of the RAF The RAF describes the basic structure of conceptual software systems and components that are organized and integrated based on their functionality and inter-operational logic. This architecture does not define a specification of a software architecture design; rather, it is intended to provide a reference for designing system architecture and determining development strategies for any software that attempts to achieve the same goals, e.g. data integration and application interoperability as in TOPS. RAF Characteristics Generally speaking, the RAF has the following characteristics: • Highly scalable, flexible, extensible, and portable • Operating system, platform, and computer language independent • Independent of any specific network protocols • Not a specific software system architecture for a particular software application • Architecture can be used as a reference in designing specific software systems that can use a view or a part of the entire architecture • Architecture defines functional roles in the entire system, but not specific implementation approaches or tools • Able to support variety of different implementations or use scenarios • Able to support variety of different architecture modes • Able to support a variety of different types of applications UBC Page 30 Yu, K 3.2.2. Design Considerations Several main design considerations are made in determining the TOPS RAF architecture. These considerations can also be thought of as the criteria used in designing architectures for actual systems based on the TOPS RAF. Support for Traditional Applications The most fundamental and apparent consideration is that the system must support traditional applications. These applications represent a major element of TOPS and they provide major domain functions used in daily AEC/FM professional practices. Such an application usually supports extensive functionality in a specific AEC/FM arena such as architectural design, cost estimating, or project scheduling, etc. However, these applications are developed by different vendors based on the requirements from a vertical industry sector. As a result, they are not effectively connected, even though they all use the same project information and their users must collaborate on the engineering and management processes that are supported by the applications in a construction project. The goal of TOPS is to bring these applications together into a connected, while distributed, computing environment so that they can share and access the same project data and operate in a collaborative workspace environment. Consequently, while new types of applications will evolve enabled by TOPS, the primary consideration is to support these legacy domain applications that the AEC/FM professionals use mainly today. TOPS RAF must be designed in a way that supports these applications. File-based Data Exchange As mentioned above, major AEC/FM domain applications are currently fragmented in a way that they do not communicate the project data effectively through electronic forms. Acknowledging the fact that most of these applications generate computer files, many attempts have been made to integrate applications in the AEC/FM arena using computer documents as the media to exchange project information. Application Application \ 3 Files Application Figure 13: File-based Data Exchange Given the technologies available at present, this is still the easiest and quickest approach for achieving a basic level of data exchange. Moreover, most early implementations of this type are vendor proprietary, meaning the data formats for exchange documents are either application or vendor specific. Recent efforts using this approach focus on standard data formats such as IAFs IPCs that can be used to contain all project information generated from any applications that implement such a data format. It is intended to support the file-based data exchange using standard information models in the TOPS RAF. UBC Page 31 Yu, K Project Model-based Data Access Currently, electronic data exchange among computer applications within the construction industry relies almost exclusively on document exchange, where datasets are exported as some type of document file from one application and imported into another. While this approach can be handy in certain situations, its disadvantages to the end users are quite obvious. For example, this approach maintains the same set of project data in one logical source. The data exchanges among applications are many-to-many relations in terms of communications. This makes it almost impossible for any party to obtain the most recent and complete project information. While standard file formats such as IFCs can ensure consistent data representations and ease the development efforts in some cases (since one application only needs to implement one exchange data format), they do not remove the problem completely. Although technically, an EFC file can contain all of the project information, it is difficult and impractical for the end users to maintain one single copy of the project file and use it among different project participants. Additionally, the exchange files, when containing much project data, tend to be too large to be effectively transferred across the network on demand when applications are distributed. Application Application A ^ErojecJJVJodeJ^ Application Figure 14: Project Model-based Integration In contrast, our early research on TOPS is focused on Project Model-based data exchange, wherein collaborative applications read and write objects to a shared project-model repository. As presented earlier, a key feature of TOPS is the notion of model-based data integration, based on which many data integration scenarios are supported. The Project Model-based Integration approach is a new generation of the technologies used in AEC/FM industries. In this approach, the entire construction project has a logical and electronic representation from a central source. This central source contains all of the project information including the physical buildings, building elements such as walls, windows, spaces and so on and their relations, and other information such as construction plans, tasks, costs, project participants, etc. It is important to note that this "central source" is a logical entity that represents the real-world objects and their information is exposed through software interfaces. This means, the actual implementation of the project data (e.g. a type of DBMSs) is not a significant factor in this context. This approach has some tremendous advantages over the file-based approach. Particularly, this method ensures that most current project information is available from one source in electronic form. The project data are consistent and complete. It is possible for users to browse overall project status or any specific project information by querying the same set of data. Once accessed, the project data can be shared, exchanged, modified, or updated. Once the project model object interfaces are standardized, applications only need to implement one set of interfaces in order to share project information with others. One crucial advantage of the use of a project model is that it makes it possible for facility owners and managers to receive complete datasets about the entire building. The datasets contain complete and consistent objects with logical relationships, which are available for FM applications such as maintenance management to retrieve and use during building operation phase. This is a very useful feature in supporting lifecycle project management functions. Inevitably, this approach does generate new technical challenges and it does not resolve all the problems for TOPS. Nevertheless, given the state of current IT technologies such as the Internet technologies, database systems, and object-oriented mechanisms, this approach indeed holds excellent promises in achieving many CIC scenarios in supporting data access, sharing, and exchange among AEC/FM applications. Therefore, the design of the TOPS RAF considers the support of project model-based integration to be a primary functionality. UBC Page 32 Yu, K Domain Transactional Processes Application • ^ ^ /Message / Application Message Application Figure 15: Domain Transactional Process Integration Although Project Model-based Integration continues to be the cornerstone of TOPS RAF to data exchange among AEC/FM applications, it exhibits many shortcomings (Eastman 1999). For example, numerous model-management issues remain unresolved (such as extensibility of models, supporting different application models and perspectives, version management, etc.), model-based exchange has little to offer at the level of integrating user interaction issues, and there are many situations where "shared models" are simply not desired. A simple example is a bank transfer, where a message requesting the transfer is sent from one account to another—there is no sharing of complete account information between the two accounts. The TOPS' response to this is Domain Transactional Process (DTP) Integration. A DTP is one or more inter-system sub-processes that perform a domain function. DTPs belong to the category of general application interoperability. The DTP Integration involves sending messages from one application to other applications. Messages include some type of instruction or some notifications indicating that an event has occurred. Messages may also include datasets and may result in a response from receiving applications. Examples of transaction messages include notification that data has changed, exchange of specific datasets, requests to select and highlight objects in target application, requests to switch to certain views or perspectives, etc. DTP-based application interoperability also plays an important role with respect to emerging trends in the structure of construction information technology. Traditionally, individual computer applications encompassed three main responsibilities or "layers": representation and management of domain data, application functionality and logic, and user interface/information presentation. Model-based integrated systems move much of the responsibility for the data layer away from individual applications and into distributed model-based project repository mechanisms, yet this provides little support for integration of the logic or user-interface layers. DTP integration has no such limitation; transactions can relate to data, logic or user interface issues. Thus, DTP-based interoperability provides support for the interactive workspace issues (Fischer, Liston, and Kunz 2000) that are missing from model-based approaches. Moreover, current trends in information technology systems indicate greater separation of the application logic and user interface layers, as in the systems offered by emerging e-commerce providers for the construction industry, where data and application logic components reside on service-providers' central systems while user interaction occurs through web-based interfaces. As application logic and user interface layers are split apart, the need for standard mechanisms of communicating both data and messages between components increases: a need that is addressed by transaction-based integration. The DTP integration does not replace model-based integration, but it could provide an important additional service offered by distributed system architecture. Like project model-based data exchange, however, its adoption requires formalization of the role that it should play in systems integration, industry-level standardization of transaction messages, and various other design issues. Consequently, the TOPS RAF is designed to support this feature on top of the project-model based data integration. While the data and application integration paradigms discussed in this section are the most critical ones that the TOPS RAF supports, there are also other scenarios that should be addressed (see Section 3.1.4 and 3.1.5). The detailed discussions regarding the architectural issues of this subject are contained in Chapter 5. UBC Page 33 Yu, K 3.2.3. TOPS RAF Overview The TOPS RAF is a framework of references that can be used to assist in developing large-scale software systems that fulfill the objectives of TOPS. As a foundation for discussions, a conceptual view of the TOPS RAF's system is depicted in Figure 16, in which the information about the entire construction project is represented as a project model and is contained in the project servers. The project model also has "representatives", i.e. Project Model Proxies, on local machines. Also connected to the project servers are computers and devices running software applications. These applications interoperate either directly or through the software engines on the project servers. They also contribute to, access, share and exchange the project information from the project model (or the model proxy). The TOPS RAF provides design references for developing computer systems supporting such a CIC scenario. We believe that the entirety of TOPS RAF is novel for AEC/FM applications in the context of its functional capabilities, system scope, and design approaches. However, it is also a representation of current best practices, as many of its portions are built on various system architecture design concepts and experiments from other research and development efforts (see Chapter 2). Project Model Project Model Proxy Figure 16: Conceptual View of TOPS To understand the role of the TOPS RAF in developing CIC systems, it is useful to make a comparison to the general field of building construction engineering. Both building construction and software engineering have a similar type of ultimate goal, that is, to produce a product. The product for the building construction is a physical building, while the goal for software engineering is to create a software application. Table 2 shows the major aspects of both building construction and CIC software system development and presents the role of each aspect. The design for a specific building is based on set of fundamental knowledge units, which is referred to here as the Design Reference Framework. For example, the fundamentals of building architecture and engineering define what elements (e.g. foundations vs. columns, beams, and walls, etc.) a typical building contains and how they relate (e.g. a foundation is at the bottom of a building providing support for the entire structure, while a roof is at top of the building as a covering device). These fundamentals do not refer to a specific project; rather, they provide a reference for designing specific buildings. Additionally, technologies, theories, rules, and regulations are also essential. Al l these elements provide a reference framework for designing buildings. U B C Page 34 Yu, K Correspondingly, the TOPS RAF is the CIC system counterpart aspect of the Building Architecture and Engineering Fundamentals. The TOPS RAF provides a reference architecture for developing CIC software systems, but it is not a specific system architecture for a specific application. Similarly, CIC development also requires a set of technologies (i.e. Technological Elements) and design guidelines (i.e. Design Principles). Therefore, the TOPS RAF is neither a specific system architecture nor a computer program. Based on the TOPS RAF, new types of computer software can be developed and existing applications can be enhanced. The TOPS RAF is structured by conceptual software elements. These elements are organized using the idea of architectural layers and threads described in the following sections. Table 2: Understanding The TOPS RAF Building Construction CIC Software Systems Aspect Example Aspect Example Design Reference Framework Building Architecture and Engineering Fundamentals Roles and relationships of foundations, infrastructure, superstructure, columns, beams, walls, spaces, roofs. TOPS RAF Roles and relationships of the architecture layers, threads, and their elements. Technologies and Theories Architecture, Structural Mechanics, Thermal Characteristics, Architectural Acoustics, HVAC engineering, Theory of Materials Strength. Technological Elements Information Models, Information Systems Architecture, Applications, Work Practices, Information Content Rules and Regulations Code and Standard Compliance Guidelines Design Principles Construction and Im plementation Goal A specific building Goal A specific software system Design Architectural Design and specification, Structural Design, Electrical Design, HVAC Design, etc. Design User interface design, Functional Specification, Systems Architecture Design, Component Design, Object / Interface Design. Construction Planning Selection of materials, Selection of construction methods, Selection of construction equipment Implementation Strategy Selection of software tools, Selection of software programming languages Construction Operations Construction of the building Programming UBC Page 35 Yu, K 3.2.4. T O P S R A F Layers The TOPS RAF is organized into five logical layers (see Figure 17): • Project Model Services represent real-world projects as computer models • Domain Services provide servers to manage domain functions and service applications • Project Model Proxy Services maintain project models on a local machine • Project Maintenance Services containing servers for handling project sessions, project participant registrations, and presentation controls • Applications contain domain application programs ( Project Model Services ) ( Domain Services ) ( Project Model Proxy Services ) ( Project Maintenance Services ) \_ Applications ) Figure 17: TOPS RAF Layers These layers set the "formwork" for "constructing" software systems that follow the logic implied in these layers. These layers are related according the logic set based on the services that each layer performs, while they are independent meaning that they do not strictly rely on each other in order to support domain applications. Moreover, most of the layers are also optional architectural components. That is, systems can be developed without implementing some components of a layer (e.g. a project model proxy) if that part of functionality is not supported. More detailed descriptions of each layer are provided in this section hereinafter, while detailed software component functionality of each layer is explored in Chapter 6. 3.2.4.1. Project Model Services Layer The Project Model Services layer (see Figure 18) represents a project model, which is a logical entity in electronic form that represents the entire construction project. The project is represented by a set of objects including physical buildings, building elements such as walls, windows, spaces and so on and their relations, and other information such as construction plans, tasks, costs, project participants, etc. Whilst the actual project data can be implemented in any form of persistent storage (i.e. Project Data Storage) such as databases or computer files, the project model is represented by a set of objects and their interfaces, which can be implemented through software APIs. Project Data Services are responsible for maintaining the project model data implementation, and Project Model Servers are essential for maintaining the project model objects. In the TOPS RAF, a meta-model facility can be supported for the project model data, including Meta-data Storage and Meta-data Services. UBC Page 36 Yu, K Project Model Serv ices Meta-data JStorageJ Meta-data[ Services [ Project Data Services —I Project L_Jaja_SJorage^1 Project Model Servers EP L" - O - o Figure 18: Project Model Services Layer The basic functions supported by these functional services are summarized as follows: Project Data Storage • Data storage implementations • Data synchronization • Data security controls • Data record transactions • Low-level data access interfaces Project Data Services • Import and export project models from and to external sources • Synchronize, check in and check out project model • Partial project data access services Project Model Servers • Implements and exposes project objects, their relationships and attributes; • Implements project object business logic and rules • Project objects support data access • Project objects support applications and user-interfaces • Project object transactions • Project object versioning controls • Command set including save, load, update, and fetch objects, collections, or object attributes. Meta-data Storage • Provides data storage implementation for meta-models • Implements meta-data including mapping data for project models • Low-level data access interfaces for meta-data Meta-data Services • Interfaces exposing meta-data information • Interfaces exposing project model information using meta-models • Meta-data objects • Meta-data mappings UBC Page 37 Yu, K 3.2.4.2. Domain Services Layer The Domain Services layer, as depicted in Figure 19, contains software engines that handle domain functional support through Project Model Servers. These domain services are "published" so that all applications can access and utilize them. Four basic service categories that can be used to support the "published" domain functions include: Domain Transactional Process (DTP) Services, Domain Application Servers, Domain Message Control Services and Domain Functional View Services. Domain Services Domain Transactional Process Services Domain Application Services Domain Message Control Services Domain Functional | View Services Figure 19: Domain Services Layer Domain Transactional Process Services As its name suggests, DTP Services are used to support domain transactional processes as noted earlier in the Design Considerations section. This feature supports formalized domain transactions and allows applications to register as the providers for the processes. Functions of DTP services include: Publishes standard domain transactional processes Publishes standard interfaces supporting the transactional processes Provides interfaces for applications to browse standard domain processes Allows applications to register to support the standard processes Provides interfaces for clients to use standard transactional processes through APIs , Provides facilities to control runtime transactions, e.g. monitoring transaction status, aborting transactions, transaction'failure recovering, etc. Provides messages and notifications management Domain Message Control Services While Domain Transactional Process (DTP) Services provide an essential supplement for the project model-based integration, DTP alone does not provide all the mechanisms needed for all domain function services. For example, in an interactive working environment for a construction project, applications often need to simply send some project related messages and notifications to other applications and project participants. Although some specific DTP implementation approach may still involve some particular messaging techniques, the notion of DTP (i.e. transactions) calls for integrity of the domain processes in regard to their lifecycle. This means, once an application initializes a transactional process, it expects to have the responses back. Additionally, the applications that take part in the transactional processes must commit to follow the rules and ensure to returns responses. These are all reasonable requirements for the DTP approach since it is intended to support complex domain processes. Therefore, the DTP is essentially a two-way communication process. However, as noted earlier, typical construction projects involve one-way communications. For instance, once a project management system completes a change order, it automatically sends a notification to other applications, which can in turn automatically update their datasets accordingly. Similarly, once a CAD program has made a change to an object, it can send a notification to the project "bulletin board", so that other applications can be aware of the changes, even though they are not tightly incorporated with the CAD program for any specific transactional processes. That means, once the application sends out a notification, it does not expect any specific actions to other parties. Again, these types of application interactions occur often in construction projects. Thus, it is intended for TOPS RAF to enable software systems that support these interactions. The significance is that application interoperability is dramatically improved through a very flexible mechanism in a very distributed application environment. UBC Page 38 Yu, K Domain Message Control (DMC) Services are proposed to support the message-based interoperability. The functionality supported by DMC Services is as follows: • Allow applications to "broadcast" domain related messages • Messages can be dispatched to other parties (i.e. applications and participants) • Messages can be persisted and can be dispatched at a later time • Messages can be classified into categories so that applications can register to claim the types of messages they need to receive These functions require that the message data must be structured using a standard information model so that any applications on the system can interpret the data. The meta-data about the message data must also be supported so that the DMC servers can handle software programs that deal with message categorization. Domain Application Services Unlike transaction-based integration, Domain Application Services do not provide formal definitions of domain transactions through project servers. However, they do provide facilities for any applications to publish vendor specific domain functions and register their services, which any client program can utilize. Basic functions to be supported are summarized below: • Allow applications to publish and maintain their services • Allow applications to register to support their services • Provide interfaces for clients to choose and use vendor specific but published services Domain Functional View Services AEC/FM involves many domain functions. These functions require project model objects that are handled by Project Model Server. These objects are structured based on the information model that is developed using a computer modeling methodology such as object-oriented approaches based on requirements for all domain functions. As a result, these objects, while representing a project model, are not structured in a way that is intuitive to many domain specific functions. Additionally, these objects are intended to cover all the requirements of all domain functions. However, a domain function usually only uses a subset of the entire dataset and different data representations that are derived from the common dataset - that is, a function only deals with a view of the entire project model. Therefore, the project model data structures and object interfaces are not necessarily effective to individual domain functions. To demonstrate the idea of domain functional views, Figure 20 shows an example of a "wall" object's geometry implementation. The Generic View is a simplified descriptive representation of IFC 2.0's geometry model for IfcWall. In order to support many different CAD engines, generic geometry like this is typically supported in TOPS RAF-based systems in their project models. However, these models are not necessarily meaningful to cost estimating applications. As shown in the Cost Estimate View, much simpler object attributes are usually used for cost estimating programs. Likewise, many non-CAD domain applications have similar object requirements. Rationally, data mappings need to take place in order to convert data between the different models. To support a large range of domain functions, it is necessary for the TOPS RAF to support the object information based on domain functional views, and these functional views can be configured at runtime by application developers or even end users. UBC Page 39 Yu, K Wall Geometry DAta Mapping Generic View Cost Estimate View Generic / ^ " ^ W a " ( Direct Mappings ) - LocalPlacement V J - j Representation(s) - — ^ ^ ' ; ProductDefinitionShape \ \ \ / ShapeRepresentation(s) \ \ / / 1 ShapeRepresentation A\ // i GeometricRepresentationlterfi 7 / SolidModel V/ DimensionCount / / AttributeDriyefiExtrudedSolra P a t h / / ' / ' 1 AjJ^uteDrivenE^fiuaedSegment(s) j " D e p t h (widthj/ j Position / / j Extrude'aDirection 1 - AttribuJteTJrivenProfileDefinition .RpctangleProfileDefinition • ..XDimension (height) •'' YDimension (thickness) Cost Wall Width / * Height / , . • Thickness / v NumberOfCorners ; A NumberOfIntersections / No direct \ I Mappings J Figure 20: Domain Functional View Example 3.2.4.3. Project Model Proxy Services Layer Project Model Proxy 1—r 1 Project (J j Model \ Proxy L,—1 Proxy Data CJH Proxy Services 1 Manager I — 1 1 Adapters r^ p ^ Figure 21: Project Model Proxy Services Layer Whereas Project Model Services are typically implemented on remote project servers, they can be made available to local applications through software components on users' workstations. These components can be thought of as a local copy or proxy for the shared project model (see Figure 21), i.e. Project Model Proxy (PMP) Services Layer. The local model proxy component, then, exposes the distributed information services to client applications, and handles the work of communicating and coordinating the local data with the distributed servers. This component may also implement "business logic" on the project data. The significance of this layer is to provide a facility that can dramatically improve the performance of applications accessing shared project data, either on-line or off-line. Model proxies are effective for both coarse-grained and fine-grained data exchanges. The use of project model proxies is extremely helpful for coarse-grained data exchange (see Section 3.1.4), which is required by TOPS. For example, a proxy can load and save big chunks of project information at a time into a "local model". Applications requiring a large set of project data can take advantage of this approach. PMPs support two major functions: 1. Project data access when the central model server is unavailable (e.g. when off-line). 2. Improving performance by separating data access from applications communicating to the remote project model server to applications directly connecting to local datasets. UBC Page 40 Yu, K The basic requirements for PMPs include the following: ' -• PMPs manage synchronization with shared project models so that applications do not have to add this complexity to their domain functional scope. • Applications can request granularity of transactions, e.g., commit after every object write, or after a complete model write. When an object is saved, it can either be written out to the main model immediately, or saved to the proxy until an overall save is done • Applications can request services checking in and out data sets through U l As shown in Figure 21, the PMP Services layer has three components: the Proxy Manager, the Project Model Proxy, and the Proxy Data Adapters. The Proxy Manager maintains the data in the Project Model Proxy, which is a local representation of project model. Proxy Data Adapters are used to import and export data sources for the project model. Details of these components will be discussed in Section 6.3. 3.2.4.4. Project Maintenance Services Layer The TOPS RAF emphasizes the idea of a project model server that holds the common project information available for applications to access and use. In order to support many applications accessing the project model, some control services need to be in place that handle the communications and data accesses in a unified manner. The Project Maintenance Services layer holds components, as illustrated in Figure 22, that provide these services. Project Maintenance VServices Presentation Services Project Registration Services Project Session Services Figure 22: Project Maintenance Services Layer A Project Session is a state in which an application is kept logged-on to the project model. Once an application makes a request to start a project session, the Project Session Services will start to establish the connection to the project model on the servers. Alternatively, the services can also detect the server connection conditions and link the applications to either the project model server or local model proxy. Additionally, in the case of multiple project models being supported, the project maintenance services can simply provide U l that lists the available project models for applications to use and connect to. This layer also provides services for project participants to register onto the system so that they can access project data. Standard presentation services that can be used by many applications to perform common project tasks (e.g. browsing project information) are also provided in this layer. 3.2.4.5. Applications Layer At the top of the layering architecture is the Applications layer. This layer represents all the AEC/FM applications of all types. These applications can play different roles in this architectural framework. For example, some applications will generate project data and contribute the data to the project models. Some others might just be data consumers that draw data through project models. Some programs can be domain function suppliers, and some others may serve as domain transactional process providers. Devices such as palm PCs also belong to this layer. Internet portals can participate in the integration scheme just as other applications. Since the layers are optional elements, the applications do not have to participate in the entire system through a specific layer (although it is generally preferable if they do). In other words, the applications can choose to connect to any components of any layer directly, and these connections are made possible through the Adapters (see the next section). UBC Page 41 Yu, K 3.2.5. T O P S R A F Threads The architectural layers form the basic logical building blocks for the system. However, the operations of the system are made possible through the architectural "threads" that ensure the system connections and communications. Three major threads are considered significant in the framework: Standard Information Models, Standard Software Interfaces, and Adapters (see Figure 23). This section explains the functionality of these threads. Standard Software Interfaces Project Model Services 4P> <Adapter> <Adapter^> 1 Standard Information Model Domain Services Project Model Proxy Services Adapter Adapter Project Maintenance Services Applications Figure 23: TOPS RAF Threads 3.2.5.1. Standard Information Models A Standard Information Model (SIM) is a conceptual model supporting the data representations across the entire system. At the Project Model Services layer, the Project Model is directly based on the standard information model represented through a set of software interfaces. Although the underlying implementation data structure of the project data store is not necessarily based on the standard information model, its data context and scope correspond to what is defined in the SIM. An important requirement of the TOPS RAF is that different SIMs can be loaded at runtime. This, in turn, requires that a set of standard generic interfaces be implemented as the bottom level of the Project Model interfaces. On top of these generic interfaces, explicit project model interfaces can still be supported. A common misconception is that a SIM is only needed at the Project Model layer, specifically, supporting the project data store and project model. In fact, the TOPS RAF stipulates that all of the data integration implications at different layers can use the same SIM for the project, while other types of individual models, e.g. application models or customized mapping models, can still be supported. Particularly, a SIM for a project should also be used to support the Local Model Proxy. Additionally, data exchange between two applications can also use the same model, while using different data exchange modes. For example, if IFCs are used as the SIM for the central project model, which applications can access through their IFC adapters, IFC files can also be used for application data exchange, possibly via the same application adapters. This approach eases the development of applications using the TOPS RAF. Moreover, more applications can join the system over time to exchange project information since the standard information model is used across the system for different data exchange modes. Therefore, a SIM is truly a critical "thread of rules" that governs the consistency of information representations throughout the entire system. UBC Page 42 Yu, K 3.2.5.2. Standard Software Interfaces Software interfaces, which can also be referred as Application Programming Interfaces (API), define the agreements and specifications on how data are exposed (i.e. accessed from a client perspective), and how services are provided (i.e. requested from a client perspective). The standardization of the interfaces is key to data exchange and interoperability of the applications. They also hide much of the data management complexity. Generic Object Interfaces 6 6 6 6 6 o. 6. lObject / IRelationship / lAttribute Specific Object Interfaces 6 6 6 6 6 6 0 IProject / IBuilding /IWall Figure 24: Generic Object Interfaces The TOPS RAF stipulates that a standard set of generic and late binding interfaces (but early binding interfaces can also be supported in conjunction with the late binding interfaces) should be supported by all software interfaces of any component, object, and application (through their adapters) in the system. Figure 24 shows some examples of generic interfaces, which are aimed at exposing object information at any object abstraction level across the entire system; these include specific application objects, common project objects, and meta-models. The generic interface approach ensures powerful data accessibility—key to data integration and to streamline the application interoperability. Other early-binding and explicit interfaces can still be supported on top of the generic ones (see Figure 24); however, this support is optional. One much desired feature of the TOPS RAF supported systems is the capability for applications to plug-in and plug-out: "plug & play". This is considered to be a "must-have" application deployment feature for a large distributed system since a complete re-installation for such a large-scale system would be impractical. 3.2.5.3. Adapters The "Adapter" in this context represents a logical component attached to a program in order to connect to another party in the system. The data and operations supported within any application must be mapped to the shared data and operations available within the integrated system. This mapping is carried out by an application-specific adapter software component. Depending upon the nature of the application, an adapter may be encoded within the application itself, may be an add-on or macro within the application, or may be a separate program that interacts with the application through the application's API or operates on the application's data files. Adapters may be needed at any layer for applications or service components. Thus adapters, all the way through the system, provide a thread that connects and integrates all of the parts of the entire system. UBC Page 43 Yu, K 3.2.6. Design Principles Based on the TOPS RAF architecture presented in the previous section, it is useful to define a set of design principles as references for systems that will be implemented in compliance with the TOPS RAF. While specific and detailed principles should be defined for a TOPS RAF-based system, some of the focal ones are summarized as follows: • Systems should be designed in a way that they do not require specific operating systems and platforms, nor do they require specific software programming languages. • A set of standard interfaces representing a project model must be supported. If possible (but not mandatory), the same conceptual model should be used supporting the project model and other data exchange interfaces. • One set of basic generic interfaces must be supported at all levels of APIs exposing object information so that any types of applications or components are able to retrieve object information, either through early binding or late binding. • A set of standard interfaces representing domain functional services must be supported. • A set of standard interfaces representing domain transaction processes must be defined. • Software facilities or servers must be designed based on a system architecture that allows applications to be adapted at runtime supporting or requesting domain functional services or transactional processes. • Participating applications should be able to perform the same data integration and application interoperability schemes, either through networks or locally (i.e. on-line or off-line). Adapters can be used to handle this requirement. • Applications are able to connect to data sources or other applications through adapters. • Applications can be added to or removed from the system seamlessly at runtime without breaking the system operations. » The system should allow expansions and extensions of domain service components to the system at runtime. • The system should allow business objects to be added without breaking the existing system at runtime. • Various mapping mechanisms and tools should be provided for both information model mappings and data mappings. 3.2.7. Configuration Variations Although the architectural components described in this chapter represents a typical—or reference— architecture, a wide range of variations are both possible and required. The layering and threading architecture proposed supports different implementation mechanisms or configurations. For example, a typical configuration might involve the central database and a data server component that interacts with model proxy components across an Internet or Intranet connection. Alternative configurations could include distributed data sources, where the central database is replaced. with numerous, distributed, heterogeneous data sources, and approaches that rely on file exchange between model proxies with no central database. UBC Page 44 Yu, K 3.3. Chapter Conclusion This chapter provides a thorough overview of the TOPS RAF as an aid for enabling multiple AEC/FM applications operating in a widely distributed computing environment to participate in a high degree of data integration and application interoperability supporting CIC. While each of the TOPS RAF elements is not revolutionary in its context alone, the notion of a massive distributed system supporting a large variety of different kinds of applications interacting based on standard information models and transaction processes across major industry domains is indeed innovative. To place a foundation for understanding the TOPS RAF, a high level architecture of the TOPS RAF is presented. There are five basic elements identified in TOPS, and each of them alone requires extensive research. The "Information Models" technology element is an integral part of the TOPS RAF. It is also a major contribution in this Ph.D. research and will be comprehensively covered in Chapter 4. The architecture of the TOPS RAF is also a critical arena. Key technologies required to develop the details of this architecture are various data integration (DI) approaches and application interoperability (APPI) methodologies. As a contribution of this Ph.D. research, Chapter 6 will provide a detailed summary of various DI and APPI paradigms, many of which are supported by the TOPS architecture. Based on the underlying TOPS RAF architectural foundation, with Chapter 5 and Chapter 6 as essential super-structures, Chapter 7 specifies the detailed conceptual elements of the TOPS RAF, including their functionality and functional relationships. UBC Page 45 Yu, K Chapter 4: Information Models for AEC/FM Chapter Abstract: This chapter discusses various fundamental issues regarding information models and modeling techniques, especially as they are applied in AEC/FM applications. It reviews a number of major international conceptual data modeling efforts for the AEC/FM industries. To date, the largest standard domain model in AEC/FM is the Industry Foundation Classes (IFC) model developed by the International Alliance for Interoperability (IAI). This chapter explains the information models developed in this research, which have been developed in conjunction with the Release 2.0 of the IFC effort. It also discusses in detail the IFCs' support for construction and project management applications. A cornerstone of the TOPS RAF is the ability to exchange and share project information, thus allowing the industry's widespread variety of computer applications to interoperate. A key technology required to enable this interoperability is high-level model standards for representing and communicating project information. The process of formalizing these standards using computer languages is, as referred to in this dissertation, information modeling. Today, the role of information modeling for data exchange and sharing among multiple types of applications for a major industry is widely recognized. However, the field is not yet mature enough to have adopted any standard development mechanisms, approaches, or terminologies. Standard information models and modeling for AEC/FM are portions of the primary contributions of this research and a key technological element of the TOPS systems architectures. This chapter covers various basic aspects of information models that are essential for the AEC/FM models, but also are applicable to general computer information modeling practice. It also discusses issues about developing large-scaled domain standard models that support many different types of applications used in a specific domain project. The chapter then focuses on models that are developed for AEC/FM applications. It reviews the scope and status of the current developments of several important AEC/FM modeling efforts. As part of our research effort, we have also participated in today's largest standard model effort for the AEC/FM industries -the IAI (IAI 1996), and we have contributed our modeling efforts and research results directly to the development of the IAI's IFCs. Consequently, many of the models discussed in this Chapter are contained within the IFCs Release 2.0 (IAI 1999). The chapter also discusses the IFCs' ability to support construction and project management applications. 4.1. Context of Information Modeling Computers were invented to reflect and deal with real world problems, which, in turn, concern real-world objects. In order to do so, computer applications must capture and use the information about these objects. When the object information is captured in computer systems, it must be represented using computer data structures. Furthermore, these data can be thought of as abstractions of object information in computer formats (i.e. data structures). Different types of computing require different abstractions and types of data structures. Bjork (1992) has taken the approach of layering the computer information types to represent the different levels of these abstractions. This approach calls for four major formal types of information representations: actual real-world objects, conceptual models that define the semantics of the objects in computer formats, implementations of the conceptual models, and the actual instance data based the conceptual and implementation models. UBC Page 46 Yu, K Reality represen ted in computer by * Data Layer Computer Object Instances J described in Physical Data Format (PDF) specified by ^ Physical Data Format Language (PDFL) Model Layer provides object contexts and semantics for" Conceptual Object Model Modeling Language described by Figure 25: Data Representation Scheme Adopting the idea of separating conceptual models from implementation, we have developed an alternative model-layering scheme useful for data modeling discussions. Figure 25 shows one way of describing the computer data representations of real-world objects and presents the terminologies for use in further discussions. In this scheme, a real-world object can be thought of as being represented in computer object instances using a Physical Data Format (PDF). The PDF is specified by a computer language (i.e. Physical Data Format Language, PDFL) that is invented to stipulate the rules for formatting data. The object instances are created based on the object contexts and semantics defined in a Conceptual Object Model. Represented through a computer modeling language, the model governs what object information should be captured and how it relates to other information. Throughout the discussions regarding information modeling and data integration in this dissertation, this data representation scheme will be used as the basic framework. Also based on this framework, this chapter explores some detailed modeling issues, as they are key elements in generic data modeling fields and, more specifically, to CIC systems such as TOPS for AEC/FM. 4.1.1. Modeling Object Aspects A computer information (or data) model encompasses representations of real-world objects using computer software data structures. The real-world objects can also be described as having basic characteristics. Information about these object characteristics is what computer systems must capture and use in their applications. An information model is essentially a collection of objects of a specific domain or major function field. These objects possess these characteristics, which, in their entirety, serve as the data sources for applications to use. Information modeling is a process of identifying these objects and their characteristics, and documenting them using formal modeling languages. In the context of data modeling, there are two types of objects: physical objects and abstract objects. The physical objects are substances that have material existence. Many physical objects also have a body and shapes. On the other hand, abstract objects are concepts used in practice that express qualities apart from physical objects. Typically, abstract objects do not have concrete material existence. A real-world object has various aspects that need to be represented and captured in computer formats in order to be used in computing systems. The systems dealing with complex domain problems such as AEC/FM require comprehensive object aspects so that sophisticated business processes can be supported. Figure 26 illustrates the basic aspects of an object. UBC Page 47 Yu, K Figure 26: Object Aspects • Accessibility: an object can have a collection of rules that stipulate who has what privileges to access and use the object's characteristics. This feature is especially important in a multi-user system environment. • Appearance: is the external look and material patterns, especially as it is represented in a CAD application. Unlike object shapes, which should be characterized using object geometry properties or relationships, the appearance concerns the look and feel of the object. The appearance is an important aspect in certain types of applications such as CAD or product catalog selectors. The appearance aspect only applies to physical objects. • Behaviors: are "reactions" to changes made to the object, related objects, or to the executions of object methods. Standard behaviors are key to application interoperability. • Constraints: are rules of an object that govern certain object property values. Constraints are essential aspects used to support object characteristics and business rules. • Identities: Identities arise from the uniqueness of the individual objects. To facilitate the life cycle and versions of the objects, identities must be explicitly supported in the object context. • Methods: are functions that expose or change object states (e.g. property value changes), or perform actions. Methods are executable operations supported by the object, and they may or may not be available to external entities (i.e. objects, applications, or users) to use. • Ownerships: as its name suggests, objects are owned by applications or users. The ownership is also key information in object accessibility control. UBC Page 48 Yu, K • Properties: are values of qualities that an object possesses. • Relationships: unlike the "Properties" that are possessed directly by the object, relationships to other objects are associations between the objects. • Services: A service consists of a group of methods that are exposed to, and thus can be used by, external entities (i.e. objects). The distinction between services and methods is important in designing object-oriented systems since services are usually matched to application programming interfaces (APIs) that are exposed to external entities, while methods supply the implementations for the APIs. • State: is an object aspect that represents the status of the object. Basically, a state is represented by the entirety of the values of all the object properties and the execution status of the object methods. It is also affected by the property values of the related objects. • Versions: object versions are different "proposals" or "editions" of the same substance. The concept of object versions is essential in many design and management applications. The versions are also tightly related to object identities. In addition, the data type of the versions is not always as simple as a string or number. Some applications can require quite complex context information regarding object versions. For example, relations between different versions of the objects may need to be explicitly represented. • Views: a view consists of a collection of references to a set of object properties, relationships, methods, and services. The views provide a mechanism allowing applications and users to access or use only certain parts of the object's characteristics. The views extend the intelligence of the objects because they enable more controls to the object accessibility for the systems that support the objects. These capabilities supported by the object views are crucial in integrated systems that must support multiple applications and many different users. To further explain the concepts of these aspects, Table 3 shows the sample characteristics for a real-world object, i.e. a door, as it is designed and built in an integrated AEC/FM system. Some of these characteristics, such as properties and relationships, are well established and broadly supported by computer programming languages or conceptual modeling languages. Others, like ownerships, are not widely recognized or supported by computer or modeling languages since they are not considered crucial requirements in traditional stand-alone systems. Some object characteristics are only supported in certain types of applications since they are crucial elements only for those application types. For example, views are commonly supported by database management systems (DBMSs), but are not explicitly or extensively supported by most object-oriented languages such as C++ or modeling languages such as EXPRESS (ISO 1991). Formalized support of these object characteristics in computer modeling languages and programming languages is highly desirable in designing and implementing complex large-scale integrated systems that support many application types and users. Table 4 shows some of the common support of object characteristics in today's computer languages. As can be seen, the object characteristic support in today's conceptual modeling languages is indeed limited, while programming languages and some specific computing systems have been dramatically improved in this area. In spite of this limitation, complex systems such as TOPS for AEC/FM can still be developed. However, in order to do so in the most effective and efficient manner, this research calls for extensive future developments of conceptual modeling languages in this area. While understanding of the entire picture of object characteristics is critical in designing large-scale integrated systems, object characteristics are meaningful only within a context of an application scope. Not all kinds of computer systems demand all of these object aspects to be modeled and captured, nor do all the objects of a given domain have these characteristics. In other words, capturing the characteristics of objects is not an isolated task; rather, it requires identifying the information requirements and their usage scenarios for the application processes that need the object information. UBC Page 49 Yu, K Table 3: A Sample For Object Aspects Aspects Door Properties Height = 9 feet; OpeningHeight= 0; Type = GarageDoorResidential Relationships Attached to the wall opening; Has Electrical Opener; Has cost objects; Constraints Height >= 8 feet Appearance DoorOakPanel White. gif Ownerships Building Owner; Different costs can be created and owned by different cost estimators; Identity {F3A2302B-4521-4795-A17A-C1F1C64931A2} Version Design.Proposal.2; Base Version=Design.Proposal.l; State Half-Open {Door.Open returned true; OpenHeight = 3 feet;} Methods Door.Open; Door.Close Behaviors OnWallMove->Move Services ArchitectService {GetHeight; GetType; GetFinalCost; GetAttachedWall;} EngineerService {GetHeight; GetType; Door.Open; Door.Close;} Views CostView {Properties (Height,Type); Relationships (wall, cost objects that owned by this role); Constraint (Height>=8feet); Services (CostService); Accessibleness (CostEstimator); Appearance (DoorOak6Panel White .gif)} Accessibility Role: Architect - read and write Role: Scheduler - read only Role: Cost Estimator - read only Table 4: Computer Language Support For Object Aspects Aspects General Support in Computer Programming Languages General Support in Conceptual Modeling Languages Properties Yes Yes Relationships Yes Yes Constraint Not explicitly but can be implemented Yes, in some languages. Appearance Not explicitly No Ownerships No, but can be implemented in some systems such as COM+ in conjunction with Windows 2000 and SQL 2000 No State Not explicitly No Methods Yes No, but some languages such as EXPRESS have some level of method support. Behaviors Yes, in some modern languages No Services Yes, through standard API mechanisms such as COM/IDL No Views Not in all languages, but can be supported by certain systems such as DBMSs. No Accessibility Not in all languages but can be supported by certain systems such as DBMSs. No UBC Page 50 Yu, K 4.1.2. Modeling Conceptual Models Many different model types can be developed for different purposes. Froese (1996) summarized several types of information models and their intended uses: ' • Type model • Core or reference model • Conceptual model • Application model • Aspect model or property model • Classification systems model In practice, some models can also be developed that combine the characteristics of two or more of these basic types. Most relevant in this research is the type that possesses the characteristics of both the conceptual and aspect models. As indicated in Froese (1996), conceptual models (or core models) provide formal and high level definitions of the basic entities and relationships required to represent information about some domain. Conceptual models map the semantic contexts and properties of real-world objects and their inter-relationships to a computer format. Therefore, for example, a wall is represented in a computer as a "wall" object (i.e. rather than a series of lines) that contains semantic attribute values, such as its thickness, material properties, etc. The most typical application of conceptual models is a core model for a major business domain. Such a core model contains classes that support the common information used by different domain applications for data sharing and exchange purposes. Core models support comprehensive object information at a high level. For instance, models that only support one specific application type such as CAD are not core models for AEC/FM. An example of the core models for AEC/FM is the set of the IFC classes at the IFC Core and Interoperability Layer (IAI 1999). Core models must represent the common requirements of all the applications supported. In the context of this dissertation, the terms "Conceptual Models" and "Core Models" can be used interchangeably. Conceptual Model Characteristics Conceptual models are intended to provide a unified reference for a large variety of application types that are based on various application models. Thus, they must be neutral, supporting the following types of independence: • Modeling language independence: that is, the same set of models can be represented using different modeling languages. • Specific or local industry data references or classifications format independence: that is, conceptual models should not be structured based on a specific (e.g. regional) classification system that attempts to classify project information into different hierarchical categories for referencing purposes. • Persistent data structure independence: that is, the instances of the models can be stored in different physical formats. • Implementation programming language independence: this is, the model can be implemented in any programming language. • Implementation operating platform independence: that is, instances of the model can be stored in computers running on any operating platform of the user choice. UBC Page 51 Yu, K Figure 27: Conceptual Model Language Support Although conceptual models must be described using a modeling language, which typically implies a certain type of data modeling methodology (e.g. object-oriented modeling), they are independent of any specific modeling or implementation approaches. More specifically, once a conceptual model is defined and documented in one language, it can be converted into another modeling language to represent the same model scope and context. Note that not all the modeling languages support the same notations or modeling elements. Model language mapping specifications are essential in using multiple modeling languages. Figure 27 represents the relationships of conceptual models, modeling languages, and implementation languages. While conceptual models are not necessarily intended to be instantiated for storing actual data in a specific types of applications, they can be used to create runtime objects for purposes of both data exchange and shared project data repository. Additionally, different data implementation methods can also be used to persist the data instances. For example, once a conceptual model is defined using EXPRESS, the object instances can be stored in ISO-STEP Part 21 File (ISO 1992b). Alternatively, a relational database system or X M L (W3C 1998b) and DOM-based files (W3C 2000a) could be used to store the instance information. The requirements for doing so are as follows: • The implementation provides an appropriate entity relational schema or X M L schema that supports all the object context of the original model; • The implementation provides the specification of the mapping between the physical data structure used for implementation (e.g. XML) and the models (e.g. EXPRESS). More detailed data mapping schemes are covered in Chapter 5. Conceptual Model Development Process Conceptual models are developed to support data representations for computer applications. Hence, their development must be based on the requirements provided by these applications. The primary development methodology of a conceptual model is based on the information analysis of typical industry functions and processes of the concerned domain. From this analysis, common process information requirements will be identified and modeled. Although variations can be applied in different projects, the following general development procedure should be followed in most cases: • Define the intended uses of the models • Identify the software applications to be supported • Identify use cases and processes to be supported • Identify process steps, including choosing a process modeling language • Analyze process information requirements • Model the information requirements, including choosing a modeling language and documentation • Implement and validate the models UBC Page 52 Yu, K 4.1.3. Modeling Large-Scale Domain Conceptual Models A large-scale domain conceptual model (LSDCM) such as one for AEC/FM is usually intended to support data exchange and sharing among many different types of applications that access, exchange, and share from a huge amount of information within the domain. However, different applications require either different data or the same data stored in different formats. To take some examples from the AEC/FM domain, CAD applications would require detailed geometry information for physical building objects, while for the same objects, cost estimating software needs to know about the specifications, object style details, and parametric dimensional data (i.e. height, width, etc). Similarly, a scheduling program would be interested in the resource uses and process assignments to the objects, while a procurement application is concerned about the object material decompositions (i.e. bill of materials) and cost data from the suppliers for these types of materials. LSDCMs can be developed for different implementation objectives. However, since the effort to implement several LSDCMs always tends to be overwhelming, it is preferable that one standard LSDCM be used in different data integration scenarios (see Section 3.1.4). For large integrated systems such as TOPS for AEC/FM, it is vital that a LSDCM can be used to support a repository of object information about a real-world project, i.e. Shared Project Data Store (SPDS). More detailed discussions about SPDS will also be conducted in Section 5.1.4. This modeling goal inevitably raises the level of requirements for the LSDCM. Hence, the scope in LSDCM is much broader than that in a typical software application. As a consequence, modeling a LSDCM has many different requirements - much keener challenges in applying appropriate procedure and modeling mechanisms. This section addresses the issues involved in developing such a LSDCM. LSDCM Objectives The objectives for a LSDCM can be generally considered as supporting the following abilities: • Different data integration scenarios should be supported, including direct application data exchange or shared project data stores. • Multiple different application types should be supported by providing different model views and data types. • Object type definitions can be used to instantiate objects. • The data structure of the objects should be constructed in ways that support actual software implementations effectively and efficiently. • Intended uses of object aspects should be explained explicitly; ambiguous modeling styles should be avoided. • The models should be developed in such a way that their software implementations can be based on any operating system and using any programming language. • The models should be comprehensive and generic so that they can be described using other modeling languages. • The models should be generic and comprehensive enough to support any specific classification system model; the objects should not be structured based on a classification model context, e.g. an object hierarchy for a classification model. UBC Page 53 Yu, K The Basic Procedure In general, the basic procedure for developing a LSDCM approximately parallels regular conceptual model development procedures. Several specific recommendations are made in this research. • Define the intended uses of the models A LSDCM is typically not intended to support a specific computer program; rather, it is usually developed to support data integration (i.e. data sharing or data exchange) for multiple applications. Identifying the intended usage of the models is critical since it affects many technical decisions during the entire downstream development process. • Identify the software applications to be supported As mentioned above, a LSDCM is to support data integration among multiple applications. Some modeling developments start from identifying industry processes based on model developers capturing industry practices. This approach could potentially cause a problem in controlling the model scope. That is, the resulting models can fall outside the scope of what most relevant available software applications currently support or are able to implement. We believe identifying the intended applications, which will implement the conceptual model at this step, is critical to control the scope of the models. This also ensures that the models can be implemented in real software. • Identify use cases to be supported A use case in this context is not necessarily the same as one for a specific application. For a LSDCM, a use case is a scenario in which the identified applications exchange or share project object information. Identifying these use cases is a basic step for identifying what data will be exchanged and thus need to be modeled. In developing a LSDCM, this step also verifies that the models to be developed can be used for the intended purposes. • Identify processes to be supported Based on the use cases identified, application processes supporting the use cases should be identified. This step also discovers the transactional procedures (i.e. the sequences of the processes being invoked) between the processes in order to imply the use scenarios. These process sequences (or transactions) can also be formalized to support comprehensive data exchange scenarios depending on the purposes of the models. Basically, this step sets the actual scope of the LSDCM. • Identify process steps, including choosing a process modeling language For each of the processes identified, more detailed breakdowns need to be developed. This step requires the use of a formal process modeling language in order to identify the information requirements effectively. Choosing an appropriate language is important, and it can be affected by many factors, including the intended use of the models. • Analyze process information requirements Once the detailed processes and their steps are identified, information requirements (i.e. input and output data types) can be captured for each process and each step within the process. The identified information is the foundation for the data models. UBC Page 54 Yu, K • Model the information requirements, including choosing a modeling language It is common in LSDCM scenarios that the same type of information is required by multiple processes or multiple steps in one process. The information requirements captured in the last step need to be further analyzed in order to identify their commonalities. The requirements then must be documented using a formal modeling language appropriate for the intended use of the models. It is normal that a model needs to be documented in different languages to support different implementation technologies. This is a step of information abstraction in which information types are represented through objects and their characteristics. • Document specifications and usage methods of the models Although the context and semantics of the models are explained using the model languages, most LSDCMs require additional documentation using human readable languages. These documentation provide specifications for intended uses of the models. • Model validations There can be various techniques for validating a conceptual model. Different levels of validations may be needed. For a LSDCM, the validations should be performed through the use of the intended applications. 4.1.4. Modeling Processes and Domain Transactions The development methodology for a LSDCM calls for analyzing specific industry processes and developing detailed use cases of the way in which the models could be used to support domain work practices. However, these use cases are usually developed in an ad hoc manner and they are used to support model development only. In contrast, some data standards being developed for some industries include standardized specifications of specific partner-to-partner business transactions, for example, the Partner Interface Processes defined by the RosettaNet effort for the electronics industry (RosettaNet 2000). These "transaction standards" are developed in addition to the data model standards, and they set out the context and criteria under which the data exchange occurs between partners. One of the obvious advantages of transaction-based interoperability is that applications do not need to share or exchange entire sets of the project data. Data are exchanged based on demand. One characteristic of transaction approach is that the participating processes must follow a certain set of rules that ensure the data consistency and business conventions. Many Internet based e-commerce scenarios call for domain based process transactions. To enable a LSDCM to be used in sophisticated application integration scenarios, domain standard inter-processes (i.e. transactions) should be developed. This effort can be incorporated into the LSDCM development. With regard to process modeling languages, there are a number of them currently available. Several examples are: UML's activity diagrams (Rumbaugh, Jacobson, and Booch 1999), IDEFo (IDEFo 1981), or X M L . While these methodologies could be used for defining transactions, none of them were created explicitly to support transaction modeling. The elements for modeling standard transactions are basically: "transaction name", "transaction data (this is based on the conceptual model)", "transaction return data (this is based on the conceptual model)", and "transaction rules". A "transaction modeling language" must support these elements in its modeling notations. Additionally, to describe transaction scenarios, actors and application types should also be represented along with the transactions. The implementations of transactions can be in different forms, while requests for transactions are desirable in the form of computer messages, which are text based and system independent, such as X M L . UBC Page 55 Yu, K 4.2. Domain Conceptual Models for AEC/FM Many efforts are underway to develop large-scale conceptual models and to establish them for use throughout various industry segments for the AEC/FM industries. In our research, we have conducted thorough investigations on many of these efforts. This section summarizes some of the major modeling developments for the AEC/FM industries. 4.2.1. Challenges for Modeling AEC/FM Objects The information modeling for the AEC/FM is exceptionally challenging. First, the AEC/FM objects by nature are multifaceted in terms of their object aspects. There are many types of AEC/FM objects and each type possesses different characteristics, as summarized in the following list: • Complex building products with detailed geometry data • Product and process relationships and roles such as controls and resources. • Project management concepts and documents, • Library and classification information • Type information (e.g. product types, process types, etc.) • Cost and financial aspects • Lifecycle object management • The inter-relationships among all of these Second, there are very many different application types involved in an AEC/FM project. The various data integration and application interoperability scenarios and system architecture possibilities for these applications require extremely comprehensive support of object characteristics and views. This heightens the challenges for modeling a LSDCM for this industry. 4.2.2. Industry Foundation Classes (IFCs) Within the building construction industry segment, the current largest data modeling effort is by an international industry-based organization named the Industry Alliance for Interoperability (IAI) (IAI 1996). Started in 1994, the IAI develops data standards for AEC/FM projects called the Industry Foundation Classes (IFCs) (IAI 1996). Releases 2.0 (IAI 1999) and 2x of the IFCs has now been distributed and is beginning to be supported by commercial software companies while release 3.0 is currently under development. Although much of the initial focus of the IFCs has been on representing the physical components of buildings themselves (i.e., the product models), the scope of the IFCs also includes non-physical project data such as construction tasks, documents, costs, organizational aspects, schedules, construction resources, and other types of information. As a part of this research effort, we have been active participants in IAI in activities such as domain project developments, IFC developments, and IPC implementations. As one of the contributions of this research, more detailed discussions regarding the IFCs will be covered in Section 4.3. UBC Page 56 Yu, K 4.2.3. ISO-STEP The Standard for the Exchange of Product Data (STEP) develops data exchange standards for building products under the International Organization for Standards (ISO) (ISO 1994). The formal name of STEP is ISO Standard 10303: Industry Automation Systems & Integration and Industry Data. Beginning from mid 80's, STEP has delivered numerous standards (i.e. STEP parts), among which are its data modeling tools and methodologies that have been used, in many major data modeling developments. Before the IAI, STEP had been the major standard data model development effort for the AEC/FM industries. STEP Development Methodology The basic development methodology, as described in Al-Timini & MacKrell (1996), is illustrated in Figure 28: Application Activity Model (AAM) Application Reference Model (ARM) Application Interpreted Model (AIM) Application Protocol (AP) Application Interpreted Construct (AIC) Integrated Resource (IR) Figure 28: STEP Development Methodology • Application Activity Model (AAM): is a model that represents the processes of the application described using J D E F 0 . The A A M also provides the information requirements for the ARM. • Application Reference Model (ARM): is a collection of entities and relationships based on the information requirements from A A M . The ARM is typically documented using EXPRESS-G (ISO 1991), or IDEF1X (IDEF1X 1993). , • Application Interpreted Model (AIM): is the detailed representation of the ARM, which provides fully defined entity attributes and refined relationships for implementation purposes, and is fully integrated with other STEP parts. The ATM also provides a reference for the AP, AIC and IR models. • Application Protocol (AP): An AP is a STEP part that contains the data model specifications for one specific application area. Each AP contains an AIM plus reference AAMs and ARMs as described previously. In order to manage and maintain the models efficiently, common objects used by multiple APs are collected into the Integrated Resource (IR) and the Application Interpreted Constructs (AIC). While the IR contains the most fundamental model elements, the AIC represents identifiable sections in a specific domain. UBC Page 57 Yu, K STEP Technology Software Adoption A great deal of quality work has been done in ISO-STEP. Some of its technologies, such as modeling tools, have made good contributions to the data modeling fields. Some of the STEP standards (e.g. APs) have also been implemented in certain specific application domains. Nevertheless, the STEP has not yet demonstrated tremendous success in obtaining widespread acceptances and implementations in the building construction industries. Several causes are observed: • The ISO-STEP communities have not really publicized these technologies to a broad range of software vendors. Lots of popular AEC/FM software companies are either unaware or unfamiliar with these technologies. • The STEP development processes are considered difficult to understand and implement. The complexity of the processes and modeling requirements may require a great deal of resources and can be overwhelming to many software vendors. As a consequence, the STEP standards developments can arguably be slow in meeting the demands of software deliverables. • Generally, the STEP technologies are not in full harmonization with many popular IT solutions for which pervasive types of software tools are available (e.g. RDBMS, object-oriented programming languages, UML, COM, XML). STEP technologies are heavily dependent on EXPRESS for information modeling, Part 21 for Data Persistency, and SDAI (ISO 1992a) for data access. Although tools for mapping these legacy technologies to new ones can be developed to accommodate this technological gap, they do not always provide easy-to-use, thorough, or most-efficient solutions (Verhoef, Liebich, and Amor 1995, West 2000). • Similarly, the pervasive use of the Internet has dramatically accelerated the demands for client-server software systems that support many applications to access the same data sources. The direct-data-exchange oriented STEP technologies fall short in many technical aspects in being adopted in the new Internet paradigm. 4.2.4. Var ious A E C / F M Conceptua l Models While the IFCs and STEP models may be the two most significant efforts, they are not the only models for the AEC/FM. Conceptual model development for the AEC/FM industries started in late 70's with a primary focus on building product models (Eastman 1978). That work provided the fundamental ideas of using conceptual models to support applications to exchange data. Some more extensive developments unfolded in the 80's. A number of significant efforts have been reported over the past decade as summarized in Froese 1996, while the following is a list of some early innovators in the 90 's: • The General AEC Reference Models (GARM) (Gielingh 1988) developed at the Dutch research institute TNO: that provide a high-level general reference model for AEC product-definition data. • The American AEC Building Systems Model developed at the University of Michigan (Turner 1990): that is a sophisticated product model built on the "AEC Global Model" framework. • The General Construction Object Model (GenCOM) (Froese 1992), that defines a set of object types and their logic links central for construction management. • The Unified Approach Model (Bjork 1992), that is aimed to provide a generic conceptual model framework to support modeling of all kinds of project information for AEC/FM projects. UBC Page 58 Yu, K • The ATLAS LSE Project type Model (Tolman, Bakkeren, and Bohms 1994), that is an abstract model largely based on STEP resource model to support different specialized functional views in a large-scale engineering project. • The Generic Reference Model (Reschke and Teijgler 1994), that intends to provide a reference model for the uses of objects across life-cycle of an engineering project. • The Building Project Model (BMP) (Luiten 1994), that emphasizes the progression state aspect of building objects that are related to construction activities and resources. • The models developed in Information/Integration for Construction (ICON) project (Aouad et al. 1994): that addresses construction management processes. • The RATAS Models (Mottonen 1995): that uses product models to represent the requirements of facilities maintenance and operations. • The Integrated Data Model of the COMBINE project (COMBINE 1995): that supports building design processes. Some of these models attempt to cover multiple project development phases. Others, however, focus on a more specific domain such as design or construction management. In late 90's, in addition to ongoing work on the IFCs and several STEP models, more conceptual models were developed for the facilities management area, including the following: • Object-oriented Model for a Facility Information System (FMIS) (Bos 1995): that stressed the need for comprehensive FM models, data repositories, and usage requirements in an integrated FM system that must be flexible to changes and must provide a uniform language and intuitive user interfaces. • Information System for Facility Management (ISFM) (Majahalme 1995): that included both products and FM processes at a high level and attempted to formalize the FM data transformation methodology through the models for a documentation system. • Integrated Facilities Management Information System Based on STEP (Cheng, Patel and Bancroft 1996): that integrated a CAD system with an asset and maintenance management system and a building energy management system. The project also suggested a STEP-conforming system architecture for integrated F M systems and specified a generic product data model to support the data shared by the three integrated systems. • The KBS Model (Svensson 1998): that, based on a set of standard national building product classification tables, covered building products in different model views such as spatial systems, building technical systems, construction sections and construction parts. Al l these efforts, as well as the IFCs and STEP models, demonstrated the need for explicit and integrated conceptual models for AEC/FM application integration and set good examples for future development in the area. Some of these projects also suggested and implemented system architectures based on the models developed. Nonetheless, none of these models have found general acceptance among popular commercial software applications for AEC/FM. 4.2.5. AEC/FM Standard Process Models AEC/FM projects are process oriented - design to construction project management. In a construction project, business transactions among different project participants (and thus the computer applications they use) are common practices. Computer supports for the automation of these transactions are critical in achieving goals of CIC. UBC P a g e 59 Yu, K Most previous research in information modeling for AEC/FM has focused on the product or project data models. There are some efforts on developing formalized processes for the industry. However, these process models are either not intended to or difficult to directly support software implementations. For example, the Integrated Build Process Model in Sanvido (1990) provides a high level AEC/FM life-cycle process framework. It may well be useful as a high level reference for understanding AEC/FM processes or identifying areas for software solutions, it is not at such a level that is detailed enough for directly supporting software developments. Today, the most recent critical industry-wide efforts such as IAI do not emphasis the standardization of domain processes or business transactions. This research has found no standard models that represent business transactions in an AEC/FM project. Given the industry trend of IT uses for the AEC/FM, Froese and Yu 2000 observes the needs for the transaction standards in AEC/FM projects and urges the development of these standards. 4.2.6. AEC/FM XML Schemas The Extensive Markup Language (XML) (W3C 1998b) is yet another physical data format language (PDFL). X M L specifications set a series of rules in formatting text that contains information about real-world objects. Since information models are also a kind of real-world "object", logically they can also be represented through a "PDFL", which in this context serves the same role of a modeling language. The trend of X M L evolution is to use this language as both PDFL and the modeling language for computer data representations. The X M L specifications are defined based on this goal. Whereas X M L , being a candidate for both PDFL and the modeling language, is still not mature enough to support all expected data representation capabilities such as those provided in an object-oriented modeling language, the idea of using a neutralized data format for all data structures is valuable. This will streamline many software implementation efforts, especially for data exchange and mappings. XML. Schema proposed by W3C (W3C 2000b) and X M L Data used by Microsoft (W3C 1998a) are specifications containing notations for using X M L natural formats as a modeling language. Information models using the notations such as X M L Schema or X M L Data are commonly referred as X M L schemas. Since the popularizing of X M L , numerous X M L schemas development efforts have occurred in different industries of different forms. For the AEC/FM industries, major software vendors have started defining company-based X M L schema standards for the objects of their specialties. For example, Timberline Software (in a project led by the author) has developed several X M L schemas representing cost estimates, estimate takeoff, estimate databases, and buyout documents (e.g. request for quote, quote, and purchase order) (Timberline 1999). Many of these schemas are also published on the www.biztalk.org public schema repository (Biztalk 2000). The largest AEC/FM modeling effort, the IAI, has also started their X M L adoption strategy by mapping out IFC property sets models into X M L formats. The IAI has also provided operation services for another AEC/FM X M L initiative - aecXML (aecXML 2000). The aecXML is a consortium of AEC/FM software companies that are interested in developing X M L schemas as standards for data exchange. At the time of writing this dissertation, aecXML is working on establishing a data transactional framework and schema guidelines for companies to submit their schemas as contributions to the standards. Almost all these X M L schema developments are in their very early stages. Most schemas published are too immature to implement, partially because the X M L technologies themselves are not well established in many aspects. Most commercial AEC/FM software programs are yet to become ready to implement the X M L technologies. Nevertheless, we believe the biggest challenge for the industries in adopting X M L technologies is still the establishment of meaningful business cases using real applications among software vendors. The success of those X M L schema developments will largely be based on these business cases. UBC Page 60 Yu, K 4.3. Industry Foundation Classes (IFCs) The IAI is the largest effort to date for developing electronic data standards for the AEC/FM industries. In specific, the IAI develops the IFCs, a set of classes that represent information of AEC/FM projects and objects. Those classes are developed to support data exchange between different software applications used in an AEC/FM project. At the time of this writing, the latest release of the IFCs is IFC 2.0 (IAI 1999). During the development of IFC 2.0, the IAI's Project Management committee (in which the author actively participated) and Facilities Management committee (which was chaired by the author) defined a series of application use scenarios and industry processes that provided the requirements for the IFC's project management models. As a member of the IAI's information modeling task force, the author was the primary modeler responsible for Project Management, Construction Management and Facilities Management Schemas. As one of the contributions to this Ph.D. research, this section provides the detailed discussions about the project management models developed in this research effort, which are also contributed to IFC 2.0. 4.3.1. Introduction to IAI The IAI is a global, industry-based consortium for the Architecture, Engineering, Construction and Facilities Management (AEC/FM) industries (IAI 1996). Their mission is to enable interoperability among industry processes of all different professional domains in AEC/FM projects by allowing the computer applications used by all project participants to share and exchange project information. The IAI's scope is the entire lifecycle of a building project from strategic planning, design and engineering, construction, to building operation. The IAI's goals are to define, publish and promote a specification— named the IFCs—for sharing data throughout the project lifecycle, globally, across disciplines and technical applications. IAI members come from AEC/FM industry firms, software vendors, research institutes and universities, professional organizations, and government agencies. The IAI is organized into different regional chapters overseen by an international co-ordination council. Current IAI chapters include North America, German-speaking countries, United Kingdom, France, Singapore, Nordic countries, Japan, and Austral-Asian, with more than 700 members around the world. Based on the interest and initiative of the IAI members, a series of domain committees are established within each chapter to represent specialized industry sectors and to provide information requirements for the IPCs from these sectors' perspective. Domain committees include architecture, structures, codes and standards, building services, HVAC, project management, facilities management, etc. Furthermore, the IAI has combined with another industry-wide effort, aecXML (aecXML 2000), which is aimed at producing XML-based standards for AEC/FM. 4.3.2. IFC Architecture and Development Methodology A large portion of the IFCs focuses on product models, while their scope includes other project information for the entire life-cycle applications such as processes, construction resources, costs, documents, and category information. As a result, the IFCs are a large set of objects with complex relationships. Therefore, the IFCs must be modeled, documented and maintained based on a well-organized structure so that they can be correctly defined, effectively maintained, and easily understood. Given the size and complexity of the model, how well the IFC architecture and development methodology are established is key to their future achievements. This section presents these IFC aspects and discusses their pros and cons. UBC Page 61 Yu, K IFC Architecture The IFCs architecture is based on layers containing model schemas (IAI 1999). The layers include: a resource layer that describes distinct underlying concepts (e.g., geometry, units and measures, etc.); a core layer that defines a kernel meta-model and core extensions to define the basic AEC/FM objects (e.g., projects, products, processes, resources, etc.); an interoperability layer that defines data that is used across multiple domain areas (e.g., building elements, structural components, etc.); and a domain layer that defines detailed data used within specific application areas (e.g., space layout, power and lighting system design, property management, etc.). Figure 29: IFC Architecture This architecture lays out the large number of classes nicely and eases the documentation and maintenance of the models. The organization of the layers and schemas is also useful for understanding the scope of the models. While the schemas do not have much impact on implementations, they do provide easy-to-understand model documents. The TEC architecture also implies some reference rules regarding how the objects should be referenced. While these rules may make the models appear consistent and may ease the modeling tasks by using some guidelines to define object relations, they do not always reflect application requirements for objects. Consequently, this problem will toughen the software implementation work unnecessarily and sometime may even have negative impact on software performance. For example, one of the IFC referential rules is that objects in a higher layer schema may not reference objects at a lower layer schema. Particularly, IfcProduct defined in the Kernel Schema cannot reference IfcRelCostsObjects defined in the Project Management Schema, which is the only objectified-relationship object to cost models such as IfcCostElement. While an IfcProduct instance can be attached through the Inverse relationship to IfcRelControls - a supertype of IfcRelCostsObjects, this implicit modeling style essentially makes the model very difficult to understand or to use. Furthermore, since not all the implementation methodology supports the Inverse relationship, this object-to-cost relationship may not appear among the runtime objects. This makes the IFC-based instances look very awkward since a program cannot retrieve objects' cost information by querying the object itself. Any workaround to this problem in implementation will suffer runtime performance. In fact, the IAI recommended implementation method, ISO-STEP Part 21 file format doesn't support such inverse object relationships. UBC Page 62 Yu, K IFC Development Methodology The IFC standards are developed through IAI projects. IAI projects are carried out by IAI members who represent two basic roles: domain experts—who contribute their domain expertise and define the information requirements for the industry processes—and technical experts—who provide software engineering skills in information process analysis and modeling. IAI project development follows a process-oriented methodology, which involves the following major steps (Yu, Froese, and Grobler 1998): Process \ Usage Process \ Information \ Selection / Scenarios Definition / Analysis / Information Modeling and Documentation Figure 30: IFC Development Steps • Processes Selection: identifies projects for development based on many criteria relating to market demand, and available resources. • Usage Scenarios: define the basic requirements and illustrate their use in real-world examples. • Process Definitions: determine the specific tasks followed to complete the process and the information flows associated with the tasks. • Information Analysis: carries out the preliminary information modeling to support the processes. • Information Modeling and Documentation: finalizes the information models in the context of the entire IFCs and carries out their validation, mainly through implementation by member software vendors. While this IFC development process approximately mimics the general development steps for conceptual models, it is not in compliance with the procedure set for developing LSDCMs (see Section 4.1.3.). The most obvious distinction is the use of real software applications for defining model scopes and development methodologies. As can be seen in Figure 30, IFC development does not use software programs as the primarily sources for information requirements. Rather, IAI projects are mostly based on ad hoc industry processes defined by industry professionals. Again, the potential problem this would cause is that the resulting models tend to be off the scope and do not support commercial software directly and easily. As a consequence, models tend to be difficult to be adopted into real software implementations. One of the major criticisms of the IFCs is related to this problem. The fact that the IAI projects use ad hoc process definitions rather than real software applications limits the potential use of the IFC models. Specifically, the IAI processes are not developed in a way that they can be standardized, and thus are not considered to be one of the final IAI deliverables. As a result, it is difficult to allow the resulting IFCs to participate in more flexible business-to-business (B2B) process transactions since the models are not validated against industry-wide transaction standards. We recommend that the IAI consider the approach of formalizing its industry processes and enable IFCs to support standard industry B2B transactions. UBC Page 63 Yu, K 4.3.3. I F C M o d e l s f o r P r o j e c t M a n a g e m e n t The IFCs' goal is to support all the processes and their data exchange across the entire AEC/FM domain. Although much of the IFCs' focus is on representing the facilities that are being designed and constructed (i.e. the product model), a significant amount of IFC models such as costs, schedules, work tasks, resources, etc. are also developed for project management information. While many IFC classes in any of the IFC schemas can be used for project management processes, there are also objects that are modeled particularly to support construction or facilities management processes and their integrations. These classes explicitly encompass project management (PM) contexts through their support of object aspects. These PM classes are primarily contained in four IFC schemas: Process Extension schema, Project Management schema, Construction Management (CM) schema, and Facilities Management (FM) schema. The Process Extension schema includes classes to support basic AEC/FM processes and tasks. The PM schema contains classes that represent common information for PM functions, and they represent common data requirements for construction and facilities management. The Construction and Facilities Management schemas include classes that are specifically needed for construction and facilities management processes respectively. Al l these classes are also linked to other classes, such as product models, defined in other schemas. To give a general idea of the scope of the IFC PM related models, Table 5 in the next page lists the classes and their schema in IFC 2.0. Details about these objects can be found in IAI 1999. Although these classes in the latest IFC release (i.e. IFC 2.0) do not yet support a large number of PM processes, they are indeed capable of supporting several of the most typical and useful processes that are key to integrating across domain applications. The rest of the chapter will discuss some of this integration support by the IFCs. 4.3.4. P r o d u c t a n d C o s t E s t i m a t i n g I n t e g r a t i o n The Project Management (PM) Domain Group of the IAI North American Chapter (IAI NA PM) has developed portions of the IFCs to support product and cost estimating processes (IAI 1998). Much of these processes have now been incorporated into the IFCs. This section presents the details of how these objects are modeled within the IFCs. It also demonstrates examples of how the models can be used to support runtime product and cost estimating integration. Process Models of Product Cost Estimating The process used to identify the information requirements for cost estimating is developed in Cole et al. (1998a) by the North American Project Management Committee's Cost Estimating project. Froese, Grobler, and Yu (1998 and 1999) extend some detailed issues for the project. This process, as shown in Figure 31, represents the very basic steps involved in a typical cost estimating scenario. Whereas this process is not tightly mapped to any commercial CAD or cost estimating applications, it serves the need of identifying general data types required for one type of cost estimating at a high level. Many of the current IFC cost related models have resulted from the analysis of this process. Context of Object Costs A simple way of representing costs is to associate a basic cost attribute with any building product or other kernel object. The IFCs release 1.5.1 implemented this representation, which is sufficient for some data exchange purposes. However, any cost value is only meaningful if the context in which the cost value is known. For example, the fact that a door in a construction project costs $100 is only useful information if its context information is also specified. Information about whether the unit price of a work task includes material purchases, transportation, material use wastes, equipment uses (operational or rental costs), labor costs, taxes, general contractor mark-up, etc. must be provided along with the numerical cost value. UBC Page 64 Yu, K In addition, information regarding to whom this cost applies—such as subcontractor, general contractor, or owner—is essential. Details about what are included in the cost, e.g. delivery, installation, and taxes are important. The cost type (e.g, is the cost a rough estimate or a firm quote) is also essential for further use of the cost. When cost information is sent from one participant to another, the context of the cost is usually implicit in the context of the data exchange (i.e., the information was sent for a specific purpose and both parties know that purpose). However, i f cost information is stored in an IFC-based project database, there is no implicit context to that cost information. This requires the cost context to be explicitly represented. The approach of associating a simple cost attribute with IFC objects does not capture the context of the cost information, leaving a high potential for misinterpretation of cost information, and this approach is no longer used in the IFC 2.0 or later versions. Table 5: IFC Project Management Models Schemas IFC Classes Process Extension Schema IfcWorkPlan IfcWorkSchedule IfcWorkScheduleElement IfcWorkTask IfcRelNestsProcesses IfcRelNestsWorkScheduleElements IfcRelNestsWorkSchedules IfcRelUsesResource IfcScheduleTimeControl Project Management Schema IfcBudget IfcChangeOrder IfcCostElement IfcCostSchedule IfcProjectOrder IfcPurchaseOrder IfcRelCostsObjects IfcRelNestsCostElements IfcRelNestsCostSchedules IfcWorkOrder Construction Management Schema IfcCMDocPackage IfcConstructionEquipmentResource IfcConstructionMaterialResource IfcConstructionZoneAggregationProduct IfcCrewResource IfcLaborResource IfcProductResource IfcRelAggregatesCrewResources IfcSubcontractResource Facilities Management Schema IfcFurniture IfcFurnitureModel Ifclnventory IfcOccupancySchedule IfcOccupancyScheduleElement IfcOccupancyTask IfcRelNestsOccupancyScheduleElements IfcRelNestsOccupancySchedules IfcRelWorklnteraction Ifc Sy stemFurnitureElement IfcWorkstation UBC Page 65 Yu, K Figure 31: Cost Estimating Process UBC P a g e 66 Yu, K Basic Cost Model The IFC model represents costs using four basic classes (see Figure 32). IfcCostElement represents a specific cost associated with an object in a project. The IfcCostElement also contains context information for the cost value. Each IfcCostElement can be associated by an IfcCostSchedule object, which describes the specific context, e.g. a cost estimate, for a collection of IfcCostElements. Each IfcCostElement is typically associated with an IfcObject, which is the representation of the thing (e.g. a product or process) in the project that is being costed. Finally, each IfcCostElement is associated with one or more IfcCost objects, which capture the actual monetary values of cost. IfcObject IfcCostSchedule through IfcRelCostsObjects IfcCostElement IfcCost Figure 32: Basic IFC Cost Model IfcCostSchedule The IfcCostSchedule entity represents an overall cost assessment of something for some purpose. The cost assessment is represented by a collection of IfcCostElements and the purpose is represented by attributes that describe the context for the cost schedule. IfcCostSchedule can be used to represent any form of cost list, such as an estimate, a budget, or a unit price table. IfcCostSchedule is a subtype of IfcControl; thus it inherits all of the properties possessed by IfcControl and all its super classes. It is worth noting that IfcCostSchedule can also include other IfcCostSchedule(s). Some of the important attributes of IfcCostSchedule and IfcControl are as follows: Title: The title of the document, e.g. a cost estimate report, represented by IfcCostSchedule. SubmittedBy, ApprovedBy, PreparedBy: People or organizations. SubmittedOn, UpdateDate: The dates the cost schedule was submitted and updated. TotalCost: The total cost on the schedule. CostElements: The collection of IfcCostElements. Controls: A cost schedule can be associated with any individual objects in a Project through the IfcRelControls relationship entity. • Classification: Reference to the access information for classified information. At the time when this dissertation is being written, several new attributes have been proposed in IFC 2.X. Status: The current status of a cost schedule. IntendedUse: Intended use for the cost schedule. Comments: Assumptions, qualifications, conditions, and other context information. TargetUsers: The actors for whom the schedule was prepared; can also control access permission. ValidFromDate, ValidToDate: Time period during which the cost schedule is valid. UBC Page 67 Yu, K IfcCostElement The IfcCostElement entity represents the cost of goods, services, or the execution of work, under certain conditions and context. The entity addresses cost context by providing cost information, relating to the object being costed, and relating to a cost schedule document (IfcCostSchedule) that describes the context of a list of cost elements. An IfcCostElement instance can be associated with the objects being costed (e.g., a product, a resource, a process, etc.), through the objectified relationship IfcRelCostsObjects. It can hold information such as the unit price, quantities and total cost for the costed object. An IfcCostElement is also typically included in IfcCostSchedule as one cost item. It can also be used to group related sub-costs using an IfcRelNestsCostElements relationship. Similar to the IfcCostSchedule element, IfcCostElement can also group sub-costs using an IfcRelNestsCostElements relationship. This is a key feature to support decomposed costs of different context or costs for decomposed objects. IfcCostElement is a subtype of IfcControl. Some of its attributes are as follows: • Description: General description. • ContextDescription: Contextual information. • ElementCost: The unit or item cost of a single item of each "Quantity" (an IfcCost). • ExtensionCost: The total cost (an IfcCost). • CostUse: Indicates how element calculations are to be carried out (e.g., does this cost provide an element cost only, an extension cost only, an extension of a nested set of element costs, etc.). • PreparedOn: The date the cost is provided. • Quantities: The quantity of the associated items; a measure with unit. • CostType: The cost type. Allowable values include: basic cost, overhead cost, profit cost, purchase cost, subcontract cost, contingency cost, etc. • CostSchedule: A reference to the cost schedule to which the cost element belongs. IfcCost The actual monetary amounts associated with IfcCostElements are represented by IfcCost, which can be a simple currency value or a more complex assembly of cost values and modifiers. IfcCost is also able to accumulate other IfcCost(s). IfcCost includes the following attributes: • CostType: Type of Cost specified. • BaseCostValue: Amount of this cost before the application of cost modifiers. • FinalCostValue: Amount of this cost following the application of cost modifiers. • Currency: Currency for this cost amount. • ModifierBasis: The manner in which cost modifiers are applied to a cost. Note that where cost modifiers are specified, the modifier basis must be asserted. • ModifierValues: Modifiers, which may be applied to a cost to change its value. • UnitCostBasis: The number and unit of measure on which the unit cost is based. • CostDate: The date at which the cost is applied. • CostComponents: Costs that are components of another cost and from which that cost may be deduced. UBC Page 68 Yu, K IfcCostModifier IfcCostModifier represents a modifier that influences a cost. Cost modifiers can potentially be applied on a complex bases (e.g., a percentage markup on hours of overtime labor). Cost modifiers can accommodate a limited set of calculation alternatives (static/running and add/subtract/multiply). Modifiers applied on a more complex basis can be converted within cost applications to these simple bases (e.g., the more complex modifier can be resolved into a fixed currency value modifier). Attributes of IfcCostModifier include the following: • Purpose: The purpose for which a cost modifier is applied. Each cost modifier may be assigned a purpose by which it may be recognized. Purposes might include trade discount, quantity discount, bulk purchase rebate, postage and packing cost, abnormal working conditions factor, etc. • CostValue: The value assigned to a cost factor. • CostOperator: A mathematical operator that determines how the cost modifier is to be applied to the cost to vary its value. Example Object Costs Using IFC Models A more complete IFC cost model is shown in Figure 33 using EXPRESS-G (ISO 1991). Note that other sample model diagrams in this chapter are also presented using EXPRESS-G. IfcProcess IfcProduct OnProducts S[0:?] IfcControl IfcCostSchedule ^ IfcWorkPlan IfcObject r RelatingObject (INV) Costs Elements S[0:?] (INV) Schedule ObjectCost S[0:?] _ "(INV) CostsFor S[0:?] IfcRelCostsObjects e-HasCostSchedules S[0:?] (INV) WorkPlan Item Description -- e -IfcCostElement ExtendedCost IfcRelationship I BaseCost -4 —Context— -PreparedOn —6 <b STRING <b IfcCost - 6 -IfcDateAndTime Figure 33: IFC Object Cost Model Based on these cost models, together with other IFC product and process models, the integration between products and cost information can be implemented through objects in this object-oriented system. A complete example is extremely helpful in understanding the IFC representation structures for products and their costs. UBC Page 69 Yu, K 4.3.5. Cost and Scheduling Integration This section presents the typical project management processes that have been developed in IAI projects: cost estimating, construction scheduling, and specifically their integration. It examines how the IFC models can be used to support the integration of these processes. Scope and Scenario The intended scope for both the estimating and scheduling projects ranges from high-level preliminary conceptual estimates and schedules to very detailed planning. For example, the estimating process identifies the components of the project to be priced out, and then optionally supports detailed work method and resource planning. The scope also includes the task of editing and refining existing estimates and schedules to add detail and incorporate changes as the project progresses. The scope for the process of initializing a schedule from an existing estimate addresses a scenario in which an estimate has been prepared, including work method and resource planning, and this information is used to define an initial set of schedule activities. Scheduling Process Model While cost related IFC models are defined based on the cost estimating process discussed in the last section, scheduling-related IPC models were developed by the Construction Scheduling Project documented in IAI 1997 and 1998. Froese, Grobler, and Yu (1998) also discuss this construction scheduling process in further detail. The high-level process model is illustrated in Figure 34. This project identifies many basic IFC objects related to construction processes and resources. It also provides requirements for objects needed to create construction work plans and schedules. Identify \ Work Scope —v Planning Determine Duration Develop K Use Schedule 1/ Schedule i L i L Figure 34: Schedule Process Model UBC Page 70 Yu, K Process Models for Estimating and Scheduling Integration The IAI project includes not only the individual cost estimating and construction scheduling processes as already discussed, but also the process of initializing a schedule from a cost estimate. Figure 35 illustrates a conceptual process model for the integration of estimating and schedule, involving four basics steps (Cole et al. 1998b): 1. Retrieve Cost & Scheduling Work Tasks: retrieves work tasks and all their related information regarding resources, logic and duration, etc, generated by both estimating and scheduling process. 2. Compare Work Tasks: compares estimating work tasks with scheduling activities (or vice versa) to identify their commonalities and differences. 3. Identify Work Task Mappings: identifies work task mapping points, i.e. where a work task identified from estimating should be mapped to one or more work tasks from the scheduling process (or vice versa). 4. Identify Additional Work Tasks: After the work tasks are compared and the mappings are identified, additional activities can be identified and created by breaking down a high level task into more detailed ones or inserting a task from one process to the other. Estimating Identify Cost Objects Select Work Methods & Task Types Select Resource & Material Types Quantify Costs Completed Estimate Estimating & Scheduling Integration Receive Cost & Scheduling Work Tasks Compare Work Tasks Identify Work Tasks Mappings Identify Additional Work Tasks Scheduling Identify Scheduling Work Tasks Identify Activity Logic & Duration Develop Activity Scheduling Figure 35: Process for Estimating and Scheduling Integration (abridged process) This integration process provides additional informatiori requirements for integrating cost estimating and scheduling data, and it conforms that the IFC models are able to support this integration. The rest of the section examines the IFC models supporting this integration scenario. UBC Page 71 Yu, K IFC Models for Construction Processes and Planning Documents An important aspect of the project management portions of the IFCs is the explicit representation of work processes. While cost estimate items and schedule activities can be associated with work processes, the processes themselves are distinct elements that can be independently described and represented in project models. There are two main entities in the IFCs to support construction processes: IfcProcess and IfcWorkTask (see Figure 36). The former represents any general actions taking place in completing a task of design, engineering, construction, or facilities management. IfcWorkTask, a subtype of IfcProcess, is intended to describe the work processes that make up construction operations. Information such as construction work methods, schedule dates and duration is defined at the IfcWorkTask level. IfcTimeDurationMeasure -TimeLag- IfcRelSequence Q q>-IfcSequenceTypeEnum i <J) SequenceType-RelatedProcess (INV) IsSuccessorFrom S[0:?] IfcActorSelect ! © -RelatingProcess (INV) IsPredecessorTo S[0:?] i PerformedBy IfcWorkScheduleElement (j> e S[0:?] Schedule IfcProcess (INV)Worktask - ID IfcWorkTask Elements S[0:?] (INV) WorkSchedule -Name-£ 6-Description yyBS -e- - 9 -STRING -Method HasWorkTasks S[0:?] (INV) WorkPlan S[0:?] IfcWorkSchedule HasWorkSchedules S[0:?] (INV) WorkPlan IfcWorkPlan IfcControl Figure 36: IFC Process and Work Plan Model Work Plans Any collection of IfcWorkTask instances makes up a plan, represented by the entity IfcWorkPlan. Tasks can be organized in different ways to make up different IfcWorkPlan instances (see Figure 36), representing different work plans. For example, tasks may be organized into a nested hierarchy according to the type of work required to define a plan that supports cost estimating, then the same tasks can be organized into another nested hierarchy according to work locations, possibly with additional work tasks added to expand certain details, to define a plan that supports work scheduling. UBC Page 72 Yu, K Work Schedules Time scheduling information can be assigned to work plans and work tasks by associating them with related work scheduling objects (see Figure 36). Specifically, an instance of the entity IfcWorkScheduleElement, which holds time scheduling information such as start dates, end dates, float times, etc, can be associated with an IfcWorkTask instance to represent all the date and duration information for the work task (i.e., the combination of an IfcWorkTask and associated IfcWorkScheduleElement provides the equivalent of a traditional scheduling activity). All IfcWorkScheduleElement instances for a work schedule are grouped into an IfcWorkSchedule instance. One or more IfcWorkSchedule instances can be associated with any IfcWorkPlan. Thus, the related instances of IfcWorkPlan and IfcWorkSchedule comprise a subset of basic planning documents for a project (see 4.3.4 for estimating documents). Process Nesting Work tasks represent processes at any level of detail, from broad project phases to very detailed tasks. All levels have the same data structure rather than different entities for different levels of activities. For example, an overall project, its development phases, work packages, activities, work tasks, and operations can all be represented as instances of IfcWorkTask. A key requirement for the estimating and scheduling integration process is the nesting capability of work tasks. That is, a work task can be broken down into sub-tasks, but it still remains the same work task itself. In the IFCs, the entity IfcRelNestsProcesses is used to establish the nesting relationship between work tasks (see Figure 37). -RelatedObjects LIST[1:?]- 1 IfcObject 9 IfcRelNests - RelatingObject -IfcRelationship 1 Constraints: 1. RelatedObjects and RelatingObject must | IfcRelNestsProcesses be of the same type. Constraints: 2. RelatingObject must not be in RelatedObjects, and vice versa. rNestingCriteria- STRING — 9 - NestingDescription 1. RelatedObjects and RelatingObject must be of IfcWorkTask. Figure 37: IFC Process Nesting Model Process Sequence The sequence of processes is defined as an objectified relationship between IfcProcess instances, as represented by IfcRelSequence. This entity establishes the link between a successor and a predecessor process, providing a time lag and sequence type (e.g., start-to-start or start-to-finish sequence, etc.). Linkages with Products One of the central relationships in modeling construction processes is the association between processes and the products upon which they operate. The IFC approach to this is to use an objectified relationship entity named IfcRelProcessesProducts between IfcProduct and IfcProcess indicating the operation type such as install, transfer, operation on, construct, remove, erect, and so on (see Figure 38). UBC Page 73 Yu, K IfcProcess -RelatingProcess" IfcRelProcessesProducts • IfcProduct q> RelatedProducts LIST [0:?] IfcRelationship OperationType-6 IfcOperationTypeEnum; Figure 38: IFC Model for Process and Product Association-Construction Resources and Their Relations to Processes Construction resources are things that are used to carry out construction processes. The entity IfcResource can be used to represent either types of resources or individual occurrences of resources needed to aid in a construction process. The IFCs currently support five different resource types: subcontractor, construction equipment, construction material, labor, crew, and product resources (see Figure 39). A crew is a collection of resources (typically a collection of labor resources with some associated equipment and materials). A product resource is used in the situation where a product that results from a work task is used as a resource in another process. Although it may well be a logical idea to model things such as construction equipment, materials, and labor as resources, it presents a problem in that all of these are things that might also play different roles on a project. For example, a crane might be represented as a temporary constructed product, materials might be represented as design properties or as the basic components in a materials management application, and labor might be represented as part of the organizational information for a project. Further, the characterization of these things as resources, products, etc, can be very dependent upon the perspective of the user of the information. Generally, things should be modeled as "what they are" rather than as "a role they play". However, the concept of "resources" represents a role that certain things play on a construction projects, and it is difficult to design representational structures that satisfy all these different perspectives. Thus, a subtle but important change the IPC Release 2.0 is that IfcResource is interpreted as representing "the use of a thing in the role of a. construction resource," rather than representing the thing itself. If only basic resource information such as the names, quantities, and prices is of interest to users of a project model, then IfcResource objects alone are sufficient to represent the information. However, if further information is required about the things that are being used as resources, then the IfcResource instances can be associated to other instances that represent those things (i.e., IfcProductRes and IfcMaterialRes can be associated to IfcProduct objects, IfcLaborRes can be associated with IfcActor instances, etc, see Figure 39). IfcProductRes* IfcMaterialRes • -e— IfcProduct IfcResource q> I -Contains-IfcEquipmentRes IfcLaborRes T IfcCrewRes IfcSubcontractor IfcConstructionEquipment IfcActor Figure 39: IFC Construction Resource Model. Processes use resources This resource-use relationship is modeled by IfcRelUsesResource as an objectified entity carrying information such as resource use duration, quantity, waste factor, and costs (see Figure 40). UBC Page 74 Yu, K Related Issues The modeling constructs presented in this section show only a few of the core elements of the project-management-related portions of the IFCs. Many other issues—such as multiple views of work schedules, classification of work tasks, references to external libraries of work types, etc.—are also being addressed. Other IAI projects are also examining other project management applications, including document management, preliminary cost planning, and planning of temporary facilities. REAL IfcRelationship WasteFactor- IfcRelUsesResource RelatedResource (INV) UsedlnProcesses S[0:?] -Duration - cp IfcResource RelatingProcess (INV) UsesResource S[0:?] IfcProcess IfcTimeDurationMeasure Quantity- <b IfcMeasureWithUnit ResourceUseCosts S[0:?] o IfcCostElement Figure 40: Resource Usage 4.3.6. Project Management Related Classes in IFC 2x This section briefly reviews the classes that are related to project management functions. Figure 41 shows a conceptual, yet simplified, model of these classes. The IfcObject Class Because IfcObject is the root class for all domain objects, any changes to it will have impact to many other objects. In IFC 2x, IfcObject has an additional attribute named "ObjectType". This is a string type attribute that, according to IAI 2000, further specifies the type of the object in addition to the semantics of the class itself. This attribute is especially useful if the object instantiated at runtime cannot be represented by any class explicitly defined in IFC 2x. For example, if a software program needs to support a scaffolding object and exchange its information with other applications using IFC 2x, an instance of IfcBuildingElement can be created with its "ObjectType" specified as "scaffolding". This capability allows the IFC models to support much larger scope of object types and software types. Additionally, the IfcObject class also supports the following new relationships: • Has Associations: SET OF IfcRel Associates FOR RelatedObjects; • HasAssignments: SET OF IfcRelAssigns FOR RelatedObjects; • Decomposes: SET OF IfcRelDecomposes FOR RelatedObjects; • IsDecomposedBy: SET [0:1] OF IfcRelDecomposes FOR RelatingObject; These generic relationships have impact to all other classes that are derived from IfcObject. That is, in many cases, explicit object relationships at a lower level are implicitly represented by these general relationships at the highest object hierarchical level. One advantage of using these generic relationships at such a high level is that it provides maximum flexibility for most objects in supporting various object relationships. However, this approach is also one of the ambiguous modeling methods because the actual context of the object relationships at lower levels is always subject to interpretation. Furthermore, since the context of these relationships is not specified for all objects in the IFC models, it must be interpreted by the software programs that implement the objects, and understood consistently UBC Page 75 Yu, K by many different software developers of different domains - note that this is not an easy task. Thus this approach is not necessarily a desirable approach for supporting interoperable software development. IfcObject k IfcControl IfcProcess IfcTask IfcWorkControl d> IfcWorkPlan IfcResource IfcRelationship IfcRelAssigns IfcRelAssignsToControl <3 IfcRelAssignsTasks IfcRelAssignsToResource IfcRelAssignsToControl IfcWorkSchedule IfcCost IfcRelUsesResource IfcCostValue <p IfcRelCostsObjects Figure 41: Project Management Classes in IFC 2.X The IfcCost Class In IFC 2.X, the IfcCost defined in the IfcSharedMgmtElement schema is a renamed class from IfcCostElement from IFC 2.0. The following is the EXPRESS definition of this class. As specified in W R 1 , this class is used to represent the cost information for IFC objects through IfcRelCostObjects relationship class. UBC Page 76 Yu, K ENTITY IfcCost SUBTYPE OF IfcControl; ContextDescription: IfcLabel; ElementCost: OPTIONAL IfcCostValue; ExtensionCost: OPTIONAL IfcCostValue; CostUse: IfcCostUseEnum; PreparedOn: OPTIONAL IfcCalendarDate; Quantities: OPTIONAL LIST [1:?] OF UNIQUE IfcCostQuantity; CostType: IfcLabel; INVERSE CostSchedule: IfcCostSchedule FOR CostElements; WHERE W R 1 : SIZEOF(QUERY(temp <* SELFWcControl.Controls | . NOT('IFCSHAREDMGMTELEMENTS.IFCRELCOSTSOBJECTS' IN TYPEOF(temp)))) = 0; END_ENTITY; Same as in IFC 2.0, the nesting relationship of this class is done through IfcRelNests relationship class, which is in fact a subtype of IfcRelDecomposes. One change of this class is the aggregation (i.e. use of "LIST") relationship "Quantities", which in IPC 2.0 is a single cardinality relationship. The related class IfcCostQuantity is actually a new class introduced in IFC 2x. More information about this class is provided in the next section. The IfcCostResource Schema The IfcCostResource schema includes basic classes support cost information. In this schema, there are two classes worth noting: IfcCostValue and IfcCostQuantity. Particularly, the IfcCost class from IFC 2.0 is renamed to IfcCostValue in IFC 2x, while the semantics of this class remains the same. IfcCostQuantity, however, is a new class in IFC 2x. This class contains quantities of items, for example takeoff items, which may be applied to a cost. The following is the EXPRESS definition of this class. ENTITY IfcCostQuantity; BaseQuantity: OPTIONAL IfcMeasureWithUnit; FinalQuantity: OPTIONAL IfcMeasureWithUnit; WasteFactor: OPTIONAL IfcPositiveRatioMeasure; RoundOfflncrement: IfcReal; RoundOffBasis: IfcQuantityRoundOffBasisEnum; END_ENTITY; The attribute definitions are as follows: • BaseQuantity: The "as measured" quantity resulting from a quantity takeoff or similar operation. • FinalQuantity: Value used for the actual price calculations and the only quantity used if no modifications are used. • WasteFactor: A quantity to be added to base quantities to account for wasteage. Note: It is normal to add waste factors as percentages. Applications will need to interpret the positive ratio measure used in the data type for this attribute in percentage terms. UBC Page 77 Yu, K • RoundOfflncrement: A number indicating the size of units that quantities should be rounded off to, particularly in the case of materials that must be ordered in specific size lots. • RoundOffBasis: The basis on which quantities are 'rounded off i.e. the nearest unit for quantification purposes that can be used. For instance, a numerical quantity may be determined to be 4.886 but should be rounded up with an increment of 0.1 meters or 1 decimal place. In this case, a value of 4.9 would be applied. Along with IfcCostValue, IfcCostValueRelationship is created in IFC 2x to establish a relationship between IfcCostValue instances. Additionally, IfcCostModifier, which is defined in IFC 2.0, is also supported in IFC 2x. The IfcProcessExtension Schema The IfcProcessExtension schema contains classes that support construction tasks, work schedules and work plans. This section reviews the classes defined in the IfcProcessExtension schema for IPC 2x in comparison with IPC 2.0. The following table presents an overall situation of the classes in this schema in both IFC versions. Table 6: IfcProcessExtension Schema Class Name IFC 2x IFC 2.0 Remark IfcTask Renamed class IfcWorkTask IfcTask is renamed from IfcWorkTask. IfcWorkControl New Class X Supertype of IfcWorkPlan and IfcWorkSchedule IfcWorkPlan X X IfcWorkScheduleElement Not Exist X The concept is removed in IFC 2x. IfcWorkSchedule X X IfcWorkTask Not Exist X Renamed as IfcTask in IFC 2x. IfcRelAssignsTasks New class Not Exist IfcRelNestsProcesses Not Exist X Functionality can be provided using IfcRelNests in IFC 2x. IfcRelNestsWorkSchedule-Elements Not Exist X Not needed in IFC 2x since IfcWorkScheduleElement is removed. IfcRelNestsWorkSchedules Not Exist X Functionality can be provided using IfcRelNests in IFC 2x. IfcRelUsesResource X X IfcWorkControl, a new class in IFC 2x, is the supertype of IfcWorkSchedule and IfcWorkPlan, leaving that the latter two classes do not have any additional attributes. This in turn makes IfcWorkSchedule and IfcWorkPlan no difference in IFC 2x. IFC 2x documents do not clearly explain how IfcWorkPlan is related to, or different from, IfcWorkSchedule. This model is ambiguous and is considered to be a potential source of problem for implementations. For example, because the model of the two classes does not specify the semantics at the attribute level, the context of their instances will be subject to interpretation by different application developers. In an environment of interoperable systems, a consistent understanding of the object context is critical, but in this case, it can be difficult to be achieved. Additionally, In IFC 2.0, a design intent of IfcWorkPlan is to contain multiple IfcWorkSchedule(s), while an IfcWorkPlan instance can also include other IfcWorkPlan(s). While the 'Decomposes' relationship inherited from IfcObject can be used for either of the relationship types since both IfcWorkPlan and IfcWorkSchedule are a subtype of IfcWorkControl, it is vague how these relationships should be implemented precisely. The IfcWorkScheduleElement class is removed in IFC UBC Page 78 Yu, K 2x, while the concept can be represented using IfcTask. IfcRelAssignsTasks is a new class, which assigns IfcTask(s) to IfcWorkPlan and IfcWorkSchedule. This relationship exists in IFC2.0 explicitly supported by IfcWorkPlan and IfcWorkSchedule. The IfcRelUsesResource is defined in IFC 2.0 and modified in IFC 2x. The following list shows the full attribute view of this class. There are two modifications worth noting. The first one is that this class is made as a subtype of IfcRelAssigns, which along with the WHERE rules allows the instances of IfcRelUsesResource to be associated to any IfcProcess instances. Another modification is the use of IfcCostValue to the 'ResourceUseCosts' relationship. The use of IfcCostValue provides the actual cost values to the resource uses, while it lacks the capability to provide cost context information. Therefore, to the author's opinion, this relationship should be associated to IfcCost instead, which supports cost context information. ENTITY IfcRelUsesResource; ENTITY IfcRoot; Globalld: IfcGloballyUniqueld; OwnerHistory: IfcOwnerHistory; Name: OPTIONAL IfcLabel; Description: OPTIONAL IfcText; ENTITY IfcRelAssigns; RelatedObjects: SET [1:?] OF IfcObject; RelatedObjectsType: OPTIONAL IfcObjectTypeEnum; ENTITY IfcRelAssignsToResource; RelatingResource: IfcResource; ENTITY IfcRelUsesResource; Duration: OPTIONAL IfcTimeMeasure; Quantity: OPTIONAL IfcMeasureWithUnit; ProductivityConversionRate: OPTIONAL IfcMeasureWithUnit; ConverterMultiplierOrDivider: OPTIONAL IfcMultipleierOrDivider; ResourceUseCosts: OPTIONAL SET [1:?] OF IfcCostValue; WasteFactor: OPTIONAL REAL; WHERE WR1: HIINDEX(SELF\lfcRelAssigns.RelatedObjects) = 1; WR2: ' IFCKERNEL.IFCPROCESS' IN TYPEOF(SELF\lfcRelAssigns.RelatedObjects[1]); END_ENTITY; 4.3.7. Current Status of IFCs Given the objectives set by the IAI, modeling IFCs is an enormously challenging task. Yet, there is plenty of room for improvement for the current IFC models. First, as mentioned earlier, software applications are not always used in defining use cases and identifying processes in IAI projects. From a purely "academic" point of view, this is not a mandatory requirement, and in some cases this is not even desirable. However, this approach introduces a potential problem, that is, the models developed are not intuitive enough to the applications that attempt to implement the IFCs. This has already been realized in some of the real-world software IFC implementations. Second, some of the IFC object relations are not structured efficiently enough to make the models easy to implement. Some of them may also cause software runtime performance inefficiencies. Additionally, most typical AEC/FM applications must deal with design and planning processes. These processes usually require the information regarding not only the object instances, but also object types (e.g. product styles, cost library information, process types or construction methods, etc.). However, in the latest IFCs, object types are still not very well UBC Page 79 Yu, K supported. Furthermore, AEC/FM projects all span across multiple project domains and stages. The IFCs capability to handle object life-cycle management is critical in supporting data integration between applications that are used in different domains or stages. The latest IFCs fall short in even supporting object versioning that is only one key aspect for managing life-cycle objects. These are several basic problems observed by this research. Extensive supports for more sophisticated object aspects in IFCs are also desired. While this dissertation is being written, the IAI has just completed version IFC 2.X - a refinement of IFC 2.0. Some IAI projects for IFC 3.0 are also being proposed. Since the release of IFC 2.0, the entire IFCs development has slowed down as the model coverage is considered to be much more than most software vendors can implement within one cycle software release. Many IAI members feel that more implementation efforts should take place instead of continuingly expanding the models without sufficient validations and commercial uses by real software. The IAI is also facing the new challenges of the fast growing Internet technologies, which involve new data formats and new ways project information can be shared and exchanged. More work is required for the IAI to ensure that IFCs will be ready to participate in the new and Internet-based software interoperability and data integration arena. 4.4. Chapter Conclusion To summarize, this chapter discusses information models for AEC/FM. The chapter examines many fundamental technical issues regarding object information modeling. It also addresses modeling strategies for large-scale domain conceptual models (LSDCM). Furthermore, this chapter conducts inclusive reviews of most significant modeling efforts for AEC/FM industries. Among these modeling efforts, the Industry Foundation Classes (IFCs) developed by the International Alliance for Interoperability (IAI) represent the most significant mission in these industries. The research related to this Ph.D. work has directly contributed in the development of the IFCs. The chapter presents the IFC models and focuses on presenting the capabilities of IFCs' support for project management processes and their integrations. This chapter provides an essential knowledge base for data integration and application interoperability, which will be discussed in the next chapter. Since conceptual information models are a key technological element for TOPS RAF systems, this chapter lays down the first stepping-stones towards building up the entire TOPS architecture. In fact, the IFCs will be used as the reference models for the primary object data representation structures in designing the TOPS components and determining implementation approaches, which will be covered in Chapter 6. UBC Page 80 Yu, K Chapter 5: Data Integration and Application Interoperability Chapter Abstract: In this research, Data Integration (DI) describes all scenarios of data exchange, data access, and data sharing, while Application Interoperability (APPI) designates the operation of applications communicating, invoking, or requesting services. This chapter explores five basic DI scenarios, to which various data mapping schemes that can be applied. The meta-model approach is also discussed as it is applied to DI and data mappings. The chapter also presents several basic APPI schemes and addresses details of message-based and transaction-based architectural configurations. All the discussed technologies are key elements for integrated systems such as TOPS. This chapter provides an essential technical knowledge base for designing detailed architectures and determining implementation strategies for TOPS. The core of CIC, and thus of TOPS, encompasses two fundamental aspects: Data Integration (DI), and Application Interoperability (APPI). DI calls for data exchange, access, and sharing (DEAS), while APPI concerns requesting and providing services and data through application communications. The main distinctions between DI and APPI in the context of this research are as follows. First, DI does not involve or require applications to communicate or invoke each other. In contrast, APPI emphasizes mechanisms that allow applications to interact either through software APIs, messages, or notifications. Second, DI technologies focus on the data structures and content, while APPI focuses on data messages and instructions to indicate expected actions to the called applications. Moreover, DI focuses on producing and interpreting data and its meaning within a context, and it does not directly address issues of when other parties will receive the data and how they will respond to it. On the other hand, APPI focuses more on how the other applications react or behave according to the instructions and messages. It is important to note that the concepts of DI and APPI used herein are for the convenience of discussions, since this makes it easier to address the technical issues used in different scenarios. Many CIC application scenarios will inevitably involve some combinations of different DI and APPI schemes. Although generally, the specific technologies involved in DI and APPI are not revolutionary in this research, a thorough overview of the relevant technologies in relation to their use for AEC/FM systems is essential for understanding the design of the TOPS framework. This chapter attempts to examine, or extend when necessary, the general DI and APPI schemes that are specifically needed by, but not limited to, the AEC/FM applications that participate in TOPS. 5.1. Data Integration In this discussion, we use DI (refers to Data Integration) as a designation for the entire context of DEAS. DI is a core aspect in designing a system such as TOPS (Chapter 3), in which the success of the overall system depends largely on its level of DI support. Independent from specific system architectures and implementation technologies, there are several generic DI schemes that are relevant to DEAS and, thus, that can be aligned to some DEAS use scenarios. This section is aimed at exploring the rudiments of the various DI schemes. UBC Page 81 Yu, K 5.1.1. Application Data Scheme At its core, DEAS is about communicating information through the data used by applications. Generally, a software application must support a set of functions. These functions generate and use data, which in turn are represented by a data model. The data model is described by a computer modeling language, while the data are stored (either persistently or temporarily) based on a data structure of a Physical Data Format (PDF) specified by a computer language. In the discussion of DI schemes, it is useful to explicitly "verbalize" and "visualize" this set of application data relations, which is designated in this dissertation as the Application Data Scheme (ADS). Figure 42 depicts the ADS data relations using an EXPRESS-G diagram (ISO 1991). Application supports <p Function ADS —e— Data generates/uses is_defined_by Data Model is stored in is_specified_by Physical Data Format (PDF) Modeling Language is_specified_by -e-Physical Data Format Language (PDFL) Figure 42: Application Data Scheme (ADS) To illustrate the use of the ADS in a software application, Table 7 shows some example ADS elements used in a simple application that lists all the objects and their properties in an ".ifc" file through a MS Windows user interface. Table 7: ADS Example ADS Elements Examples of ADS Elements Physical Data Format Language ISO-STEP Part 21 Specification Physical Data Format #100=IfcWall (120, 108, 6, #101); #101=... Data Model Entity IfcWall Length: DOUBLE; Height: DOUBLE; Thickness: DOUBLE; Room: OPTIONAL IfcSpace; End_Entity Modeling Language EXPRESS Specification Generally, all computer software applications apply this ADS paradigm for their internal data representations, though some of the ADS elements are not explicitly acknowledged or emphasized in the design of certain applications. When software applications participate in DEAS scenarios, their ADS implementations will become important in designing DI scheme uses. UBC Page 82 Yu, K 5.1.2. Direct Data Exchange The most basic and popular data exchange scheme is Direct Data Exchange (DDE). This scheme enables an application to directly exchange project data through the Exchange Data to another application. Figure 43 shows the basic idea of DDE. [Application Exchange Data Application Figure 43: Direct Data Exchange (DDE) To further discuss the details of the DDE scheme, Figure 44 illustrates a decomposed view of the DDE architecture, in which the Exchange Data and the Data Transformer are the basic elements. Application Mapping Specifications Data Transformer ADS Physical Data Format (PDF) Model of Exchange Data I Data Mapping Specifications Transformer i ^ Application Figure 44: Direct Data Exchange Components The Exchange Data is essentially a computer data storage media, usually a computer file or text stream that stores the project information intended to be exchanged between the two parties. Like any computer data for an application (i.e. ADS), the Exchange Data must be represented by a data model (i.e. the exchange data model), and must also be stored according to a PDF. Logically, one requirement for this data exchange implementation is to define the data model and determine a PDF as the agreed upon "standard" between the two participating applications. The process of defining the exchange data model is similar to any other data model development process, that is: 1. define use scenarios and functional processes, 2. identify data requirements, and 3. convert the data requirements into a model language. It is worth emphasizing that the step for identifying data requirements in this context is to discover only the data types that need to be exchanged but not those that support the entire applications. This requirement can be defined by understanding the scenarios of data exchange rather than by examining the application's specific functionality. UBC Page 83 Yu, K The Data Transformer is an application-dependent software engine that converts data between the application's PDF and the PDF of the Exchange Data. It is a requirement for any applications that attempt to participate in such a data exchange scenario to implement a data transformer, which usually provides its application with import and/or export functions for the exchange data. In order to perform the data conversion, the data transformer must use the mapping specifications between the context of the data model and/or PDF language for both the Exchange Data and the supporting application. One advantage of DDE is that its implementation scenario is easy to understand and relatively easy and quick to implement, especially for those applications that are explicitly object-model based. It is also a handy approach for small projects that may sometimes only involve data exchange between two or three applications. Additionally, this approach can work well in terms of data usage efficiency if only a small amount of data need to be exchanged. Unlike the SPDS (i.e. Shared Project Exchange Data Store) scheme, which will be discussed in Section 5.1.4, this scheme does not require the applications to have to access a large storage of project data, which would in turn require much more complex implementation technologies and development efforts. On the other hand, the DDE approach falls short in several ways. First, the exchange data is not typically maintained by a comprehensive data management system such as a DBMS; in fact, the most typical form of the Exchange Data is a physical computer file that is transferred between the application users. Thus, DDE is considered to be the least automated data exchange approach. In practice, it still requires substantial human interactions and communications regarding the information about the exchange files, such as project status, the purpose of the files, the status of objects in the files, etc. Second, as noted earlier, this approach requires each participating vendor to work out a data model and a PDF for the Exchange Data with the partner vendor and implement a data transformer to realize the data exchange. This requires tremendous amount of work (sometimes very repetitious) for a software vendor that needs to exchange data with many applications. Third, since this approach does not maintain a central project data storage that always stores up-to-date project information, it is difficult for an application, and thus a user, to obtain the latest project status in electronic forms. This limitation of runtime object handling prevents certain application types that require up-to-date objects and complex project object information from participating in this data exchange environment. Some of the early DEAS adopters for AEC/FM such as Timberline's CAD Integrator (Timberline 1995) have used DDE as the primary implementation mechanism. Early implementations of the IFCs are anticipated to achieve only a DDE type of project data exchange scenario in spite of the use of industry wide standard models as the Exchange Data. 5.1.3. Standard Project Exchange Data As an extended utilization of the basic DDE scheme, industry-wide standardization of the exchange data model and PDF can allow a much larger range of application types to be involved in this data exchange scenario. Theoretically, a complete real project data exchange environment can be achieved through the use of common project exchange data files among all the applications used in the construction project. Figure 45 shows the conceptual architecture of this extended DDE scheme - the Standard Project Exchange Data (SPED) scheme. The SPED scheme calls for the following basic elements: • A Standard exchange data model • A Standard PDF • Each application must implement its own data transformer U B C Page 84 Yu, K Figure 45: Standard Project Exchange Data (SPED) Practically, there are two basic choices for using the exchange files: one is to use a single project file while allowing applications to work on a local copy of the file. The other choice is to use a set of project files, each retaining the object referential links to other objects in other files. Compared to the simple DDE, this approach provides some major advantages. First, it uses and encourages one set of uniformed representations of data structures that are standards within a certain domain. These standards can effectively open the data exchange opportunities for different applications that agree to speak the same language. The standards can also dramatically improve the common understanding about the context of the business objects. This can, in turn, streamline the industry-wide development efforts of DEAS, and thus specifically of CIC for AEC/FM. Second, each participating application needs to implement only one data transformer in order to work with all other participating applications for data exchange. This is considered to be a big cost and time saving for software vendors, industry practitioners who run AEC/FM projects, and ultimately the building owners who own the facilities. Third, the implementation of SPED can allow all project objects that reference each other to be persisted in one physical or logical data store. This means a unified and complete project data existence can be maintained and, hence, up-to-date project object status can be updated and obtained at runtime. Nevertheless, the drawbacks of the SPED approach are considered to be so critical that they have prevented this technology from being widely adopted. The first drawback, which has been observed in a few major standards-development efforts such as IAI or ISO-STEP, is the difficulty to actually produce the standard models. As discussed in Section 4.3.5, this difficulty is manifested in the following areas: • Agreements on use scenarios, industry processes, models, and software requirements • Technical requirements of project participants • Managerial, organizational and business challenges • Competitor conflicts of interests • Modeling techniques • Documentation requirements • Establishment of practical business cases at a software level among vendors UBC Page 85 Yu, K Additionally, this approach requires significant runtime file maintenance and object data consistency: the former requires a high degree of human management efforts and the latter needs complex software implementations. This approach assumes that the common set of computer files are well maintained across many project participants. Albeit this is still possible, especially for small projects, it can be very difficult to achieve in large projects that involve hundreds of organizations. Moreover, various detailed implementation issues are yet to be resolved in order to achieve the ultimate goal of the SPED, while the architecture itself provides few solutions to those problems. Some of the problems include: partial data exchanges, object ownerships, access or modification privilege controls, data consistency, and so on. Furthermore, like all data models, the standard models must also be described by a modeling language and the standard PDF for persisting data is usually dependent on the modeling language used (see Section 5.1.1). An industry-wide implementation adoption of the standards requires a general acceptance of the modeling language and PDF chosen, for which a variety of software tools should be available. For AEC/FM, given the complexity of the project objects, object-oriented modeling language and PDF are highly desirable. To date, this research has discovered no ideal object-based modeling language and PDF international standards for AEC/FM domains. For example, among the many relevant technologies, the EXPRESS and ISO-STEP Part 21 based formats are not widely acknowledged in North American software communities. This fact has been recognized as one of the major reasons that North American software vendors have only slowly (if at all) adopted STEP or IAI technologies that are extensively based on EXPRESS, ISO Part 21, or SDAI (ISO 1992a) technologies. Another example is UML, in which notations have been developed to be the standards for various software development purchases. However, arguably, those notations may not be appropriate for developing large-scale conceptual models. Their use in real-world software development environment is still limited. This is partially due to the fact that UML tools are not widely available. A more interesting example is X M L . Although this SGML-oriented technology, together with its runtime corresponding standard .API, the Document Object Model (W3C 2000a), may perhaps hold the best opportunity to become the true international standards for the modeling language, PDF, and runtime object access APIs, they are not yet mature enough to support comprehensive object-oriented features. Consequently, the lack of a widely accepted standard modeling language and PDF is another major reason why the AEC/FM industries hesitate to adopt the SPED scheme. The most noticeable example of the intended use of the SPED scheme for AEC/FM is the IFC implementations, in which exchanging data via a common set of project files is set as one of the IAI's primary objectives. 5.1.4. Shared Project Data Store A further extended implementation of the SPED scheme is the Shared Project Data Store (SPDS) scheme, as showed in Figure 46,which is also based on standard conceptual data models. As its name suggests, all project data are contained in a data store that provides access interfaces for applications - that share the project information. Once they are instantiated, the objects or records in the data store usually represent a model of a specific domain entity, such as a complete project model for a real world construction project (Fischer and Froese 1995). Figure 46: Shared Project Data Store (SPDS) UBC Page 86 Yu, K Figure 47 demonstrates a more detailed, yet still high-level, architecture for the SPDS scheme. Unlike SPED, which stores project data in physical files, the SPDS stipulates that the project data are contained in "data storage", and the access to the data must be through standard access interfaces provided by the SPDS Server. The "data storage" is a logical concept: its actual implementation format is insignificant in this architecture. In other words, it can be implemented in, e.g. a traditional database system (the most typical scenario), an object-oriented database, or even a set of files along with software engines that operate on the files. The key point, however, is that the applications only access project data through the standard access interfaces rather than accessing the physical files, and application can assume that the project object data are always up-to-date. Similar to the SPED, each participating application must also implement a data transformer that transforms the data obtained from the SPDS server to the application's PDF. The data mappings are encoded according to the internal functional logic of the data transformer, which in rum, are stipulated by the specifications of the model mappings between the data model of the shared project data and the application data model. From the perspective of data exchange, a key element of the SPDS architecture is the exchange data media scheme (see Figure 47). Although the applications must access the shared project data through the APIs, various data formats can be used to structure these data such as X M L streams, SQL type of recordsets, binary data type passed through the interfaces, or some form of electronic messages. In fact, physical files can still be chosen as the intermediate transformer media, but, conceptually, they are not the primary data containers and do not serve as the primary data entry mechanism for central project information. What is key to the exchange data media is the standard data model - specifically the Domain-based Conceptual Model (DBCM). It is the standard DBCM that specifies the context and semantics of the transformed data and that governs the implementation of the various physical data formats. ADS Data Model PDF > o' SI 5' 3 O r Data Transformer — co 2- 5T n> zi S a. <» > GO 8 > CD in co \ Data Mapping Physical Data Format Model Mapping SPDS Server 1 Shared Project Standard DBCM w CO CO D X 3 CQ i -Exchange Data Media XML SQL T 1 ^ Physical Data Format Data Model i — _ Figure 47: Shared Project Data Store Components UBC Page 87 Yu, K The requirements for the SPDS scheme can be summarized as follows: • A standard DBCM that supports the data format for the exchange data and different application requirements. Since shared project models are used to support different types of applications for data sharing, they must be based on a very comprehensive conceptual model that provides standard data structures to multiple computer applications. For example, a shared project model for AEC should contain information of all aspects of the building project such as the building products, designs, construction plans, costs, and so on. • Comprehensive standard interfaces that must support different functional views of the project objects for various application types. Once the data structures based on the DBCM are instantiated (i.e., project-specific data values are stored), then different computer . • applications can access the data through the standardized program interfaces. • A set of implementation strategies for the SPDS Server that spell out implementation plans for the data model, standard access interfaces, and PDF. Various architecture modes and implementation configurations need to be considered in designing the overall SPDS architecture. A variety of implementation technologies ought to be taken into account for optimum runtime performance supporting different types of applications. • Each participating application should also need to implement a data transformer that converts application's PDF to or from SPDS by accessing the standard access interfaces. • Each participating application also needs to define the model mapping specifications that define the mappings between application's data model and the SPDS's data model. These specifications provide implementation foundations for the application's data transformer. As an alternative configuration, the underlying data structure for the SPDS Server can also be based on standard DBCMs. However, as in most cases, some conceptual models are not necessarily developed for this level of implementation. As a result, the SPDS may not provide the optimum operating efficiency for data storing and accessing. For instance, the IFCs are developed mainly, though not exclusively, for data exchange based on ISO-STEP part 21 files, and its development has included little consideration of the efficiency of the data structure for life-time data access. Consequently, the IFCs' data structure is inefficient when directly implemented as the primary SPDS data storage mechanism and is accessed directly by applications. Compared to the DDE and SPED schemes, the SPDS scheme provides some powerful advantages. Particularly, the entire project object data set is maintained by the SPDS; this ensures maximum data consistency and object access privilege controls. Also, all applications can access up-to-date project information concurrently. Additionally, the SPDS scheme eliminates the need for applications and users to directly manage physical computer files. Consequently, the SPDS architecture provides higher-level automation of data exchange than the DDE and SPED. The SPDS architecture also yields several shortcomings (Eastman 1999). A negative aspect of the SPDS scheme is its much more complex implementation requirements. This approach also requires all the project data that needs to be exchanged to be stored in the project data store. However, some participants may not wish to store all the exchange data in the project data store. Data security is one reason for this hesitation. Unfortunately, the SPDS scheme provides few solutions in this case. In summary, the SPDS architecture makes better use of standard DBCMs for the purpose of DEAS, and provides many unique advantages capable of supporting multiple applications. The SPDS can be one-step closer to achieving industry-wide DEAS for a large domain. UBC Page 88 Yu, K 5.1.5. Data Mapping Schemes As can be seen, a common requirement of all the DI schemes discussed so far is a data transformer that each participating application must implement to exchange the data. The data transformer, however, is coded based on the semantics of the data mappings between the two sets of the data. Therefore, the data mapping is a crucial aspect in determining any DI implementation strategy. Basically, the objective of data mapping is to map one PDF to another, each representing one data set. There can also be several schemes for data mapping approaches, while each of the elements in the ADS (see Figure 42) paradigm for each set of the data to be mapped plays an important role in these data mapping schemes. This section discusses the various data mapping schemes. Scheme 1: Same Data Model, Different Modeling Language, and Different PDF Language The first data-mapping scheme to be discussed is a situation where two sets of the data are supported by the same data model, which is, however, described by different modeling languages. Generally, a PDF language is invented to work with a specific modeling language in order to ensure that the resulting PDF can handle all the notions supported by the modeling language. Therefore, in many cases, if the modeling languages used are different for the two data sets, the PDF languages are also different. Figure 48 shows an example of this scheme, in which the conceptual model used for both data sets is the same one. However, the two data sets have different requirements for the data format - that is, data set A must be stored in ISO-STEP Part 21 format and data set B must be in X M L . Accordingly, EXPRESS is used as the modeling language for the, data set A, while X M L Schema is chosen for data set B. While this approach does not really require PDF language mapping, the main problem is its ability to handle data consistency during data exchange. Specifically, since the two modeling languages may not support the same types of object notations, data in one set may not end up with being converted to another in an appropriate way. For example, the LIST collection type in EXPRESS is not supported by X M L Schema. Nevertheless, there are several interesting issues raised in this example. The first is the mapping between the two modeling languages. Since the basis of this scheme is to use the same conceptual model, a mapping specification for the two modeling languages must be defined in order to create two versions of the same model using two different languages. This modeling language mapping must resolve details such as whether an Entity should be mapped to a complex type, how to handle inheritances or related entities in X M L Schema, how to represent collections like SET or LIST in X M L Schema, etc. It should also be noted that there are no "standards" for this modeling language mapping specifications. Each implementation must define its own modeling language mappings based on their project needs, characteristics of the concerned data, software tools available, and modeling principles and experience. Once the modeling language mapping specifications have been defined, the actual model mappings between the two model versions can be spelled out accordingly. The "Data Exchange" is performed by the data transformer, which is, in turn, based on these model mappings that specify details such as which entity maps to which complex type and which attribute maps to which element. U B C Page 89 Yu, K r PDFL Data Models Modeling Language Data Set A Mapping ISO-STEP Part 21 Y PDFL Mapping (Optional) #100=Wall (#101); #101=Door(36, 84,1.5); Data Set B XML Data Exchange Entity Wall hasDoors: S[1:?] Door End_Entity Entity Door width: DOUBLE; height: DOUBLE; thickness: DOUBLE; End_Entity <Wall> <Doorwidth=36, height=84, thickness=1.5/> </Wall> Model Mapping A f<Schema ...> 1 <complexType |name="Wall"> <element name-'Door"/> </complexType> <complexType name="Door"> </complexType> |</Schema> EXPRESS k' Modeling Language Mapping y, XML Schema Figure 48: Data Mapping based on Same Model Another issue worthy noting is the relations between the two PDF languages used. Some recent efforts, e.g. ISO-STEP Part 28, have focused on developing standard mapping specifications for direct physical formats. These mappings can help to produce different data formats for the same set of data without the involvement of model mappings or modeling language mappings. This approach may be useful in some data integration scenarios, while it may not be suitable or desirable for other cases. For example, a piece of Part 21 code as shown in Figure 48 can be converted directly into X M L as either of the following formats or others, depending upon which PDFL mapping specification is used: Table 8: Data Mapping Example ISO-STEP Part 21 X M L Version A X M L Version B #100=Wall(#101); #101=Door(36, 84, 1.5); <Wall id = 100> <Doorid=101 width=36, height=84, thickness=1.5/> <AVall> <Wall id = 100, idref= 101/> <Doorid=101 width=36, height=84, thickness=1.5/> The two major problems of this approach are: • Because these mappings are not based on the context of the models, the semantics of the data in the resulting data set cannot always be easily identified. • A PDF language chosen is usually based on the modeling language used since both are invented supporting the same set of object aspects. Since different modeling languages have different constraints, a direct mapping between two different PDF languages of the two data sets may not always produce the desired data format. UBC Page 90 Yu, K Scheme 2: Different Data Model, Different Modeling Language, same PDF Language As illustrated in Figure 49, the second scheme occurs when both data sets are persisted using the same PDF language, in this case, X M L . The data models and the model languages used are different. The key point for the data exchange here is the model mappings that stipulate the semantic matches between the two models. It is important to note that mappings between the two different modeling languages, in this case X M L Schema and X M L Data, are not needed in this scheme, although the modeling languages are different. In other words, the specifications for mapping the notations of the two modeling languages are not insignificant since they do not provide the mappings for the model contexts. Nevertheless, the use of a generic data representation format, e.g. X M L , for the modeling languages such as X M L Schema or X M L Data can allow the use of standard mapping software such as an XSLT (W3C 1999) based mapping tool to be used in performing model mappings. This scheme seems to be easier to implement than Scheme 1 because of the use of the same PDF language. PDFL Data Set A XML Mapping No Mapping Data Set B XML PDF i*SNa\> <Doorwidth=36, height=84, thickness=1.5/> tyWall> 1 Data Exchange)) |<Wall> <Opening area=100/> |<AA/all> /^ Schema~7.> s <complexType name="Wall"> <element name="Doors" type="Door"/>... </complexType> <complexType name-'Door"... </complexType> WSchema> y [(Model Mapping <ElementType name="WaH"> <element name="Opening"/> </ElementType> <ElementType name="Opening" <AttributeType>area</ AttributeType> <Attribute name=area/> </ElementType> Modeling Languages I XML Schema No Mapping XML Data Figure 49: Data Mapping Based on Same PDFL UBC Page 91 Yu, K Scheme 3: Different Data Model, Same Modeling Language, Same PDF Language This data-mapping scheme is similar to the Scheme 2, in the sense that the two data sets are based on different models, while the PDF languages used for instance data are the same. Unlike Scheme 2, the modeling languages used for both data sets are the same in this scheme. In Figure 50, the two data sets to be mapped are based on two schemas described using W3C's X M L Schema as the modeling language. As with any typical X M L implementation, the PDF language is also X M L . In this scenario, there is no need for modeling language mappings nor PDF language mappings. The only requirement is to map the matching concepts of the two models in the model specifications so that a data transformer can be developed to convert actual data. The use of a generic data representation language such as X M L and standard modeling languages such as X M L Schema provides immense benefits for software development in the areas of improving development speed and streamlining the development process. For instance, some standard mapping languages and tools can be developed, like XSLT (W3C 1999) for X M L . This approach successfully reduces the data mapping problem to one major issue, i.e. the mapping of domain concepts - an issue that must be resolved by the domain developers. Today's XML-based e-commerce IT paradigm is largely based on this idea. r PDFL PDF Data Set A XML f<Wall> <Doorwidth=36, height=84, thickness=1.5/> l</Wall> Mapping No Mapping Data Set B XML r <Wall> <Opening area=100/> </Wall> Data Modeling <schema ...> <complexType name="Wall"> <element name="Door"/> </complexType> <complexType name="Door"> </complexType> </schema> Mapping /^schema ...> <complexType tname="Wall"> <element [name="Opening'7> </complexType> <complexType name="Opening"> </complexType> Wschema> < J Modeling Language XML Schema No Mapping ^XML Schema Figure 50: Data Mapping based on Same Modeling Language and PDFL UBC Page 92 Yu, K 5.1.6. Meta-models A common model understandable to software applications is one of the key requirements to share and exchange project data effectively. Domain conceptual models, such as IFCs, focus on strongly typed models that describe AEC/FM concepts and objects in an explicit manner. One of the requirements for applications that implement IFCs is that they must understand the semantics of the IFCs and map the IFC models to the application's internal models. However, software applications used in AEC/FM processes are not always based on an internal model that can be explicitly mapped to a strongly typed model. Instead, it is common that some of the applications are either purely generic without an explicitly defined domain schema, or generic enough so that they must deal with run-time databases whose underlying schemas do not match at the same level of the domain models used for data exchange. For example, walls are defined in IFCs as explicit object types, i.e. IfcWall. In a data exchange scenario, an instance of IfcWall should be created from, e.g. a CAD program, representing a real-world wall object. However, because of the requirements of a specific application type, a cost system such as Timberline's Precision may not have built-in explicit representation of the concept "Wall". In specific, Precision's cost database is based on a schema that supports assemblies and items, which can be thought of as any types of objects that can be further broken down into smaller pieces (i.e. quantity takeoff) for pricing purposes. As for what object type an assembly represents, it is up to the end user to define at runtime. In other words, there is not a matching object in Precision corresponding to the instance of IfcWall. In order to allow this type of software to share and exchange data with other applications through the models such as the IPCs, data schemas must be mapped at a higher abstract level that allows for runtime model schema configurations and mappings. Additionally, software data modeling methodologies (XML, UML, EXPRESS, C++, SQL, etc.) for different development purposes and data sharing media use different syntaxes. However, for the applications developed using these different data representations to exchange data, the data supported must be based on the same set of the model contexts (i.e. domain contexts). Thus, the models described by the different languages need to be further represented at a higher level so that the supported data can be mapped. While there can be different approaches, the meta-model approach has a great potential in dealing with these problems. A meta-model, as its name suggests, is a model that describes higher-level abstracted information - that is, the information beyond the domain objects, e.g. a model that describes a modeling language. Accordingly, meta-models are not a model type for representing domain object aspects; rather, they are an implementation approach for data exchange and mappings. Basic Meta-model Scheme The basic meta-model scheme is shown in Figure 51 using a simple EXPRESS-G example (The relationships shown only represent one design of the meta-model. Other design configurations are also possible). Fundamentally, a meta-model is a special information model that describes information such as what a class is and how it is represented, what an attribute is, and how the class is related to the attribute. On the contrary, a regular information model specifies what classes can be used to model some domain, what attributes these classes have, etc. This distinction allows a system to persist data about models (e.g. an instance of "class") in addition to data about real-world domain objects (e.g. an instance of "wall"). This persistent data is presented as Meta-model Content in the figure. Meta-models become an important tool in developing interoperability solutions between systems based on different modeling languages. The use of meta-models also calls for the availability of software APIs that expose the meta-data at runtime. UBC Page 93 Yu, K Meta-model 1:m Class (INV RelatingClass) 1:m (INV RelatedClass) <±> Relationship 1 :m (INV Class) —cp Attribute T data type Enum Cp J enum type — string I Information Model I—| Wall —bounds—oSpace n e . i g M ^width area O 6 , ir-inear measure :area measure Meta-model Content Classes: Wall: Relationship = bounds Attribute = height Attribute = width Space: Relationship = boundedBy Attribute = area Relationships: bounds: RelatingClass = Wall RelatedClass = Space Attributes: height: data type = enum enum type = liner_measure Class = Wall width: data type = enum enum type = linermeasure Class = Wall area: data type = enum enum type = area_measure Class = Space Enums: linerjmeasure: area measure: Figure 51: Basic Meta-model Scheme Meta-model Capabilities The meta-model approach for data mapping supports the following capabilities: • Data exchange without many-to-many application mappings: the meta-model approach allows different application data based on different information models to be mapped to a single data store. This has an enormous value in supporting data integration among many different applications based on different models since it eliminates the need for each application to obligatorily implement mappings for many data models. Obviously, the meta-model approach is a good candidate for a SPDS data integration scheme. • Specifying domain schemas at runtime: meta-models are a late-binding technology. This means that only generic model data needs to be coded at the development stage. Different information models (or schemas) can be specified and stored in the system at runtime. This allows the system to support unlimited domain schemas for different purposes. This feature is extremely valuable in large-scale domain systems that involve multiple domains and their data integration. End users can add more functionality to the system without a need for a software re-build or a new release. • Specifying schema mappings at runtime: because of the above, mappings between different data sets based on different schemas can be achieved through schema mappings at runtime. This is a desirable feature in developing software since it can effectively support dynamic changes of requirements without the need for rebuilding the entire application. • Support for non-domain model-based applications: to provide flexible functionality, many applications widely for AEC/FM functions, such as spreadsheet based applications, are not directly supported by explicit domain objects. The meta-model is a very effective approach to enable these applications to participate in the data integration scenarios by supporting data that describes the context information of the actual application data. UBC Page 94 Yu, K • Support for data mapping based on different model languages: much of the data to be exchanged is in different physical formats. A meta-model can be used to represent the information about the languages used to support the data formats. This provides the basis for mapping the data through the means of meta-data. Meta-model Implementation There can be various implementation architectures using meta-models. Figure 52 shows a very basic usage of the meta-model approach for data mappings. In this scenario, the data set of application A must be mapped to the data set of application B. Each data set is based on an information model defined for the application. The meta-data is a database of information about the model information of both models, while the database's schema is based on the Meta-model. Because the information about the information models is explicitly persistent and accessible at runtime, mappings between the two models can also be specified and stored in a persistent form, in this case, a database of model mappings. To map one data set to another at runtime, the data transformer engine can use the information in the mappings database to map the actual objects to the other data set. Note that because the meta-data and the model mappings are all stored in databases, they can be specified at runtime. That means, at runtime, any additional applications can be supported in this scenario to perform data exchange with other programs. This can be done by adding the information regarding the information model of the new application to the Meta-data database, and specifying the model mappings in the Model Mappings database. Based on this basic architecture, various different configurations can be designed and implemented to support more sophisticated data mapping requirements. Meta-models is stored- Model Content -is stored Application A Information Model supports-Model Mappings Content Application B Information Model Applicatio Data Meta-modeis for Mappings -supports-Actor Figure 52: Meta-model Mapping Implementation Sample Meta-model Summary Consequently, the meta-model method is a uniquely powerful and promising approach for integrated systems. The meta-information is especially valuable for runtime data mappings by supporting richer data. It is encouraging to see that some of the new types of data formats such as X M L for ADO (ADO 2000) now contain both meta-data and object data in a single data file. Extensive use of the meta-model example is found in Microsoft's Repository (Microsoft 2000). It is believed that much more support and adoption of meta-models will be seen in future IT developments. UBC Page 95 Yu, K 5.2. Application Interoperability An equally essential counterpart of DI for CIC and TOPS, is Application Interoperability (APPI), a theme in which applications communicate with others to request certain services or transactions. In the context of APPI discussions, the term "application" means any type of software program that can either execute itself or be loaded by other programs. While one type of service is providing project data for data exchange purposes as described in the DI schemes, the emphasis for APPI is on the software mechanism schemes, based on which the applications communicate. This section is dedicated to the discussions on the various APPI schemes. 5.2.1. Direct Service Request Application -Request Services--Provide Services-Application Figure 53: Direct Service Request Direct Service Request (DSR) is the most popular APPI method used in current software. In this scheme (see Figure 53), one software application or component makes requests for services through calls to the APIs provided by the other application or component. This scheme is the most basic APPI scheme and easiest to implement. This scheme is useful in supporting simple APPI scenarios among a small number of applications, and typically its implementations require running applications on a single machine. Nonetheless, it can still be an integral part of a large-scale integrated system in supporting some specific applications, although it does not provide sufficiently sophisticated functionality for involving a very large number of applications in an APPI environment. DSR can also be used in client-server network communications, while it is rare to use DSR for a distributed APPI environment. 5.2.2. Service Provider Server Request Services ^Application T Provide Services w CL < CD O ' £ CD CO [Service Provider Server I ication plication Application Figure 54: Service Provider Server Figure 54 depicts the Service Provider Server (SPS) APPI scheme. In this scheme, services are provided through a server that consists of multiple applications that actually implement the services. The caller application communicates through the server APIs to obtain services, while it is unaware of what applications reside on the server supporting the services. The SPS is an architecture that is typically used in a client-server environment. One requirement for the SPS is that the service provider applications need to be implemented in a way that they support multiple clients appropriately. One beneficial feature of this scheme is that the APIs are independent of the implementations of the server applications. In other words, new applications can be developed to replace the old ones at runtime. The formalization of the APIs can also provide opportunities for more clients to take part in the overall APPI environment. UBC Page 96 Yu, K 5.2.3. Service Broker and Registration Request Services—*Q— w Applications Provide Services-APIs Service Broker/Service Registration (SBR) Service Registration Server Service |—{ Applications \ Application Register jServices :Load Applications Figure 55: Service Broker and Registration As shown in Figure 55, the Service Broker and Registration (SBR) is an extended application based on the SPS scheme. In the SBR scheme, the application server exposes services, which client applications can request through standardized APIs. The main distinction from the SPS scheme is that the server does not implement the services. Thus, no service applications are required to be built within the server component. In this scheme, service applications must register on the SBR server to claim the services they support. In order for the SBR server to load the service applications at runtime, there should also be some formalized communication protocols specified by the SBR regarding how the service applications can be loaded on demand. The "Registration Server" is a software component including a set of system level set ups that handle and support the protocols. When service applications register their services, they must provide and record such information on the "Registration Server". Hence, in SBR, not only must the APIs be formalized and exposed to the clients, they must also be published so that they can be implemented by the applications that attempt to provide the services. This scheme possesses two important, beneficial features. First, it is an architecture that can truly support runtime plug & play scenarios. The service applications do not have to be compiled at one time in order to offer services since they can be plugged-in at runtime. Second, this scheme does not require the applications to be on the same machine—neither server nor local machines. Furthermore, if some generic networking protocol is used as the basic communication mechanism such as HTTP, the service applications do not need to run on the same operating system as the SBR server. This makes the nature of this architecture truly distributed, and thus it is naturally suitable for distributed environments. 5.2.4. Message-based APPI Section 5.2 explains several fundamental APPI schemes. Many different configurations for real systems can be assembled from these basic forms. A common alternative APPI paradigm is Message-based APPI, in which applications communicate by sending and receiving message data, and operate accordingly. Most notably, Microsoft's entire Windows (Petzold 1998) architecture is, in fact, message-based. The message-based APPI systems are generally intended to support two functions: 1. multi-process or multi-application; 2. late-binding behavior handling. Support for Multiple Processes It is desirable that a running application can be "accessed" by, or respond to, multiple clients. Some of the traditional application-to-application communication architectures require the caller application to access the physical memory address of the called application. This generates tremendous technical challenges for the system developers. One solution for this is to allow applications to use messages as the application communication media that describe the expected requests for services. Since the messages can be "broadcasted" to a "message board", the responding applications can react to the requests described by the messages without being directly accessed by the caller application. UBC Page 97 Yu, K Late-binding Behavior Much of software system design requires that object behaviors be declared at design time, while their implementations can be applied at runtime. Using messages, the system can declare standard behaviors based on the messages so that client applications can be developed assuming that they can "access" the object behaviors, which were pre-declared. For runtime, however, service applications can be developed that implement the behaviors of the objects corresponding to the messages. This APPI approach provides great flexibility in designing software systems and increases the potential for involving many applications in an APPI environment. This section explains various message-based APPI schemes. 5.2.4.1. Message Server and Dispatch (Application ^ Application j<-Message Server Send Messages- Message Dispatcher - Dispatch r-~Messages~ Figure 56: Message Server and Dispatch (MSP) Figure 56 shows the basic components of the simplest message-based application scheme, a "Message Server and Dispatch (MSD)" system. In this architecture, request messages can be sent to a "Message Server", which in turn dispatches the messages directly to the requested applications. In MSD, a message is not persisted in state on the server; that means, once it is sent out, it will be dispatched right away to the requested application. If the requested application is not available when it is requested, the message's validation will expire and the application communication will fail. Although this scheme is easy to understand and implement based on current software technologies, it has a number of drawbacks. Because only one message can be handled by the server at one time and because the message's lifetime is instantaneous, it makes difficult for this architecture to handle communications among many applications. Also, the MSD scheme requires that the applications must remain connected to the server persistently to ensure that they will be able to receive any incoming messages. This sets some limitations to certain application types and domain application usage scenarios. 5.2.4.2. Message Server and Container As its name suggests, the "Message Server and Container (MSC)" scheme implements a container technology on the server that can store and persist a series of messages. Unlike the MSD, in which messages are dispatched immediately after they are sent to the server, the MSC keeps the messages alive in the queue. This technology enables several advanced APPI scenarios. First, the contained messages make the Message Dispatcher an optional component. Because the messages are made available all the time, applications can pick up the messages promptly without the need of a dispatcher to dispatch messages. Secondly, it allows applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. This opens the door for applications to be distributive while participating in APPI across integrated and large-scale domain systems. Thirdly, message containers provide guaranteed message delivery. If the requested applications are not available at a specific time, the messages remain valid and can be re-delivered at a later time. Furthermore, because the messages are held persistently, service components can be developed to provide additional system controls, such as routing, security, and priority message controls, on the application communications and message data. UBC Page 98 Yu, K Additionally, this scheme offers more potential to work in conjunction with standardized domain-based messages so that further advanced architecture technologies can be extended to support more complex DI and APPI scenarios. Moreover, various implementation techniques can be used for the Message Container. For example, Martens and Woo (1997) take an approach of "blackboards" that hold "broadcasted" messages sent by any applications on the network. Service applications must keep monitoring the messages on the blackboards and select the requests of their expertise to perform the services. Responses as the results of the services are also "pasted" on the blackboards so that the requesting applications can acknowledge the outcomes. In comparison, Microsoft Message Queue (MSMQ) uses a queue mechanism for controlling the messages. Since the messages are, in fact, organized in sequence in the queue, responding applications can only pick up the messages from the beginning of the queue. The first-in-first-out algorism is used in this case. Application Application Send Messages-Read Messages Dispatch -Messages-Message Queue H [ Message Dispatcher Message Server Figure 57: Message Server and Queue (MSQ) 5.2.5. Transaction-based APPI The application interaction, schemes, as discussed in the previous sections, usually involve applications invoking other applications directly, to request services explicitly supported by the requested applications. Transaction-based APPI schemes, however, apply to scenarios where clients request a service involving a series of processes by making a single call to a server. The definition of the term "Transaction" in this context can be described as: "a series of formal processes that in their entire completion perform a domain specific job in an electronic form based on a set of operating rules that all processes must obey". Transaction-based architecture involves broadcasting of messages from one application to others. The messages include some types of instructions or notifications indicating that an event has occurred. The messages may also include data sets and may result in a response from receiving applications. Examples of transaction messages include a notification that data has changed, exchange of specific datasets, requests to select and highlight objects in target application, a request to switch to certain views or perspectives, etc. Froese and Yu (2000) discusses the needs for transaction-based APPI for AEC/FM. The basic requirements for the transaction-based APPI include: • The transactions must be standards and published. Although there have been some de facto languages used to describe standard transactions defined by certain efforts (RosettaNet 2000), no international standard transaction language has been widely adopted. • The message types transferred between the client and requested applications must also be formalized. The messages are types of computer data, thus their standardization will inevitably involve standardizing domain conceptual data models and physical data formats. • If one transaction consists of multiple sub-transactions, all the sub-transactions must follow a certain set of rules to ensure the consistency of exchange data and operation behaviors, through which certain business rules can also be applied at the inter-application level. Some example rules could be: "If one sub-transaction rolls back, then all previous ones must roll back", or "Sub-transactions must be operated in sequence". UBC Page 99 Yu, K As discussed in Froese and Yu (2000), transaction-based APPI addresses many of the shortcomings of information exchange based on shared data store while it has better control on how applications interoperate. For example, unlike the shared model based data exchange, in the transaction-based APPI scheme, there is no requirement for sharing complete sets of information between the participating parties. It is unnecessary for the server to maintain a database of project objects and handle the related object access issues. This characteristic also makes transaction-based APPI architecture suitable for many use cases in which sharing the complete dataset is not desirable. There.are several transaction-based APPI schemes worthy of discussion, some of which are addressed in the following two sections. 5.2.5.1. Server-based Transactions Server ( Application Message (Response)^^ Message (Response)" Client Application Transaction z request transaction _ -(standard message)* Figure 58: Server-based Transactions (SBT) In the Server-based Transaction (SBT) scheme, a transaction is supported by the applications that reside on the server machine. This architecture is similar to SPS, but it applies the "transaction" controls into the system. Consequently, the SBT comprises the requirements and characteristics of the SPS and general transaction-based system. 5.2.5.2. Distributed Application Transactions Figure 59: Distribute Application Transactions (DAT) UBC Page 100 Yu, K Similar to the SBS, the DAT scheme is the counterpart of the SBR scheme, in which the applications are distributed outside of the main server. The DAT however extends the entire system to apply the transaction mechanisms. In the DAT scheme, applications that attempt to support certain transactions must register their supporting conformity and their existence on the server. The registration process includes the declarations of the transactions the application supports, how it can be accessed, and how the supported transactions can be requested, and so on. The DAT also requires a transaction server software engine that dispatches the requests to the applications that have registered on the "Registration Server" to support the transactions. Since the DAT is, in fact, a transaction-extension of the SBT, it embraces all the SBT features in addition to those provided by general transaction-based APPI architectures. 5.3. Chapter Conclusion In summary, Data Integration (DI) and Application Interoperability (APPI) stress the essence of integration in computer-integrated construction (CIC) systems. Message-based and transaction-based APPI architectures extend the normal APPI schemes while overcoming some of the DI limitations in supporting data exchange, access and sharing (DEAS). This chapter reviewed several schemes of DI and APPI, as well as message- and transaction-based architectures. Al l these schemes are useful in sophisticated systems that require extensive DEAS and application interactions in a client-server and distributed environment supporting various application types. In the case of many domain application types such as AEC/FM needs to interoperate and require various data integration methods, any of these schemes or their multiparty uses can become essential. The discussions of the chapter provide another stepping stone towards understanding and designing the architectures for large-scale CIC systems such as Total Project System (TOPS), which will be explained in detail in the next chapter. UBC Page 101 Yu, K Chapter 6: TOPS Framework Components Chapter Abstract: The TOPS Reference Architecture Framework consists of conceptual software components at each layer. These components are related according to data integration and application interoperation logic. At the Project Model Services layer, Data Storage provides the main mechanism for storing project data, while Data Services provide functionality for exposing the data. The Domain Functional Services layer holds components supporting domain processes and applications. Project data in the Project Model Proxy layer is maintained by a Proxy Manager and exposed by Proxy Data Adapters. The Project Maintenance Services layer includes Project Session Servers, Registration Servers, and Presentation Servers. Various AEC/FM applications implement adapters to support various modes of data integration and application interoperability - representing true CIC scenarios. All these functional components operate based on standard information models and software interfaces. This chapter explores details of these components defined in the TOPS RAF. Previous chapters provide a knowledge base essential to understand the overall TOPS framework as described in Chapter 3, and spell out all the main high-level technological elements, including detailed discussions of Information Models in Chapter 4 and the various schemes of data integration and application interoperability discussed in Chapter 5. The TOPS RAF structure can also be further decomposed into functional components. Given this knowledge base, more detailed issues regarding the TOPS RAF functional components can be explained. These functional components are also conceptual or logical entities that represent one or more units of functionality required by the reference framework. Thus, they do not necessarily correspond to actual implementation software modules, components, or objects in a specific system. This chapter is intended to discover the required functionality of the TOPS functional components at each layer or thread and to examine how they relate to other parts of the architecture. The entire set of the TOPS RAF components are also presented in Appendix D. 6.1. Project Model Services The Project Model Services layer is the top layer of the TOPS RAF (see Section 0). It contains the following functional and conceptual components (see Figure 60). These components operate based on the functionality of the TOPS RAF threads. This section explains how Project Model Services work and how they relate to the threads. Project Model Services Meta-data Storage Meta-data [ Services [ Project Data Services Project Model Servers I 9 Project ata_SJoracje^-xl - O - o - o Figure 60: Project Model Server UBC Page 102 Yu, K 6.1.1. Project Data Storage Project Data Storage (PDS) is the implementation of persistent physical data formats for the project model (see Figure 61). It contains the persistent data in electronic formats that are commonly required by many project applications. Project Data Storage 1 Project Data Services Data Maintenance" Server Figure 61: Project Data Storage and Data Services Functionality PDS provides primary sources for project information. Its main function is to store updated and interrelated project information. It is required that PDS contains the details of project data that is sufficient for signifying a complete profile of the entire project such as the physical buildings, object status, construction plans, and so on. Moreover, it is commonly desirable from a building owner's perspective that this data storage contains as much project data as possible. However, PDS should not be assumed and treated as the exclusive data source of all project related information. Much project related information is, in fact, not contained and controlled in PDS. Data Integration (DI) From the entire system point-of-view, the DI role of PDS is basically the Persistent Data Format (PDF) as described in Section 5.1.1, Application Data Scheme (ADS). According to ADS, a data model (DM) must also be in place supporting the PDF. For example, if a relational database is used for the project data storage, an entity-relational model should be provided to implement the database tables (i.e. PDF). Technically, the context of the data in PDS is governed by the relational database; however, it must support the type of information stipulated in the TOPS RAF thread Standard Information Models (SIM) that is implied throughout the entire system. When the project data is exposed to clients through the Project Model Server, the Standard Software Interfaces supporting the SIM should be used. Between the two models (i.e. the PDS data model and the SIM) involves the data mapping schemes described in Section 5.1.5, depending on specific implementation approaches. In a more general context, the use of the PDS by the participating applications matches the data integration scheme described in Section 5.1.3 Shared Project Data Storage (SPDS). Implementation PDS is also a logic entity, the entirety of which represents all of the information about the project. The actual implementation approaches of PDS are not significant in the TOPS RAF architecture. TOPS RAF is meant to support alternative configurations of PDS, based on which different implementation approaches must be possible. For example, in designing a real system using the TOPS RAF, either relational databases or any types of physical data files can be used as the implementation mechanisms for PDS. Additionally, this architecture does not exclude the use of distributed sources where the central database is replaced with numerous, distributed, heterogeneous data sources. UBC Page 103 Yu, K Nevertheless, one goal of TOPS RAF-based systems is to provide a complete project model with rich electronic information for facilities management after the project construction has been completed. Typically, a building owner would prefer to receive a complete set of data in one database for ease of use and maintenance during the building operation phase. This, if the distributed database approach is used, in turn requires that a database consolidation strategy be implemented to consolidate the data from distributed sources into a centralized database. System Infrastructure Again, the implementation approach of Project Data Storage can use different methods. When a complex data management system is used, certain systems infrastructure needs to be in place in order to handle the implementation and runtime operations of the data storage. This infrastructure includes operating systems, hardware drivers, hardware configurations, database configurations, and so on (Kimball, et al 1998). The choices of technologies for the infrastructure are dependent on many factors including systems requirements, technical constraints, policy and organizational issues, etc. Whilst the specific issues regarding these infrastructure components are out of the scope of this research, they are essential in system implementations and must be carefully determined in system design. 6.1.2. Project Data Services The physical data in Project Data Storage must be exposed, accessed, and maintained through software engines in order to ensure their availability, healthiness (i.e. the data are updated, consistent, etc.), and accessibility. Project Data Services are intended to provide these services. They represent software engines that implement the basic functions for accessing and maintaining the data directly to Project Data Storage. There are conceptually two functional components, Data Access Engine and Data Maintenance Engine, as depicted in Figure 61. All of the services provided are exposed through software interfaces. Data Access Server A Data Access Server deals with low-level data access functions (i.e. directly at the physical data format level) such as reading and writing the data once they are available within the data storage. This engine understands the data format used in the data storage, and it parses it accordingly and loads it to memory. It also writes data to the storage. Different levels of querying capabilities can be built on this engine. These services are available to the clients of data services (e.g. Project Model Services) through software interfaces, while exchange data is transferred from or to the clients. This scenario is supported by the simple Direct Data Exchange (DDE) explained in Section 5.1.2. Data mapping may or may not be an issue between Data Access Server and its clients, depending on the physical format of the exchange data, i.e. whether it is the same PDF used to support the project data storage. Nonetheless, the system-wide Standard Software Interfaces, specially the generic interfaces, should be supported by the access server in order to expose both the domain data and its meta-information. Data Maintenance Server The data in the storage needs to be maintained in a very healthy state at all the time. This healthiness includes data consistency and data versioning correctness. Other capabilities such as data-level transactions, data indexing, or data backing up and failure recovering can also be supported depending on the needs. If the data storage is implemented using a distributed approach, this server is also responsible for data transforming, consolidating, and updating across the disseminated datasets. Similarly, these services are also exposed through software APIs that are accessible by Project Model Services. UBC Page 104 Yu, K 6.1.3. Meta-data Storage The Meta-data Storage is a key element at the Project Model Services layer. As its name suggests, this element provides persistent storage for keeping information about the data stored in Project Data Storage. Functionality Kimball, et al (1998) mentions several kinds and levels of meta-data as it is implemented in a complex database management system. Any of these can be chosen in implementing a specific TOPS-based system depending on the specific requirements. However, the TOPS RAF emphasizes the need of meta-data to handling multiple domain information models, data exchange, and data mapping between the applications that are based on different information models. Meta-data Object Server Figure 62: Meta-data Storage and Meta-data Services Meta-data Maintenance The data contained in the meta-data storage is about information such as the standard information model, other information models, object types, relationships, attribute types, and so on. In order to represent and instantiate the meta-data in the storage, a meta-meta-data structure (or meta-data catalog) should be defined (see Figure 62). This meta-data catalog is also an essential element in the meta-data storage. Data Mappings What is not addressed in most traditional database management systems is the facility (i.e. a data store) to contain object mappings between two information models. Since the information about each information model can be stored using the meta-data, the object and attribute level data mappings can also be stored in Meta-data Storage (see Figure 62). Once the object mappings information is stored persistently, applications based on the mapped models can exchange data at runtime using the mappings. In the case that both mapped information models are known at the design stage, the mappings can be predefined in Meta-data Storage. However, if one information model is not available or simply the target application does not have a domain explicit information model, the mappings must be specified by the end users at runtime, via Meta-data Services (see next section). The use of meta-data in this Data Integration context implies the scheme discussed in Section 5.1.6. Implementation and System Infrastructure Since Meta-data Storage and Project Data Storage are both about persistent data and data formats, the implementation and system infrastructure strategies as discussed in Section 6.1.1 apply to both cases. UBC Page 105 Yu, K 6.1.4. Meta-data Services As shown in Figure 62, the Meta-data Services element contains functional components including Meta-data Object Server and Meta-data Mapping Server. Meta-data Object Server Meta-data Object Server consists of two basic components: the Engine and User Interface (Ul). Like the Data Access Server for the Data Services, this Engine is responsible for defining the meta-data, and accessing and updating the meta-data and its catalog data using the low-level APIs. It understands the underlying physical data formats used for the meta-data. This engine also handles import and export of the information models. Most importantly, the engine exposes the meta-data using the system-wide generic standard interfaces; hence, any client programs can retrieve and browse the meta-information through a standard set of APIs. Since the system is designed to handle different information models at runtime, meta-data regarding different information models will be specified at runtime by the end-users. Thus, a U l component is needed that allows the end users to define and modify information models. This U l component also uses the interfaces supported by the engine. Meta-data Mapping Server The Meta-data Mapping Server consists of an Engine and Ul . Similarly, the Engine handles data access and updates for the mappings data, while the U l allows users to use the Engine's functions at runtime. 6.1.5. Project Model Servers The Project Model Servers component is yet another key element at the Project Model Services layer in the TOPS RAF. This element is a foundation supporting the domain intelligence for all applications to enhance and utilize through programmable software interfaces. At the backend, it uses the services provided by the Meta-data Services and Data Services and relies on them for low-level data management. At the front end, it represents all the project objects as a project model and provides domain object services to applications. The Project Model Services element has two functional components: the Project Model Utility and the Domain Object Server. Model Servers ject Model Utility Data Import Source Export Broker Engine TJT Domain Object Server Data Domain Manager Objects Figure 63: Project Model Servers Project Model Utility Project Model Utility is intended to import a project model from different data sources and export it to the Project Model Server. Figure 64 depicts the detailed components of Project Model Utility. Project Model Utility Adapter V * — Data Source Broker Import Export Engine Ul Figure 64: Project Model Utility UBC Page 106 Yu, K The Import/Export Engine is responsible for communicating with Project Data Services and Meta-data Services using a Data Source Broker in order to import and export project models. The Data Source Broker is a set of standard and late-binding interfaces that can be used to represent the information of external data sources. In fact, the broker interfaces are also a set of meta-model interfaces capable of representing any data at an abstract level. Because of this, an Adapter (see Figure 64) can be developed that implements the same interfaces to expose the object data for each data source. For this reason, Adapters can also be attached to the system at runtime since the Import/Export Engine only communicates to the standard interfaces specified by the Data Source Broker. This approach allows a new data source to be imported at runtime. The use of meta-model interfaces for the Data Source Broker to map different data models of different data sources is compliant with the Data Integration scheme discussed in Section 5.1.6 Meta-models. As shown in Figure 64, the Project Model Utility requires a UI component, which provides a set of standard user tools for selecting, importing and exporting data sources to and from the system. Domain Object Server The Domain Object Server consists of a set of domain objects in software binary form that is structured based on the standard Information Model. These objects are sophisticated enough to support the aspects described in Section 4.1. Therefore, these objects can support many types of applications. Importantly, the domain objects handle business rules, perform domain functions, support object behaviors, and so on. The Domain Object Server handles the links to Project Data Storage and is responsible for transforming data from data storage to the domain objects. The objects are also exposed through the standard interfaces. Since the domain objects ensure the data integrity using domain rules, clients should not access the project model data directly, bypassing the domain object servers. ^Project Model Services 1 Domain Object Server i Data I . I ^ Domain 1—.—1 1—,— Objects | | | Manager i i i Figure 65: Domain Object Server Two basic conceptual components for the Domain Object Server are the Data Manager and the Domain Objects as presented in Figure 65. The responsibilities of the Data Manager include: • Loading project data to domain objects • Saving domain objects to project data • Synchronizing project data Data Manager is essentially an adapter that maps the data from the underlying storage to domain objects. This adapter understands the formats of both information models and their mapping specifications. The data mapping schemes are addressed in Section 5.1.5. UBC Page 107 Yu, K On the other hand, Domain Objects support the following functionality: Add and delete objects Read and write object collections Read and write object attribute values Object data caching so that it can be transferred over the Net Locate an object given an object identifier Locate an object given some property values Retrieve the collection of all objects of a particular class Follow a relationship from one object to another 6.2. Domain Functional Services The Domain Functional Services layer is below the Project Model Server layer since the former uses the services provided by the later. This layer contains the following four functional services: • Domain Transactional Process Services • Domain Application Services • Domain Functional View Services • Domain Message Control Services 6.2.1. Domain Transactional Process Services Given the goal of the TOPS RAF of supporting Domain Transactional Processes (see Section 3.1.5), The Distributed Application Transactions (DAT) scheme (see Section 5.2.5.2) is appropriate for TOPS-based system to implement. Domain Transactional Process Services Transaction Server [ Message j ^Dispatcher J Message Message Client DTP Application ^J3a^a]og__J Registration Server Transaction Application Adapter Message Dispatcher Message Receiver A Message DTP 7 DTP x Adapter . L ^ ; Application Figure 66: Domain Transactional Process Services UBC Page 108 Yu, K Based on the DAT scheme, a detailed logical component architecture is designed as in Figure 66. Domain Transactional Process (DTP) Interfaces are a set of standard processes defined using programmable process definitions (at the time this dissertation is being written, no standard methodology is available for this purpose). They define standard processes, object interfaces to access processes, and detailed descriptions for each process. A U l component is also needed for service applications or 3 r d party vendors to look up processes that they intend to implement. Once the application chooses a standard process to implement, it can, through a Ul , use the Process Registration Server to register their support for the process to the DTP Application Catalog. The catalog essentially contains information regarding which applications support which processes, and where and how the application services can be accessed. Having chosen a DTP service to use, a client application can request a service by sending required messages to the Transaction Server. The messages include information about the name of the DTP, the calling API, the bit data required by the service, and optionally the payload data used by the service. Upon receiving the request, the Transaction Server needs to access the DTP Application Catalog to find out which application supports the requested process and how the application can be allocated and invoked. Using this information, the Transaction Server can then load an appropriate Transaction Application Adapter, which can attempt to invoke the supporting application and send the requested message to the application. A Message Dispatch needs to be implemented that can send messages over the network (e.g. the Internet). Once the application receives the requests, it starts to perform the services and returns appropriate messages back to Adapter's Message Receiver. The Adapter, in turn, sends the returned message to the Transaction Server, which sends the message back to the client, through its Message Dispatcher. It is recommended that the application implement the same standard DTP through a DTP Adapter. Two configurations for the client using the transactional process services are possible. After a request has been sent out, it can choose to wait for a response. Alternatively, it can drop from the transaction and receive responses some time in the future. The significance of the DTP architecture is that it does not require the availability of a project model that is shared among many applications. The data transferred as messages can also be proprietary information only shared by the calling and called applications. An important advantage is that the message passed can provide an instruction about what is expected of the called application. If the service requires access to a larger amount of data, it can either use the data maintained in the service application data set, the local model proxy, or the on-line project model. On the other hand, data that is not available within any of these datasets can also be passed through the messages and be used by the service application. The Domain Transactional Process approach for the AEC/FM industries calls for work in the following areas: • Formalization of the role of transactional processes to supplement model-based integration. • Identification of types of transactional processes that are common to AEC/FM in general, such that any application should implement these types of processes and adapters in order to participate in an integrated and distributed environment. • Addition of transactional services to the other integration services already under development (such as model-data access services). UBC Page 109 Yu, K 6.2.2. Domain Message Control Services Domain Message Control Services (DMCS) are designed to support the message communications between AEC/FM applications and project participants. The base functional mechanisms for message-based APPI discussed in Section 5.2.4 are used as foundations for DMCS. Figure 67 illustrates the DMCS components. Domain Message Control Services Message Receiver 1 Message Container Message Dispatcher Message Catalog Message Registration Figure 67: Domain Message Control Services The Message Receiver is a component exposing functionality for applications to broadcast domain messages. Upon receiving the messages, the receiver initializes an instance of the Message Dispatcher responsible for sending the messages. In order to send the messages to appropriate parties (e.g. applications or participants), the dispatcher first accesses the Message Catalog for registered applications or participants that claim and are qualified to receive the messages. If the messages cannot be sent out at the time, the dispatcher then persists them to the Message Container that maintains all of the unsent messages. Message Catalog information is updated by applications or participants that expect to receive project messages through the Message Catalog Registration server. The registration server is an engine that updates the catalog database. It also has a UI component. 6.2.3. Domain Application Services Domain Application Services (DAS) enable applications to supply their services to other programs. In the TOPS RAF, the emphasis in this scenario is on the standardization of generic APIs used for the application communication, while supplying various specific domain functions. Functionality The major functionality of the DAS is to provide a central gateway for applications to access domain services that are supplied by other applications. To permit maximum interoperability among the applications, the goal is to enable any service applications to be attached to the system at runtime and the requesting applications can invoke any applications seamlessly, without knowing which specific applications will be invoked at design time. Specific functions that the DAS needs to support include: • Allow users to define domain services using standard interfaces, • Provide a mechanism for applications to claim their support for certain domain services, • Provide a mechanism for service applications to be invoked on demand, • Provide a mechanism for requesting applications to utilize the domain services without the need for proprietary implementation with specific applications. UBC Page 110 Yu, K Architecture Figure 68 illustrates the conceptual components supported by the DAS. The Application Registration stores information about the domain services and applications that claim to support the services. The registration component also exposes its functionality (i.e. get and set domain services, and get and set application information) through software APIs. The domain services are defined through Domain Service Interfaces that are standardized within the system. The Application Broker is a component that can be instantiated by a service request application to access the domain services. It is also required to implement the standard domain interfaces. When the broker is invoked by the requesting application, it accesses Application Registration to retrieve service application and invokes the application accordingly. Once the application is loaded, it is attached by the broker to the requesting application. Domain Application Server (DAS) Application Registration t Application Broker I M Application Domain Service Interfaces Application Figure 68: Domain Application Servers Application Interoperability The DAS in the TOPS RAF is in conformance with the application interoperability scheme of the Service Broker and Registration (SBR) as discussed in Section 5.2.3. Other message-based APPI schemes as addressed in Section 5.2.4 can also be supported for the DAS purpose. It is important to note that data integration issues are not crucial factors to enable this interoperability. That is, the information models and data content of the data passed from one application to another is not the main concern in this case. Rather, the significance of this scheme is the mechanisms of how applications interoperate and the application interoperability thereby supported. 6.2.4. Domain Functional View Services The Domain Functional View (DFV) Services are functional components that deal with functional views of the project model object. These services listed as follows are supported by several components as depicted with examples in Figure 69: • Define Domain Functional Views • Configure Domain Functional Views • Expose Domain Functional Views through software interfaces • Query project objects given specific Domain Functional Views UBC Page 111 Yu, K Domain Functional View Services Example I F u r ? Interfaces Exposinq DFVs ctionalView(s) lObjectType(s) lAttributeType(s) IRelationshipType(s) Example lObject(s) Interfaces ! . . Exoosina i 'Attnbute(s) DFV Objects 1 IRelationship(s) DFVs DFV DFV DFV j | P D F V En 1 Adapters <Adapter> <Adapter> <Adapter> r~l Figure 69: Domain Functional View Services A Domain Functional View (DFV) defines and exposes a set of object interfaces and properties that represent specific domain functional needs for project objects. These interfaces should be generic exposing the meta-information of the functional views. The DFV interfaces also expose object data according to a DFV. From a data mapping perspective, the process of defining functional views inevitably involves information mappings. In addition, the object data exposed from the DFV is the results of data exchange from the project model objects. Technically, a functional view can be treated as an information model different from the project model. To expose object information using the functional view model, objects and their properties of the project model must be converted to the functional view model formats. This conversion is a programming process and is performed by a DFV Adapter. The data mapping scenario in this case conforms to the 3 r d data mapping scheme discussed in Section 5.1.5, that is "Different data model, same modeling language, and same physical data format language" (in this case, software interfaces). The DFV Adapters need to access project model objects' meta-information through the Project Object Services. DFV Services also have a User Interface component that allows users (i.e. application developers) to define and modify functional views, and to attach adapters that implement the DFV interfaces. 6.3. Project Model Proxy Services Project Model Proxies (PMPs) are "representatives" of Project Models. These representatives reside on a local network or individual machine and they represent actual project models by providing the same object interfaces for applications. PMPs encapsulate the tasks required to access remote data sources, as well as providing some local caching of commonly used data, and allow applications to work with shared, remote data sources as if they resided on a local machine. Project Model Proxy Services provide PMP facilities using a Proxy Manager, a Proxy Project Model and Proxy Data Adapters (see Figure 70). Project Model Proxy Services r—1—, Proxy Manager — | Proxy Project Model |—'—| Proxy Data Adapters |—'—| r—^— Figure 70: Project Model Proxy Services UBC Page 112 Yu, K 6.3.1. Proxy Manager An important capability of Project Model Proxies is to maintain the associations with the Project Model Services. A Proxy Manager is a functional component that handles the tasks relating to moving model data between the local model proxy and the remote project data sources. It provides such service by supporting the following functions: • Load project objects from the Project Model • Save project objects to the Project Model • Synchronize project objects with the Project Model This component accesses the Domain Object Server of Project Model Servers (see Section 6.1.5). It transfers project data to and from the Proxy Project Model, which maintains a set of project objects on local machines. The structure of the data transferred by the proxy manager should be based on the standard Information Models used across the entire system. It is also crucial that the format of the data is appropriate for traveling over the Net. 6.3.2. Proxy Project Model The Proxy Project Model is a set of objects that represent an entire or a portion of a project model on a local machine. The objects support the same standard Information Models defined for the entire system and expose object information through the same Standard Interfaces. These hold true for different external data types or different project models. It also can offer objects holding data pass-through from local application to remote server optionally with the capability of being persisted and re-opened at a later time. Data supported by these objects can be updated via the Proxy Manager from the remote project server. It can also be used as a "Project Model" by importing an external data source through a Proxy Data Adapter (see next section). The objects also need to support data persistency so that they can be reloaded when a remote project server is not available. 6.3.3. Proxy Data Adapters PMPs provide a data source for applications to access and use on a local machine. Therefore, PMPs can be implemented using any type of physical data format, either with sophisticated domain data access interfaces, or with one or more data files that can be opened locally. For example, a proxy can either build up an entire copy of the project model dataset locally (e.g. a large IFC file), or from a database of some selected objects supporting a functional view for some specific applications running on the local machine. This mode can be fully supported by treating the data source component as a file, the contents of which are exposed to an application adapter through a model proxy component. These different forms of data sources must be imported to and exported from the Proxy Project Model. Proxy Data Adapters are responsible for this task. Conceptually, one adapter needs to be developed to handle one type of data source. At the software level, the adapters actually perform data mappings between the external data sources and the proxy model objects. The data mapping schemes involved in this case can correspond to any of the schemes discussed in Section 5.1.5. A set of generic object interfaces supporting a meta-model can also be used to map the proxy objects so that the adapters can be attached at runtime to handle new types of data sources. UBC Page 113 Yu, K 6.4. Project Maintenance Services The Project Maintenance Services layer has three functional services: Project Session Services, Project Registration Services, and Presentation Services (see Figure 71). These services provide gateways to applications and project participants to work under a project environment connecting to other system services. This section presents the component functions for these services. Project Model Proxy Services I 1 Domain Services Project Maintenance Services Project Session Services PresentatiorC Services r Project p^ —| Session ~1 Manager I—r Ul Figure 71: Project Maintenance Services 6.4.1. Project Session Services Project Session Services are essential tools for enabling applications to work on different project models (i.e. different construction projects) that are distributed at different sites. The session services allow the users to choose a project and start a project session, allowing applications to access project objects. Two basic conceptual components are required as shown in Figure 71. The Project Session Manager is a software engine capable of communicating with Project Model Proxies or Project Model Servers. It starts a project session by opening a project data source and enabling a connection to project objects. Once a project session is initiated, a project handle object is passed over to the requesting application. Multiple project handles can be instantiated for multiple applications. Once the applications obtain a project handle, it can access project objects. Additionally, standard interfaces can be provided by the session manager component application's adapter to initiate project sessions through program code. The Ul component provides graphical interfaces for users to choose, log on, or log off a project model. Depending upon the approach for a particular application, the U l functions maybe initiated by the application's Adapter code (hidden from user), or initiated explicitly from the user. 6.4.2. Project Registration Services While applications can participate in the entire integrated project environment through Domain Transactional Process Services or Domain Application Services, many project-related operations require the knowledge of project participants in order to handle object access, message notifications, application invoking and utilizations, or uses of functional services, etc. The information about the project participants must be "registered" on the system in computer formats in order for functional servers to use when communicating with various registered applications. In fact, the participant information can be stored in the project model based on the standard information models. Project Registration Services are tools (including a U l component) that allow the end users to enroll themselves as eligible system users and assign appropriate system privileges. UBC Page 114 Yu, K 6.4.3. Presentation Services Although, as noted earlier, various U l services are provided for different functional components, some standard project user-interface tools can also be implemented that perform some general services common to many users and applications. For example, some general project information browser can be provided to allow any project participant to view and update project information. The requirements for these U l components are as follows: • They should use a set of standard controls that have the same commands and look and feel available to all applications across the network. • They should be able to access both project model and local model proxy objects, and operate the same way either with the Project Model Server connection or off-line. • They should be implemented in a way that they can be loaded on a local computer of any distributed applications. 6.5. Applications and Adapters The goal of the TOPS RAF is to allow applications to access, share, and exchange project information and to interoperate seamlessly with each other. Based on the TOPS framework laid out in the previous chapters, there are several data integration and application interoperability schemes for which AEC/FM applications can be enabled, as shown in Figure 72. Adapters are a major thread in the TOPS RAF. They provide connectors for linking software pieces to an integrated system. They enable applications to take part in a highly interoperable environment. The TOPS RAF envisions and supports the notion that all AEC/FM applications can be heterogeneously connected on a network such as the Internet. The distinction between server and client applications in TOPS RAF is insignificant. Many typical AEC/FM applications that deal with sophisticated domain functions can serve as servers or project models supporting a functional view. Many of these applications can behave much like today's Web applications accessed by many users on vast networks. All applications, behaving like clients, can be enabled to share project model data or use other application services. Additionally, all of the applications access, share, and exchange project data. Project participants using the applications can freely send or receive notifications and messages in a highly integrated and interactive working environment. Many applications can also interoperate regardless of their locations, residing machines, or operating systems. This section describes the usage scenarios of how the TOPS components can be used in supporting the CIC scenarios. 6.5.1. Project Model-based Integration A main feature of TOPS is the ability to allow applications to exchange, access, and share common project data. This is achieved through the Project Model-based Integration as shown in Figure 73. This feature enables any legacy applications to participate in this highly integrated environment. Generally speaking, legacy applications, which mainly focus on specific domain functions, are not intended to interoperate with Project Model Services (or Model Proxies). Thin client applications can also use a project model server through standard interfaces directly. UBC Page 115 Yu, K Project Model Services Project Model Proxy Services Adapter Application 1 Domain Function Services Project Model Proxy Services I Adapter Adapter Adapter I Application Figure 72: Applications and Adapters r Project Model Services Project Model Proxy Services Project Model Proxy Services Adapter Adapter Application Application UBC Figure 73: Project Model-based Integration Page 116 Yu, The application Adapter is a key component that enables the integration of the legacy applications to TOPS. The role of Adapter is to map the application data format to the Standard Information Model format supported by the project model (or its proxy). The mapping scenarios involved can be different depending on the types of applications. Direct model-based mappings such as those discussed in Section 5.1.5 are needed if the applications are domain model-based. For example, a CAD application might directly support concepts such as walls, windows, doors, and so on, at an API level. Other types of applications do not support domain objects explicitly; for instance, Timberline's Precision (Timberline 2000) databases support generic concepts such as assemblies but not walls. These application types need the adapters to handle more complex issues, such as meta-data, for data mapping and the adapters may need a UI component for users to specify mappings at runtime. It is worth noting that Project Model-based Data Integration alone does not involve Application Interoperability - that is, the applications do not need to communicate directly through software APIs or any other means to interact each other. 6.5.2. File-based Data Integration Based on the same runtime environment, the applications can continue to use a file-based Data Integration approach (see Figure 74). The exchange file is based on the data structure specified in the Standard Information Model used for the system. This encourages many applications to participate in the data exchange with one implementation effort. Since most applications are not developed based on the domain standard information models, application Adapters are also needed to transfer exchange data to the application data. Similar to the model-based integration, depending on the types of applications, multiple adapters and sophisticated mapping functions may need to be supported, including UI components for users to specify data context mappings. This integration scheme falls into the Direct Data Exchange (DDE) category (see Section 5.1.2) and it incorporates the meta-data mechanisms presented in Section 5.1.6. Similarly, File-based Data Integration does not require APPI schemes so that application adapters can be developed totally independently as long as they can read, write and interpret the standard exchange files. Meta-model Actor Figure 74: File-based Data Integration UBC Page 117 Yu, K 6.5.3. Application-based Data Integration Application-based Data Integration is application-to-application data exchange. This is a variation of Project Model-based Integration, which involves applications communicating directly with one another rather than with a common project database. This mode fits within the reference architecture by simply allowing individual applications to be treated as data sources as well as data clients, and implementing the data source API's against the applications. This mode usually requires the data server application to retain a rich set of data, e.g. a CAD program hosting a complete building product model with rich and accurate geometry data. Data Source Application Adapter Application Interfaces T T T 7 T 7 ADS Adapter Application Figure 75: Application-based Data Integration Figure 75 conceptually depicts the components involved in this integration. The generic data view of software applications, i.e. Application Data Scheme (ADS) discussed in Section 5.1.1 is the theoretical foundation for applications being able to serve as data sources. Nevertheless, in order to enable applications to be used as data sources, an Adapter needs to be implemented that converts the application's internal data and exposes it through "published" Application Interfaces. Like model-based integration, the client application also needs to implement an adapter to communicate Application Interfaces to retrieve the application data. In the TOPS RAF, generic standard interfaces ought to be implemented as the base interfaces for Application Interfaces. This empowers the applications to use many other applications' data seamlessly. 6.5.4. Transaction-based Interoperability Transaction-based Interoperability features of the TOPS RAF enable AEC/FM applications to perform domain services by sending just essential instructional messages to the requested applications. This overcomes some drawbacks of the model-based approach. This interoperability is achieved in the TOPS framework by Domain Transactional Process Services (DTPS) as depicted in Figure 76. request (response) Domain Transactional Process Services Adapter Application request (response) Figure 76: Transaction-based Interoperability UBC Page 118 Yu, K As presented, the project data sources such as project models, proxies, or data files are not required in the architecture. If a requested application must use project data to perform the requested domain processes, it is responsible for requisitioning the data from any sources available. Adapters must be developed in order for a domain application to either utilize or supply the transactional processes. These adapters either directly invoke the U l components or access the APIs supported by DTPS. The interoperation of the domain processes involved in the transactions is two-way communication, meaning that the adapters for the calling applications wait for a response from the server for the outcomes of the transactions. 6.5.5. Message-based Interoperability Likewise, Adapters are key components to enable applications to use message-based interoperability. Conceptually, two adapters are needed; they are Message Adapter and Data Adapter as shown in Figure 77. Domain Message Control Server Send Message / t v1essage s \ ^ / Data \ A d a p t e r / " ^ X A d a p t e Pick Message Receive Message i _ . . l e s s a g e x / ' Data \ /Message^. / Data v^dapterx~^ .Adapter / \ A d a p t e r / ^sAdaptery I Application (Application Application Figure 77: Message-based Interoperability If the application sends domain messages, the Message Adapter is used to communicate with the Message Receiver of the Domain Message Control Server (see Section 6.2.2) and send domain messages. Alternatively, if the application is to pick up messages from the server, the Message Adapter is then responsible for connecting to the Message Container, monitoring the messages, and picking up the messages. However, if the application expects to receive messages automatically through the message server, the adapter provides interfaces for the Message Dispatcher to send the message. The Data Adapter is an independent engine and can be used by any other components in all three cases. It provides data mapping engines for transforming data formats between domain messages and application internal data sets. 6.5.6. Direct API Interoperability Direct API Interoperability is concerned with scenarios in which applications invoke other programs using software APIs. This scenario is popularly supported in many current applications. However, in the TOPS RAF, this interoperability is supported by standard APIs that can be implemented by service applications using adapters. The standardization allows any applications to implement one set of interfaces of typical domain services (e.g. visually view an object) so that an application requesting such a service just needs to implement one adapter. UBC Page 119 Yu, K Application Adapter Domain Application Server (DAS) Application Registry Application Broker registry - Application + \ Adapter Figure 78: Direct API Interoperability As a result, the requesting application can virtually interoperate with any applications that provide the same types of services. Domain Application Servers (DAS) discussed in Section 6.2.2 can fully support this interoperability. Again, Adapters are key components in this architecture (see Figure 78). For the calling application, the adapter is responsible to interpret the application specific command. It can invoke an instance of the Application Broker that will in turn invoke a called application according to the application registration. The called application also needs to implement an adapter in order to implement the standard interfaces and thus can be invoked by the Application Broker. 6.5.7. Web Applications Although this mode provides a marked departure from traditional desktop-based applications, it still fits well within the general distributed-system architecture. The primary difference is that all of the components shown in the typical architecture reside on servers, with the exception of the user interface elements of the application, which are separated out and delivered to the user's computers through Internet HTTP capabilities. Dot.com portals can serve the project model servers, provide other services by registering domain functional services, or provide thin clients to access the project model server. They can also serve as any types of client applications accessing project model hosted on other machines on the network. 6.6. Chapter Conclusion Based on the AEC/FM information models developed in Chapter 4 and essential software technologies for data and application integration as summarized in Chapter 5, this chapter further explores the details of the TOPS RAF at the conceptual software component level. It provides a thorough analysis on how the components of different TOPS RAF layers and threads inter-relate to others in an integrated system. It also explains how these components support AEC/FM applications in data integration and application interoperability. All of the details covered in this chapter can be thought of as part of the functional specifications for the TOPS RAF to support actual developments of CIC systems. To validate the concepts proposed in the TOPS RAF architecture, prototypes supporting CIC scenarios can be developed based on the architectures specified in this chapter. The next chapter will demonstrate a complete validation process, including software prototypes developed in this research. UBC Page 120 Yu, K Chapter 7: Implementation and Validation Chapter Abstract: One of the primary contributions of this research is the reference architecture of TOPS (the TOPS RAF) that utilizes the information models developed as the base standard data representations. To validate the TOPS architecture and the information models developed, an actual system prototype is the most logical approach to examine the workability of these research results. During the course of the research, several software systems have been developed or enabled using the TOPS RAF. These systems range from commercial applications to research prototypes, covering major AEC/FM domain functions. It is intended to use these systems as the validation mechanism for this research. In this chapter, a thorough description of these systems is provided, including their systems architectures, components; services, and AEC/FM applications and usage scenarios supported. To validate the research, a set of validation criteria are defined and validation procedure is determined. The results of the validation are summarized The theories developed throughout this research must be validated. In this case, the testing is performed by software programs as an approach for proof-of-concept. The programs utilize the theories as design guidelines and implement the technologies developed in the research. Additionally, the programs are intended to allow for experimentation of the research theories. They are used to examine different design configurations. This chapter explains the details of the software systems, and how they are used in the theory validation. 7.1. Overall Process The overall validation process involves two major parts involving several steps: Application Implementation and Validation, as described below: • Application Implementation 1. Determine application scopes 2. Design application architecture 3. Determine usage scenarios 4. Select or develop domain programs 5. Implement the applications 6. Run the applications using construction project data • Validation 1. Define validation criteria 2. Validate applications 3. Summarize validation results The following sections describe the details. UBC Page 121 Yu, K 7.2. Application Implementation Several software systems have been developed, which both contribute to the development of the TOPS RAF and benefit from the use of the TOPS R A F as a design reference. These programs cover a extensive range of A E C / F M functions, and they support a rich set of CIC functions. They are also used to validate the usability of TOPS RAF and the information models developed in this research. This section describes these software systems. 7.2.1. IWPM Prototype The architectures used for the prototype developments evolve throughout the research. The first prototype is a project model-based architecture that is developed in a collaborated effort of the Center for Integrated Facilities Engineering (CIFE), UBC's Computer Integrated Construction lab (primary contributor Professor Thomas Froese) and Timberline software (represented by the author). This project is called "Interactive Workspace for Project Management (IWPM)" (Froese, Yu, Liston, and Fischer 2000). Several important architectural concepts of TOPS R A F were experimented in this prototype including: component layers, project data model, project model proxies, and application adapters. 7.2.1.1. IWPM Architecture The Interactive Workspace for Project Management (IWPM) is a CIFE (Center for Facilities Engineering) project that integrates several research decision support systems, commercial project management systems, and advanced collaborative human-computer interaction approaches using emerging industry data standards and Internet technologies. The project involved the simultaneous use of several construction-related software tools to analyze the effects of changes to construction plans made during construction site meetings. This approach requires the ability to share project information among the different software programs. Exploring this construction system integration was the second major objective of the project. Thus, although the integrated systems approach is not dependent upon the interactive workspaces, the workspaces work both requires a solution for information integration, and provides an excellent test bed for it. Figure 79: IWPM Architecture UBC P a g e 122 Yu, K 7.2.1.2. IWPM Applications The integrated system developed for this project is illustrated in Figure 79. The system included three applications: a custom 4D tool (3D CAD plus time visualization), Primavera Project Planner for scheduling and resource management, and Timberline Precision Estimating for cost analysis. The shared schema was based loosely on the IFC Release 2.0 model, but was greatly simplified to provide only the data representation required for this prototype. It contained approximately 10 object classes for representing building elements (without geometry), work plans, work tasks, resources, and costs. 7.2.1.3. IWPM Components The adapter component for the 4D tool was created within the source code of the application, and allowed import and export of building objects, scheduling tasks, and relationships from building objects to tasks. The adapter component for Primavera was implemented as a stand-alone utility that mapped schedule task and resource information from the shared project model in and out of Primavera's COM API. The adapter for Timberline was a stand-alone utility that mapped building component, schedule task, and resource information from the shared project model into Timberline cost estimating assemblies, through a Timberline COM API, to create an estimate within the Precision Estimating application. The local model proxy component implemented the shared schema objects and exposed them to the adapter components through a COM interface. Data layer components were developed for both X M L file and relational database data storage options. 7.2.1.4. IWPM Usage Scenario The prototype was fully implemented and used to conduct a test-case scenario. This scenario, drawn from an actual project situation, centered on a site meeting held during the construction of a new Disney theme park. A contractor had realized that the original construction schedule did not provide adequate time for equipment testing required after a lagoon area was filled with water. Therefore, the construction operations for the lagoon base would have to be accelerated. During construction, however, a congested site necessitated that the lagoon area be used for material lay-down and crane working areas. Thus, the acceleration of the lagoon construction had to be carefully planned and coordinated among numerous work groups. At the beginning of the scenario, the three construction planning applications (4D tool, scheduling, and estimating) and the common project database were all synchronized to the current construction plan. The analysis of the proposed change began with changes made inside the scheduling application to the number of crews assigned to the lagoon base construction activities. This resulted in a revised and accelerated construction schedule. The revised schedule dates and resource assignments were then exported from the scheduling tool to the project database. Next, the new project information was read out of the project database and used to create an updated cost estimate, which could be compared with the initial estimate (although the building components and activities were the same, the addition of extra crews had been accompanied by a slight decrease in productivity, so the overall cost was somewhat higher). Finally, the new schedule information was read from the project database into the 4D-planning tool, so that the new construction sequence could be carefully analyzed for adverse work interactions. UBC Page 123 Yu, K 7.2.2. Jigsaw Project The next generation of the prototype system is named "Jigsaw", which is exclusively developed in a research project led by Professor Thomas Froese at the Computer Integrated Construction Lab in the Civil Engineering Department of the University of British Columbia. The basic idea of the Jigsaw project is to develop a system supporting several AEC/FM applications based on a system architecture that conforms to the TOPS RAF. The Jigsaw project is intended to support both project-model-based data integration and transaction-based application interoperability. The Jigsaw system implements the TOPS RAF by creating necessary system components that enable a wide variety of AEC/FM applications to interact. These applications can serve as both data servers and data clients, and they communicate to exchange project data through a standard API, which exposes project object data based on standard information models, in this case, IFCs. Specifically, the Jigsaw system utilizes X M L as the base data format and the X M L DOM (W3C 2000a) for base APIs. 7.2.2.1. Jigsaw Architecture The Jigsaw architecture is an application closely based on the TOPS RAF in a distributed environment. In this architecture, every application is required to communicate with others using a standard set of interfaces (or API), through an application adapter (see Figure 80). Because of the standard interfaces used, any application, serving both data client and data server roles, can freely exchange data with another. Additionally, the data transformed through the interfaces is based on standard data models, e.g. IFC models. Each application can choose to support one or more data models through its adapters. Applications can also choose to support either early binding or late binding for data, through the same generic Jigsaw interfaces. Data Data Data Source Source Source Adapter Application Adapter Application Figure 80: Jigsaw Architecture The Jigsaw API is called JsServerDOM (see Figure 81). In a typical data exchange scenario, a data client uses JsServerDOM for a l l communications w i t h other a p p l i c a t i o n s or data sources. The Jigsaw data server component provides an adapter for an underlying data source, adapting it to the JsServerDOM APIs. Data Client -JsServerDOM-T Data Server Client Data Files Data Source Specific API Data Source Figure 81: Jigsaw APIs UBC Page 124 Yu, K 7.2.2.2. Jigsaw Components A set of the major Jigsaw components is shown in Figure 82. The following are some of the components envisioned for the Jigsaw system: Jigsaw Client Components: • JsBrowser: Connects to any Jigsaw data server to browse and edit data. • JsTransporter: Connects to any two Jigsaw data servers and moves data between them, acting as a general data import/export tool. Data Source Adapters • JsXMLFileAdapter: Adapts X M L files to act as a Jigsaw data server. • JsP21 Adapter: Adapts STEP Part 21 files to act as a Jigsaw data server. • JsMSRepositoryAdapter: Adapts Microsoft Repository to act as a Jigsaw data server. • JsRemoteDataProxy: Acts as a local Jigsaw data server that connects to a primary data server on a remote server using SOAP (XML and HTTP) protocol. • JsRemoteDataServer: an optional component that works with an H1TP server to accept SOAP connections from JsRemoteDataProxy clients and pass them on to a Jigsaw data server residing on the server (local server components may be able to play this role directly). Software Components • JsServerDOM: The interface specification for Jigsaw data servers. • JsApplicationObjects: Jigsaw Application Objects are custom, data model-specific components consisting of Visual Basic classes that implement a specific data model as a Jigsaw data client. These classes are generated by the Jigsaw Modeling Tool. • JsCommonAppObjs: A component that provides general support for Jigsaw Application Objects (common for all data models). • JsVisualizationEngine: A "visualization shell" that allows custom visualization applications to be constructed for Jigsaw data. Some clients and servers can work with any datasets supported by any information models through late bounding (due to the use of generic standard API), while others can work with pre-specified information models via early bounding with the standard information models, i.e. IFCs. Applications can import and/or export project data by using one or more of the following approaches: • Implementing a jigsaw data client • Implementing a jigsaw data server and using JsDataTransporter to transport data • Working with another data source that Jigsaw interacts with. UBC Page 125 Yu, K IAI Q_ < o in A A a> o I E 3 f V Q (/) y ~ 3 CD to 0) A Z A A) w o v S </) c o A A A A (0 u Figure 82: Jigsaw Components UBC Page 126 Yu, K 7.2.2.3. Jigsaw A E C / F M Applications The Jigsaw system supports several AEC/FM applications that share and exchange project information. This section introduces these applications and explains how they are supported by the Jigsaw architecture. TOPSPro TOPSPro integrates construction scheduling information with design data by allowing the users to assign the scheduling tasks to building objects such as walls or windows. It also provides a set of rich views of the project information through its user interfaces. These UI views display project object information from different perspectives such as attributes, costs, tasks, resources, construction progress animation, and so on. Timberline's PECAD Led by the author, Precision Estimating CAD (PECAD) is a new commercial software application developed by Timberline Software Corporation (Timberline 2000). PECAD imports design information through IFC 2.0 data files, X M L , and potentially other design data formats. It generates cost estimating information for the building objects and exports the information into the integrated design data source such as IFC 2.0 files. PECAD can also interoperate with other applications such as MS Visio to show the different views of the building objects. More information about PECAD architecture is provided in Section 7.2.4. Asset Management Tool (AMT) The Asset Management Tool (AMT) (Hassanain, Froese, and Vanier 2001) is an integrated application that supports processes involved in facilities maintenance management. Built in a rich database of asset inventory, assets can be identified and their Performance Requirements can be specified. The user of AMT can then perform condition assessments for the assets and develop strategic maintenance plans, which include cost estimates, asset failure probability analysis, and asset life cycle service analysis. It can then create maintenance work requests, which can, in turn, be used as input for creating detailed maintenance work task plans. Within the Jigsaw environment, AMT can act as both a data server and client, capable of importing CAD and roofing system data, and importing and exporting work task information. JsRoofer JsRoofer is a Jigsaw adapter that connects to an existing industry database of roofing maintenance information in relational format - MicroRoofer. Like other Jigsaw adapters, JsRoofer supports the standard Jigsaw API, JsServerDOM. Therefore, the roofing information can be made available for any Jigsaw clients such as AMT. Other Applications The Jigsaw package also includes other AEC applications that are available as commercial software. Two examples of these applications are Microsoft Project (a project management scheduling program) and Autodesk's Architectural Desktop (ADT), which is an architectural CAD application. The applications are connected to the Jigsaw system through application adapters, serving either as data servers or clients. UBC Page 127 Yu, K 7.2.3. TOPS Prototype (TOPSPro) Developed by the author, the TOPS Prototype (or TOPSPro) is a set of software programs based on the TOPS architectural framework. These programs integrate different types of AEC data sources and provide a rich set of domain functional views, which allow the user to browse and view project information of different types from different perspectives. TOPSPro, along with other Jigsaw applications, provide a proof-of-concept of the TOPS RAF. 7.2.3.1. T O P S P r o Functionality There are two client programs included in the TOPSPro: the 4D-Enabler and the Project Browser. 4D-Enabler The 4D-Enabler, inputs two types of data sources: design data and scheduling data. It shows the design information through a hierarchy of building objects, which can be organized in groups defined by the user. 4D-Enabler also displays scheduling tasks and resources information. It then allows the user to assign tasks to the building objects, which are operated by the assigned tasks. The assigned tasks and the assignment information can also be saved along with the design data within a single data source file. Integrated Project Browser (IPB) The Integrated Project Browser (IPB) imports integrated design data sources of different formats. Once the integrated project data sets have been imported, several domain functional views, as follows, can be used to browse project information: • Product Tree View: provides a hierarchical or tree view of the object relationships. • Attribute and Cost View: displays a list of attributes and costs for each object in the project. • Task and Time View: shows the schedule tasks related to each building objects. It also displays a 3D representation of each constructed building object at any given time. • 4D Animation View: provides animated displays of the building objects being built up based on the scheduling information. • Resource View: shows the construction resources associated with the products at any time. UBC Page 128 Yu, K 7.2.3.2. TOPSPro Architecture As depicted in Figure 83, the system architecture used in the TOPSPro conforms to the layered systems architecture design principle specified in the TOPS RAF. Whilst it does not cover all of the aspects of the TOPS RAF, this architecture closely follows the TOPS framework. Client Applications System Standard Data Models Data Broker } = J Data Adapter ta Adapter Data Adapter Data Sou reel Data Source Data Source External N\ / External \f External Data Modelsy yData Modelsyvpata Modelsy1 < -o -o o -o -o -o Figure 83: TOPSPro Architecture The key features of this architecture include: • Separation of UI from Internal Systems The separation of the client applications from the internal systems and engines allows the applications to easily integrate and benefit from using various data sources of different models, without the need to modify or recompile the UI source code. Additionally, it allows for the same system engines and data models to support different UIs for different application functions. This architecture was proven in TOPSPro to be an important aspect in TOPS RAF because of the requirement of integrating many kinds of data sources in CIC systems. • Generic Software Interfaces (or API) A set of generic software interfaces is used by TOPSPro data servers. They provide consistent access points of the system functionality for the client applications. Unlike explicit software interfaces that are defined based on a specific domain data model, e.g. IWall, Idoor, or IWall->Doors (T indicates 'interface'), the generic interfaces expose objects and their relationships using a standard set of interfaces. For example, any object of different domain models is exposed through IObject, while any object relationship is exposed through Iobject->RelatedObjects ('RelationshipName'). Therefore, the client applications are able to seamlessly access and utilize different data sets from different data sources using the same software interfaces. These generic interfaces provide a mechanism for the data broker and data adapters to supply runtime project data of different types using a consistent manner. • Data Broker The Data Broker, which supports the Generic Interfaces, is a software engine that provides the contacting point for the client applications to access the internal systems. It performs the 'hand shaking' with the clients in order to understand what data source type is being requested, and it loads the appropriate Data Adapter, which provides actual data services to the clients. Due to the use of the Data Broker, the clients do not need to be aware of the existence of the various adapters, but they are able to use the various data sources. The benefit of this mechanism is that, when new adapters are added to the system to integrate new types of data models, the client programs do not need to be modified. UBC Page 129 Yu, K • Data Adapters The Data Adapters are software engines that perform the actual functionality for importing and exporting project data. The adapters also support the Generic Interfaces. As a result, when they are attached to the client programs by the Data Broker, the clients can access the functionality provided by the adapters transparently. As explained in the previous chapters, the importing and exporting of the project data essentially involve data mappings between two data sets based on two data models. While this architecture allows for various data mapping mechanisms to be implemented without any impact to the functionality of the client applications, TOPSPro utilizes the Direct Data Mapping based on early-binding techniques as discussed in Section 6.5 of Chapter 6. • System Standard Data Models These are data models used by TOPSPro. These data models define data structures of project information relevant to the client applications. A key architectural feature related to these models is that they are defined separately from the internal software coding system, i.e. outside of the data adapters' source code. This allows for the models to be modified, or the new models to be added. It also makes the models available in well-documented formats to the client applications. Consequently, the clients can choose to either access the project data using late-binding mechanisms without having to enforce the interpretations of the model semantics in software code (as in the case of a generic data browser), or use the data sets based on an early-binding method to support more specific domain related functionality. The Generic Interfaces allow either implementation scenarios. • IFC 2.0 Model Support The IFC 2.0 Models supported by TOPSPro (through TOPS_IFC20Adapter) are the models described in Chapter 4. The actual project instances based on these models are populated in ISO STEP Part 21 file format and X M L format based on BLIS X M L Schema. BLIS (Building Lifecycle Interoperable Software, BLIS 2001) is a coordination project involving AEC/FM software vendors who are committed to implementing IFC 2.0. These models, which are considered to be the inter-system wide standard information models within TOPSPro, also supported by Jigsaw interfaces and other AEC applications such as Visio 2002 or Graphisoft ArchiCAD 6.5. This use of the standard models conforms to the TOPS RAF over a wider scope than TOPSPro itself (see Section 3.2.5.1). The Part 21 files or the X M L files are the data exchange media between the systems - a use case of data mapping as described in Section 5.1.5. UBC Page 130 Yu, K 7.2.3.3. TOPSPro Usage Scenario This section presents the usage scenarios of TOPSPro. An overall usage scenario procedure which also includes PECAD (as described in Section 7.2.4) is shown in Figure 84. As stated in the last section, TOPSPro includes two major client applications, the 4D-Enabler and the Integrated Project Browser (IPB). The usage scenarios of each application are described in this section. C Visio ArchiCADY Microsoft Project MPP File Integrated Project Browser Product View Attribute View 4D View Time View Cost View Resource View Task View Document . View / Figure 84: TOPSPro and PECAD Usage Scenario 4D-Enabler The usage scenario for the validation is a virtual construction project of a 4-story office building. In this project, a construction schedule containing work schedule tasks was created using MS Project. Then, 4D-Enabler imported the schedule file. Al l of the schedule tasks are presented in 4D-Enabler in a tree view showing the relationships of tasks nesting other tasks (Figure 85). Detailed information about each task can also be viewed, such as predecessors, successors, start and finish time, durations, and so on. Information about construction resources assigned to the tasks can also be viewed. An initial architectural design of the project was also completed using MS Visio 2002, which supports IFC 2.0 for exporting design data. The next step of this scenario is to export the design file from Visio format to IFC 2.0 format. Then 4D-Enabler imported the TEC file and presented the design information through its user interfaces. In specific, building objects are listed based on certain relationships. For example, walls were listed as contained objects of the story, while windows were shown as sub-objects of a wall. Detailed attribute values of each building object could also be viewed. UBC Page 131 Yu, K iSfxj Schedule Project Repository Schedules 1: Foui-stoiy Office Building (100.000 square feet) 4SturyBldg_0709.mpp - s r H 2: General Conditions • 10: Long Lead Procurement H 18: Mobilize on Site E3 24: Site Giading and Utilities H 32: Foundations H 33: Excavate foundations P 34: Excavate elevator pit P 35: Form column piers and spread foundations P 3S: Rough-in electric and plumbing in elevator H 37: Form elevator pit walls H 38: Set reinforcing and anchor bolts H 39: Pour column piers and foundations H 40: Pour concrete elevator walls P 41: Cure elevator wall concrete H 42: Cure piers and foundations H 43: Strip wall forms P 44: Strip column piers and foundation forms H 45: Install pneumatic tube in elevator pit P 4S: Prepare and poui concrete floor in elevator pit P 47: Steel Election P 56: Form and Poui Conciete - Floors and Roof Start: Finish-Duration: Early Start: Early Finish: Late Start: Late Finish: Free Float: Total Float: Is Critical: 1)312001 8:00:00 A M 6M2002 5:00:00 P M 369 Days 1)3(2001 8:00 00 A M 6M2002 5:00 00 P M 113(20018:00:00 A M 6/3/2002 5:00:00 P M OOays ODays True Building Components Protect - Site - Building - Stories (4) - j j Story: Test bldg 2 Floor 1 IBr i lHPf! I l - Columns (10) CJ ColumnS204 _J Column8208 _J Column8214 1 Columntt21B _j Column8218 ; " J Columntt228 !_J Column8373 i Column8374 i_J Column8375 _J Column8376 i JJ Walls (67) B L±j Windows (85) S i i Doors (19) 1 *J Story: Test bldg 2 Floor 2 + Story: Test bldg 2 Floor 3 i i Si Story: Test bldg 2 - Floor-4 I Form 1 st floor I Install rebar and in-flooi utilities I Pour 1 st floor slab I Cure 1 st floor slab _ | Strip forms from 1 st floor slab Figure 85: 4D-Enabler Usage Scenario Typically, scheduling tasks are defined based on different construction working zones or object groups. For instance, a work task can be defined as "pouring concrete for columns in zone 1 on second floor". Therefore, building objects can be grouped into any user-defined groups. Then the work tasks can be associated to any building objects. Once all the task-object associations have been complete, the overall design data set—including the work tasks, resources, building objects and their associations with the work tasks—can be exported into an integrated project data source or format, in this case, an IFC file. Integrated Project Browser (TPB) The Integrated Project Browser (IPB) imported the IFC file containing the integrated project information, which included building objects, associated scheduling tasks, and object costs (which can be exported from P E C A D as described in the next section) (Figure 86). Once the IFC file was loaded into Project Browser, all of the building objects were shown in a tree view representing the containment relationships of the objects based on the building systems such as architectural, structural, or H V A C . To provide more detailed information for the user about each object, an attribute view could be used. Because the building objects were associated with scheduling tasks, the time view could show when a specific object would start to be built and when it would be finished. Details about the associated scheduling tasks could also be viewed. Additionally, the user could also visualize the building design in 3D mode. UBC Page 132 Yu, K j.ProJMl Vwjjte C:\MyDoair^ ^ Projects Work Flans Mews Wnfcws JM 1 ioix - j S i t e - _ J Stories (4) •-J$iofideslbld§2-Fta1 +-_| Stoi^: Test bldg 2 - Fkxs 2 Name j Value CuveAnde 0 ErtaiorOiirtew 1 FifRatag Heght 2500 Hcraniaftncje 0 Length 3400 LocaiPkemenlX 15000 LocaiHacemenff 13400 LDcalPiacsmentZ 0 8 . • x Worktask | Start | Finish Imtal flashing at paiapeiwak 12/3/2001 i n 3 4 5 6 7 10 11 12 13 14 15 16 1? 18 10 20 21 22 23 24 25 26 27 20 23 2 3 4 5 6 ? 3 10 © 1 2 13 14 25 26 27 26 23 30 31 1 2 31 5 6 7 3 9 III 12 13 14 15 16 i; 19 20 21 22 23 2' 26 27 28 29 30 3' Finish I Task 1 2 M D 1 Iraalfl 0 x Caiegcfj Cost I Qmency Labor 2 M USD M M 138.7 LSD S t tan tad 0 USD 0 USD Other y USD lotal : 435.G8 JbD - • ! x] n o w View AsDesigned r AsBuiliof ™ 1 ™ j 500000 -J w N a 1e+006 500000 - U t a Cost - M*CTKCCS • foufmsrt Cost S t a t e Cos! - OherCosI - TcWCost N M  «OS S J J P) Figure 86: IPB Usage Scenario UBC Page 133 Yu, K Moreover, to evaluate the feasibility of the construction schedules, the user could provide a date (through the Ul), and choose to see the construction status of any objects in 3D on the given date. An animated view of the objects being constructed (i.e. 4D view) could also be used to visualize construction progress planned based on the schedules. In the 4D view, multiple tasks operating on a building object were coded in different colors, helping the user to identify the stage of the construction of the building object at a certain time. Since the scheduling tasks are also linked to the construction resources, the resource allocations can be represented which can be useful for detecting any resource assignment conflicts. Furthermore, a cost view was used to view the cost information for each object. In conjunction with the time and resource views for the object, the cost view helped the user to check out whether the cost estimate for the object matches the tasks according to the resources used. Finally, from the document view of the IPB, the user could easily find out all the schedules and cost estimates, and view information such as overall project start and finish date, or the grand total costs of different categories. 7.2.4. Precision Estimating CAD Precision Estimating CAD (or PECAD) is a new commercial software application developed by Timberline Software Corporation. PECAD integrates architectural and engineering design data with construction cost estimating functions. Led by the author, the PECAD is developed using TOPS RAF technologies for its architecture and software component designs, in which external CAD data sources are integrated through adapters. Additionally, a set of standard generic interfaces is used to expose the object information based on different data models. 7.2.4.1. P E C A D Functionality PECAD includes two major applications: CAD Integrator and Precision Estimating Mapper. CAD Integrator CAD Integrator is a program for cost estimators or designers to perform cost estimating using architectural or engineering design data. This program imports CAD design data of various formats such as IFCs, and it shows the design information through the non-CAD Ul , including building objects such as walls, windows, doors, etc, their relationships, and attribute values. For each of these building objects, construction cost data, including labor, materials, equipment, subcontractors, and others, can be generated by associating them with costs through Precision Estimating's (Timberline 2000) takeoff engines. Complete cost estimate documents containing the detailed costs can also be created. Finally, the data about object costs and cost estimates can be exported, along with the design data, into an integrated project file such as an IFC file. PE Mapper Precision Estimating Mapper (or PE Mapper), an integral part of PECAD, is an application that creates the associations (i.e. mappings) between the building object types and Precision database elements such as assemblies and items. These elements contain basic cost information for different types of building objects. They also contain formulas that are needed for taking off the assemblies into pieces so that detailed quantities can be generated for costing. The mappings are established at both object and attribute levels, and mapping rules can be specified to provide appropriate constraints. A mapping ensures that a type of building object is mapped to one or more cost database assemblies or items, and its attributes are mapped to the variables of the assemblies or items. Once such a mapping is defined, actual instances of the building object type can be associated to appropriate cost database elements (i.e. the assemblies or items), and their attribute values can be converted to variable values of the mapped elements. Then the instances of the building object can be 'taken-off by taking-off the assemblies and items, in order to generate detailed quantities and costs. UBC Page 134 Yu, K 7.2.4.2. PECAD Architecture The PECAD architecture, as depicted in Figure 87, is similar to TOPSPro, with a few additional features. • Adapter Registration: One of the requirements for PECAD is that additional adapters can be added at runtime (without the need of re-installing the entire system), and thus they are able to import new data sources in new formats. The Adapter Registration mechanism allows each data adapter to register the object type information of its creatable objects. The Data Broker, instead of explicitly encoding the loading process of each adapter based on the data source type known at design time, must access the registration information about the data adapters and load the appropriate adapter on-demand based on the data source type at runtime. This offers true 'plug-in & play' functionality for the software engines at runtime. This adapter registration mechanism is an application of the 'Application Registration' defined in TOPS RAF as explained in Section 6.5.6. • Model Adapter: In addition to the Data Adapters that expose information about project instances, the Model Adapter exposes the information about the data models (i.e. the meta-information about the project instances). There are two basic uses of this adapter in PECAD. First, since PECAD needs to allow the user to define what building object types map to which Precision Database elements such as assemblies or items (Timberline 2000), the data models must be exposed to the user interfaces so that the user can view and assign the object types and object attributes to the Precision database elements. This mapping mechanism in PECAD enables the entire system to handle runtime defined building object types and cost database elements. Second, the PECAD main user interface is intended to be generic when retrieving and displaying project instances and their information. This means, it needs to expose the project instance information without knowing the object types of these instances at design time. The exposure of the data model enabled by the Model Adapter allows the U l to retrieve data model information such as object type names, object type relationship names, and attribute names and data types. Then the U l can pass this model information as an 'argument' to the Data Adapter in order to retrieve the actual project instance information. This feature is useful for the single user interface to handle different types of project data based on different models at runtime. The Model Adapter mechanism conforms to the TOPS RAF's architectural aspect 'Application Adapter' as described in Section 6.5.6. ^-(^Client Applications j—^ Internal Software Systems & Engine: External Data ModelsJ) ^External Data Models Figure 87: PECAD Architecture UBC Page 135 Yu, K 7.2.4.3. P E C A D Usage Scenario The usage scenarios for the validation involve both applications in PECAD. PE Mapper While CAD Integrator is the main UI for PECAD, an object-mapping database must be prepared in the first place in order for the user to use PECAD to perform cost estimating. To use PE Mapper, a Precision Estimating database was created containing various assemblies and items with cost data (Timberline 2000). Within PE Mapper, the database was first opened (see Figure 88). Then the supported building object types were listed, and the user could use one from the list to create a new mapping to the cost database elements. For example, once the building object type 'Wall' was selected for creating a new mapping, the mapping dialog box (see Figure 88) allowed the user to select assemblies to map to 'Wall'. 1 — CAD Intpcjrat on Suite Mapping Utility - C:\_Worfc IAI-BI IS' ^ite-CertificaUon\Mapperf>B... f Fte Edit View Actions Help 1 c* I # # ® °E " E I § Column - _J\Wal • Exterior; E] Door B Assem: 0922- Interior Bearing Mstal Stud Wa l H DuctBend ;- _ J Wall - Interior DucU unction | | Assem: 0911- Exterior Bearing hvetal Stud Wall 13 DuctTerminal B t 3 Wall - Partition Interior CH3 DuctTransilion H Assem: 0921 - Interior Partition Metal Stud Wall % FlexibleDuct ED H WallA-1 Q Slab M Assem: 0911 - Exterior Bearing ketal Stud Wall •M StraightDuct B H WallA-3 O VerticalDuctJunction Ml Assem: 0922- Interior Bearing Mstal Stud Wall Q)l Wall! 5 Window Ready 7/12/2001 12:20 PM Figure 88: PE Mapper Usage Scenarios In this usage scenario, the assembly "Exterior Metal Stud Wall 2x4" was selected. Then all of the variables for the selected assemblies were shown in a list, in which, the user could specify what wall attributes should map to which variables. In this case, the attribute 'Height' was mapped to the variable 'Wall Height M M ' , while 'Width' was mapped to 'Wall Width M M ' . The mapping rule field allowed the user to specify mapping constraint, in this case, WallUseType = EXTERIOR, meaning that only if an instance of the Wall class is of 'EXTERIOR' type, then this mapping can be used. Similarly, multiple mappings could be defined for Wall or other building object types supported. Once all the mappings were defined, they were saved to the same cost database, which could be associated estimate file. This estimate file could then be used in CAD Integrator. UBC Page 136 Yu, K Meld Stud Eriem Wal-MM 1j ASM 0922- Inteiot Bearng Metal Stud Wal Mapping Select fteci«n Variable •tew* Select Mapped Attributes teeptChanges Wall Length MM MM Length Wall Height MM MM Height Cancel jelp MB Attribute Unit Default I p kwMifq (LINEAR Stmg Mat ing LINEAR String LINEAR Red tantatagfc mm Real 1.,,.,,,,,,,,,™,,,. a , Length LINEAR Red LocaFteeme* LINEAR Real L o c d r t e n f Y [LINEAR Real tee (LINEAR String Shape j LINEAR Emm S p a m e LINEAR String ThamaRaBng i LINEAR .... ... . j ... . . . . . . Stmg I N c t e LINEAR Real W a U M p LINEAR Enum UBC Figure 89: PE Mapper Details Page 137 Yu, K CAD Integrator The first step in this scenario was to open a design file, in this case, an IPC file containing architectural design data. Once the file was opened, building objects such as walls, windows, and doors were shown based on the building stories (see Figure 90). Attribute values of the objects were shown in a list view. To generate costs for an object, a Precision estimate file had to be opened (alternatively a new estimate file can be created), which already had an association with a cost database. The next step was to perform a quantity takeoff on a selected object, for example, a wall. The takeoff Window (see Figure 91) shows the mapped cost database elements, in this case, an assembly representing '2x4 metal stud walls', while the mapped assembly variables are shown alone with the converted values. Then detailed quantities of the wall can be calculated, and the actual takeoff function will generate the costs for the wall. Alternatively, the user can also select a different assembly for the wall to generate quantities and costs. Because the building object types were pre-mapped to default cost database elements, the user could select multiple objects and perform quantity takeoff automatically on all these objects at one time. The selection of the objects could be based on different criteria such as all walls on the second floor, all windows and doors, or all objects of the building. In addition, detailed quantity and cost items in the estimate for each object could be viewed, as shown in Figure 92. Once the objects had been taken-off, the estimate file then contained all the totals information, and a total estimate report could be produced. The estimate file could be opened from Precision Estimate for detailed cost estimating functions. To identify the locations of the building objects in the building, the user could enable the option to connect CAD Integrator with a CAD application such as MS Visio where the design drawing is opened. Since the programs were able to communicate with each other through APIs, common objects could be identified in both applications. In this usage scenario, the user would select a wall instance from the CAD Integrator tree view, and the wall would be automatically selected within the Visio drawing. UBC Page 138 Yu, K I; PECAD file 'm Estimate Takeoff Tods Reports hec HI Project H ft [Site) B 1 [Biiding] - Jf Stories (5) 11 [Story] 11 (Story) B | (Story) H Duel Junctions [5] •% Straight Ducts (17] - fjj Columns (8) I (Slab) Slab.11B8 i $ Wals [85] rWall) Wal.1145 [j (Wall) WI1138 S Cl (Wall) Wall.1131 + [ j (Wall) M f t l T B + Cl(Wall)Wall111S | (Wall) Wal.5S7 B | (Dpening) Q [Door) Double [J (Wall) Wall.477 3 [J (Wall) Wal.410 t (Wall) Wal.382 [J (Wall) Wai.451 | (Wall) WaB.444 | (Wall) Wail.423 | (Wall) Wal.402 5 [j (Wall) WallblG I [j (Wall) Wal.479 1 (Wal) Wa l f f i 1 [j (Wall) Wall.430 hi «,/-ni 1,1.inn Building Element Name: Wall.5S4 Attribute Value Unit StyleName WallUseType Shape A-1 EXTERIOR STRAIGHT Length 2500 LINEAR MILLIMETER Height 3500 LINEAR MILLIMETER Thickness 200 LINEAR MILLIMETER Mat ing 240 minutes ThermalRaling AcousticRating 7/11/2)01 225 PM UBC Figure 90: PECAD Usage Scenario Page 139 Yu, K (I Selected Building Elements for Takeoff Ip Openings (2) J p |(##t)Wiidow1166 lOperng] | (Wndw) Wrdow11% Mapped Precision Items/Assemblies | jWai-Ejteiioii I Assent 0ffi2- Irtew Bering Metal Stud Wa! Wal-Interior I Asset: i l l - EiderwIeaingHetd StudWal ] WalA-3 | km 0922- Intern Seanng Metal StudWal 3 WaJA-1 1 Assam 0911- Extern Seating Metal StudWal Wall • Partition Intera 1 km 0321- Intern Partition Metal Stud Wall Assem;M22- Interior Bearing Metal Si Value Unit AsserrcesH- Exterior Bearing Metal StudWal Hepi l i Select Al Select Defaults Aprjj Changes mappings lot all Walls in the AvalabJeBJrig Elements JakeoH Undo ated ItetBi Phase Mem Description Quantity Unci Qose i Figure 91: PECAD Object Takeoff U B C Page 140 Yu, K Fie View Estimate Takeoff Took Reports Help J i n li *z n u\\ n A Design File: C:LWork\W-BUS\ChicagoAEC\BLIS_TestBldAEC_Final_AHObjects ric B($Walk|67] J IS £ j (Wall) Interior Metal Stud#383 | { J iVal) Interior Metal SludB380 l | [Wall] Interior Metal Slud»3S9 l { ) [Wal| Interior Metal Sludtt3S7 ffl ^ [Wall] Interior Metal Stud8365 (Wall) Intern Meld S l u d W U [Wall] Exterior Metal Studtt313 Sliding Element Name: Exteiia Metal Stud8308 Attribute Value Unit _ J i StyleName E-1 WaWseTjpe EXTERIOR Shape STRAIGHT Length 1600 LINEAR MILLIMETER H e i g h t 3 0 0 0 LINEAR MILLIMETER H (V« all S t u d 8 3 0 i | Thickness 150 : LINEAR MILLIMETER * r}J (Wall) Exterior Metal Studtt30G 1 rj) (Wal] Exterior Metal S t u d M S | [Wall] Exterior Metal Stidt4300 ffi (Wall) Exterior Metal Stud8288 | (Wall) Exterior Metal Stud82B3 | W Exterior Metal Studtt254 | [Wall] Exterior Metal Stud8252 j IN . . . . . «J FireRating 60 mtnute TheimalRating AcousbcRaling Total Cut 90.22 USD Estimate Fie C:\terrip\peispectwejesL: CcstContsxt All the costs associated nl.< CostDate 7/10/2001 j-rj Building Element Group Phase Description Takeoff Quantity Labor Amount Material Amount Equip Amount Sub Amount Other Amount Total Amount Addon Grand Amount Total MM E... 50.96 39.26 90.22 ! 90.22 90000 FINISHES 50.96 3926 9022 90.22 liT" Metal Framing Labor 16V64 1f.S4 16.64 mm Labor 52 SF 16.64 • - - 16.64 -] 16J64J 90200 Metal Framing Parts m m m Stud18Ga77JB"x15Fx11'6" 4 EA -: 4.68 4.68 4.68 Tradt18Ga77l8"x15f?Rl 6 If •I 3.12 - 3.12 •I 3.12 90900 Caulk, feews, 1st , 0.26 0,26 0.26 Self Tapping Screws 43 EA -| 0.26 • - 0.26 •j 92500 O p a l 34.32 3120 65.52 | 65.52 Labor to Hang 104 SF 16.64 16.64 - 16.64 Tape 8 Finish 104 SF 17.66 4.16 21.64 21.84; DrywallWeinC" 104 SF • 27.04 27.04 -j 27.04 Ready 7/11/2001 2:50 PM Figure 92; PECAD Object Cost Items U B C Page 141 Yu, K 7.3. Validation This section explains validation process including the validation criteria, procedure and how the implementation programs were used for the validation purpose. It also summarizes the results of the validation. 7.3.1. Validation Criteria To ensure the validation is meaningful, a set of criteria for the validation must be determined. In this case, whether and how well the following criteria are supported in the prototype must be recorded and measured to examine the validity of the theories developed by this research: • The TOPS RAF can be used as a reference governing or assisting in designing the architecture and determining implementation strategies for prototype systems. For example, the TOPS RAF architectural elements can be implemented through specific implementation approaches and architectural configurations. • The major deliverables of the research can be used to support the prototype systems, including the information models developed and major components of each layer of the TOPS RAF. • The functionality of the prototype can support key features that TOPS are intended to support. These features include project model-based and transaction-based data exchange, as well as the TOPS DI and APPI features. • The TOPS RAF can enable legacy AEC/FM systems to be "adapted" effectively to distributed systems supporting desired DI and APPI features. • The TOPS RAF can be used to develop new types of AEC/FM applications. • The systems to be developed must also be challenging. The systems must support different types of data sources and their integration. The systems must also link to different types of applications that exchange the common project data. The results of the design and implementation of the prototype systems will be examined against these criteria. 7.3.2. Validation Results The results of using the TOPS RAF and the AEC information models in designing and developing the software prototypes or extending the interoperability features to existing commercial software are summarized in this section. These results were documented during the course of the software development or from the software usage scenarios. Most of these results demonstrated positive facts, and they proved the concepts developed in this research. The AEC/FM Applications The complexity of the systems developed is shown to meet the challenging requirements. First, the variety of the application types covers all AEC/FM domains. The following table shows the applications developed or supported in this research for each domain. Second, the applications supported span from existing commercial systems, newly developed commercial software based on the TOPS RAF, and research prototypes (see Table 10). This demonstrated the validity of the TOPS RAF and the standard models developed in this research. Additionally, the usage scenarios supported by all these applications cover many scenarios of data sharing, data exchange, and application interoperability among many kinds of AEC/FM data sets. UBC Page 142 Yu, K Table 9: Domain Applications Supported Architectural Architectural Desktop (ADT) 2000i; Graphisoft ArchiCAD 7.0; MS Visio; TOPSPro (3D and 4D Views); 4D Tool in IWPM Engineering MS Visio (HVAC) Construction Management Precision Estimating; PECAD; TOPSPro; MS Project; Primavera Project Planner; 4D Tool in IWPM Facilities Management Asset Management Tool (AMT); MS Visio (space and asset management); JsRoofer Table 10: Application Types Supported Commercial Software Architectural Desktop (ADT) 2000i; Graphisoft ArchiCAD 7.0; Precision Estimating; Primavera Project Planner; MS Project; MS Visio Newly Developed Commercial Software PECAD Research Prototypes 4D Tool in IWPM; Asset Management Tool (AMT); JsRoofer; TOPSPro Architectural Design The overall architectural framework provides a very easy to follow design reference. The TOPS RAF specifies the fundamental software component types of different kinds of data sources or applications and how they can connect other systems for integration. Therefore, it was easy for us in designing the system architectures for the applications involved in this research to support their data integration.. For example, the IWPM project uses the project modal-based architecture applying the TOPS RAF's layers concept (see Section 3.2.4), while Jigsaw supports the distributed applications based on the transaction-based architecture following both the 'layers and threads' ideas specified in the TOPS RAF (see Section 3.2.5). Consequently, IWPM is a demonstration and validation of project model-based architecture supporting different AEC/FM applications. PECAD is also a good example of new commercial software using the TOPS RAF's layers concept. Moreover, the idea of supporting both centralized project data model and distributed data sources in an integrated system framework allowing same set of applications exchanging data freely is clearly demonstrated. For example, the IWPM project exposed the drawbacks of using only central project data approach in supporting application interoperability. That is, data not in the central project database cannot be made available to applications when needed. UBC Page 143 Yu, K Data Mapping and Meta-Models Within the scope of all these implementation projects, various data mapping mechanisms are used. For instance, the Jigsaw architecture involves all the three data mapping schemes described in Section 5.2.1. Similarly, in PECAD, IFC data are mapped to internally standard PECAD models using the data mapping 'Scheme 2' method, while the IPC data can also be in both Part 21 format and X M L format following the data mapping 'Scheme 1' approach. PECAD is also an example of using meta-models (see Section 5.1.6) in supporting late-binding data integration. In PECAD, a set of standard internal PECAD models must be defined in a model database, which is based on a set of meta-models. They must also be exposed through generic APIs so that the models (i.e. classes and their relationships) can be mapped at runtime to cost database elements (a meta-model data mapping scenario). They also must be used by the generic user interfaces. Consequently, the meta-model scheme described in Section 5.1.6 was applied successfully in supporting PECAD's unique DI functionality. Architectural Components The concepts of data brokers and data adapters (see Section 6.5) are valid and robust in supporting different data sources and integrating different application types. Additionally, they are effective in supporting the integration of all different types of data sources, i.e. new types of applications such as TOPSPro and existing software like Microsoft Project. The idea of generic interfaces (APIs) (see Section 3.2.5.2) is used in the Jigsaw project and PECAD. The idea works very well for late-binding or generic client applications, while it can also support early-binding programs in conjunction of the explicit use system standard data models. Moreover, the data brokers and adapters, along with the appropriate registration mechanism implemented, also provide key mechanisms for software 'plug-in & play' features. This was demonstrated well in PECAD. Data Integration and Application Interoperability A key feature that the implementation projects must demonstrate is their capabilities in supporting DI and APPI. This was a main focus of each project in this research. In particular, the Jigsaw project is a good example of using TOPS RAF's application-based data integration (see Section 6.5.3), while all of the four projects successfully implemented a file-based data integration approach (see Section 6.5.2). Additionally, both IWPM and the Jigsaw applications applied project-model based data integration architecture (see Section 6.5.1), where the project-model-proxy concept was proven useful in a client-server data-sharing environment (see Section 6.3). Among the implementation projects, PECAD demonstrated well in supporting APPI in several perspectives. First, CAD Integrator communicates with MS Visio for the same objects using the Direct API Interoperability mechanism described in Section 6.5.6. Different 'Model Adapters' of PECAD also conform to this mechanism and support runtime plug-in & play feature. Furthermore, TOPSPro presented its functionality supporting multiple domain functional views (see Section 6.2.4) using a rich set of data based on the standard models developed (i.e. IPCs). Standard Information Models The approach of standard information models (see Section 3.2.5.1 and Chapter 4) was proven to be extremely useful. For example, the IFC models were used in all the prototypes and applications developed in this research. These models effectively support the data exchange, data sharing among different AEC/FM applications. Particularly, IFC models are used to support a central project repository in IWPM for data sharing, while Jigsaw applications can exchange project data using any IFC supported data sources such as files or databases. Moreover, TOPSPro uses IFC based file to contain integrated project data, while PECAD uses IFC files for importing CAD data and exports IPC files to publish cost information. UBC Page 144 Yu, K Observations A drawback of generic interfaces is observed. Because these interfaces do not expose data model semantics through the names of the individual interfaces, the use of these API unavoidably requires the program developers to thoroughly understand the data models and apply them as textual arguments in their code. This can sometimes make the coding more difficult because of the lack of intelligent API naming conventions, which do not have the context of data models. Unlike the traditional APIs, the generic interfaces can be error prone during the software code development because the software compiler cannot help in detecting syntax errors, which would be related to data types. Since some applications are domain specific and thus must be early-bound, the generic interfaces methodology does not provide better development approaches than traditional domain specific APIs. 7.4. Chapter Conclusion This chapter describes the details of the software implementation projects, which are developed based on the research results, i.e. TOPS RAF and the standard information models. In summary, this chapter covers four implementation projects, namely: IWPM Prototype, Jigsaw Project, TOPS Prototypes, and PECAD. These projects involve various software applications of different types from existing commercial programs, newly developed commercial software, and research prototypes. The scope of the applications covers the AEC/FM domains, while they support various CIC scenarios. As also explained in this chapter, these applications are developed and used to validate the research. The validation process is conducted based on a set of criteria. The overall results of the validation can be summarized as follows: • Based on TOPS RAF, specific system architectures (or configurations) can be designed logically without major difficulties. • Functionality of the components can be implemented in a consistent way. • DI (e.g. data exchange) and APPI functions perform as expected » Benefits of using standard information model and APIs are obvious. • The use of generic standard API can support many robust features for data integration, while some of its disadvantages are also exposed. Although the implementations conform to many aspects of the research results, due to the time constraints and limitation of the applications' functionality, some capabilities of the TOPS RAF were not completely implemented. Thus these features are not sufficiently tested. It is acknowledged that the following functionality was not thoroughly validated; therefore, further research effort will be required: • While the Jigsaw project involves some aspects of transaction-based integration, more detailed implementation and validation is needed to thoroughly examine the workability of the transaction-based architecture in TOPS RAF. • Message-based integration is not sufficiently supported in the implementations. Further effort in this aspect is required. In conclusion, the research and implementation projects are evolving efforts. While all the implementation projects developed in this research successfully utilized and thus validated the research results, at the same time, they also made tremendous contributions to the advancement of the theories. UBC Page 145 Yu, K Chapter 8: Conclusions Chapter Abstract: To conclude this dissertation, this chapter summarizes the major technology deliverables resulting from this research work for achieving CIC systems including the TOPS RAF and Information Models. It also summarizes the contributions made to IT research and development for the AEC/FM industries. Finally, the chapter suggests future research topics that, based on this dissertation, would provide other significant requirements for the goal of CIC. Overall, the research recognizes the future requirements of systems targeted for CIC objectives. In this research, integrated AEC/FM software tools are considered to be paramount to improving the productivity and efficiency of design and construction processes for building construction projects. The proposed means of using these software tools is that they all access, share, and exchange project information and they invoke, request services, and send notifications freely. These scenarios are characterized as Computer Integrated Construction (CIC), where the software tools used by all project participants can contribute to and draw from the pool of project data. In CIC, the software tools can also communicate to share and exchange the project data in highly intelligent ways, in which data is structured based on its real world object context and is available from different distributed sources. To achieve the goal of CIC, the research proposed an approach named "Total Project Systems (TOPS)" that are capable of enabling all AEC/FM applications to support the CIC scenarios. The results of this research are believed to be significant for current and future research and development in the field of IT in construction industries. 8.1. Summary The goal of this research is Computer Integrated Construction (CIC). The research approach is "Total Project Systems (TOPS)", which call for five technological elements: Systems Architectures, Information Models, Information Contents, Work Practices and Applications. The research premise is that TOPS, which possess the characteristics of comprehensiveness, extensive data integration, application interoperability, and flexibility, can be adopted as large-scale systems to support various existing and new types of applications for the goal of CIC. This research focuses on two of the major TOPS technologies: Systems Architectures and Information Models. For each, supporting technical issues are identified and developed: • TOPS RAF: An architecture framework that is used as a reference for supporting TOPS applications for CIC objectives. TOPS RAF is structured by layers that separate the software components according to their domain functionality and data logic and by threads that implement technologies that streamline the component communications and data transformations. TOPS RAF enables ApC/EM applications to be adapted to entire systems in order to integrate with other applications by supplying and requesting domain services and project information. • Information Models: A set of computer data constructs defined as formal representations that are contributed as international standards for supporting data requirements for all AEC/FM applications. These models constitute a major technological element for TOPS and represent a major thread of the TOPS RAF to support TOPS data instantiations. While each technology element of TOPS may be useful individually, they are most promising when implemented using a highly structured and logical methodology, i.e. the TOPS RAF, that supports a cohesive approach for developing powerful and integrated computer applications for CIC objectives. UBC Page 146 Yu, K 8.2. Contributions I believe that this research has made several major contributions to the mission of Computer Integrated Construction (CIC). These contributions can make considerable impact on, future research and developments of IT solutions for the AEC/FM industries. They make significant steps closer to actual software systems that truly support the objectives of CIC. These contributions are summarized as follows: • TOPS: I think the most significant contribution of this research is the establishment of "Total Project Systems (TOPS)". TOPS provide solutions that can potentially offer actual software tools directly supporting CIC objectives. Prior to TOPS, most research with the goal of CIC focuses on either information models or a comprehensive applications' functionality for a specific domain problem. Unlike these efforts that provide only partial or limited solutions, TOPS present a clear roadmap of technologies towards CIC. The depth and broadness of the domain functions and their integrations supported by TOPS represent an innovative class of systems that are promising to the goal of CIC. The acknowledgement of TOPS' five technological elements sets the foundations and directions for TOPS research and developments. • . TOPS RAF: I consider the second major contribution to be the TOPS Reference Architecture Framework (RAF). The idea of a reference architecture is new in the sense that it is capable of supporting different architectural configurations for systems that implement different types of CIC functions. The TOPS RAF makes a significant contribution in the field of CIC system design and development in its approaches and software component architectures. The TOPS RAF is also innovative in its mechanisms to support data integration, specifically both project model-based and domain transactional process-based data exchange and sharing, and its abilities to support extensive application interoperability. • Information Models for AEC/FM: I consider the next major contribution of this research to be the information models of project management to support AEC/FM applications and their functions in CIC. These models are sophisticated, having been developed based on comprehensive integrated domain use cases and process models. The models provide essetial and integral concepts in the entire TOP RAF. These models, by being contributed to the largest industry model standards effort, i.e. IAI's IPCs, also make a significant contribution to the general information modeling arena for AEC/FM — a cornerstone technology for CIC. They further make a valuable contribution to the general data modeling field for large-scale systems involving many different types of applications by employing sound modeling principles, methodologies, approaches, and rigorous development procedures. • Data Integration and Application Interoperability Techniques: A further contribution made by this research is the thorough review of generic techniques for data integration (DI) and application interoperability (APPI) as they are applied to different types of AEC/FM applications. Although each individual technique discussed in this regard is not revolutionary, they as a whole provide valuable references and guidelines for AEC/FM applications to implement solutions supporting DI and APPI features, as they are desired in TOPS for CIC. While the contributions made by this research make a significant impact on the area of technology research and development for CIC, they do not constitute final or definitive solutions. Additional research and development are still required, which are recommended in the next section. UBC Page 147 Yu, K 8 . 3 . Future Work This research points out several future research and development areas that are required to fully achieve the goal of CIC through the completion and refinement of TOPS, as described below: • Systems Architectures: since CIC systems involve many types of applications, their integration is essentially a challenging technical issue. Therefore, the systems architecture issues are inevitably complex. This research proposes a comprehensive approach, i.e. the TOPS RAF, to handle the systems architecture requirements. Many clear advantages of TOPS RAF technologies are demonstrated through prototypes, but they are still immature technologies. Further research is needed to validate every component of the TOPS RAF, and to refine the component functionality and relationships. Additional research is required, especially in the areas of the impacts to the design of TOPS from utilizing various information types (i.e. Information Content) involved in construction projects, and the design and management work practices due to the use of such software tools. • Information Models: While this research makes a significant contribution to information models for AEC/FM, the coverage of our modeling work is limited to certain integrated construction management functions, for example, cost estimating and scheduling integration, and product and cost estimating, etc. Although the models developed based on these integration processes may well support some other domain processes, they do not support all typical design and project management processes. More models must continue to be developed supporting more typical domain processes. Additionally, as stated in Chapter 4, the models developed are based on use cases and ad hoc processes defined by industry experts. Technically, these models should represent the requirements and scope of the domain functions described as process models, but they may not be structured using the most efficient object relationships since they are not developed based on actual software functions. These models need to be refined to support software functions in the most efficient manner based on feedback from implementations. One important area worthy of further research is the capability of standard models such as IFCs to support specific domain functional views, for instance a cost estimating view of product geometry. • Information Content: Integrated applications used by different project participants of different firms typically involve different types of project information, such as product components, construction tasks or plans, organizational data, personnel data, external libraries of costs and product catalogs, and so on. Some of these information types are shared with all participants, but some others are proprietary and their access and sharing are controlled by business cases. Although TOPS RAF is designed to be able to support all types of project-related information being stored or exchanged, the impacts of these different information types and their usages in the TOPS RAF, integrated domain processes, and integrated software functions are yet to be discovered. • Work Practices: CIC systems such as TOPS improve many typical domain functional processes and their integrations. The way that these CIC systems work will dramatically improve the efficiency of how professionals design and manage projects using these computer tools. Like most revolutionary technologies, TOPS will have profound impacts on domain work practices, which simultaneously greatly affect how these IT solutions will be designed and implemented to support highly integrated and complex business cases. Research in these areas is crucial for the continued success of TOPS. UBC Page 148 Yu, K References ADO (2000), Active Data Object, http://wvw.microsoft.com/data/ado/default.htm aecXML (2000), http://www.aecXML.org. Al-Timini, K., and MacKrell, J . (1996), "STEP: Towards Open Systems", CIMdata, Ann Arbor, Michigan. Ahmad, I.U., Russell, J.S., and Abou-Zeid, A. (1995), "Information Technology (IT) and Integration in the Construction Industry". Construction Management and Economics, ASCE, 13(3), pp. 163-171. Amor, R., Anumba, C. (1999), "A survey and analysis of integrated project databases". Proc. of the 2 n d International conference on Concurrent Engineering in Construction, Espoo, Finland, 217-228. Anumba C. J . , Bouchlaghem N. M., Whyte J . , and Duke, A. (2000), "Perspectives of an integrated construction project model", International Journal of Cooerative Information Systems, Vol 9, No 3 (2000), 283-313. Aouad, G., et al. (1994), "Integration of Construction Information, Final Report", University of Salford, 1994. Autodesk (2000), AutoCAD R14, 2000, and 2000i. http://www.autodesk.com. Bentley (2000), ProjectBank, http://www.bentley.com/products/projbank/. Schedule Simulator: http://www.bentley.com/products/peproducts/. Biztalk (2000). http://www.biztalk.org. Bjork, B. C. (1992), "A Unified Approach for Modeling Construction Information", Building and Environment, Vol. 27, No. 2, pp. 173-194, 1992. Bjork, B. C. (1994), RAT AS Project - Developing an Infrastructure for Computer-Integrated Construction. Journal of Computing in Civil Engineering, 8(4): 401-419. BLIS (2000), "Building Lifecycle Interoperable Software", http://cic.vtt.fi/projects/blis/. Bos, J . N. W. (1995), "Software Analysis of a Flexible Object-Oriented Facility Management Information System", Product and Process Modeling in the Building Industry, Scherer. R. J . (ed.), Balkema, Rotterdam, pp. 379-385. Carr, R., (1993), Cost, Schedule, and Time Variances and Integration. Journal of Construction Engineering & Management, 119(2): 245-265. Cheng, F. F., Patel, P. and Bancroft, S. (1996), "Development of an Integrated Facilities Management Information System Based on STEP - A Generic Product Data Model", International Journal of Construction Information Technology, vol. 4, no. 2, pp. 1-13. Cole, M., et al. (1998a), "IFC Model Requirement Analysis, ES-1: Cost Estimating", IAI Documents. Cole, M., et al. (1998b), "AEC Industry Process Definitions, PM-2: Estimating and Scheduling Integration". IAI Project Document for IFC R3.0. COMMIT (1995), construction Modeling Methodologies for Intelligent information integration, http://www.salford.ac.uk/iti/proiects/commit/commit.html. Eastman, C. M. (1978), "The Representation of Design Problems and Maintenance of their Structure", In Latcombe (ed.), Application of Al and PR to CAD, North-Holland, Amsterdam, pp. 335-337. Eastman, C. M. (1999), "Information Exchange Architectures For Building Models, Information Exchange Architectures", Durability of Building Materials and Components 8, Vancouver, May 1999. pp. 2139-2156. UBC Page 149 Yu, K Fischer, M., Froese, T. (1995), "Examples And Characteristics of Shared Project Models". Journal of Computing in Civil Engineering, ASCE, March, 1995. Fischer, M., Liston, K., Kunz, J . (2000), "Requirements and Benefits of Interactive Workspaces in Construction", submitted to the 8th International Conference on Computing in Civil and Building Engineering, Stanford, USA. Froese, T. (1992), "Integrated Computer-Aided Project Management Through Standard Object-Oriented Models", Ph.D. Thesis, Dept. of Civil Eng. Stanford University, 1992. Froese, T. (1996), "Models of Construction Process Information", Journal of Computing in Civil Engineering. 10 (3): 183-193. Froese, T. (1999), "Interwoven Threads: Trends in the Use of Information Technologies for the Construction Industry", a white paper prepared for the Berkeley-Stanford CE&M Workshop, August 1999. Froese, T., Fischer, M., Grobler, F., Ritzenthaler, J . , Yu, K., Sutherland, S., Staub, S., Akinci, B., Akbas, R., Koo, B., Barron, A., and Kunz, J . (1999), "Industry Foundation Classes For Project Management—A Trial Implementation", Electronic Journal of Information Technology in Construction, Vol. 4, 1999, pp.17-36. Available online at http://itcon.Org/1999/2/. Froese, T., Grobler, F., and Yu, K. (1998), "Development of Data Standards for Construction—An IAI Perspective", The Life-Cycle of Construction IT Innovations-Technology Transfer from Research to practice, Proceedings of the W78 conference, Stockholm, Sweden, June 3-5, 1998. KTH, Stockholm, pp. 233-244. Froese, T., Rankin, J . , and Yu, K. (1997a), "An Approach to Total Project Systems", Computing in Civil Engineering: Proc. of the Fourth Congress, ASCE, Philadelphia, PA, June 16-18, 1997. pp. 1-8. Teresa Adams, Ed. Froese, T., Rankin, J . , and Yu, K. (1997b), "Project Management Application Models And Computer-Assisted Construction Planning In Total Project Systems", International Journal of Construction Information Technology, Special Issues on Integrated Environments, Vol. 5, No. 1, Summer 1997, pp.39-62. Froese, T. and Yu, K, (2000), "Architecture Issues For Distributed AEC/FM Systems", The 8th International Conference on Computing in Civil and Building, Engineering (ICCCBE-VIII), Stanford University, California, USA, August 14 -17 , 2000. Froese, T. and Yu, K. (1999), "Industry Foundation Class Modeling For Estimating and Scheduling", Durability of Building Materials and Components. Vancouver, May 1999. Vol. 4, pp. 2825-2835. Froese, T., Yu, K., Liston, K., and Fischer, M. (2000), "System Architectures For AEC Interoperability", Construction Information Technology 2000 (Conference of CIB-W78, IABSE, and EG-SEA-AI), Reykjavik, lceland,28 - 30 June, 2000. Gielingh, W. (1988), "General AEC Reference Model (GARM)". ISO TC184/SC4/WG1 doc. 3.2.2.1, TNO report Bi-88-150. Delft, Netherlands. Oct/1988. Gorlick, A. L., and Froese, T. (1999), "A Prototype Distributed CIC System Based On IAI Standards", Durability Of Building Materials And Components. Vancouver, May 1999. Vol. 4, pp. 2171-2179. Hassanain, M. A., Froese, T, and Vanier, D (2001), "Architecture Of A Distributed, Model-Based Asset Management System", Proceedings of the 2001 Conference of the Canadian Society for Civil Engineers, Victoria, BC. May 30-Jun 2, 2001. CSCE Montreal Canada. Paper C19. IAI (1996), "End User Guide to Industry Foundation Classes, Enabling Interoperability in the AEC/FM Industry". International Alliance for Interoperability (IAI), 1996. IAI (1997), "Process Definitions and Information Requirement Analysis for IFC R2.0: Construction Management", IAI project working documents for IFC R2.0, 1997. UBC Page 150 Yu, K IAI (1998), International Alliance for Interoperability, Industry Foundation Classes, Domain Project Documentation, Project Summary - [PM-1] Scheduling, Draft 3, Rev. 2, November 10, 1998. IAI (1999), Industry Alliance for Interoperability. IFC Object Model, Release 2.0, [CD-ROM]. IDEFo (1981), "Integrated Computer-Aided Manufacturing (ICAM), Architecture Part II, vol. IV -Functional Modeling Manual (IDEF-0)", SofTech, Inc. Waltham, MA, USA, 1981. IDEF1X (1993), INTEGRATION DEFINITION FOR INFORMATION MODELING (IDEF1X), Federal Information Processing Standards Publication 184, issued by the National Institute of Standards and Technology, December 21,1993. ISO (1991), International Organization for Standardization (ISO), TC184/SC4 Project Management Advisory Group, 1991. ISO Standard 10303-11, EXPRESS Language Reference Manual, ISO TC184/SC4/WG5. Geneva, Switzerland: ISO. ISO (1992a), International Organization for Standardization, "ISO 10303 Industrial Automation Systems and Integration - Product Data Representation and Exchange - Standard Data Access Interface Specification", Working Draft, ISO TC184/SC4, 1992. ISO (1992b), ISO DIS 10303 - Product Data Representation and Exchange - Part 21: Clear Text Encoding of the Exchange Structure, ISO TC184/SC4/WG7, 1992 (E). ISO (1994), International Organization for Standardization (ISO), TC184/SC4 Project Management Advisory Group, 1994. ISO Standard 10303-1, Industry Automation Systems-Product Information Representation and Exchange-Part 1, Overview and Fundamental Principles. Geneva, Switzerland: ISO. Kimball, R. et al (1998), "The Data Warehouse Lifecycle Toolkit", publised by John Wiley & Sons, Inc. ISBN 0-471-25547-5. Leslie, H. G. (1996), "Strategy for Information Management in the AEC Industry", lnCIT96, Sydney, Australia, April 1996. Liston, K., Kunz, J . , and Fischer, M. (2000), "Advanced Human-Computer Interfaces for Construction Planning", submitted to the 8th International Conference on Computing in Civil and Building Engineering, Stanford, USA. Lottaz C , Stouffs R., and Smith I. (2000), "Increasing Understanding During Collaboration Through Advanced Representations", February 2000, http://itcon.Org/2000/1/, edtor: Turk Z. Luiten, G. (1994), "Computer Aided Design for Construction in the Building Industry", Ph.D. Thesis, Fac. Of Civil Eng., The Delft University of Technology, Netherlands, 1994. Luiten, G., Froese, T., Bjork, B. -C, Cooper, G., Junge, R., Karstila, K., and Oxman, R. (1993). "An Information Reference Model for Architecture, Engineering, and Construction". Proceedings of the First International Conference on the Management of Information Technology for Construction, World Scientific, Singapore, 391-406. Maher, L. M., Simoff, S. J . and Mitchell, J . (1997), "Formalising Building Requirements Using an Activity/Space Model", Automation in Construction, vol. 6, no. 2, pp. 77-95, 1997. Majahalme, T. (1995), "Information System for Facility Management (ISFM)", Doctoral Thesis, Tampere University of Technology, Department of Civil Engineering, Publications 174. Tampere, Finland. Marir F., Aouad G., Cooper G. (1998), "OSCONCAD: a Model Based CAD System Integrated With Computer-related Construction Applications", ITCon the electronic journal, 1998, http://www.itcon.org. Martens, C , Woo, C. (1997), "Journal of Organizational Computing And Electronic Commerce 7(2&3), 227-251 (1997)". Microsoft (1999), "Introduction to Designing and Building Windows DNA Applications", http://www.msdn.microsoft.com/library/default.asp?URL=/librarv/techart/windnadesiqn intro.htm , Microsoft Corporation. Microsoft (2000), "Repository 2.0 Document - MSDN Library", January 2000 Edition. UBC Page 151 Yu, K Microsoft Project (2000), Microsoft Project 2000 Online Help, Microsoft Corporation, 2000. MottSnen V. J . , Matilainen, U. and Parjanen, T. (1994), "Applications of Product Model Theory in Facilities Management", Proceedings of the International Symposium on Management, Maintenance and Modernisation of Building Facilities, CIB W70 Tokyo Symposium, pp. 1183-1190. Mottbnen, V. (1995), "Information Systems for Facilities Management", High Technology in Finland 1995, pp. 72-73. Petzold C. (1998), "Programming Windows®, Fifth Edition", Microsoft Press, Published on November 11, 1998, ISBN 1-57231-995-X. PMI (1996), "A Guide to the Project Management Body of Knowledge. Project Management Institute (PMI)", PMI Standards Committee, Upper Darby, PA. ProjectBank (2000), http://www.bentley.com. Rankin, R. (2000), "Computer-Assisted Construction Planning", Ph.D. Thesis, Department of Civil Engineering, University of British Columbia. Rivard, H. (2000), "A Survey on the Impact of Information Technology on the Canadian Architecture, Engineering, and Construction Industry", Electronic Journal of Information Technology in Construction, May 2000, Vol. 5, pp. 37-56, http://itcon.Org/2000/3/. Rogerson, D. (1997), "Inside COM, Microsoft's Component Object Model", Microsoft Press, Redmond, Washington 98052-6399, Copyright© 1997 by D. Rogerson. Rumbaugh J. , Jacobson I., and Booch G. (1999), "The Unified Modeling Language Reference Manual", Bk&Cd Rom edition (December 1998), Addison-Wesley Pub Co; ISBN: 020130998X. Reschke, P.. and Teijgler H. (1994), "Generic Reference Model for Life Cycle Facility Management (a proposal)". ISO TC184/SC4/WG3 Document N351, Rev. 1, 1994. . Robie, J . (2000), "What is the Document Object Model?", Software AG, http://www.w3.orq/TR/DOM-Level-2/introduction.html, 10 May, 2000. RosettaNet (1999), "RosettaNet Implementation Framework Specification Version 1.1", November 08, 1999, http://www.rosettanet.org. RosettaNet (2000). http://www.rosettanet.org. Russell A. (1995), "Repcon 2 Educational & Research Version User Manual Version 2.00", Construction Management Group, Dept. of Civil Eng., University of British Columbia, Canada, 1995. Russell, A. and Froese, T. (1997), "Challenges and a Vision For Computer-Integrated Management Systems For Medium-Sized Contractors". Canadian Journal of Civil Engineering. 24 (2), 180-190. Russell, A. and Udaipurwala A. (2000), "Visual Representation of Project Planning & Control Data", Proceedings of the Eighth International Conference (ICCCBE-VIII), Volume 1, page 543 - 549, Stanford University, Stanford, California, Computing in Civil And Building Engineering, ASCE. Sanvido, V. (1990) "An Integrated Building Process Model", Computer Integrated Construction Research Program, Pennsylvannia Sate University, Technical Report No.1. Staub F. S. and Fischer M. (2000), "Industrial Case Study of Electronic Design, Cost, & Schedule Integration", CIFE Technical Report #122 (Draft), July 2000, Stanford University. Svensson, K. (1998), "Integrating Facilities Management Information A Process and Product Model Approach", Ph.D. Thesis, Kungl Tekniska Hogskolan, Royal Institute of Technology, Construction Management and Economics, Stockholm 1998 KTH Hbgskoletryckeriet. Teicholz, P. and Fischer, M., (1994), "Strategy for Computer Integrated Construction Technology". Journal of Construction Engineering, and Management., ASCE, 120(1), pp. 117-131. Timberline (1995), "CAD Integrator User's Guide", 1995, Timberline Software Corp, 15195 NW Greenbrier Parkway Beaverton, Oregon 97006, USA UBC Page 152 Yu, K Timberline (1999), Timberline_BuyoutDocuments_Schema, Version: 1.0, April 12, 2000, Timberline Software Corp, 15195 NW Greenbrier Parkway Beaverton, Oregon 97006, USA Timberline (2000), Precision Estimating for Windows, "http://www.timberline.com". Timberline Software Corp, 15195 NW Greenbrier Parkway Beaverton, Oregon 97006, USA Tolman, F., Bakkeren, W. and Bohms, M. (1994), "ATLAS LSE Project type Model", ESPRIT Project 7280-ATLAS/WP1/Task 1500 Document D106-lc, April 1994. Turner, J . (1990), "AEC Building Systems Model", ISO TC184/SC4/WG1, Doc N363 Working paper, Geneva. . Verhoef, M. Liebich, T. & Amor, R. (1995), "A Multi-Paradigm Mapping Method Survey" in Modeling of Buildings Through Their Lifecycle: Proceedings, CIB Publication 180, Palo Alto, CA, USA, eds M Fischer, K Law, B Luiten, pp. 233-247. Vinoski S. (1997), "CORBA, Integrating Diverse Applications Within Distributed Heterogeneous Environments", the IEEE Communications Magazine, Vol. 14, No. 2, February, 1997. W3C (1998a), XML-Data, W3C Note 05 January 1998, http://www.w3.orq/TR/1998/NOTE-XML-data-0105/. W3C (1998b), Extensible Markup Language (XML) 1.0: W3C Recommendation 10-February-1998, http://www.w3.orq/TR/1998/REC-xml-19980210. W3C (1999), XSL Transformations (XSLT), Version 1.0, W3C Recommendation 16, November 1999, http://www.w3.orq/TR/xslt. W3C (2000a), Document Object Model (DOM) Level 2 Core Specification, Version 1.0, W3C Recommendation 13 November, 2000, http://www.w3.orq/TR/2000/REC-DOM-Level-2-Core-20001113/ W3C (2000b), XML Schema, W3C Candidate Recommendation 24 October 2000, http://www.w3.orq/TR/xmlschema-0/ West, M. (2000), "Integration of Industrial Data for Exchange Access and Sharing: Architecture Overview and Description", ISO TC184/SC4/WG10/N254. Wix, J . , Yu, K., and Sorgenfri, P. O. (1999), "The Development of Industry Foundation Classes for FACILITIES Management", 8th International Conference On Durability Of Building Materials And Components, May 30 - June 3, 1999 Vancouver, Canada. Yu, K. (1995), "Application of Project Information Models to Computer-Integrated Construction", M.A.Sc. Thesis, Dept. of Civil Eng., University of British Columbia, October 1995. Yu, K. and Froese, T. (1997), "Implementation of AEC Core Reference Models in StartPlan", Canadian Journal for Civil Engineering, Vol. 24, No. 5, Oct. 1997, pp. 671-682. Yu, K.. Froese, T. and Grobler, F. (1998a), "International Alliance For Interoperability and IFCs", Computing in Civil Engineering: Proc. of the International Computing Congress, ASCE, Boston, MA, October 19-21, 1998. pp. 395-406. Kelvin Wand, Ed. Yu, K., Froese, T., and Grobler, F. (1998b), "Development of Industry Foundation Classes by International Alliance for Interoperability", the Proceedings of Computing Congress 98, American Society for Civil Engineering (ASCE), Boston, Oct. 1998. Yu, K., Froese, T., and Grobler, F. (2000a), "A Development Framework for Data Models for Computer-Integrated Facilities Management", Automation in Construction, special issue on facilities management, Vol 9, No. 2, 2000, pp.145-167. Yu, K., Froese, T., and Grobler, F. (2000b), "Interoperability for the Building Industry: IAI Industry Foundation Classes", Proceedings of the 1998 Conference of the Canadian Society for Civil Engineers, Halifax, NS, June 10-13, 1998. CSCE Montreal Canada. Vol. 1, pp.87-96. Yu, K., Froese, T., and Vinet, B. (1997), "Facilities Management Core Models", Proceedings of the 1997 Conference of the Canadian Society for Civil Engineers, Sherbrooke, Quebec, May 27-30, 1997. CSCE Montreal Canada, 1997. Vol. 2, pp. 2-195 to 2-204. UBC Page 153 Yu, K Appendix A: Functional Categories for Project Management Partial Listing of Functional Categories for Project Management 1. Project Scope Management 1.1. Initiation 1.2. Scope Planning 1.3. Scope Definition 1.4. Scope Verification 1.5. Scope Change Control 2. Time Management 2.1. Activity Definition 2.2. Activity Sequencing 2.3. Activity Duration Estimating 2.4. Schedule Development 2.5. Schedule Control 3. Cost Management 3.1. Resource planning 3.2. Cost Estimating 3.3. Cost Budgeting 3.4. Cost Control 4. Quality Management 4.1. Quality Planning 4.2. Quality Assurance 4.3. Quality Control 5. Risk Management 5.1. Risk Identification 5.2. Risk Quantification 5.3. Risk Response Development 5.4. Risk Response Control 6. Safety & Environmental Management 6.1. Safety Planning 6.2. Safety Control 6.3. Environmental Planning 6.4. Environmental Control 7. HR & Organizational Management 7.1. Organizational Planning 7.2. Staff Acquisition 7.3. Team Development 7.4. Employee Management 8. Management of Procured Resources 8.1. Procurement Planning 8.2. Solicitation Planning 8.3. Solicitation (tendering/purchasing) 8.4. Source Selection 8.5. Contract Administration 8.6. Change Management 8.7. Contract Close-out 9. Operational Methods and Processes 9.1. Methods Planning 9.2. Methods/Productivity Control 10. Information & Communications Management 10.1. Communications Planning 10.2. Information Distribution 10.3. Performance Reporting 10.4. Administrative Closure 11. Financial Resource Management 11.1. Banking 11.2. Bonding 12. Physical Resource Management 12.1. Materials Management 12.2. Equipment Management UBC K Page 154 Yu, Appendix B: Project Documents Partial Listing of Project Documents Activity list Activity type list (productivity records) Application for payment Application for prequalification Bid Bid documents Bill of quantities Change order Change order log Change order proposal Change request Contract (client, sub) Contract documents Contractor list Correspondence log Cost budget Cost budget update Cost estimate Cost estimate update Cost report Daily site report Defective work notice Drawing Dunning letter (response overdue) Employee record Equipment maintenance schedule Equipment on site list Field order Invitation to bid Invoice Issue Job application Job description Letter Product design document Progress payment Progress report Project charter Project network diagram Punch list Purchase order (supply contract, purchase agreement Quality criteria Quality plan Quality result Quality test Quote Rental equipment list Request for change order quote Request for clarification Request for information Request for prequalification Request for quote Request for submittal Resource allocation plan Responsibility chart Safety notice Schedule Schedule update Scope management plan Shop drawing Site photograph Spare parts list Specification Submittal Supplier/vendor list Telephone conversation Timesheet To-do items UBC K Page 155 Yu, Appendix C: Data Topics for Project Management Partial Listing of Data Topics for Project Management Account Photograph Activity Prequalification Activity progress Process Activity sequencing/constraints Product Activity type Product design Bid Product representation Budget Productivity records Company Progress payment Contract Project Contract change Project charter Contract documents Project schedule Control Purchase Cost Quality criteria Costs-as bid Quality result Document Quality test Drawing Quantity Employee Rental Equipment Resource Equipment maintenance Resource allocation Estimate Resource availability Estimate item Resource cost/productivity Job Resource requirements Material Responsibilities Materials storage log Roles Meeting minutes Site activity Memo To-do items Methods plans Transmittals Notice of acceptance Unit price database Notice of completion WBS Notice to comply WBS coding system Organization WBS listing Organization chart WBS standards Organizational structure Work calendars Participants list Work method plan Performance report Work package Person UBC K Page 156 Appendix D: TOPS RAF Project Model Services catalog Meta-data Storage 3 Project Data Storage Meta-data Services Meta-data Object Server Engine UI Meta-data Mapping Server Engine UI Project Data Services Data Access Server Data Maintenance Server Project Model Servers Domain Object Server Data Domain Manager Objects Domain Services Domain Transactional Process Services TP Application CatalogJ Registration Server Transaction Server Message Dispatcher Transaction Application Adapter ( Message ^Dispatcher Message Receiver DTP UI UI • • • I HHBi Message Control Services Message Receiver Message Dispatcher Message Catalog Message Registration Message Container J Domain Functional View Services DFVs DFV DFV DFV Adapters Adapter^ ^Adapter Domain Application Server (DAS) Application Registration Application Broker Domain Service Interfaces Project Model Proxy Services Proxy Manager Proxy Project Model Proxy Data Adapters Project Maintenance Services Project Session Services Project Session Manager Project Registration Services Presentation Services UBC K Page 157 Yu, 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

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

Comment

Related Items