Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Field evaluation, testing, and analysis of the future potential of the facility management turnover information… Ahmad, Waqar 1998

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

Item Metadata

Download

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

Full Text

Field Evaluation, Testing, and Analysis of the Future Potential of The Facility Management Turnover Information System. by Waqar Ahmad B . S c . Engineering (Civil), University o f Engineering & Technology Lahore, Pakistan 1980  A THESIS SUBMITTED I N P A R T I A L F U L F I L L M E N T OF T H E R E Q U I R E M E N T S F O R T H E D E G R E E OF M A S T E R OF APPLIED SCIENCE  in  T H E F A C U L T Y OF G R A D U A T E STUDIES Department o f Civil Engineering  We accept this thesis as conforming to the required standard  T H E U N I V E R S I T Y OF BRITISH C O L U M B I A  July, 1998  © W a q a r Ahmad, 1998  In  presenting this  degree at the  thesis  in  partial  fulfilment  University  of  British Columbia,  of  the  requirements  I agree that the  for  an  advanced  Library shall make it  freely available for reference and study. I further agree that permission for extensive copying of  this thesis for  department  or  by  his  or  scholarly purposes may be her  representatives.  It  is  granted by the understood  that  publication of this thesis for financial gain shall not be allowed without permission.  Department The University of British Columbia Vancouver, Canada  DE-6 (2/88)  head of my copying  or  my written  ABSTRACT Facility managers carry out their responsibilities in areas related to project and asset management. They need access to the right and timely information to make informed decisions and maintain a competitive edge. The nature of work performed by facility managers brings them in contact with construction managers when the facility is completed and ready for handing over to the facility operators. This process involves not only the transfer of the actual facility to the facility manager, but it is also accompanied by the transfer of a wide array of facility related documents. Traditionally, in the construction industry, the data is collected at each specialty area and there is very little exchange of information between different specialties. This results in duplication of effort and inconsistencies in data from different sources. To avoid this duplication this thesis identifies the useful sources of data which are generated during the project development phase and which could be useful for facilities groups for the project operation phase. Based on this information, a computer-based Facilities Management Turnover Information System (FMTIS) has been developed which enhances the problem solving and information management abilities of facilities managers. The FMTIS has been developed based on an understanding of the functions and information needs of the personnel responsible for facilities management. The thesis includes a description of the development of an operational prototype. The system presented here allows users to document and retrieve facility related information in the form of text. It is developed for PC platforms and runs under Microsoft Windows ™ operating environment using Microsoft Access software.  ii  TABLE OF CONTENTS Abstract  ii  Table of Contents  iii  List of Figures  vii  List of Tables  ix  Acknowledgement  x  CHAPTER 1: INTRODUCTION  1  1.1 Introduction 1.2 Problem Identification 1.3 Defining Facilities Management 1.4 Research Obj ectives 1.5 Research Methodology 1.5.1 An Overview of Information Control Process 1.5.2 Literature Review 1.5.3 Study of Turnover Documentation of a Selected Project 1.5.4 The Framework To Model Facilities Management Turnover System 1.5.6 System Development 1.5.7 Conclusion and Discussion of Results CHAPTER 2: INFORMATION CONTROL PROCESS 2.1 Construction Projects and Information Management 2.2 Data Sources 2.2.1 Information Routing and Information Users 2.3 Overview of Databases and Database Management Systems 2.3.1 Database Concepts and Relational Database Systems 2.4 Evolution of Data Models 2.4.1 Data Modeling Process 2.4.2 Data Analysis 2.4.3 Database Terminology 2.4.4 Definition of Relational Database Terms 2.5 Normalization 2.6 Resolution of Problem CHAPTER 3: LITERATURE REVIEW 3.1 Introduction 3.2 Role of Information in the Construction Process 3.2.1 Traditional Information Flow Framework 3.2.2 Information Flow Requirements 3.3 Project Documents and Records in the Construction Industry  1 1 2 5 5 6 6 6 7 7 8 9 9 10 10 12 12 14 16 18 20 24 24 26 27 27 28 29 30 30 iii  3.3.1 Why the Records Should be Stored 3.3.2 Types of Engineering Documents/Records 3.3.3 Project Photo Records 3.4 Information and Information Systems 3.4.1 Information Management and the Construction Industry 3.4.2 Computer Based Information Systems 3.5 Information Model 3.5.1 Entity-Relationship Model 3.5.2 Structural Data Model 3.6 User Interface 3.7 An Integrated Approach to Facility Management 3.7.1 Computer Aided Facility Management Applications 3.7.2 Zoser Systems Group 3.7.3 CAFM Market and Related Works  31 32 34 35 36 39 39 41 43 47 48 49 51 54  CHAPTER 4: ADVANCED MATERIALS AND PROCESS ENGINEERING LABORATORIES (AMPEL)  57  4.1 Introduction 4.2 Organizing Concept of the AMPEL Building 4.3 AMPEL: The Seven Domains 4.3.1 Domain 1: High Head Dirty Laboratories 4.3.2 Domain 2: Standard Dirty Laboratories 4.3.3 Domain 3: Standard Laboratories Group one 4.3.4 Domain 4: Standard Laboratories Group Two 4.3.5 Domain 5: Standard Clean Rooms 4.3.6 Domain 6 & 7: Support Services and Faculty Rooms 4.4 A Brief Description of Various Laboratories 4.4.1 High Head Dirty Laboratories 4.4.2 Pyrometallurgical Processing 4.4.3 Microstructural Engineering (Pilot Rolling Mill Facility) 4.4.4 Composites 4.4.5 High-Temperature Combustion Research Facility 4.4.6 Powder Metallurgy (Plasma Processing) 4.4.7 Fabrication of Ceramic Components Laboratory 4.4.8 Shared Advanced Metals Facility (Solid Preparation Laboratory) 4.4.9 Shared Advanced Metals Facility (Physical Modeling Laboratory) 4.4.10 Computer Facility 4.4.11 Surface Analysis and Structure 4.4.12 LEED & Auger Electron Spectroscopy 4.4.13 SIMS & SAM 4.4.14 X-ray Photoelectron Spectroscopy 4.4.15 Laser Desorption Microprobe FT-ICR Spectrometer 4.4.16 Polymers (Polymer NMR and ESR Spectroscopy and Imaging) 4.4.17 Magnetism 4.4.18 Opto-Electronics 4.4.19 Superconductivity  57 57 59 59 59 59 60 61 61 61 61 62 62 63 63 64 64 64 65 65 65 66 66 66 66 67 67 67 67 iv  4.4.20 Thin Film and Surfaces 4.4.21 Surface Physics 4.4.22 Semiconductor Processing 4.5 AMPEL Project Systems 4.5.1 Architectural System 4.5.2 Mechanical System 4.5.2.1 Domestic Water Subsystem 4.5.2.2 Sanitary & Acid Drainage Subsystems 4.5.2.3 Storm Drainage Subsystem 4.5.2.4 Fire Sprinkler Subsystem 4.5.2.5 Natural Gas Subsystem 4.5.2.6 Fuel Oil Subsystem 4.5.2.7 Steam/Water Heating Subsystem 4.5.2.8 Chilled Water Subsystem 4.5.2.9 Ventilation Subsystems 4.5.2.10 Exhaust Air Subsystem 4.5.2.11 Control Subsystem 4.5.2.12 Compressed Air Subsystem 4.5.3 Electrical System 4.5.3.1 High Voltage Power Distribution Subsystem 4.5.3.2 Emergency Generator Subsystem 4.5.3.3 Lighting Subsystem 4.5.3.4 Total Lighting Control Subsystem 4.5.3.5 Voice Data Subsystem 4.5.3.6 Fire Alarm Subsystem  68 68 68 69 69 70 71 72 73 73 74 75 75 76 77 79 79 80 80 81 81 82 82 82 82  CHAPTER 5: A DEVELOPMENT FRAMEWORK FOR A FACILITIES MANAGEMENT TURNOVER INFORMATION SYSTEM 89 5.1 Introduction 5.2 Framework for FMTIS Development 5.2.1 Project Selection 5.2.2 Feasibility Study 5.2.3 Analysis Phase 5.2.4 Design Phase 5.2.5 Implementation Phase 5.2.6 Performance Evaluation and Review 5.3 FMTIS: Facilities Management Turnover Information System 5.3.1 Objectives of FMTIS 5.4 Planning for FMTIS CHAPTER 6: SYSTEM ANALYSIS AND DESIGN 6.1 Brief Description 6.1.1 Proposed Users of the System 6.2 Objectives and Scope of the FMTIS 6.3 User Views 6.4 Database Design  ....89 89 91 92 94 97 99 100 100 101 101 102 102 103 103 104 105  6.5 File Organization Schemes 6.5.1 Core Entity- Product Breakdown Structure 6.5.2 Other Basic Entities 6.6 System Views 6.6.1 View 1: Facilities 6.6.2 View 2: Contacts 6.6.3 View 3: Products and Warranties 6.6.4 View 4: Tests 6.6.5 View5: Drawings 6.6.6 View 6: Permits..... 6.6.7 View 7: Commissioning 6.6.8 Integrated View 6.7 Entity and Relation Attributes 6.7.1 Entities 6.7.2 Data Dictionary 6.8 Suggestions for Implementation Environment 6.8.1 System Hardware and Software Options 6.8.2 Sources of Data Input 6.8.3 System Data Output 6.9 Physical Implementation 6.9.1 Microsoft Access Terminology 6.9.2 Prototype Development 6.9.2.1 Developing Tables 6.9.2.2 Setting Default Relationships between Tables 6.9.2.3 Designing Queries 6.9.2.4 Creating Forms 6.9.2.5 Producing Reports 6.9.2.6 Creating Applications With Macros CHAPTER 7: CONCLUSION 7.1 Thesis Review 7.2 Benefits and Applications of FMTIS 7.3 Experiences and Observations 7.3.1 Validation and Testing 7.4 Contributions 7.5 Extension and Future Research  106 106 108 112 113 115 117 120 122 124 126 128 130 131 133 134 134 135 136 139 139 142 143 143 145 146 152 153 154 154 155 156 158 160 161  BIBLIOGRAPHY  162  APPENDICES  170  Appendix A: Data Dictionary Appendix B: Default Relationships Appendix C: System Generated Reports and Printouts Appendix D: List of CAFM Vendors  170 178 182 186  vi  LIST OF FIGURES Figure 2.1 Figure 2.2 Figure 2.3 Figure 3.1 Figure 3.2 Figure 3.3 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 5.1 Figure 5.2 Figure 5.3 Figure 5.4 Figure 5.5 Figure 6.1 Figure 6.2 Figure 6.3 Figure 6.4 Figure 6.5 Figure 6.6 Figure 6.7 Figure 6.8a Figure 6.8b Figure 6.9 Figure 6.10 Figure 6.11 Figure 6.12 Figure 6.13 Figure 6.14 Figure 6.15 Figure 6.16 Figure 6.17 Figure 6.18 Figure 6.19 Figure 6.20 Figure 6.21 Figure 6.22 Figure C. 1 Figure C.2  Data Analysis System Structure Steps in Normalization Decision making in a Traditional Framework An Example of Entity-Relationship Data Model Structural Data Model Example The AMPEL Seven Domains AMPEL UBC Balancing Schematic Basement Floor Plan AMPEL UBC Balancing Schematic Main Floor Plan AMPEL UBC Balancing Schematic Second Floor Plan AMPEL UBC Balancing Schematic Third Floor Plan AMPEL UBC Balancing Schematic Fourth Floor Plan Proposed System Development Framework Phase 1 & 2: Project Selection and Feasibility Study Phase 3: Analysis Phase Phase 4: System Design Phase 5 & 6: Implementation & Review Phases E-R Diagram of Facilities View E-R Diagram of Contacts View E-R Diagram of Products and Warranties View E-R Diagram of Test View E-R Diagram of Drawings View E-R Diagram of Permits View E-R Diagram of view Commissioning E-R Diagram of Integrated View (Part A) E-R Diagram of Integrated View (Part B) System Data Organization Diagram A Part of Drawings Table Data Entry Form Commissioning Data Entry Form Contacts Data Entry Form Drawings Drawings and Products Browser Products and Related Records Browser FMTIS Switch Board Data Entry Form Products Data Entry Form Facilities Data Entry Form Tests A View Information Form Contacts Information Report Image Warranties Information Report Image System Generated Drawing of High Head Room Lab System Generated Permit Image of Natural Gas Subsystem  19 23 25 30 42 45 58 84 85 86 87 88 90 93 96 98 100 114 116 119 121 123 125 127 128 129 138 144 147 147 148 148 149 149 150 150 151 151 152 153 182 183  vii  Figure C.3 Figure C.4  System Generated Test Report Image System Generated Drawing of Safety Roof Anchor & Tie Back System  184 185  LIST OF TABLES Table 3.1 Table A. 1 Table A. 2 Table A.3 Table A.4 Table A. 5 Table A. 6 Table A.7 Table A. 8 Table A.9 Table A. 10 Table A. 11 Table A. 12 Table A. 13 Table A. 14 Table A. 15 Table A. 16 Table A. 17 Table A. 18 Table A. 19 Table A.20 Table A.21 Table A.22 Table A.23 Table A.24 Table A.25 Table B. 1 Table B.2  A Partial List of CAFM Vendors List of Data Elements for Commissioning List of Data Elements for Contacts List of Data Elements for Contracts List of Data Elements for Drawings List of Data Elements for Facilities List of Data Elements for Permits List of Data Elements for Products List of Data Elements for Tests List of Data Elements for Warranties List of Data Elements for WBS List of Data Elements for Commissioning Locations List of Data Elements for Locations List of Data Elements for Contact Locations List of Data Elements for Contract Doc Locations List of Data Elements for Drawing Locations List of Data Elements for Permit Locations List of Data Elements for Product Locations List of Data Elements for Product Drawings List of Data Elements for Product Tests List of Data Elements for Test Doc Locations List of Data Elements for Warranties Locations List of Data Elements for WBS List of Data Elements for Sub_Systems List of Data Elements for Facilities Locations List of Data Elements for Systems Default Relationships Queries and Join Tables  54 171 171 171 172 172 172 172 173 174 174 174 174 175 175 175 175 175 176 176 176 176 176 177 177 177 178 179  ix  ACKNOWLEDGEMENT I would like to appreciate the constant guidance and support of my research supervisor Dr. Thomas Froese which he provided throughout the research project. It was through his keen sense of direction and advice that I was able to finish this research report. I would also like to thank Dr. Alan Russell for reading this report and providing me with valuable and inspiring suggestions.  I would also acknowledge the help and cooperation extended by Mr. Rob Seversen manager of UBC Plant Operations who was very helpful in my data collection effort during this research project. It was through his cooperation that I was able to gather information about AMPEL from various resources available at plant operations.  I would like to make a special mention of my friend and colleague Asad H. Udaipurwala a doctorate student in construction management. In order to implement the data model in Microsoft Access, I used to discuss my ideas with him at the construction management laboratory and he provided me with his useful suggestions.  In the end my warm appreciation and gratitude for my wife Zoobi who was a constant source of strength and motivation for me during this project. It was also through her financial help that I was able to carry out my work without any financial worries.  CHAPTER 1: INTRODUCTION 1.1  Introduction  This chapter introduces the basic problem o f information management in the construction and facilities management industry and gives an overview o f the information generation and control problem. The objectives o f the thesis are given and the adopted research methodology is explained. Finally, an overview o f the thesis is given.  1.2  Problem Identification  Accurate and comprehensive information is a necessity for making informed decisions. In the absence o f sound and timely decisions even a well-planned building project can run into many problems during construction or even completion o f the project at the time o f handing the facility over to the client. Decision support tools can help both the owners and contractors to avoid the problems at a crucial time o f project turnover.  Construction projects are becoming more complex with the progress o f technology. During the project development phase, the project team generates a large body o f information about the facility. This information is o f immense value to the owner, end users, and facility management groups. The information generated before completion generally includes but is not limited to construction specifications, structural design, drawings, contractor  and  subcontractor information, vendor and material suppliers information, cost and schedule information, accounting information, change orders information etc. Typically, there are no  1  facility turnover processes in place to allow end users and facility management groups to retrieve this information in a useful and interpretable form. This information resides at multiple locations and is not in a well-organized form. It can take a lot of time and effort on the part of facility managers to consolidate this information for their future reference. A typical example of the lack of coordination between facility people and the construction teams arises when a system breakdown (HVAC, Pumps, Electrical etc.)  occurs after demobilization of  construction teams. If the required information to handle such situation is not readily available to the facility staff, necessary calls to the outside vendors must be resorted to. The collection and organization at project information during construction phase for transfer to facility managers at project completion can be greatly enhanced by a facilities management ternover information system (FMTIS).  1.3  Defining Facilities Management  In order to understand the term facilities management turnover system, we first arrive at some acceptable meanings to define the term, "Facilities Management". Facilities Management is an application of information management [Hamer 1988]. Facility Management (FM) as a field of study is in its infancy and is multi-disciplinary by nature [Grimshaw et al 1992]. Much time has been spent trying to define its boundaries and identify its core disciplines. This has proved difficult because much of the work carried out by practicing facilities managers is at an operational level far short of the strategic role promoted by the pioneers of the discipline who see FM as fundamental to the efficient operation of any organization (Becker, 1990).  2  The International Facilities Management Association (IFMA) defines facility management as, " the practice of coordinating the people and the work of an organization into the physical workplace." A more detailed definition is offered by Engineering News-Record (April 4,1985):  "Facility Management is the discipline of planning, designing, constructing, and managing space, in every type of structure from office buildings to process plants. It involves developing corporate facilities policy, long-range forecasts, real estate, space inventories, projects (through design, construction, and renovation), building operation, and maintenance plans, and furniture and equipment inventories."  Facilities management integrates the principles of business administration, architecture, and the behavioral and engineering sciences. This definition or many other like it, whilst inadequate as a direct basis for constructing a working model for facilities management, nevertheless confirms, the realization that there are at least three principles aspects to the facilities management function.  •  It is a supporting function to the core business of an organization  •  It concentrates on the area of interest between physical workplace and people  •  It requires a multi-skill approach  3  Against the back drop of the above discussion a Facilities Management Turnover Process could be defined as an activity which takes place when a physical facility such as a school, hospital or sports stadium is handed over from the construction group to the project operator, usually an owner or his appointed agent. The usual industry practice is that along with the actual facility, the project documentation generated during the course of project development is handed over to the facility operators in a paper format. If the documentation turnover process is automated with the help of computer systems in the form of a user friendly computer application this automated process is called Facilities Management Turnover Information System.  Facility managers carry out their responsibilities in the area of construction related services. They need ready access to the right information to carry out their job in a professional manner. The timely access of properly processed data for decision making can provide a competitive edge. Traditionally, in the construction industry, data is collected at the specialty level, and there is very little exchange of information between different groups engaged on the site. As a result, there is a great deal of duplication of effort for capturing the same information, which results in inconsistencies while making updates. The problem is compounded when the facility is ready for handing over to the facility management group. At this stage, project managers some timesfindthemselves unable to hand over the complete set of documentation to the facilities group in a meaningful and interpretable form.  4  1.4  Research Objectives  The objectives o f this thesis are as follows:  •  The first objective is to analyze the information needs o f the project and facilities management personnel, to gather information by literature review and to determine what type o f documents are turned over by project management groups at the time of facility turnover to facility management groups.  •  The second objective is to develop a computer-based Facilities Management Turnover Information System capable o f providing information and solving the problems o f facility managers.  The research uses current computer technologies to manage all the information which is generated during project implementation to be used during facilities operation. This system will enhance the problem solving and operational capabilities o f the facility  management  groups. The thesis will focus on the facility management information required to maintain the facility.  1.5  Research Methodology  The research consisted o f five main components. The following sections summarize these steps which are discussed in the following chapters o f this thesis.  5  1.5.1 An Overview of Information Control Process Chapter 2 will examine in some detail the fundamental issues o f the information control process. Some o f the key concepts for assuring quality and value in the development o f an information system are discussed. A n overview o f the basic concepts o f data, data models, database management systems, and relational data base systems is given.  1.5.2 Literature Review Chapter 3 provides an overview o f the information control problem resulting from a thorough search o f the literature o f various fields o f study such as: construction processes, construction documents, integrated information management,  construction management,  data models,  relational databases, civil engineering computing, facilities turnover processes and facilities management. The literature search has resulted in the production o f a framework for the project turnover documentation and also helped in the development o f ideas to focus on this research.  1.5.3 Study of Turnover Documentation of a Selected Project Chapter 4 describes the research on the transfer o f project information from the construction phase to the operation phase o f a recently completed actual project. A suitable project for studying the turned over documentation was obtained through assistance from the Plant Operations Department of U B C and the plant operations facilities manager was very helpful in arranging the access to the project documentation.  6  The purpose of this exercise was to see what type of information was forwarded from the contractor and how it is organized and used by the operator. As this research was planned to be a case study, a recently completed project called the Advanced Materials and Process Engineering Laboratory, (AMPEL), within the University of British Columbia (UBC) campus was selected after some field search among the recently completed UBC projects. Most of the turnover documentation was studied at the facilities management department of UBC Plant Operations. The study of project documentation gave deep insight into this very complex and advanced engineering research laboratory and it's various systems and processes, which are supported by large electronic and electro-mechanical instrumentation.  1.5.4  The Framework To Model Facilities Management Turnover System  Chapter 5 presents the development of a framework to model facilities turnover information. The approach synthesized the study of turned over documents of AMPEL, which was particularly helpful in creating a breakdown of documents into logical constructs and common data items.  1.5.6  System Development  Chapter 6 discusses the development of an information system based on the literature search, the proposed data model and the data collected. It was found in the literature search that there were many sophisticated software packages in the market for automating facilities management functions, but they are not used routinely in professional organizations. This could be explained by the fact that facilities management information systems are relatively  7  new and computer application of its various functions is slowly finding favor with practitioners [Hamer 1988]. More interestingly, it was found that in spite of a large inventory of projects managed and operated by Plant Operations of UBC, there was no facilities management turnover system in place for operating this large collection of assets.  The system has been developed by keeping in mind the requirements of a medium level contractor and facilities manager who are willing to address the project turnover issues through a PC based solution.  1.5.7  Conclusion and Discussion of Results  Chapter 7 summarizes the discussion carried out in the previous sections and provides a critique on the goals, which were set at the beginning of the project. A point by point analysis of objectives of the thesis is given.  8  CHAPTER 2: INFORMATION CONTROL PROCESS This chapter examines in some detail the issues which are fundamental to the information control process. Some o f the key concepts for assuring quality and value in the development o f an information systems are discussed.  2.1  Construction Projects and Information Management  [Sanvido & Paulson 92] and [Toker 90] have pointed out many shortcomings o f traditional tools which provide information for construction project control. These tools include, but are not limited to, progress reports, change order reports, cost and budget reports. These reports focus on only one aspect o f the project, that is the end product itself, but do not inform us about the dynamics o f the processes involved. The inadequacy o f the reports is felt when a problem occurs. Present day projects are very complex and require the involvement o f a large number o f interested groups. In addition to various groups involved in the execution o f the project, further complexity to the project management process is caused by complex building systems. Therefore, the need for information management has increased with the passage o f time.  Organizations in every industry, from educational institutions to industrial firms, are faced with the challenge o f expanding and managing their facilities [El-Bibany et al 1997]. The construction industry is no exception to this phenomenon. Construction is an information intensive industry. For a contractor, management o f the project information begins the day he bids for the project, and the volume o f information keeps on increasing with the evolution o f  9  the project [Kangari 95]. Most of this information is of great interest for facility managers. They need accurate, reliable and timely information to make informed decisions on very short notice whenever the need arises.  The basic source of all this information is data which when interpreted in some organized way conveys logical meanings.  2.2  Data Sources  Data in construction industry are generated from numerous sources such as contract documents, contract drawings, project test results, daily inspection reports, change orders, survey reports, warranty reports, minutes of the meetings, shop drawings, submittal logs and city or municipal regulations, to mention a few.  Data have been defined into two types as objective data and subjective data [Toker 90]. Objective data are the information which can be mapped directly from the document, whereas subjective data require formal decision making and some degree of expertise to decipher.  2.2.1 Information Routing and Information Users Information users for our purposes include project managers, facility owners, facility managers, system designers, engineers, and users of an information system. According to [Silberschatz et al. 97] there are four different type of database system users, differentiated by the way that they expect to interact with the system.  10  •  Application programmers are computer professionals who interact with the system through Data Manipulation Language ( D M L ) calls, which are embedded in a program written in a host language. These programs are commonly referred to as application programs. Examples in a business environment include programs that generate payroll checks, that debit or credit accounts, or transfer funds between accounts.  •  Sophisticated Users interact with the system without writing programs. Instead, they form their requests in a database query language. Each such query is submitted to the query processor whose function is to break down D M L statement into instructions that the storage manager understands.  •  Specialized Users are sophisticated users who write specialized database applications that do not fit into traditional data processing framework. Among these applications are computer aided design systems, knowledge based and expert systems, and systems that store data with complex data types.  •  Naive Users are unsophisticated users who interact with the system by invoking one o f the permanent application programs that have been written previously. The example includes a bank teller who needs to transfer $50 from account A to account B , and invokes a program called transfer. This program asks the teller the amount o f money to be transferred, the account from which the money is to be transferred, and the account to which the money is to be transferred.  [Peters 84] suggests routing o f information to the right people by assigning tasks and responsibilities through a responsibility matrix. A l l functional specialists who have a role to  11  play occupy a position in the matrix where their responsibilities are well defined. [Peter 84] explains that such a matrix will also be the framework of an information system in which appropriate information is channeled to the right users of the information.  [Mintzberg 73] suggests that information collected by the senior management is used in the following four ways: (1) to disseminate it to others; (2) to develop value position for the firm; (3) to identify business problems and opportunities; and (4) to develop mental images models of how the organization and its environment functions.  2.3  Overview of Databases and Database Management Systems  A database management system (DBMS) is an organized set of facilities for accessing and maintaining one or more databases, [Baynon-Davies 93]. A DBMS is a shell which surrounds a database and through which all interactions takes place. The interaction catered for by most exiting DBMS fall into 3 main groups; (1) file maintenance, (2) information retrieval, (3) database administration.  2.3.1  Database Concepts and Relational Database Systems  In most computer applications, the associated data are kept separately from the programs that process it [Paulson 95]. Physical locations of the files of information can be online, meaning that the device containing the information is continuously attached to the computer and ready for access, and offline, meaning that the information may be contained on storage media stored away from the derives on which they can be mounted. Online storage is used for  12  information needed on a continuous basis, such as the files for an airline reservation system, whereas offline storage serves for archiving annual records, backing up online files, and so forth.  There are many ways of organizing and storing information; the most suitable in a particular case depends upon the nature of the application. [Townsend 92] states that a database systematically stores information for retrieval or analysis and describes two types of databases that dominate small computing environment, namely: flat-file and relational databases. Flat-file database contain records of information, each similar in format, and more complex databases that provide integrated access to integrated blocks of information that can be viewed from different perspectives.  Relational database management systems provide the capability to build integrated applications that draw upon the equivalent of multiple files. Individual files, usually called tables or relations in databases can focus on the primary information needs and responsibilities of certain individuals and groups. Relational database also makes it relatively easy to make inquiries and prepare reports that draw upon multiple tables to extract desired information and put it into new and custom formats that can facilitate analysis and understanding of relationships among different type of data [Paulson 95].  [Burger & Halpin 77] state that the database concept provides a suitable environment for a sophisticated user-oriented project information system. Data used and generated at the project level is stored and maintained in a highly integrated structure instead of separate applications  13  files. The approach permits organization of data in hierarchical, network or relational systems. [Tenah 84] states that the planning, designing and controlling of information and information systems rely on an extensive database of high quality to be a useful tool in solving the complex problems of today and of the future. [Bengtsson & Bjornsson 87] advocate computerized database systems for timely and easy retrieval of data. [Bowler 94] points out the importance of relational database management systems in engineering office. He discusses the use of database applications in project management, business development and administrative applications.  A database can be seen as an attempt to overcome some of the limitations imposed by the conventional filing system [Bamford & Curran 91]. It is the database management which allows the user to create and maintain a database system. The database is a physical implementation of an information or data model.  [Lock92] states that the foundation of any Management Information System (MIS) is its data bank which contains raw data that can be accessed by the MIS user, directly or indirectly. For this reason a DBMS is needed which permits simultaneous access to many different data banks that exist in an organization.  2.4  Evolution of Data Models  [Silberschatz et al 96] have described the data model as the underlying structure of a database, and it is a collection of conceptual tools for describing data, data relationships, data semantics and consistency constraints. The evolution of database management systems has always been  14  driven by the search for new ways of modeling increasingly complex real-world data [Rob & Coronel 95]. This search has yielded many proposed data models; yet few have been implemented, and even fewer have achieved commercial success. The most frequently recognized data models include the following:  •  Hierarchical Data Model  •  Network (CODASYL) Data Model  •  Relational Data Model  •  Entity Relationship  •  Semantic Data Model  •  Extended Relational Data Model  •  Object Oriented Data Model  Each new data model capitalized on the short comings of the previous models. The Network (CODASYL) model replaced the hierarchical model because the former made it easier to represent complex (many to many) relationships. In turn, the relational model offered several advantages over the hierarchical and CODASYL models through its simpler data representation, superior data independence, and relatively easy-to-use query language [Codd 70]. Although the debate about the relative merits of the older hierarchical and CODASYL models and newer relational models lasted several years, the relational model emerged as the dominant database model for business applications [Rob & Coronel 95].  15  The entity relationship model, appearing after the relational model, introduced an easy to use graphical data representation, thus becoming the database design standard.  In response to the increasing complexity of applications, two new data models have emerged: the Object-Oriented Data Model (OOBM) and the Extended Relational Data Model (ERDM). The OODM is based on concepts derived from object oriented programming languages and has gained strength during the past several years. The ERDM, championed by relational database researchers such as Dr. E.F.Codd, constitutes the relational world's response to the OODM challenge. At the time of writing this report, neither OODM or ERDM, has emerged as the clear victor in the battle for market dominance. The OODM and ERDM are similar in the sense that each attempts to address the demand for more semantic information to be incorporated into the model. However, the OODM and the ERDM differ substantially both in terms of underlying philosophy and the nature of the problem to be addressed. The ERDM is based on relational data model concepts, while the OODM is based on 0 0 and semantic data model concepts. The ERDM is primarily geared to business applications, while the OODM focuses on specialized engineering and scientific applications.  2.4.1  Data Modeling Process  Several authors have explained data modeling in detail ([Atre 80], [Bamford & Curran 91], [Tsichritzis et al 82], [Cary & Michael 97], [Beynon-Davies 93], [Vetter 87] and [McFadden & Hoffer 88]). The process of generating a working database involves the creation of the following three models: the conceptual data model, the logical data model and the physical data model. 16  In a conceptual model, the data is represented as conceptual objects, such as entity sets, relationship sets, entity attributes and relationship attributes. These conceptual objects can be defined using fully normalized elementary relations. The conceptual model is based on the perception o f an organizational area or a problem, which is being examined. The advantages of using conceptual data modeling are fourfold [Vetter 87]:  1. The approach allows the analyst to model the real data used by an organization in a very precise way. 2.  Everybody working with the approach is obliged to analyze the real data in the same systematic way.  3.  Since an elementary relation is small (it usually contains no more than 4 attributes) the normalization criteria is easily applied.  4. The approach does not lead to elementary relations which hold two or more independent complex associations for an entity type.  The logical model is derived from the conceptual model and is a formal representation describing data items and their structural relationships. The conceptual model is translated into a data model compatible with the chosen D B M S . It is possible that the relationships between entities as reflected in the conceptual model are not implementable with the chosen D B M S . The various D B M S s impose a number o f constraints and rules for implementation to the physical database. F o r example, some D B M S insists that only two relationships need be used on the data model: one-to-one and one-to-many. Many-to many relationships must  17  be resolved into two one-to-many relationships by the introduction of a third link entity. In such situations, a modification to the conceptual model is made to reflect these constraints.  If no relational DBMS is available, then we have to transform the conceptual data structure into a logical (also called external) data structure and the physical (also called internal) data structure [Vetter 87]. The logical model is either a relational, hierarchical, or network data model. The version of the conceptual model that can be presented to the DBMS is called the logical model.  The physical model is the actual implementation of the database consisting of the data tables or files with supporting software. The translation process of the logical schema to a physical model is performed by the DBMS software.  2.4.2  Data Analysis  The intent of data analysis is to develop stable foundations for application systems. The end product of data analysis is a set of data structures designed to suit some application [BeynonDavies 93, p. 99]. The data analysis process has been shown in figure 2.1.  There are two complementary approaches to conducting data analysis: top-down approach and bottom-up approach, [Beynon-Davies 93] and [McFadden & Hoffer 88, pp. 67-68].  18  Data Analysis  Process Analysis  Data Processing/ Information System M o d e l  Figure 2.1  Data Analysis  (Source: [Beynon-Davies 93], p. 99)  Conducting top-down data analysis reflects the use o f a diagramming technique to map what the developer thinks o f the things o f interest to the enterprise and the relationship between these things o f interest. Top down analysis is frequently referred to as conceptual modeling because we remain at a fairly higher level on an abstract plane. -The product o f such a modeling exercise is usually an entity-relationship diagram. This diagram can be transferred into a set o f table structures called a relational schema via a straight-forward process o f translation or accommodation. In bottom-up analysis, the developer deals with concrete data. To do bottom up analysis, we must have a pool o f data items extracted from the examination o f existing enterprise documentation. T o this pool o f data, the developer applies a series o f transformation rules. Bottom-up analysis is also called normalization [Beynon-Davies 93].  19  2.4.3  Database Terminology  Some of the terms as defined by [Silberschatz et al 96] to describe data and its representation (shown in figure 2.2) are as follows:  Data Manipulation Language (DML) compiler: translates DML statement in a query language into low-level instruction that the query evaluation engine understands. In addition, the DML compiler attempts to transform a user's request into an equivalent but efficient form, thus finding a good strategy for executing a query. Embedded DML Precompiler: converts DML statements embedded in an application program to normal procedure calls in the host language. The precompiler must interact with the DML compiler to generate the appropriate code. DDL interpreter, interprets (Data Definition Language) DDL statements and records them in a set of tables containing metadata. Query evaluation engine: executes low-level instructions generated by the DDL compiler. Authorization  and integrity manager: tests for the satisfaction of integrity constraints and  checks the authority of users to access data. Transaction manager: ensures that the database remains in a consistent (correct) state despite system failures, and concurrent transaction executions proceed without conflicting. File manager: manages the allocation of disk storage and the data structure used to represent information stored on disk. Buffer manager: is responsible for fetching data from disk storage into main memory, and deciding what data to cache in memory. Data files: store the data itself and is a collection of data records. Example, an office report. 20  Data dictionary:  is a set o f system tables that contain the data definitions o f the database  objects. It is independent o f any database management system ( D B M S ) . Indices: provide fast access to data items that hold particular values. Schema: the overall design o f the database is called schema. Instance: the collection o f information stored in a database at a particular moment is called an instance o f the database. Entity: is a thing or object in the real world that is distinguishable from all other objects. Entity set: is a set o f entities o f the same type that share the properties or attributes i.e., the set of all persons who are customers at a particular bank. Attributes: descriptive properties possessed by each member o f an entity set. Relationship:  an association among several entities. A relationship exists between two  entities i f they share one or more common attributes. Relationship  set: is a relationship o f the same type. I f E i , E , . . . . E 2  n  are entity sets, then  a  relationship set R is a sub set o f {(ei,e2,... .e„) / ei G E i , e2 e E , . . . . , e G E } where (ei,e2,...e„) is a relationship. 2  n  n  The degree o f relationship is the number o f entity sets that participate in a relationship. Key attribute o f an entity: has the property that identifies the data values o f other attributes o f the same key. K e y attributes can also be called entity identifier. Mapping  Cardinalities:  or cardinality ratios, express the number o f entities to which  another entity can be associated via a relationship set. For a binary relationship set R between entity sets A and B , the mapping cardinality must be one o f the following:  21  One to one. An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A. One to Many. An entity in A is associated with any number of entities in B. An entity in B, however, can be associated with at most one entity in A. Many to one. An entity in A is associated with at most one entity in B. An entity in B, however, can be associated with any number of entities in A. Many to many. An entity in A is associated with any number of entities in B, and entity in B is associated with any number of entities in A.  22  Naive user  application programmers  application programs  application interface  application program object code  sophisticated users database administrators  4  embedded ^ DML precompiler  query  ^  DML compiler  Users  database scheme  DDL interpreter  query evaluation engine DBMS buffer  transaction manager  manager file manager  disk storage  indices  data files  Figure 2.2  data dictionary  System Structure  (Source: [Silberschatz et al 96], p. 18)  23  2.4.4 Definition of Relational Database Terms A relational database consists o f collection o f tables, each o f which is assigned a unique name ([Salzberg 86], [Bull 90], [Silberschatz et al 96], [Rob & Coronel 1995]). There is a close correspondence between the concept o f table and the mathematical concept o f relation, from which the relational data model takes its name. Mathematicians define a relation to be a subset of a Cartesian products o f a list o f domains whereas a domain is defined as a permitted set o f values for each attribute [Silberschatz et al 96]. Because tables are essentially relations, this term would be used interchangeably with the term table in this discussion.  A table has the following properties: each table has a name, no two rows or tuples can be the same; the order o f tuples is not important, each attribute must have a unique name; the order of attribute is significant; at the intersection o f any attribute there is a single data value; the values in any one column are from the same domain; each tuple is uniquely identified by its primary key made up o f one or more attributes; the primary key must not be null.  2.5  Normalization  [Salzberg 86], [Date 90], [McFadden & Hoffer 88], [Rob & Coronel 96], [Rasdorf &Herbert 88] have described the normalization process in detail. Normalization is a process for assigning attributes to entities. Normalization reduces data redundancy and helps to eliminate the data anomalies that result from those redundancies. Normalization does not eliminate data redundancies; instead it produces the controlled redundancy that allows us to link database tables. Normalization works through a series o f stages called normal forms.  24  The standard steps of the normalization process are shown in Figure 2.3. A relational table must not contain repeating groups. If repeating groups do exit, they must be fixed by making sure that each row defines a single entity. When this step has been taken the data is said to be in the first normal form (INF). The second step is to ensure that, if the relation has a composite key then any data attribute in the relation should be functionally dependent upon the whole key and not just part of the key. A data attribute, which is dependent upon just a part of a composite key, is removed to form a new relation. When this step has been done, the data is said to be in the second normal form. (2NF). The third step is to remove any attributes which are functionally dependent upon other attributes, and to put these in a separate relation. After completion of this step, the data is said to be in third normal form (3NF).  User Views Un-normalized Relations Remove repeating Groups Normalized Relations(lNF) I Normalized Relations (2NF)  "Remove Partial dependencies Remove Transitive dependencies  Normalized Relations (3NF)  Figure 2.3  Steps in Normalization  (Source: [MacFaden & Hoffer 88], p. 249)  Although 3NF is usually sufficient in a business environment, there are some circumstances that may require the use of higher level normal form such as include Boyce/Cod Normal Form.  25  2.6  Resolution of Problem  One method to resolve the problem stated at section 1.2 and to significantly improve the operation and maintenance of a facility is to implement a software system based solution that would automate the project turnover process. This type of system would transfer the facility information maintained during facility design, development and construction phase into a relational database where it could be easily managed electronically. Once in a database, the required information could be easily accessed whenever required at a later date. The database can also have an interface with AUTOCAD for calling up CAD drawings.  When the useful information is captured in a database about a facility, this information can be reused by the management as a benchmark in the development of future improvements in that facility. Other construction specialization such as project planners, schedulers and estimators can both use the relevant information to prepare accurate estimates whenever required in future for new components of the facility.  26  CHAPTER 3: LITERATURE REVIEW 3.1  Introduction  This chapter reviews some o f the literature that is relevant to this thesis. The discussion will revolve around a review o f the issues o f information and information systems, information needs in construction and facilities management, and documents which are o f interest to both construction and facilities managers. Finally, a brief description o f a few facility management systems in the market is provided.  [Howard et al 1989] have highlighted the importance o f information systems for the architecture, engineering and construction ( A E C ) industry. [Howard et al 89] also claim that the construction industry is highly fragmented. This fragmentation exists through design and construction and into the facility management and operation phase.  Constructed facilities account for over half o f the capital investment o f manufacturing industries in the United States. [Christian & Pandeya 97] provide us some vital statistics which have emerged in several countries regarding operation and maintenance o f facilities. They estimated that about 30% o f all energy produced in the United States is used to operate facilities. In Canada, more than half the residential construction spending is on renovation and restoration works. Maintenance and renovation works in United Kingdom were estimated to be about 46% o f the total construction output in 1986, whereas for Singapore, with about 50% o f its building stock below 10 years o f age, such works accounted only for about 2 1 % o f the total construction output [Kiang 91].  27  Computer technologies such as artificial intelligence, robotics and databases offer the potential of improving levels of integration in decision making in the construction industry. For maintenance, operations, and future modifications of facilities, the owners need an accurate record of what was designed and built. They are seeking that record in electronic form. An example is Stanford University, which has recently tried to digitize key utility and building data of its constructed facilities from existing files of some 45,000 paper drawings just to get up to date in managing its facilities [Howard et al 89]. Working with AEC industry, both facility builders and facility managers can develop a useful model for representing data requirements for facility operations and maintenance. A major part of this effort involves the definition of the information needed to begin operation of the facility, and focusing on databases representing the as-built structure. Another part of this effort is defining the data that must be collected over the life of the facility and determining how that information can be utilized effectively in future planning, management and modification.  3.2  Role of Information in the Construction Process  The type of information required by an organization largely depends upon the focus of the organization, the role of its employees, and the type of business it conducts [Lock 92]. It is the organizational focus which determines what information is of its interest, how it will be organized, formatted and accessed so that it could be useful in the decision making process for management objectives.  [Tenah 86] acknowledges that there is a lack of information in the construction industry regarding functions, responsibilities, and informational needs of construction personnel.  28  Project managers cannot perform efficiently without proper information. In that paper, the author discusses that the information required by the construction personnel is usually organized into reports, the contents of the reports, the purpose(s) they serve, and the frequency at which they are issued. In the same paper, he presents results of a field study conducted to determine the information needs of the projects and their functional managers. In his concluding remarks, he says that, since management functions are inextricably linked, there is the need to redefine personnel function, responsibilities and information needs after revising each organizational structure.  3.2.1  Traditional Information Flow Framework  [Goldhaber et al 77] illustrate a traditional framework of information flow in a construction industry (Figure 3.1). In such a type of system, it is assumed that all parties and levels of management have the same type of information and will essentially come to the same conclusion. The same reports are generated and distributed to all levels of management. These assumptions do not represent the actual information flow process in the construction industry framework. It is common knowledge that different decisions are made at different levels. Unless meaningful and timely information is generated, there is no justification for an information system.  29  Top Management Information  Middle Management  Project Management  I  Project Staff Computer  Figure 3.1  4  <  •  System Staff  Network Systems  Decision making in a Traditional Framework  (Source: [Goldhaber et al 77], p. 116)  3.2.2  Information Flow Requirements  For an organization to function smoothly, it is essential that there should be free flow of information in all directions, i.e., upward, downward and lateral [Tenah 84]. The flow of information in a construction industry is necessary for more efficient and effective project implementation. This allows managers to learn about the events at the project and allows problem solving and quick resolution of conflicts at the project. Project records are the key functions of the information system.  3.3  Project Documents and Records in the Construction Industry  Records have been part of the engineering profession since its beginning and it is safe to say that they will continue to exit, in whatever futuristic form they might take [Hamilton 91].  30  Therefore, a records management program in an engineering organization is an essential tool. Unfortunately, a successful information and records retrieval program is either nonexistent or is nonfunctioning in most o f the organizations, causing records to abound with no control. They may appear everywhere, on tables, in filing cabinets, stacked on floor, stored in computers, in flat files, and stacked in storage rooms [Hamilton, 91].  3.3.1 Why the Records Should be Stored Some o f the basic reasons that an engineering organization needs to store its records are listed as follows:  •  Records can provide protection against or during the process o f litigation.  •  Records contain design material that is invaluable to future design, both for new  and past clients.  •  Records may contain material that is important in a historical sense.  •  Records can prove important in marketing and public relations efforts.  •  Records can prove costly to store, but not appropriately storing engineering records can be even more costly.  31  •  Records often must adhere to detailed requirements from government regulations.  In this information society, information is vital to any organization. Documents management is the control o f information, from creation to disposal. Therefore, establishing an information control system in an organization is a modern day reality which all organizations who want to survive the market realities will have to adopt to remain competitive in future.  3.3.2  Types of Engineering Documents/Records  The end product o f a design project is often thought as the "plans and specs," the drawings and specifications which a contractor will use to build the desired facility or product [Huff 87]. The plans and specifications however, are only a portion o f those items collectively known as the construction documents, the graphic and written information concerning the project that is provided to contractors for bidding a job. [Huff 87] identifies the following as some major construction documents:  •  The Drawings: Graphical construction documents are called drawings, which show the size and physical relation o f various parts o f the job.  •  The Project Manual: Written construction documents are bound together in a volume called the Project Manual, which itself is divided into four main areas:  (1) Bidding requirements; (2) Contract forms; (3) Conditions o f contract; (4) Specifications.  32  C o n t r a c t D o c u m e n t s are those items that w i l l be used to b i n d the o w n e r and c o n t r a c t o r together f o r the d u r a t i o n o f the project. T h e contract documents i n c l u d e all the graphic and w r i t t e n c o n s t r u c t i o n documents, except f o r the b i d d i n g requirements, that exist at the time bids are solicited. There are t w o other general categories o f contract d o c u m e n t s , w h i c h a l l o w f o r changes t o be made: (1) A d d e n d a ; (2) m o d i f i c a t i o n s . A d d e n d a are changes i n contract d o c u m e n t s that are made p r i o r to bids b e i n g submitted. A contractor's b i d must reflect these changes. M o d i f i c a t i o n s are changes to contract  documents, w h i c h  are made  after  the  agreement between the o w n e r and c o n t r a c t o r has been executed. M o d i f i c a t i o n s i n c l u d e field orders f o r m i n o r items not r e q u i r i n g a change in contract price o r time and change orders f o r revisions affecting price o r time, [ H u f f 87].  [ H a m i l t o n 91] suggests that engineering organizations have several u n i q u e types o f r e c o r d s i n a d d i t i o n t o the records that are c o m m o n w i t h other firms. T h e c o m m o n r e c o r d s are minutes o f the meetings, daily correspondence files and insurance documents. T h e u n i q u e types  in  engineering firms include d r a w i n g s , specifications, project files, and shop d r a w i n g s .  [Ganeshan et al 94] has listed the contract document, contract d r a w i n g s , shop d r a w i n g s , test reports, manufacturers  data, warranty  i n f o r m a t i o n , c o r r e s p o n d e n c e , change  orders,  and  i n s p e c t i o n reports as d o c u me n ts o f interest f o r a c o n s t r u c t i o n project. A d d i t i o n a l l y , there c o u l d be some other d o c u me n ts generated as a part o f project c o n t r o l process s u c h as daily site reports and project photographs.  33  [Kangari 95] focuses on the results o f poor project documentation from the point o f view o f arbitration processes. H e has reported the results o f a survey questionnaire collected from arbitrators from seven different U S cities. The paper also outlines recommendations made by the arbitrators to hypothetical clients on record keeping, organizing, storing and securing project documentation. Some o f the documents recommended by arbitrators include the following:  •  Detailed daily reports outlining work force levels, trade reports, job progress reports, inspections, equipment used, material deliveries, weather reports.  •  Job site log maintained at the site office and faxed to the home office every day.  •  Construction progress photographs taken at least weekly. These should always include critical items, dated, signed, and filed.  •  Chronological files o f all job activities, delivery tickets, field orders, and payment requisitions.  •  A l l correspondence, maintained and answered promptly to avoid problems later.  •  Requests for information, change orders, field directions, shop-drawings, submittal logs, bid tabulation forms, minutes o f the meetings, cost records, quantity take-offs etc.  3.3.3 Project Photo Records A picture is worth a thousand words [Maher 78]. The practical meanings to the phrase could be effected by incorporating project photographs as a means o f tracking the pictorial  34  d e v e l o p m e n t a l v i e w o f the project. A library o f these p h o t o g r a p h i c objects c a n be k e p t i n a database a p p l i c a t i o n f o r use by the facility manager at the appropriate time.  [ H i r o s h i & N o b u o h 93] describe a filing system o f c o n s t r u c t i o n pictures and their integration w i t h a database. T h e p r o p o s e d facilities t u r n o v e r i n f o r m a t i o n system uses this capability o f s u p p l y i n g c o n s t r u c t i o n i n f o r m a t i o n t h r o u g h j o i n t operation w i t h existing databases w h i c h can p e r f o r m multi-phase retrieval and index transaction.  K e e p i n g i n v i e w the i m p o r t a n c e o f i n f o r m a t i o n f l o w , this thesis w i l l also f o c u s o n the different sources o f i n f o r m a t i o n and d o c u m e n t a t i o n used at c o n s t r u c t i o n sites, their purposes, their o r i g i n , destination, and content.  3.4  Information and Information Systems  T h e concept o f i n f o r m a t i o n is related to data, facts and k n o w l e d g e . A fact is something that has happened i n the real w o r l d and that can be verified [ B a r t o n 85]. D a t a are facts obtained t h r o u g h e m p i r i c a l research or observation. K n o w l e d g e is facts o r data represented i n some w a y (e.g., reports, lists, letters, etc) and stored f o r future reference. I n f o r m a t i o n represents data o r k n o w l e d g e evaluated f o r specific use. C o n s e q u e n t l y , facts o r data are processed to provide information.  [ M u r d i c k & R o s s 75] defines i n f o r m a t i o n as "the behavior-initiating stimuli b e t w e e n sender and receiver and i n the f o r m o f signs that are c o d e d representations o f data." [ T e n a h 84] states that i n f o r m a t i o n is behavior-affected data. D a t a differ f r o m i n f o r m a t i o n i n a sense that data are 35  considered signs, usually recorded observations that do not affect the behavior o f men or machines. However, data may become information i f behavior becomes affected. F o r example, the database for computer systems consists o f masses o f such signs that are not affecting behavior. Until data are properly organized for a manager so that he/she reacts to them, they are not information. Thus information management is not just the forms and reports produced. It includes all the data and intelligence, cost, financial, schedule, trend forecast, and control o f a particular project or job, as well as the organization as a whole. [Aoki et al 93] defines information not only as measurement o f data, but also as expertise and construction data collected from previous projects.  3.4.1 Information Management and the Construction Industry [Kang & Paulson 97] state that construction information is generated through various phases o f project implementation and is collected from outside sources for future use. The information is attributed to the functional components o f the facilities or to the construction components o f the operations. It is important to standardize the information so that it can be used as common information throughout the design, construction, and management o f a project. Systematic information enables management o f similar projects by a standardized method and facilities application o f a computer system for information management.  [Rasdorf & Herbert 88] have emphasized the importance o f accurate and timely information for construction project management and status o f project resources. Other issues o f interest in information for project management such as labor and equipment costs have been dealt with  36  by [Pierce 88], building product information by [Coker 85], overseas projects by [Fanous & Samara 94], and project control by [Liu et al 94a].  [Fisher et al 94] stress that project managers must devote a significant portion o f their attention towards management o f information, i.e., ensuring that information is available in a consistent and accurate form and in a timely manner. [Riley & Sebet 94] explain that a construction project involves a large number o f individuals, firms, and organizations and generate a considerable amount o f information. [Fanous & Samara 94] and [Pierce 88] describe that the successful management o f engineering and construction projects require coordination and control o f many diverse activities performed by specialists assigned to the project. Successful coordination and control o f these activities require the project manager and his staff to have access to accurate and current information regarding all facets o f project activities. It is also essential that the specialists in each area o f the project have the information they need from other disciplines in order to perform their own work effectively and maximize their contribution to the project.  [Vanegas 94] emphasizes that during the construction phase o f a building project, the different members o f the project team, namely owners, designers, contractors, and suppliers need to communicate with each other; exchange technical and management data and information; analyze and comment on these information to resolve issues and make decisions; and when necessary, negotiate to reach agreements among all parties. Thus, the quality o f the total project team decision-making and implementation process is a direct result o f the availability and reliability o f information.  37  [Vanier et al 93] describe the importance o f information in the construction industry. They state that the construction industry is information intensive, and needs accurate, reliable and timely information, ranging from building codes and standards, legal requirements, through scientific research, to manufacturers,  product information, site specific data and past  information. They further state that information is becoming more and more urgent and more critical as the projects are becoming more complex and the time frame for decision makers is becoming shorter. According to authors there are many reasons for these changes, including increasingly complex projects, the debilitating cost o f long term projects, shifting demographic and client requirements.  According to [Lock 92], information has always been an important ingredient o f construction management, which relies on relevant data for effective management in all o f its operations. What is new, however, is the increased pressure on managers to process information more effectively and to integrate them with schedules, finance,.market, contractor, and operational data.  [Bhandari 78] states that we are increasingly becoming dependant on meaningful and relevant information for the growth and health o f our endeavors, and for the smooth functioning o f our institutions. Information is one o f the resources not in danger o f exhaustion on the shrinking planet. It is unique because it is limitless. One o f the primary reasons for information having proved to be such a dynamic resource is the fact that there exists a remarkable technological capacity for dealing with it rapidly and effectively.  38  [Burger & Halpin 77] explain that modern complex projects pose new challenges o f information management  for project managers.  The information at the project level is  enormous and traditional methods o f information handling are not adequate to meet the needs o f new management in this environment. Hence, new tools are required between project personnel and the participating groups for the management o f information. It is in the recent years that the construction industry has started to take advantage o f new developments in information technology, particularly in the field o f project and construction management.  3.4.2  Computer Based Information Systems  [Lock 92] states that the purpose o f computer based information systems for engineers is to integrate the collection, processing and transmission o f information so that engineering professionals can gain systematic insight into the operation and functions they are managing. This approach will minimize guesswork and isolated problem solving in favor o f systematic integrated problem solving. It also significantly reduces the labor costs for generating and manipulating data for problem solving.  The computerized information system's primary function is to improve project  managers'  efficiency in retrieving information from existing records [Toker 90].  3.5  Information Model  The design o f a computer based information system for the provision and interchange o f information within a project implies that the real-life project can be modeled in a way that  39  allows functionality in the computer system [Riley & Sabet 94]. This information model should cover the facts about all products and processes needed to construct these products. But  the design o f such an information system represents a major task. This is due to  substantial amount and different types o f information generated within a project, the variety o f project types, the considerable amount o f different experts involved, the complicated links and processes involved in the project and diversity o f client cum facility owners requirements.  [Froese 93] defines an information model as a collection o f information about a specific reallife object, and states that the information model should fulfill the following requirements:  •  General Usefulness: many different applications will use the models for performing different functions.  •  Richness: the model must capture a significant level o f detail.  •  Comprehensiveness: the scope o f the model must include a wide breadth o f project information.  •  Flexibility: flexibility is required both in what information can be represented (e.g., numeric parameters, graphical descriptions, logical relationships, etc.) and in how the information can be used.  40  3.5.1  Entity-Relationship Model  [Kent 89] states that the nature o f information modeling is shaped by the purpose at hand. General models o f knowledge and cognition are the most diverse and debatable, having the least defined criteria for correctness or adequacy. Models and methodologies in support o f current and emerging information processing technologies are tractable, being governed by the forms and capabilities o f such technologies. These approaches can at least be judged by pragmatic measures o f usefulness, i f not correctness.  The Entity-Relationship ( E - R ) M o d e l is one o f the best known tools for logical database design [Goldstein & Storey 89]. It is generally considered to be a very natural, easily understood way o f conceptualizing the structure o f a database. M a n y other researchers have claimed the benefits o f the E - R model, some o f which are: it is simple and easily understood by non-specialists, thus facilitating their active participation in the initial database requirements definition [Konsynski 79]; it is easily conceptualized [Yeo et al 78]; the basic constructs are highly intuitive and thus provide a very natural way o f representing a user's information requirements [Brodie 84].  Entity-relationship diagrams are one means o f formally expressing a data model [Bamford & Curren 91]. Basically, the entity-relationship data model augments a basic network model by introducing a special symbol, the diamond, to explicitly indicate a relationship [McFadden & Hoffer 88]. Figure 3.2 illustrates the E - R data model. Each diamond represents a relationship type; this diamond exists for both 1 : M (one to many) and M : N (many to many) relationships  41  b e t w e e n entities, w h i c h are represented as rectangles. A t t r i b u t e s are associated w i t h entities and represented w i t h an ellipse.  Figure 3.2  An Example of Entity-Relationship Data Model  G e n e r a l l y g r a p h i c a l o r diagram-based object m o d e l i n g techniques c o n v e y m o r e meanings than textural s p e c i f i c a t i o n techniques [ C a r l s o n et al 89]. H o w e v e r , d i a g r a m techniques are not w i t h o u t their p r o b l e m s . [Feldman & M i l l e r 86] c l a i m that " the usefulness o f any d i a g r a m is inversely p r o p o r t i o n a l to the size o f the m o d e l d e p i c t e d . " It has also been n o t i c e d that a modest size database such as the Facilities T u r n o v e r system contains t o o m a n y  semantic  connections b e tw e e n objects f o r easy c o m p r e h e n s i o n . E v e n i f t o o l s to display a c o m p l e t e E-R m o d e l are available, the limitations i m p o s e d by the screen size restrict the n u m b e r o f available objects w h i c h can simultaneously be displayed. T h e ability t o shrink, z o o m , e x p a n d o r p a n the E-R d i a g r a m offers a limited s o l u t i o n to this, the database design layout p r o b l e m .  [ F e l d m a n and M i l l e r 86] p r o p o s e d u s i n g multi-level E-R problems. A  multi-level E-R  diagrams t o deal w i t h the above  m o d e l is a hierarchy o f successively m o r e detailed entity  42  relationship diagrams, with a lower-level diagram appearing as a single entity type on the next higher-level diagram. The above authors described their approach as the Nested E - R model. The basic terminology o f Nested E - R model is given as follows. A simple Entity is a collection o f simple attributes. It is graphically denoted by a single lined rectangle. A simple relationship  is also a collection o f simple attributes which describe a semantic  connection between entities. It is pictorially represented by a diamond. A complex attribute is defined by a lower level entity or relationship and is represented by a double lined oblong. A complex entity is defined by a lower-level Nested E - R diagram together with a collection o f simple and complex attributes which may be derived from the lower level diagram. The pictorial representation o f a complex entity is denoted by a double lined rectangle. A complex relationship  amongst various entities is defined by a lower-level Nested E - R  diagram involving the same entities, together with a collection o f simple and complex attributes which may be derived from the lower-level diagram. A complex relationship is graphically denoted by a double lined diamond.  Nested  E - R model  supports traditional  abstraction  techniques  such  as  aggregation,  generalization and association [Teorey et al 86].  3.5.2  Structural Data Model  Selecting a data model to represent design data and processes forms a major step towards the development o f an integrated system [Law & Scarponcini 91]. A data model is a collection o f  43  well defined concepts that help the database designer to consider and express the static properties such as objects, attributes and relationships and the dynamic properties such as operations and relationships o f data intensive applications. In addition to facilitating the design o f database design process, a data model needs to provide the integrity rules to ensure consistency among the entities.  The ultimate objective o f the semantic modeling activity is to make systems more intelligent [Date 90]. The aim o f selecting a semantic data model is to represent directly, and in an easy form as many o f the objects and their relationships o f interest as possible. The structural data model (example shown in figure 3.3) that is used is an extension o f the relational model [Law & Scarponcini 91]. Relations are used to capture the data about objects and their parts. The structural data model augments the relational model by capturing the knowledge about the constraints and dependencies among the relations in the database.  The primitives o f the semantic data model are the relations (which roughly correspond to entities in E - R model and the connections formalizing relationships among the relations. There are three basic types o f connections, namely ownership, reference, and subset connections [Law & Scarponcini 91].  44  Relationship  Ownership  Symbol  Employee  Employee Reference Subset  Employee  Figure 3.3  Insert/Delete Constraints  Skills  Dept.  Skills need employee/skills go with employee Employee needs department/department stays  ^Salesman  Salesman must be employee/salesman goes with employee  Structural Data Model Example  [Law & Scarponcini 91] has explained the structural data model as follows:  The connection between two relations R l and R 2 is defined over a subset o f their attributes X I and X 2 with common domains. A n ownership connection between an owner relation R l and an owned relation R 2 describes the dependency o f the multiple owned tuples on a single owner tuple. The ownership connection implies that the owned tuples are specifically related to and dependent on a single owner tuple. A s an example, a facility consists o f systems such as architectural systems, mechanical systems, electrical systems etc. The component systems exist only i f the facility exists. This type o f connection specifies following constraints:  •  Every tuple in R 2 must be connected to an owning tuple in R l .  •  Deletion o f an owning tuple in R l requires deletion o f all tuples connected to that tuple in R 2 .  45  •  M o d i f i c a t i o n o f X I in an o w n i n g tuple requires either p r o p a g a t i n g the m o d i f i c a t i o n t o attributes X 2 o f all tuples in R 2 or deleting those tuples.  A  reference  connection  between  a primary  (referencing)  relation R I  and a foreign  (referenced) relation R 2 describes the dependency o f m u l t i p l e p r i m a r y tuples o n the same f o r e i g n tuple. A s a n example, an architectural space, w h i c h m a y b e a n office, elevator, o p e n i n g , etc., is located o n a floor. T h e f l o o r cannot be r e m o v e d w i t h o u t first r e m o v i n g the space defined o n that f l o o r . T h i s c o n n e c t i o n type specifies the f o l l o w i n g constraints:  •  E v e r y tuple i n R 2 must either be connected t o reference tuple i n R I o r have n u l l values f o r its attributes X I .  •  D e l e t i o n o f a tuple i n R 2 requires deletion o f its referencing tuples i n R I , assignment o f null values t o attributes X I o f all the referencing tuples i n R I , o r assignment  o f n e w v a l i d values t o attributes X I  o f a l l referencing  tuples  c o r r e s p o n d i n g t o an existing tuple in R 2 .  •  M o d i f i c a t i o n o f X 2 in a referenced tuple R 2 requires p r o p a g a t i n g the m o d i f i c a t i o n t o attribute X I o f all referencing tuples i n R I , assigning null values t o attributes X I o f all referencing tuples in R I , or deleting those tuples.  A subset connection  between a general relation R I and a subset relation R 2 l i n k s general  classes to their subclasses and describe the dependency o f a single tuple i n a subset o n a single  46  general tuple. F o r example, a structural element can either be a beam, column, wall or slab. Furthermore, a beam can be specialized to be either a main girder or a joist. Deleting a specific instance in a generic class o f structural element must delete the corresponding instance existing in the subclass. The subset connection specifies the following constraints:  •  Every tuple in R 2 must be connected to one tuple in R I  •  Deletion o f a tuple in R I requires deletion o f the connected tuple in R 2 .  •  Modification o f X I in a tuple o f R I requires propagating the modification to attributes X 2 o f its connected tuples in R 2 or deleting the tuple in R I .  3.6  User Interface  [Beynon-Davies 93] describes the user interface as everything concerning the human side o f information systems, an area sometimes referred to as human factors. In another more limited sense, the user interface is usually defined in terms o f screen based interfaces to information systems.  [Schneiderman 92] defines five broad categories o f interface:  •  Menu: This consists o f a displayed list o f choices. The user chooses an item from the list either by pressing some key or moving a cursor to the relevant choice and pressing the enter key. 47  •  Forms: Forms are normally used for data entry purposes, although many systems also use them for data retrieval.  •  Command Language: In this form o f interface the user enters statements in a formal language in order to carry out functions. Traditional operating systems such as M S D O S use a command language.  •  Natural Language Interface: So-called natural language interfaces are not truly natural language since they cannot accept any everyday English input. However interfaces that can interpret natural language inputs within certain narrow ranges have achieved some success as a front-ends to databases [Beynon-Davies 91].  •  Direct Manipulation Interface: This form o f interface is generally associated with  icon-based,  windows environments.  They  are  referred  to  as  direct  manipulation because the user causes events to happen by manipulating graphic objects via mouse-based actions.  3.7  An Integrated Approach to Facility Management  About a decade ago, the United States National Academy o f Science's National Research Council Building Board ( B R B ) recommended to the Federal Construction Council that an integrated database ( I D B ) was a cost effective way o f managing facilities [Scarponcini, 96]. B y looking across the entire life cycle o f the facility, it was determined that an automated approach to capturing and utilizing information generated during the various life-cycle phases  48  could result in considerable savings for the facility owners. With 85%of the cost o f a facility occurring after it is built, it was believed that the additional cost o f capturing information needed for maintenance and operation during the design and construction phases would be significantly offset by the resulting lower cost o f maintaining the facility [Scarponcini 96].  A computer-based systematic approach to facility management has become practical only very recently [Hammer 88]. Various situations have resulted in the dramatically increased interest in this area. Firstly, facility management is gaining recognition as a business function and is thus becoming a high priority for  computer  applications. Historically,  top  business  management has identified facility management with building maintenance. Recently, however, facilities have begun to be viewed, along with people, capital, and technology, as a strategic business resource.  Despite the increased attention being paid to facilities management by top management personnel and availability o f software, the major organizations only recently have begun to install and utilize computer-based facilities management systems [Hamer 88].  3.7.1  Computer Aided Facility Management Applications  Facility management automation is the application o f computer systems including, hardware, software, databases, and procedures, as aids to performing facility management functions. [Teicholz 92] lists the following as the facility management functions:  •  Long-range facility planning 49  •  Annual facility planning  •  Facility financial forecasting and budgeting  •  Real estate acquisition and/or disposal  •  Interior  space  planning, workplace specifications, furniture  and  equipment  installation, and space management •  Architectural and engineering planning and design  •  N e w construction and renovation  •  Maintenance and operations management  •  Telecommunications integration, security, and general administrative services  Automation solutions for facility management attempts to address some or all o f the functions o f facility management. According to [Teicholz 92], there are three basic approaches to the implementation o f an automated facility management system. The first approach is classified as a "hands off' approach. The facility professional can use non-facility department computers to accomplish some or all o f the department's tasks. A s an example o f this method, a facility department contracts with a service bureau to create an integrated corporate facility database and then provides the service bureau with lists, reports, drawings etc. on a regular basis, showing changes that have occurred since the database was last upgraded. The bureau makes the changes, and returns the drawings and reports to the facility department.  The second approach is a "wet-foot" approach. With this approach, the facility managers make use o f organization's computing facility for data analysis and reporting. B y using this method, the facility managers, even without very sophisticated computing skills, can perform  50  routine functions such as the use o f general-purpose database or spreadsheet software to automate specific non-integrated facility management functions.  The third approach has been termed as the "plunge" method. This approach is in keeping with the goals o f this research project. The organization decides to acquire or develop its own integrated Computer Aided Facility Management ( C A F M ) system. The decision depends on the financial  and personnel resources that will be committed to  automation  o f the  organization. This approach usually involves something larger than a P C .  3.7.2  Zoser Systems Group  This project draws from work carried out by the Zoser systems group located in San Jose, California who have also attempted to develop a facility management turnover system. In order to design their system the data model was developed by a group o f designers led by D r . Thomas Froese, Assistant Professor in the Department o f Civil Engineering at University o f British Columbia, Vancouver. This data model was based on object-oriented data model concepts as opposed to the relational schema proposed in this thesis. The Zoser data model is described in the form o f a series o f reports. These include:  •  A list of Units of Functionality ( U o f F's): A listing o f the units of Functionality, which are the concepts or topics addressed by the data model.  •  A U of F Report: A report o f the details o f all Units of Functionality.  •  A n Entity List: A list o f all the entities in the system.  •  A Nested Entity List: A list o f all entities organized in a specialization hierarchy. 51  •  A n Inherited Attributed List: A list o f all entities along with all o f the attributes defined for or inherited by the entity.  •  A n Entity Report: A complete report o f all entities along with full description and full details o f all attributes for each entity.  •  A n Issues List: A listing o f issues raised during model development.  •  A Modification List: A chronological list o f modification made to the data model.  Some o f the features and functions o f facilities management turnover system as claimed by Zoser Systems Group are listed as follows:  •  Automated links from one specific data information source to another will be provided where data relationships exist. M u c h o f the project development data will be interrelated by the work breakdown structure ( W B S ) .  •  The system will be highly stable, portable and scaleable across Microsoft platforms. It will be developed to operate on multiple platform environments such as Unix, N T , Windows 95 and Novell.  •  F M T S will be developed in object oriented programming and methodology to produce the following benefit:  •  Easily maintained and flexible enough to change with business requirements.  •  Use pre-constructed object libraries to enhance development cycle.  •  F M T S will be an open architecture system, compliant with O B D C (open database connectivity) and O L E (object linking). F M T S will establish hooks into third party products and all major databases.  52  •  A user-friendly G U I interface will be provided.  •  F M T S will be developed using J A V A and Visual C  + +  . These tools are effective,  stable, widely accepted and widely used. •  The system will be able to zoom into memo field o f a world processor.  •  The system will provide ability to customize interface screens and data fields.  •  A comprehensive query capability will exist that allow all available information on a particular item to be gathered and printed in one report.  •  The estimate  module will  have  interfaces  to  major  scheduling programs,  A U T O C A D , engineering, cost control, accounting, external estimating programs, commercial spreadsheets, word processors. •  W o r k task can be easily coded with a W B S code.  A t the start o f my research project it was envisioned that a joint research effort would be made with Zoser Systems Group and myself to take part in the development and testing o f Zoser's F M T S . But due to circumstances beyond my control the Zoser F M T S prototype was not ready for use at the time o f this project. This situation led me to work independently to develop my own data model, (based, in part on some o f the Zoser concepts) transforming the data model into relational schema and its implementation into a relational database management system.  53  3.7.3  C A F M Market and Related Works  C A F M is presently an active area as far as software vendors are concerned [Teicholz 92]. N e w software products are being introduced with increasing frequency. Some o f the related works in computer aided facilities management systems and their capabilities are listed in table 3.1 and a complete listing is provided in Appendix D .  Table 3.1  A Partial List of C A F M Vendors  (Source: Automation M a y 1996 pp. 38-48) CAFM  g  '3  •a o o  a •a  Company Name  •a 3  Software Name/Model  m •a  Operating System Accugraph Corp.  ~3 si  o  CO  B o  s  3  8  00  CO  S3, a, co  U  Mountain Top HP; SUN; I B M  W  A E C Data Systems, Inc  W  Facility Management  &  D E C ; HP; IBM; S U N  U  American Computer Software  D  Property Management Series  &  PC  W  54  1  1  2  2  1  2  2  2  1  1  1  1  1  2  1  1  2  2  2  1  Platform  2  Telecommunication sJ Cable  U;  1  a o  Space Inventory Man agement  D E C ; HP; I B M ; SGI; S U N  1  CO  Space Allocation/ Foi recasting  1  1  -*-» o  Security  D;  Room Scheduling  Autodesk, Inc.  Maintenance/Operati  1  Lease/ Property Management  W  Operating System  Integrated CAFM  1  Software Name/Model  Furniture Inventory  Construction Management  1  Company Name  Facility Budgeting/C  Architecture/ Interior• Planning  M  CAFM  Apple Computer Inc. MAC  A R C H I B U S , Inc.  2  A R C H I B U S / F M 10 PC 2  W Bentley Systems, Inc.  D;  MicroStation  M;  1  1  D E C ; HP; IBM; ITG; M A C ; P C ; U ; SUN  W  CADapult Ltd.  D;  CADapult F o r Windows  W  1  2  2  2  2  2  1  1  2  PC  •  Facility Management Applications:  •  Platform: D=DOS; M = Macintosh; U = UNIX;  l=Primary Application; 2=Secondary Application  •  Operating Systems: D E C = D E C Non PC; HP = Hewlett-Packard, Series 9000; IBM= I B M Non-PC  W= Windows; 0= Others  Model; ITG= I N T E R G R A P H ; PC= I B M P C / Compatible; M A C = Macintosh; SGI = Silicon Graphics INC; S U N = S U N SPARC Station; 0=  Others  55  It can be seen from the table 3.1 that all commercially available systems are capable o f performing a part o f facility management functions as listed at section 3.7.1. Only one system developed by A R C H I B U S , Inc. known as A R C H T B U S / F M 10 is capable o f performing the maximum number o f functions. Although the author was not able to work directly with the systems listed in Appendix D , it was established by analyzing the reported capabilities o f the commercial systems that none o f these systems have claimed the capability o f handling the facilities turnover process. After determining this aspect it was considered desirable to design a data model and develop a prototype for handling the facilities turnover process.  56  CHAPTER 4: ADVANCED MATERIALS AND PROCESS ENGINEERING LABORATORIES (AMPEL) 4.1  Introduction  The Advanced Materials and Process Engineering Laboratories which are located at 2355 East M a l l , University o f British Columbia, Vancouver, Canada, is a high-tech engineering laboratory facility established to conduct research and development in micro-structural engineering, powder metallurgy, single crystal materials, surface interface characterization and analysis, polymer characterization, low temperature magnetism and superconductivity, alloys and  intermetallic  technology,  components,  thin film  integrated  technology,  surface  opto-electronics physics  and  and  infrared  femtosecond Raman  optical  spectroscopy,  superconducting ceramics and inorganic polymers, and molecular beam epitaxy ( M B E ) . M o s t of the information provided in this chapter has been acquired from Facilities Program Technical Appendices prepared by Advanced Planning and Research for Architecture ( A P R A 92).  4.2  Organizing Concept of the A M P E L Building  Laboratory spaces and the necessary support and administrative spaces that together comprise the space utilization program for the building have been organized into seven domains. In the vision o f developers o f this project, the building plan and spatial organization should reflect this organization model. Domains one through five makes up the laboratory areas o f the building. The seven domains are shown in figure 4.1.  57  Standard Dirty Lab  Group 1 Standard Lab High Head Dirty Labs  2 1  Support Services  Group 2 Standard Labs  7  6  Administration & Faculties  Figure 4.1  Standard Clean Rooms  The A M P E L Seven Domains  58  4.3  A M P E L : The Seven Domains  A M P E L has been divided into seven functional areas which have been designated as seven domains for the purpose o f this thesis. These domains are explained as follows.  4.3.1 Domain 1: High Head Dirty Laboratories The H i g h Head labs enable pilot scale operations o f large equipment that might often be found in an industrial environment. They place high demand on services such as electrical power, natural gas and water, and generate dust and vibration. T w o labs in this domain are high head but not dirty and are self contained within the high space.  4.3.2 Domain 2: Standard Dirty Laboratories Standard Dirty laboratory provides for smaller plants, and for the fabrication and testing o f large assemblies. This is also an industrial environment. This lab places high demand on services such as electrical power, natural gas and water. It also generates dust and vibration. They are isolated in the building together with other "dirty" laboratories. Floor to floor height in this domain is 4.0 metres.  4.3.3 Domain 3: Standard Laboratories Group one Standard laboratories, group one is required for tall pieces o f floor mounted equipment that must be isolated from areas generating dust and/or vibration. Floor to floor height in this domain is 4.0 meters.  59  4.3.4  Domain 4: Standard Laboratories Group Two  Standard laboratories, group two space is typical o f university research laboratories, although with a high proportion o f floor mounted equipment, some o f it rather tall (3.0 m). This domain represents the largest single category o f space in the program and should have the potential for the highest degree o f flexibility. It supports both standard and special laboratory uses. These standard laboratories are developed by combining generic laboratory modules with a clear overhead height floor to floor o f 4.0 m (13.0 feet).  Several laboratories in this domain contain large furnaces requiring gas supply and venting. Smaller adjacent support spaces are required in most cases to accommodate noisy and/or dangerous equipment and materials such as vacuum pumps and bottled gases. These gases are toxic and flammable in some cases and require separate storage, exhaust and disposal systems.  Micro-electric laboratories in this category require the provision for modular filtered air supply units over individual pieces o f equipment, and generally, will create a high demand for supply air. Some labs contain modular rooms that are electro-magnetically shielded.  Equipment in these laboratories has a low tolerance for structural vibration generally, and in many cases requires additional isolation at the equipment itself. Because o f extremely sensitive nature o f much the apparatus in this domain with respect to vibration, a location on grade is preferred by many o f the researchers involved. Also, some o f the research utilizes equipment that requires deep wells below the floor level under the equipment.  60  4.3.5 Domain 5: Standard Clean Rooms Clean rooms are developed in shell space similar to standard laboratories and comprise a suite o f modular laboratories and service space that provide a clean environment. They are placed adjacent to the standard Group 2 lab modules so that the possibility exists to expand the clean room component in the future. Smaller adjacent support spaces are required in most cases to isolate noisy equipment and handle potentially dangerous process gases. These labs are isolated from structural vibration generally, and in many cases require additional isolation at equipment level. Because o f extremely sensitive nature o f equipment in this domain with respect to vibration, a location on grade is most desirable. Minimum overhead clearance is 4.0 m floor to floor.  4.3.6 Domain 6 & 7: Support Services and Faculty Rooms  These domains are comprised o f office room space for administrative staff and faculties.  4.4  A Brief Description of Various Laboratories  A brief description o f various laboratories in A M P E L is given in the following sections.  4.4.1 High Head Dirty Laboratories H i g h Head Dirty Laboratories accommodate a range o f research activities for metallurgical and process engineering applications. Seventy percent o f the floor area have a clear overhead height to structure o f 8.0 m. The remaining 30% is developed with a 4.0m height, as these 61  spaces serve as support space to the high head labs including instrument rooms, graduate student and technician work areas and storage. This space is suitable for setting up pilot plant scale equipment that requires high headroom. High Head laboratories in the composites area are in fact not "dirty". One o f these labs is a controlled environment room. B o t h labs in this group contain tall equipment and require the high head space.  4.4.2 Pyrometallurgical Processing Pyrometallurgical processing involves pilot plant studies in the new A M P E L building and off site plant equipment studies. This discipline occupies laboratory space in the H i g h Head/Dirty and standard dirty areas. Pilot Plant research is carried out in the flash smelting laboratory and the new electric smelting laboratory. The bath smelting, gas injection phenomena, and slag cleaning studies are conducted in the industry with some links to the pilot plant laboratories and physical plant laboratory.  Flash smelting, electric smelting, and the kiln laboratories are grouped together around a shared equipment control room. This space provides a central, lockable, environmentally control area for the equipment controls, data acquisition equipment, technician w o r k areas and tool storage.  4.4.3 Microstructural Engineering (Pilot Rolling Mill Facility) The intention o f the developers is to develop a new pilot rolling mill facility at A M P E L building to conduct research and development o f rolling processes and rolled materials. The  62  mill simulates industrial production conditions and provides automatic control o f mill operations, and ancillary facilities for controlled re-heating prior to rolling and phase transformation monitoring during or following completion o f rolling. The new facility operates as a hot mill in a two-high, single stand, reversing configuration. The mill can also operate as a cold mill in four-high configuration with work rolls o f 160 mm diameter.  4.4.4 Composites The Composites discipline occupies laboratory space in the H i g h Head and M e d i u m Head areas. The Pressure Tester and the controlled Environment Laboratory are in this location because o f the high head requirement; not because the process is dirty. The composite Processing laboratory contains six separate functions under this general heading. These functions include the Fibre Treatment Line, Layup and PrePegging R o o m , Chemical WetLaboratory plus Storage  Room,  Instrumentation  and  Control R o o m  for Autoclaves,  Autoclave/Hot Press R o o m and Specimen Machining and Preparation R o o m . Each function requires a separate enclosed work area. The linear interrelationship between the functions is critical, considering that this laboratory is used to study the influence o f processing on the mechanical behavior o f composites.  4.4.5 High-Temperature Combustion Research Facility In the high temperature combustion research laboratory, the study o f emissive and heat transfer  characteristics o f the flames is conducted. The data is incorporated into the  mathematical models being developed for various industrial furnaces.  63  4.4.6  The  Powder Metallurgy (Plasma Processing)  overall  objective  o f the  powder  metallurgy laboratory  is to  develop  detailed  understanding o f the combustion process and ultimately, a mathematical/computer model. Research in this area is similar to flash smelting except the equipment is laboratory scale and the duration o f the activity is shorter. This equipment utilizes a controlled electric arc to generate a 2000-3000° C high temperature ionized gas. The materials start as powders and the result o f the fast reaction is approximately 1.0 kg o f material out o f the bottom o f the unit.  4.4.7  Fabrication of Ceramic Components Laboratory  In the ceramic component laboratory research is conducted for the development o f fabrication techniques for complex ceramic engine components. The fabrication techniques include cold and hot pressing and hot isostatic pressing techniques as well as injection moulding.  4.4.8  Shared Advanced Metals Facility (Solid Preparation Laboratory)  A l l crushing and grinding equipment is installed in this one area. This equipment would be available for sample preparation for various advanced metallurgical processes. The solids preparation laboratory requires a crushing and screening area o f 37.0 m , and a drying area o f 2  9.0 m . A n outdoor covered solids storage area o f 28.0 m is provided to hold 4-20 barrels o f 2  2  material from industry for flash smelting.  64  4.4.9 Shared Advanced Metals Facility (Physical Modeling Laboratory) One o f the research tools available to study metallurgical process is use o f scale models o f physical plants. The physical modeling laboratory is used to build and study a wide variety o f physical plant models with the measurements being applied to elucidate the fundamentals. M o d e l experiments are employed to investigate process variables, to develop mathematical models, and to provide strategies to improve plant efficiencies.  4.4.10 Computer Facility The  computer laboratory contains the Silicon Graphics computer server and central file  storage facility. The laboratory is used by all research disciplines for data analysis and development o f mathematical models. The laboratory is in two parts, a computer room o f 10.0m , and a workstation area o f 21.0m . 2  2  4.4.11 Surface Analysis and Structure The  chemical characterization o f structures and interfaces occupies a central position in  advanced materials research, including polymer adhesion, catalysis, electrode  processes,  metallic corrosion, composite bonding, ceramic sintering, dental materials, and w o o d and paper technology. The Surface Analysis and Structures laboratory in the A M P E L undertakes basic research in all these areas.  65  4.4.12 L E E D & Auger Electron Spectroscopy  The L E E D & Auger electron spectroscopy laboratory carries out research on the structure o f significant surfaces o f single crystal materials at the atomic level.  4.4.13 SIMS & SAM  The S I M S and S A M laboratory carries out specialized surface/interface characterization and analysis. Scanning Auger Microscopy ( S A M ) provides analysis at much higher spatial resolution and Secondary Ion Mass Spectrometry ( S I M S ) provide much higher sensitivity for trace element analysis with dynamic S I M S and polymer surface characterization with static S I M S . This equipment has critical environmental requirements for low floor vibration.  4.4.14 X-ray Photoelectron Spectroscopy  X-ray photoelectron spectroscopy is a key analytical technique for characterizing chemical composition and chemical state within the surface regions o f materials. This facility combines a number o f special features, including a mono-chromatized X-ray source, i o n scattering spectroscopy and sample preparation chamber.  4.4.15 Laser Desorption Microprobe FT-ICR Spectrometer  F T - I C R is an analytical technique for characterizing chemical composition that can detect impurities within the surface regions o f materials. This facility is used for impurity tracing in  66  semi conductors and requires two major pieces o f equipment. The first is a pulsed power laser source using mirrors and the second is a sample vacuum chamber.  4.4.16 Polymers (Polymer NMR and ESR Spectroscopy and Imaging)  The Polymer laboratory houses a program in high resolution magnetic resonance studies for polymer characterization. This equipment is used to provide a fundamental understanding o f physical, mechanical and electronic properties o f polymer materials.  4.4.17 Magnetism  The magnetism facility consists o f two separate research areas, L o w Temperature Magnetism and Superconductivity, and N M R (the study o f single crystals o f metals, alloys and intermetallic components by nuclear magnetic resonance) o f metals. These two laboratories require a sample preparation area.  4.4.18 Opto-Electronics  The Opto-electronics facility consists o f two research areas, integrated opto-electronics and femtosecond Optical Technology.  4.4.19 Superconductivity  H i g h Temperature Superconductivity research consists o f material preparation and analytical facilities. The analytical facilities are composed o f the following five specialized laboratory  67  areas: Magnetometer  Room,  Microscopy  Room,  Transport  and  Thermal  Properties  Measurement Laboratory, High Field Magnet Laboratory and Microwave Measurement Laboratory.  4.4.20 Thin Film and Surfaces The Thin Film Technology Laboratory is used to develop new processes and specialized equipment for the fabrication o f industrial coatings, such as optical multilayers, high temperature superconductors, and wear resistive coatings. Four Coater System areas are grouped around a central pump room.  4.4.21 Surface Physics The principal focus o f Surface Physics is research into electronics, optical and structural properties o f surfaces and thin films made by Molecular Beam Epitaxy and other techniques. This research requires two separate laboratories.  The Surface Physics laboratory is in the  proximity o f other surface analysis facilities and the scanning electron microscope while the Molecular Beam Epitaxy lab is located adjacent to the clean rooms.  4.4.22 Semiconductor Processing This laboratory houses a collaborative program with scientists in the Chemistry/Physics Department characterizing solid materials including super-conducting ceramics and other inorganic polymers.  68  4.5  A M P E L Project Systems  F o r the purpose o f this thesis, the A M P E L facility has been divided into three major systems. Based on classification adopted by the author, these systems would further be divided into sub-systems for their mapping into the database.  4.5.1  •  Architectural System  •  Mechanical System  •  Electrical System  Architectural System  Architectural System has been divided into following Sub-systems:  i  •  General Requirements  •  Site W o r k  •  Concrete  •  Masonry  •  Metals  •  W o o d and Plastics  •  Thermal and Moisture Protection  •  Doors and Windows  •  Finishes  •  Specialties  69  •  Equipment  •  Furnishings  •  Special Construction  •  Conveying Systems  4.5.2  Mechanical System  A M P E L is a fairly complex project as far as the number o f mechanical systems and instrumentation is involved. Figures 4.2 to 4.6 show the schematic drawings o f some o f the mechanical systems installed and commissioned at A M P E L . The mechanical systems installed in this project have been further subdivided into following sub-systems:  •  Domestic Water Subsystem  •  Sanitary and Acid Drainage Subsystems  •  Storm Drainage Subsystem  •  Fire Sprinkler Subsystem  •  Natural Gas Subsystem  •  Fuel O i l Subsystem  •  Steam/Water Heating Subsystem  •  Chilled Water Subsystem  •  Ventilation Subsystem  •  Exhaust A i r Subsystem  •  Control Subsystem  70  •  Compressed Air Subsystem  A brief description of these subsystems is provided in the following sections:  4.5.2.1 Domestic Water Subsystem  Water for building's domestic water service is provided via a 200mm combined fire/domestic water service pipe which enters the north-east corner of the building basement. The main pipe continues southward to the basement mechanical room where the pipe connects to both the fire sprinkler valve station and the domestic water entry station. The domestic water entry station consists of a shut-off valve, strainer, water meter, backflow preventor, booster pumps, and pressure regulators which provide domestic cold water at both 400 kPa and 600kPa. The lower pressure domestic cold water is supplied to the domestic water heating tank, which is located in the basement mechanical room, and to the plumbing fixtures throughout the building. The high pressure water is piped to supply the equipment and fixtures in the high headroom laboratory along the West side of the building.  The domestic cold water which is supplied to the water heater, is heated by a steam heated heat exchanger installed in the tank. The domestic hot water from the tank is provided to the fixtures throughout the building. The main domestic hot water supply pipes have recirculation pipes connected to allow unused water to be returned to the water heater via pump P-14, which is also located in the basement mechanical room.  71  4.5.2.2  Sanitary & Acid Drainage Subsystems  The waste water from the washrooms and janitor room plumbing fixtures on the main and upper floors o f the building is drained via sanitary drainage piping that runs through the ceiling space o f the basement. The main 150mm sanitary drainage pipe exits the West side o f the basement at the North end o f the high head laboratory. The sanitary piping from the washroom fixtures and floor drains o f the basement area are piped to a sanitary sump located in the basement mechanical room. The sanitary sump is equipped with pumps P-24 and P-25 which operate automatically to pump the waste water to the main sloped sanitary drainage piping that exists from the North-West corner o f the building.  The waste liquid from the laboratory sinks in the main North-East section o f the building is carried by acid waste drainage piping that drains into an acid neutralizer in room 5 o f the basement. The acid neutralizer is comprised o f three main tanks, an acid storage container, a caustic storage container and final monitoring tank. The neutralizing system operates automatically to mix the incoming acid waste liquids with caustic or acid as required to maintain P H levels. The mixture is then allowed to drain into the building's main sanitary drainage piping.  The hazardous materials storage rooms, 127A to 127F, have their floor drains piped to two underground storage tanks, T K - 2 and T K - 3 , located just outside the East side o f the receiving area. A n y liquid which is spilt in the rooms and drains into the tanks is contained within the storage tanks until it is pumped out.  72  4.5.2.3  Storm Drainage Subsystem  Water from the building's roofs is carried through the building via rain water leaders that connect to the main storm drainage piping of the building. The main storm drainage pipe exits the building from under the North-West section of the building and runs Westward to connect to an existing storm manhole at the West side of Engineering Road.  Perforated piping has been installed around the foundation and under the basement floor slab. The perforated pipes allow ground water to drain to two sediment sumps, one (SS-1) is located in the airwell area at the South side of the East section of the building, and the second (SS-2) is located on the West side of the building. Water collected into SS-2 is drained into the existing storm drainage system under Engineering Road. The water collected into SS-1 is drained via storm drainage piping that runs into a storm sump located in the basement of the mechanical room. The sump also collects water from the elevator and electrical pull pits and the perforated drainage pipes under the basement. The sump is equipped with pumps P-22 and P-23 and water which is collected in the sump is automatically pumped to sloped storm drainage pipes that exit the building and drain into the existing storm drainage system under Engineering Road.  4.5.2.4 Fire Sprinkler Subsystem  Water for the fire sprinkler system is provided to the building via the same pipe that supplies domestic water to the building. The pipe connects to the fire sprinkler valve station which is  73  located in the basement mechanical room. The valve station is equipped with a double check valve assembly, fire pump (P-26), jockey pump (P-27), pressure switches, wet alarm valve and excess pressure pump (P-21). The main sprinkler pipes are connected to a fire department connection, located outside the main north entrance to the building, which allows water to be pumped into the building's sprinkler system. The piping from the valve station is connected to stand-pipe risers in the main corridors o f the building where fire hose cabinets and the zone control valves are located. The building's fire sprinkler system is divided into separate zones which provide protection to the various floors and sections o f the building. The control valve station for each sprinkler zone is equipped with a zone shut-off valve, a test & drain station and a flow switch that is wired to the fire alarm panel. Quick response sprinkler heads are provided throughout the building.  4.5.2.5 Natural Gas Subsystem  A 100mm pipe has been connected to the natural gas supply piping under Engineering R o a d to provide natural gas to the building. The pipe to the building connects to a gas meter and a seismic gas valve which will automatically shut off gas supply to the building i f an earthquake occurs. The gas supply pipe enters the West side o f the building at the N o r t h end o f the basement and runs Westward through the ceiling space o f crawlspace/corridor 43. The pipe connects to two pressure regulators which provide low pressure gas to the laboratory work stations and a third branch pipe provides gas to the three roof-top heating and ventilation units, R T U - 1 to R T U - 3 . Each o f three branch pipes to the units is equipped with a separate pressure regulator.  74  4.5.2.6  Fuel Oil Subsystem  A n underground storage tank, T K - 1 , has been installed South o f the South-East Corner o f the building to store diesel fuel for the electrical generator which provides emergency electricity to the building. P-31 is a Viking M o d e l C-432 transfer pump which is connected to the tank and supplies the fuel to generator. A return pipe allows unused fuel to drain back into the tank. A leak detection monitor panel has been installed in the basement mechanical room to provide information on fuel level and an alarm i f a leak occurs.  4.5.2.7  Steam/Water Heating Subsystem  Steam from the campus' central heating plant is provided to the building to provide heating water for the building, and the condensate from the building is returned to the central plant. The steam supply pipe enters the building at the North-East corner, running through the Northern crawlspace and basement corridor 40, and finally entering mechanical room 46 to connect the steam pressure reducing station and heat exchangers o f the building. The steam pressure regulator station consists o f steam separator, shut-off valves, strainers, pressure regulators, by-pass valve and steam meter. The low pressure steam from the station is piped to heat exchangers H E X - 1 H E X - 2 , the domestic water heater, the chiller and the heating coils and humidifiers o f the building's main air handling units.  Condensate from heat exchangers H E X - 1 and H E X - 2 is piped through heat exchanger H E X - 3 which preheats the heating water return before it is piped to a condensate receiver, located in  75  a pit in the basement mechanical room, which pumps the condensate back to the central steam plant.  Heated water is circulated through the secondary side of heat exchanger HEX-3 and then HEX-1 and HEX-2 and to the radiant panels and reheat coils via pumps P-l and P-2 which operate in parallel. The pumps are located in the basement mechanical room adjacent to the heat exchangers.  4.5.2.8  Chilled Water Subsystem  A York Model YTA-ST-3J33-58 steam absorption chiller, CH-1, has been installed in the basement mechanical room, and two Baltimore Aircoil Model VTO-141-NRC cooling towers, CT-1, & CT-2, have been installed on the roof, at the North-West corner of the building, to provide chilled water to the cooling coils of the building's main air handling units. In addition to the chiller, heat exchanger HEX-4 has been installed in the basement mechanical room and is also connected to the cooling towers to provide " free" cooling to the chilled water system.  Pumps P-3 and P-4 circulate the chilled water returning from the cooling coils of air handling units AHU-1 to AHU-3 through heat exchanger HEX-4 and through chiller CH-1. The chilled water from the heat exchanger and chiller is then pumped back to the cooling coils of AHU-1 and AHU-2 via pumps P-5 and P-6, while P-7 pumps the chilled water back to the cooling coil of AHU-3. Condensate water is circulated from the chiller and heat exchanger to the  76  cooling towers via pumps P-8 and P-9. A l l o f the pumps, P-3 to P-9, are located in the basement mechanical room.  4.5.2.9 Ventilation Subsystems  The building's main air handling units, A H U - 1 and A H U - 2 , are located in the penthouse mechanical room. They are each packaged Scott Springfield units comprised o f outdoor air damper, filter section, heating coil, cooling coil, cooling coil by-pass damper and supply fan with an automatic damper installed on the supply air ductwork o f each unit. These isolation dampers allow one unit to supply air to the entire system while the other unit is shut off for servicing. The units each blow conditioned air to main risers which feed the air to common ducts running through the corridor to variable air volume boxes which provide air to the labs and offices o f the main to fourth floors.  A i r handling unit A H U - 3 is also located in the penthouse mechanical room and it is equipped with an outdoor air damper, filter section, heating coil, cooling coil, and supply fan. Steam humidifier unit H - l has been installed to provide additional humidity to the air supplied from A H U - 3 . A i r handling unit A H U - 3 provides conditioned air to the clean room laboratories.  A i r conditioning unit A C U - 1 is a Liebert packaged unit which has been installed in the ceiling space above room 344 to provide additional cooling for the room. A C U - 1 is a water cooled unit which consists o f tube-in-tube condenser, compressor, evaporator, air filter and supply air fan. The unit draws air from the room, cools it and blows it back into the room. Unit A C U - 2  77  is also a Liebert unit equipped with the same components as a A C U - 1 . A C U - 2 has been installed in the ceiling space o f room 442A to serve that room.  Three additional Scott Springfield units, R T U - 1 to R T U - 3 , have been installed on the roof o f the West section o f the building and provide tempered air to the laboratory and high headroom areas. R T U - 1 and R T U - 3 each draw air from the ceiling space below the unit and blow the tempered air into high headroom area, while R T U - 2 draws its return air from the high head room area and blows air out to through ductwork which serves the area along the West side o f the building. Each unit is comprised o f return and outdoor air dampers, filter section, supply air fan, gas fired burner section and heat exchanger.  Supply fans S F - 4 A and SF-4B are Aerofoil M o d e l 38K1/2 1750 axial fans. B o t h fans have been installed in the North-East section o f the basement to draw outdoor air through louvres installed on the main through fourth floors o f the North-East corner o f the building and blow the air through the crawlspace corridor into transformer room 42 o f the basement. The fans are connected to ductwork which contains backdraft dampers, silencers and filter sections. A relief air louvre on the south side o f the transformer room allows air to escape to the atmosphere.  Supply air fan SF-5 is a Cook Model 150SQIB fan installed in the basement mechanical room. The fan is connected to a louvre which allows the fan to draw outdoor air, from the airwell to the South o f the mechanical room, into the mechanical room. The ductwork connecting the fan to the louvre is equipped with a filter and a motorized damper.  78  Supply fans SF-6, SF-7 and SF-8 have been installed at the top o f the main stairways. The fans are each installed to blow outdoor air into the stairway. SF-6 and SF-7 are each C o o k M o d e l 150SQUTB fans which are suspended from the ceiling o f the stairway, while SF-8 is a C o o k M o d e l 150ASP-T and it is located on the roof above the stairway.  4.5.2.10 Exhaust Air Subsystem  Exhaust fans have been installed in various locations o f the building to remove fumes, moist or warm air from the rooms served, and induce conditioned air into space. A manifold general exhaust system has been installed in the High Head Lab area providing non-scrubbed fans to exhaust heat and non corrosive fumes and a stainless steel scrubbed system for corrosive exhaust.  4.5.2.11 Control Subsystem  A Landis & Gyr, Power System 600 o f electric/electronic controls has been installed to operate the air handling units, pumps and main exhaust fans o f the building. The control panels are located in the mechanical rooms and receive information from sensors to energize, or de-energize, the equipment which it operates according to the control programs which have been installed. The programs are designed to automatically operate the equipment to maintain the temperature within the rooms as required for normal occupied and unoccupied conditions. With a computer terminal connected to the control panel the operator may view the operating  79  conditions o f the equipment, make changes to the control programs, be warned o f system malfunctions, and view historical operation.  4.5.2.12 Compressed Air Subsystem  A n air compressor station has been installed in the basement mechanical room to provide clean, dry compressed air to the outlets in the laboratories and work rooms throughout the building. The air compressor station consists o f compression tank with dual air compressors, air drier and dual air filters and air pressure regulators. The air compressors are automatically regulated via pressure switches to maintain the air pressure within the tank, and the air drier operates to remove water vapor from the compressed air. The compressed air supply piping from the air compressor station is routed alongside the domestic water piping in the ceiling space and pipe chase risers o f the building.  4.5.3  Electrical System  The electric portion o f the A M P E L project has been divided into following sub-systems:  •  H i g h Voltage Power Distribution Subsystem  •  Secondary Power Distribution Subsystem  •  Emergency Generators Subsystem  •  Lighting Subsystems  •  Total Lighting Controls Subsystem  •  V o i c e Data Subsystem  80  •  Fire Alarm Subsystem  •  Time Keeping Subsystem  4.5.3.1  High Voltage Power Distribution Subsystem  This system is comprised o f the following products:  •  15 k V H K Indoor Switchgear Assembly  •  15 k V A i r Core Current Limiting Reactor  •  15 k V Power Cable  4.5.3.2  Emergency Generator Subsystem  This section has the following main products:  •  Generator Set  •  Mitsubishi Diesel Engine  •  Alternators  •  Battery Charger  •  Transfer Switch  4.5.3.3 Lighting Subsystem  The lighting System has been taken as an integrated subsystem.  4.5.3.4 Total Lighting Control Subsystem  For the ease o f understanding this system, it is considered as an integrated subsystem.  4.5.3.5 Voice Data Subsystem  This system is divided into the following main products:  •  Data cabling  •  Data termination devices  •  Wall mount cross-connect subsystem  •  Fire stop  4.5.3.6 Fire Alarm Subsystem  This system has been further sub-divided into the following main products:  •  Audio Equipment  •  Addressable Interface  •  4.5.3.7  System Test Procedures  Time Keeping System:  This system has been treated as an integrated subsystem.  i  6  B  g §11 g 1 II  m III  lis Pi  u !-  *• CO'  Figure 4.2  si  X z. .a= Si '  A M P E L UBC Balancing Schematic Basement Floor Plan  84  85  I  Figure 4.4  I  A M P E L UBC Balancing Schematic Second Floor Plan  86  o  I  1  1  (  1  I  i  i,  ~  If:j  i i i  He  §)  J5£ —I . 0..  ^ _i  ii ©  —€  —g  3 I BP i § m 11 11 I si si  -HI  4_ 5j  --4  1  ?  S  *  . * a?  -Hi  IIP"  —-<§  —(§  ^1 ^3 rri  Figure 4.5  IS  AMPEL UBC Balancing Schematic Third Floor Plan  87  •  i  I  i  i  i  ••-€>  --€> -•-© ~©  --a  •--©  —©  --<§>  m © J -=—=i  r->  m  %  i — = -  —«—!  CDu  s ^  -i  --<§  na --©  j <m> g;  1  is  f»  ^  »  1  8 jr^s  1  mm 9 =3 m  Figure 4.6  ~  Si  ^  AMPEL UBC Balancing Schematic Fourth Floor Plan  88  CHAPTER 5: A DEVELOPMENT FRAMEWORK FOR A FACILITIES MANAGEMENT TURNOVER INFORMATION SYSTEM 5.1  Introduction  This chapter describes a proposed framework for the development o f Facilities Management Turnover Information System ( F M T I S ) . The approach which is synthesized from the study o f the turnover process and the A M P E L documentation, models the system in a semantic model. The data model selected for designing the facilities turnover process was entity-relationship model ( E - R model). The implementation has been carried out in a relational database.  5.2  Framework for FMTIS Development  A s discussed in the literature review chapter, a holistic approach towards data and information is required in order to provide an organization with an effective information system. A model (Figure 5.1) has been developed as a framework for F M T I S development for this thesis. This model is based on the following: "Information System Development Proposed Conceptual Integrated System model  [Baynon-Davies 93],  [Sardi & Kangari 93], 'Design and  Implementation o f a C I M Information System description [Chadha et al 94], Data Base Planning' description [McFadden & Hoffer 88], and 'Designing Information System outlines [Burton 85]".  89  General Planning &Information Requirements  Project Selection  Project Request  Projects  Project Report  Feasibility StudyK  Processing Requirements Feasibility Report  Analysis  User Requirements Document  Design  System Specification  Implementation  Information System  ^5 Enterprise Data M o d e l  Evaluation  Database management System Characteristics Hardware/software operating System Characteristics  Operable System  Review _  Logical Database Structure ( D B M S ) and prototype System  Figure 5.1  Proposed System Development Framework  (Source [Baynon-Davies 93] pp. 21)  90  Structured planning, analysis and design is one o f the most developed  contemporary  paradigms for information systems development [Baynon-Davies 93]. Structured information system development is usually seen as being made up o f a series o f well defined stages with well defined inputs to each stage as well as well defined outputs from each stage (Figure 5.1). The basic idea behind developing this framework is to provide a platform for the proposed information system design and its implementation.  The development o f a database application for an information control system in a facilities environment requires a through understanding o f all data sources and their uses. Figure 5.1 is a graphical representation o f the proposed system development framework. The model includes six major phases: Project Selection, Feasibility, Analysis, Design, Implementation, Evaluation and Review. Each phase involves different steps and procedures, and collectively they identify its final product.  5.2.1  Project Selection  The primary mechanism o f the project selection process is the project selection committee in a business environment. In a construction R & D environment, the project could be referred to the research team from a number o f sources such as government bodies, construction contractors, facility owners, and university faculty members, etc.  91  5.2.2  Feasibility Study  Once the decision is made that a particular project is to be undertaken the next step is conducting a feasibility study. The following steps shown in the figure 5.2 are followed to conduct the feasibility study.  •  Identification of Initial framework for the application: involves identifying the initial parameters for the proposed application. A partial listing o f its intended users, user demands, capabilities o f the system and its limitations are short listed. This allows the developer to proceed with a fairly open mind towards the solution.  •  Organizational Constraints: it is determined at this stage whether it is feasible to go ahead with the project under available resources o f the organization. The technology constraints to develop the application should also be sorted out at this stage.  •  Comments Solicitation: the end product o f the feasibility study is the feasibility report. This report should be presented to the relevant users who should be encouraged to offer their comments on the feasibility report. After receiving all the comments from different quarters, it is advisable to reconvene the meeting o f the development team to consider the comments and to incorporate the relevant portions which are technologically possible and o f interest to the user.  92  Project Selection  y ^ — -  — - o f  Feasibility Study  1*  Identification of FrameWork: for Application  r Comments Solicitation  r Organizational Constraints  f Feasibility Report  Revised Report  r To Analysis Phase  Figure 5.2  Phase 1 & 2: Project Selection and Feasibility Study  93  •  Revised Report: the user input is fed b a c k into the feasibility study and a revised report is p r o d u c e d .  I n a sense, the project selection process and feasibility study act as t w o filters at the b e g i n n i n g o f the development life cycle. Project selection is a course-grained filter w h i c h rejects the projects w h i c h are patently unsuitable. T h e feasibility study is the fine-grained filter a n d scrutinizes the projects o n minute scale.  5.2.3  Analysis Phase  T h e analysis phase can also be termed as the requirement f o r m u l a t i o n phase. It identifies and describes the data requirements o f the o r g a n i z a t i o n . T h e end result o f this phase is the user specification o r user requirements. E l e m e n t s o f this requirement are c o n t i n u a l l y r e v i e w e d w i t h end users until they are satisfied that the requirements adequately describe their needs. T h e f o l l o w i n g s steps, s h o w n i n F i g u r e 5.3, are taken to p r o v i d e i n f o r m a t i o n f o r the next phase.  •  Database Requirements: this process involves defining t h e goals, aims a n d objectives o f the database requirements f o r the o r g a n i z a t i o n . T h i s , i n t u r n , requires establishing a scope f o r the database i n terms o f business functions.  •  Data Source Identification: i nvol ves a n analysis o f the data generator, data classification, w h i c h includes data type and format, f o r m i n g a l i n k b e t w e e n data users and establishing a relationship between these items.  94  User View Identification: involves identifying user views by reviewing the tasks that are performed  or decisions that are made by users. A user view is a  description o f a user's perception about the data in a database.  Reporting Requirements: involves listing the printed reports produced by the system, and their appearance.  Processing Requirements: involves identifying various processing functions, such as calculations, transfer o f information, archiving and deleting the data.  Preparing a Data Dictionary: this involves defining in detail each data item type that appears in a user view. A classic data dictionary in a relational system is an active repository. It is an inherent, internal part o f a database system designed to buffer the user from the base tables [Beynon-Davies 93]. It is created by building a table defining all the fields to be used, showing field names, types, length, and description. It describes the objects and their functions in the system.  Data Volume and Usage Identification: involves the collection o f information concerning data volume and usage pattern, including future growth. Collecting these data is another step in the requirement analysis, however, it is best performed after the conceptual modeling is completed.  95  Database Requirements  r  User V i e w Identification  r  Data Source Identification  r  Reporting Requirements  r  Processing Requirements  Preparing Data Dictionary  r  Data Volume and Usage Identification  1  To Design Phase  Figure 5.3  Phase 3: Analysis Phase  96  5.2.4 Design Phase This phase involves the transformation o f the requirements set by the three previous phases into a system specification and design o f an interface with the end user. The following steps are followed in this phase:  •  File Organization Scheme Development: involves developing an organization scheme for construction documents. Information generated during the construction process, such as contract documents, specifications, drawings, submittals, change orders, correspondence, product and equipment information, contacts information etc., needs to be organized according to some standard code.  •  User View Definition: involves reviewing and defining in detail all the information or data required as an output before starting conceptual data modeling. A l l the main entities to be tracked in the application are listed, including the character o f each entity and the required system output.  •  Conceptual Data Model Development: involves identifying data items usually referred to as entities and their relationships. The conceptual design o f a database starts with the definition o f the requirements and produces a conceptual schema o f the data. This is the most important aspect o f the data base design because it describes the organization and scope o f the information to be stored in the implemented database. This is independent o f any particular Database Management System ( D B M S ) implementation. The steps in conceptual design include data  97  m o d e l i n g (using Entity-Relationship m e t h o d o l o g y ) , v i e w integration, c o n c e p t u a l schema development (semantic data m e t h o d o l o g y ) , design r e v i e w , and l o g i c a l access m a p p i n g .  •  Technology Identification:  involves  identifying  available  technology  and  the  i n c o r p o r a t i o n o f future t e c h n o l o g y into the system. A t this stage the most suitable hardware and software f o r the p r o p o s e d system is identified.  From Analy: Phase File Organization Scheme Development  User V i e w Definition Conceptual Data M o d e l Development  I  T e c h n o l o g y Identification  To Implementation Phase  Figure 5.4  Phase 4: System Design  98  5.2.5  Implementation Phase  In this phase, the conceptual model is mapped to a logical database structure. The important issue here is to make sure that the design specifications and user requirements, as they were identified in the previous phases are implemented properly. The following steps (shown in Figure 5.5) shall be followed in this phase:  •  System Hardware and Software Selection: involves selecting the system hardware and software based on the technology identification done in the previous phase. The selection o f hardware will be based on two general principles: first, the facility managers need to be comfortable with using this hardware, and second, the turned-over facility will be the most likely place where this system shall be kept. The selection o f software will be based on the choice o f easy-to-use data managers and compatibility for personal computers (PC's) running Windows 95 operating system. The user interface will be developed with a standard Windows user interface.  •  Prototype System Development: involves developing a working model o f the finished application that fulfills most o f the system's requirements. The purpose o f prototype is to demonstrate the idea o f using a F M T I S for information handling during project turnover phase. The prototype will be a simplification o f a complete F M T I S , but will realistically demonstrate all database functions. A t this stage all the forms, reports, and queries will be designed. Following the results o f evaluation o f the forms and reports, the database will be refined. 99  From System Design Phase  Back to Design Phase  System Hardware/Software Selection r  Prototype System Development  Review  r  To System Development  Figure 5.5  Performance Evaluation  Phase 5 & 6: Implementation & Review Phases  5.2.6 Performance Evaluation and Review The system, once written and tested, must be subjected to critical evaluation phase. Once the system is in operation, it is usually subject to a whole series of user reviews. Such reviews are likely to generate a whole series of further project requests and amendments to the existing system. In performance evaluation review, the system response to typical queries will also be estimated.  5.3  FMTIS: Facilities Management Turnover Information System  An important aspect of this research was the development of a prototype system. This chapter has presented a standard and generally accepted methodology used for the development of an  100  information system. The system development and implementation followed for the prototype system included almost all the steps mentioned in section 5.2.  5.3.1  Objectives of FMTIS  The main objective o f this research is to develop a prototype facilities management turnover information control system for facilities managers. The developed system focuses on one o f the support functions, namely information control in a larger domain o f facilities management functions. The prototype can serves as a starting point for a larger scale development process for controlling all the functions as listed in section 3.7.1 within the specialization o f facilities management.  5.4  Planning for FMTIS  This research has been conducted as a case study by studying, analyzing, selecting and mapping the documentation transferred from the main contractor to the Facilities Department o f the University o f British Columbia at the turnover phase o f recently completed project, A M P E L . A s the project selected was a real life project, all the information tracked and entered in the system is also real. When all the information needed for the development o f this system was acquired, the pace was set for the actual planning and implementation o f F M T I S .  101  CHAPTER 6: SYSTEM ANALYSIS AND DESIGN 6.1  Brief Description  A construction project passes through various stages, from the project planning, project bidding and contract  award  phases to  actual  construction,  commissioning, turnover,  maintenance and demolition phases. During all these phases, the project owners, construction companies, project managers,  and, finally, facility managers need information to make  important decisions impacting the well being o f the project. This information includes, but is not limited to, the selection o f a team o f consultants, site investigation, arranging city permits, developing preliminary estimates, bid proposals, contract documents, bid bonds, contract drawings, construction drawings, change orders, shop drawings and their approvals, material utilization reports, machinery running logs, correspondence, punch lists, warranties, and last but not least, the turnover documentation.  Considering the bulk o f information produced during project execution phase, it is very essential to have all this information organized to avoid chaos. The integration, availability, safety, security and use o f this information is a vital managerial task. In this day o f rapid automation, most o f the construction companies and facility management groups use personal computers for cost accounting and data manipulation. With the advancement o f computer technology and popularity o f database management  systems, it is possible to develop a  computerized solution for medium range contractors and facility managers to address their organizational and managerial needs.  102  6.1.1  Proposed Users of the System  This system has been developed for the use o f project managers, facility managers and their authorized agents. A s the scenario used and the information gathered is real, it can be used by the plant operations department for the routine facility management functions o f the A M P E L and other buildings. With the methodology proposed in this thesis the system could also be successfully used for the other facilities at U B C .  6.2  Objectives and Scope of the FMTIS  The F M T I S is developed as a user-friendly application, which can be accessed by project and facilities managers. A s discussed in the section 3.6, a form-oriented user interface has been developed which is easy to use and very interactive. The basic objectives are as follows:  •  T o understand the information needs o f a construction project team;  •  T o develop a data flow model o f a construction project;  •  T o develop an information model for the selected user views;  •  T o design and implement the database and F M T I S application  •  T o provide specifications for future research in similar system development;  •  T o bring into focus the project information management functions;  •  T o gain and maintain control o f the project documentation at project execution stage so that the turnover phase is smooth;  •  T o reduce the time spent on assembling all the project information, available in various formats and locations at the crucial time o f project turnover;  103  •  To support facility managers in their day-to-day affairs relating to the effective management of their facilities.  .3  User Views  As discussed in section  5.2.3,  requirement analysis is a process of identifying the users'  requirements about data to meet their present and future needs. There are traditionally two approaches for requirement analysis: a process-oriented approach which mainly focuses on data flows and processes, and a data-oriented approach. The Data-oriented approach focuses on the data that must be included in the database to satisfy user requirements [McFadden & Hoffer 88]. The Data-oriented approach has been used for the development of this application. The tools used in this approach are a user-view analysis, data definition and description, and normalization. The user view is defined as a perspective adopted by a particular user to make a decision or to carry out some action [McFadden & Hoffer 88]. User views are identified by reviewing tasks that are performed or decisions that are made by users and by reviewing the data required for these tasks and decisions. Documents, files, existing reports and displays are the important sources of information of user views.  The literature review has identified functions and information needs of construction personnel and facility managers. This covers most of the possible project management functions such as general management, accounting management, site management, procurement, safety management and facility management functions such as annual facility planning, maintenance and operations management.  104  The next task is to identify the documents which contain this information. O n the basis o f information gathered so far, several user views are identified. However, only seven will be implemented in the system due to time constraint. The views considered important for the application are as follows:  6.4  •  Facilities V i e w  •  Drawings V i e w  •  Contacts V i e w  •  Products and Warranties V i e w  •  Commissioning V i e w  •  Permits V i e w  •  Tests V i e w  Database Design  A s elaborated in section 2.4.1 on Data Modeling Process, the first step in designing the database is to perform data modeling. It has also been discussed in that chapter that the data modeling process involves the completion o f the following three steps: the conceptual data model, the logical data model and the physical model.  The conceptual data model can be expressed in different ways, such as: an entity relationship model, a data structure diagram or a semantic model. The following sections 6.5 and 6.6 present the conceptual model development o f the proposed system. Section 6.5 deals with the  105  description o f the basic files and their organization schemes. Section 6.6 deals with the description o f user views, identification o f information requirements, identification o f entities and their attributes including primary keys, description o f relationships between entities, and presentation o f an entity -relationship diagram.  Section 6.7.2 deals with the issue o f a data dictionary. The logical modeling is carried out in section 6.8. Section 6.8 also presents entities and relationships, their attributes based on the conceptual models developed in sections 6.5 and 6.6.  The translation process from logical model to a physical model will be handled by D B M S Software. Sections 6.8 and 6.9 will discuss the implementation and prototype development.  6.5  File Organization Schemes  In this section some o f the important and basic entities required for the proposed system, and their organization in the database, will be discussed. One o f the core entities identified in the system is the Product Breakdown Structure (PBS). Most o f the entities in the system are associated this entity. Other basic entities are Products, Locations, Contracts, Documents, Drawings, Commissioning, Warranties, Permits, Tests and W o r k Breakdown Structure ( W B S ) ; these basic entities are discussed as follows:  6.5.1 Core Entity- Product Breakdown Structure A classification scheme for many database entities is usually required for identification  106  purposes. A t present, CSI's M A S T E R F O R M A T is the most widely accepted structure for classification in both the private and public sectors o f the construction industry [O'Connor 93]. [Froese 93] states that classification schemes such as C S I M A S T E R F O R M A T are widely used  but  not  universally  accepted  in  A E C industry.  These  divergent  views  on  M A S T E R F O R M A T present a major problem within construction industry. This situation exits because o f complacency within separate industry sectors, variable project types, and overall industry fragmentation; however, an industry wide standard format should be pursued. Such a format could greatly assist the construction industry in making technical communication more accurate and efficient.  Although C S I M A S T E R F O R M A T is not an industry-wide standard, it has been the basis o f assigning classification to all the basic entities in this project. A l l Project Records are categorized  according  to  several  breakdown  structures  (e.g.,  W B S , P B S , Facility  Subsystems). A breakdown structure is a collection o f specific items or categories titles, usually hierarchical or nested and numbered according to a specific coding scheme. This is a form o f classification, and is modeled on a generalized classification mechanism. This meets all the requirements o f the three breakdowns mentioned, and provides flexibility for the future. The possibility o f mapping one breakdown structure to another also exits, either by defining a function that relates the codes used in the three classification schemes or by explicitly specific classification classes between the two schemes. This approach allows users to add their own arbitrary breakdown structures, which has been done in this case. F o r the proposed F M T I S , most o f the documents are tied to a Subsystem number, W B S index, or P B S index. A n example of P B S used in the F M T I S is based on the following classification scheme:  107  The absorption chiller is assigned 020-157110-0001 as a PBS index. The item code or the long identifier for any product has three codes segments. The first segment of three digits correspond to the project number of AMPEL as assigned to it by UBC Campus Planning Department. The next segment of six digits are based on the MASTERFORMAT classification, which indicate the main subsystem of which the product is a part, and the last segment of four digits represent the unique identifier associated with that particular product. Thus out of three code segment in PBS, one code relates to CSI code.  6.5.2  Other Basic Entities  The other basic entities in the system are: Facilities, Contracts, Products, Documents, Tests, Permits, Drawings, Contacts, Commissioning and Locations. These entities and their attributes have been identified from turned over documents and exhaustive discussions with facility managers of UBC Plant Operations. A brief description of these entities is given as follows:  A facility manager could manage many facilities, or be responsible for the turnover process of many facilities. The proposed system will identify all these facilities as independent of each other. These different facilities could be managed by a single manager or each facility could have many managers. Similarly these facilities could be located at diverse geographical locations or could be located at one location. The contractor completing and handing over the project(s) to different facility managers could be one or many different contractors working independently. The attributes for the entity facility will include: facility id, name, location, date of completion, owner, project cost. 108  The entity contracts will be required in the database for documenting all the information about the contracts which were awarded to complete the project. This information about contracts is a source o f interest for the facility manager. A n y information about these contracts could be retrieved by the facility managers at any future time for a variety o f purposes such as modifications, renovations and improvements in the old facility. The attributes for entity contracts are contract id, contract name, contract start date, contract finish date, contract cost, contract contractor, document location, and contract conflicts.  A t the time o f project completion, most o f the documents which are o f interest to facility managers are turned over to them. These include drawings, warranties, test reports, contact information and commissioning reports. Apart from the facility itself these documents contain much o f the vital information about the project. In fact, they represent all the milestones achieved during the implementation phase. In order to provide a logical linkage between various records in the database, the entity Locations contain a basic level o f information about all o f these documents and correspond to the place where these documents are kept. The attributes for the entity Locations include Location Id, and Location Name.  The contacts entity relates to all the parties which have contributed towards the completion o f the project or are related to the project in any way. These include the owner, facility manager, consultant, engineers,  contractors,  sub-contractors,  suppliers and manufacturers.  As a  database o f these contacts is very beneficial for the future facility management functions, this information is fairly useful and has been tracked in the system. With a simple query, the facility manager can locate any information about any o f the contacts whenever a need arises. Some  109  common situations for accessing this information arise when an extension in the existing facilities is anticipated and facility managers must make locate the exact suppliers and manufacturers who supplied original products or services. The attributes for this entity are contact id, contact name, contact address, contact phone number, contact fax number, contact trade, contact person.  The next entity o f interest is  Drawings. A construction project usually generates a large  number o f drawings. These graphical records are o f great value for facility owners and managers. The utility o f the project drawings diminishes after project completion but never fades away even after a project has been turned over. There could be many formats in which project drawings be available. A facility manager would be very interested in keeping these drawings in such a format that they could be accessed without recourse to external sources who originally prepared these documents because that involves unnecessary delays and extra cost. The drawings entity has drawing number, drawing title, drawing type, issue date, revision number, prepared by, approved by, drawings picture as attributes.  The products entity relates to all products or equipment located in the facility. F r o m the perspective o f facility manager, the products located in the facility are o f tremendous interest. A l l systems and sub-systems found in the facility are represented by these products and they need on going attention o f facility managers during the useful life o f the facility. I f the building envelope is the skeleton, then these products are the heart, lungs, and nervous system o f that skeleton. The attributes o f products entity include product Id, product name, product  110  breakdown structure, product supplier, product manufacturer, product rating, product weight, product model and product image.  A s we are dealing with automating the turnover process, it becomes important to map that information in the system which enhances the facility manager's overall knowledge about the facility. T o achieve this objective, it is important to track the commissioning and initial start up status in the system. Commissioning is a process which is employed when all the products, systems and sub systems have been installed and the facility is ready for its first trial run to determine the functioning and efficiency o f the equipment, products and processes. A s there was an actual commissioning in case o f A M P E L for which commissioning reports were issued, therefore, this entity has been incorporated in the system. The attributes o f the commissioning entity are commissioning id, product id, product location, serves, performedby, and commissioning date.  The next entity o f interest is warranties. The warranties are the manufacturer's or supplier's undertaking to replace or repair the product during a specified period set out in the warranty document i f something goes wrong with the product. The warranty information is usually required by facility managers because whenever a defect occurs in a product or process which is warranted, the facility manager could easily contact the supplier or manufacturer o f the product to set right the defect or completely replace the product. I f the project is within the maintenance period as set out in the contract then the main contractor is generally liable to correct the defect. The attributes o f the warranties entity are warranty id, item warranted, warranty start date, warranty contact person.  Ill  The next entity o f interest is tests. Tests are performed on those products or processes which are required according to the contract documents to be tested during or after their installation. Tests conducted during the construction phase provide a good view to the project manager that the product or process has been installed according to the specifications and good engineering practices. After the completion o f the project, this information could further be utilized to determine i f there are any further requirements to test the product during its useful life. Furthermore some processes need to be reevaluated and done after some time and new testing is usually required; an example is the air balancing process for the F f V A C system. The attributes o f the test entity include test id, test name, date conducted, test location description, testing method, approval #, document picture, and remarks.  The next entity o f interest is permits. Permits are documents issued by statutory bodies to either contractor or owner o f a facility during the construction process. The permits are usually time bound, i.e., they have a time limit and need to be renewed or applied afresh in many cases. Considering their importance for facility management functions, permits have been selected as an entity o f interest for facility managers. The entity permits has permit #. occupancy date, permit type, permit issue date, permit fee, issued to, permit doc picture as attributes.  6.6  System Views  This section describes selected views as listed in section 6.3.and identifies entities and their attributes referenced in each view, determines the primary key(s), defines general terms for each view, identifies relationships among entities, presents an entity relationship diagram for 112  each view, and finally presents the integrated entity-relationship diagram o f the whole system. Sources which have been used as references for this section are as follows: [Levy 94], [Tidwell 95], [Fisk 93], [Seeley 93], [O'Brian 90], [Callahan and Bramble 83], [Goldhaber et al 77], [Stewart & Stewart 86], [McFadden & Hoffer 88], [Date 90], [El- Bibany & Froese 89], [Townsend 92], and [Liskin 93],  6.6.1  View 1: Facilities  The facilities view describes all the facilities which are being managed by the facilities department o f U B C . The information has been gathered by field review and interview with the U B C plant operations facility managers. The view provides information to the various layers of the plants operations department hierarchy, such as the director, facilities manager, plant engineers, plants architectural manger, cost engineer, field superintendents, and foremen. The following are example o f the general queries for this view o f data:  •  H o w many facilities are managed by the facilities department.  •  Find the systems in a specific facility.  •  Find the sub-systems in the facility.  •  When was facility x completed?  •  W h o was the main contractor/consultant o f facility x?  •  When is the renewal date for a specific permit for facility x?  The entities and relationships that apply to this view are shown in figure 6.1.  113  Facilities  Facility Location  Systems  Figure 6.1  E-R Diagram of Facilities View  The Facilities view has been represented in the following relations: Facilities(Facility I D , Facility name, Facility owner, Date o f Completion, Date o f turnover, Facility photo) Systems(System I D , System Name, Facility ID) Facility Location(Facility I D , D o c Location ID)  114  6.6.2  View 2: Contacts  Contacts in the system have been identified as all parties who have been associated with the project during the construction and maintenance periods. These include the facility owner, facility manager, engineers, project consultants, architect, sub-trades and general contractor. A l l these people individually or collectively are responsible for creation o f the project from an abstract image to reality and keeping the project in good health. Considering its importance for facility managers, this entity has been tracked comprehensively in the system.  The following queries are typical for this view: •  List all vendors.  •  W h o are the designers o f this project?  •  W h o are the Contractors o f this project?  •  W h o are the subcontractors o f this project?  •  W h o are the suppliers or vendors o f this project?  •  What are the contracts / subcontracts issued on this project?  •  F o r a given contract / Subcontract, who is the contractor?  •  H o w well did a company or vendor perform on the project?  •  F o r supplier x or contractor y, who were the secondary contacts, including manufacturer  representative,  consultants,  or subcontractors  involved in the  project? What is their contact information? The entities and relationships that apply to this view are shown in figure 6.2.  115  Drawings  5  Warranties  Contact Trades  Figure 6.2  E-R Diagram of Contacts View  The Contacts view is represented by following relations: Contacts (Contact ID, Contact Name, Contact Address, Contact Phone #, Contact Fax #, Contact Person) Contact Trades (Contact I D , Trade) Contact Locations (Doc Location I D , Contact ID) Drawings(Drawing #, Drawing Title, Issue Date, Revision #, Prepared B y , Approved B y , Draw-Picture) Products (PBS,_Product Name, Supplier I D , Manufacturer I D , Product Rating, Product Weight, Product Model)  116  Warranties(Warranty ID, Warranty Start Date, Warranty Period, Warranty Contact Person, Item Warranted)  6.6.3  View 3: Products and Warranties  The product entity represents all the pieces of equipment belonging to any of the architectural, mechanical or electrical systems which have been installed in the project. Facility managers are particularly concerned with the performance of all systems, sub-systems and their components which make up the products tracked in this system.  Products have various relationships with different objects in the system. There could be many products represented on a single drawing, or there could be many drawings for one product. One product could be tested once, or a group of products forming a sub-system or a major system could be tested once to check the efficiency of the overall system. Similarly, one product could have one warranty document or a warranty could apply to an entire subsystem (example: a warranty for a roofing subsystem) or a main system.  The following are the typical queries for this view:  •  What is product X's Rating?  •  Where can I find the product drawing?  •  What drawing number represents this product?  •  How many drawings for this product in the system?  •  Who is the product supplier? 117  •  W h o is the product manufacturer?  •  What is the product manufacturer's address?  •  What is the manufacturer's name?  •  What is the product manufacturer's fax number?  •  W h o supplied the product?  •  What is the supplier's address?  •  What is the supplier's phone number?  •  Show a picture o f the product.  •  Where is the product located in the facility?  •  What is the product's C S I specification number?  •  What is the warranty start and expiry date?  •  Where is the warranty for the specific component?  •  What is the text o f the warranty?  •  W h o is the warranty contact person?  The entity relation diagram o f this view is shown as figure 6.3.  Product Locations 4  ^.Product_Warranties  V  Sub_systems  Product _Drawings  > Products  r  have  Warranty_Locations Contacts  Warranties  Figure 6.3  E-R Diagram of Products and Warranties View  The Products and Warranties view is represented by the following relations:  Products ( P B S , Product Name, Supplier I D , Manufacturer I D , Product Rating, Product Weight, Product Model) Warranties(Warranty I D , Warranty Start Date, Warranty Period, Warranty Contact Person, Item Warranted) Commissioning  (Commissioning ID, P B S , Product  Location, Serves,  Performed B y ,  Commissioning Date) Product Locations(Doc Location I D , P B S ID) Product_Warranties(PBS I D , Warranty ID) Sub_systems(Sub_System ID, W B S I D , System ID) Product_Drawings( P B S I D , Drawing #)  119  Product_Tests(PBS I D , Test ID) Warranty Locations(Warranty ID, D o c Location ID) Contacts (Contact I D , Contact Name, Contact Address, Contact Phone #, Contact Fax #, Contact Person)  6.6.4  View 4: Tests  In order to ensure that the specifications o f construction materials and methods as laid down in contract agreement are strictly met, tests are performed on various products, systems or subsystems.  This information is also o f interest to the facility managers who perform  maintenance and operation management.  The following are the typical queries for this view:  •  Which test was performed on a particular product, process or system?  •  W h o performed the test?  •  What were the remarks o f the authorized person inspecting the test?  •  Where are the test documents located?  •  Show me the approval document o f a particular test.  •  When is this system or product to be retested during operation?  The entity relation diagram o f this view is shown as figure 6.4.  120  Contacts  Product Tests  Figure 6.4  Tests  have^>  •  Test D o c Locations  E-R Diagram of Test View  The tests view is represented by following relations: Test (Test I D , Test Name, Date Conducted, Test L o c Description, Testing Method, Approval #, Test Contractor, Remarks, Doc-Picture) Contacts(Contact I D , Contact Name, Contact Address, Contact Phone #, Contact Fax #, Contact Person) Product_Tests(PBS I D , Test ID) Test D o c Location(Test I D , Document LocationJD)  121  6.6.5  View5: Drawings  The drawings are graphical construction documents which show the size and physical relation o f various parts o f the job. A construction project generates many drawings. The drawings generated and turned-over to the facilities group  have been categorized in the proposed  system as contract drawings, as-built drawings, shop drawings and system drawings. These drawing types have been tracked in the system for the convenience o f users to find any drawing relating to this facility.  Querying the system for as-built drawings may be very valuable for a facility, not only for initiating repairs and maintenance,  but for future  design and construction o f similar  components, and for product comparison between different facilities. Following are the typical queries for this view: •  H o w can I retrieve a specific drawing from the system?  •  Which drawings are stored in the system?  •  W h o approved these drawings before they were submitted for construction?  •  List the drawing o f the facility?  •  When were these drawings issued for construction?  •  Where is the contact list for those personnel who were involved in the approval and inspection o f drawings?  •  Who is the lead engineer for designing the mechanical drawings?  •  H o w do I reach this person via phone, etc.,?  The entity relation diagram o f this view is shown as figure 6.5.  122  Contacts  Drawing Locations  Figure 6.5  E-R Diagram of Drawings View  The drawings view is represented by following relations: Drawings(Drawing #, Drawing Title, Issue Date, Revision #, Prepared B y , Approved B y , Draw-Picture) Drawing Locations(Drawing #, D o c Location ID) Product_Drawings(PBS I D , Drawing #) Contacts(Contact I D , Contact Name, Contact Address, Contact Phone #, Contact Fax #, Contact Person)  123  6.6.6 View 6: Permits Permits are the permissions granted by regulatory bodies to go ahead with a specific item o f work, installation o f a system or product before or during the construction process. F r o m a facility manager's point o f view, it is important to track this information in the system because almost all permit types require renewal after a specified date. Permit documents also provide useful information about the products, their rated capacities, regulatory bodies, permit fees, and licensing requirements.  The following are typical queries associated with this view: •  Where are the permits for the facility located?  •  What permits were issued for this facility?  •  What fees were paid when the permit for the gas supply was applied for?  •  When do we have to reapply for the boiler plant permit?  •  When is the last date to renew the primary power supply permit?  The entity relation diagram o f this view is shown as figure 6.6.  124  Permit Locations  Permits  <^have^>  I Product_Permits  Figure 6.6  E-R Diagram of Permits View  The permits view is represented by following relation: Permits (Permit #, Occupancy Date, Permit Type, Permit Issue Date, Permit Fee, Issued To, Doc-Picture) Product_Permits(PBS ID, Permit #) Permit Location(Doc Location ID, Permit #)  125  6.6.7  View 7: Commissioning  Commissioning is a process which is undertaken after installation o f all the systems, subsystems and products to verify and check the combined operation o f all these systems. During this process, the efficiency o f all the individual products is also checked. In the case o f A M P E L buildings, the owner appointed a commissioning contractor to see how different systems behaved when tested under actual working conditions. A Commissioning report, apart from supplying useful information about the products and processes gives useful information about the product location and the areas or locations in the facility which any particular product is serving. In view o f its importance for facilities point o f view the entity commissioning has been tracked in the system. Following could be various queries associated with this view.  •  Where are the commissioning reports located?  •  W h o performed the commissioning?  •  This product is located where in the facility?  •  This product is serving which area o f the facility?  •  Which electrical circuit is feeding this product/system?  •  O n what date the commissioning o f facility performed?  The entity relation diagram o f this view is shown as figure 6.7.  126  Commissioning Location  Commissioning  Products  Figure 6.7  E-R Diagram of view Commissioning  The relations associated with this view are: Commissioning  (Commissioning  ID, P B S , Product  Location,  Serves,  Performed  By,  Commissioning Date) Products ( P B S , Product Name, Supplier ID, Manufacturer I D , Product Rating, Product Weight, Product Model) Commissioning Location(Commissioning ID, D o c Location ID)  127  6.6.8  Integrated View  The E - R diagram o f integrated view is shown as follows:  Warranties I  1 Permits |  < W >  Warranty Locations  Jiave  Contact Locations  Permit Locations  Contact Trades  A  Commissioning Locations  V  Product Locations  v  Drawing Locations  Facility Locations  Commissioning |  have Products "\ Product Tests  have  |  Drawings  |  | Facilities")  Product Drawings  WBS ^have.  Sub_systems <  have  Systems  Legend One to One One to Many  Figure 6.8a  User V i e w  E-R Diagram of Integrated View (Part A)  128  One to One One to Many User V i e w  Figure 6.8b  E - R Diagram of Integrated View (Part B)  129  6.7  Entity and Relation Attributes  In this section, the translation o f conceptual model to a logical model is discussed. A t the beginning o f this report, section 2.4.1 explains the data modeling stages and the data model environment o f commercial database management systems ( D B M S ) . Considering that the proposed D B M S is based on a relational data model, such as Microsoft Access, this section translates the conceptual concept to a logical relational model.  This section lists the attributes associated with each entity as shown in figures 6.1 to 6.7. These relations are the result o f a normalization procedure explained in section 2.5. A n attribute or a number o f attributes from these relations represent the primary key(s). The primary key for the relations is underlined. Additional attributes have been added to some o f the relations to fulfill the data information requirements. These new attributes are unaffected by the normalization process. That is, they are not a repeating group ( I N F ) , attributes o f entities with more than one identifying attribute (2NF) or functionally dependent on a non-key attribute o f an entity. They are in their third normal form (3NF). The entities as presented in the following section will be termed as tables in section 6.9 and onwards. When these relations will be mapped into physical models in a real D B M S environment, the tables will have the same title as that o f the relations presented in this section. The attributes o f these relations will be termed as fields.  The local data models o f section 6.6.1 to 6.6.7 have been combined and consolidated to arrive at the following global data model.  130  6.7.1  Entities  The entities or relations for the overall system are as follows:  Commissioning (Commissioning I D . P B S , Product Location, Serves, Performed B y , Commissioning Date)  Commissioning Locations (Doc Location I D . Commissioning ID)  Contacts (Contact I D . Contact Name, Contact Address, Contact Phone #,Contact Fax #, Contact Person)  Contact Trades (Contact I D . Trade)  Contact Locations (Doc Location I D , Contact ID)  Contracts (Contract Id. Facility I D , Contract Name, Contract Start Date, Contract Finish  Date, Contract Cost, Contractor Name)  Contract D o c Locations (Doc Location I D . Contract Id)  Drawings (Drawing #. Drawing Title, Drawing Type, Issue Date, Revision #, Prepared  B y , Approved B y , Draw-Picture)  131  Drawings Locations (Doc Location ID, Drawing #)  Facilities (Facility Id, Facility Name, Facility Owner, Facility Address, Facility Photo)  Locations (Doc Location I D . D o c Location Name)  Permits (Permit #. Occupancy Date, Permit Type, Permit Issue Date, Permit Fee, Issued  T o , Permit-Image)  Permit Locations (Permit #, D o c Location ID)  Products ( P B S I D . Product Name, Supplier ID, Manufacturer ID, Product Rating,  Product Weight, Product M o d e l , Product-Image)  Product_Warranties ( P B S ID. Warranty ID)  Product Locations (Doc Location ID, P B S ID)  Product_Tests ( P B S I D . Test ID)  Product_Drawings ( P B S ID, Drawing #)  132  Tests (Test Id, Test Name, Date Conducted, Test Contractor, Test Loc Description, Testing Method, Approval #, Remarks, Test Report-Image)  Warranties (Warranty ID, Warranty Start Date, Warranty Period, Warranty Contact Person, Item Warranted, Warranty Doc-Image)  Warranty Locations (Warranty ID. Doc Location ID)  WBS (WBS ID. Work Item)  Systems(System ID. System Name)  Subsystems( Subsystem ID. Subsystem Name, System ID, WBS ID)  6.7.2  Data Dictionary  A data dictionary is defined as a set of system tables that contain the data definitions of database objects [Jennings 93]. Much of the information related to the data is specified by means of a data dictionary. The Data dictionary is an important feature of the DBMS and acts as a general reference tool for describing all the data held in the database.  Appendix A contains the data dictionary of the proposed system and provides information about each attribute as described in section 6.7.1. Typically, each entry in the data dictionary describes the following: 133  6.8  •  the name o f the attribute  •  the data type  •  the length or width o f the attribute  •  indexing requirements  •  a brief description o f the attribute  Suggestions for Implementation Environment  In this section, suggestions and recommendations are provided for implementation environment o f the proposed system.  6.8.1 System Hardware and Software Options Computer technology is changing very rapidly and there is always a tendency to acquire what is perceived as the newest and the best. But the criteria for evaluating the facilities management system hardware and software should be based on what is important for the company [Tidwell 92]. The selection o f hardware is based on the following needs o f the facility managers: speed o f a personal computer (PC) for processing and updating data, R A M (random access memory) for file sizes and new software requirements (database, spreadsheets, graphics capabilities), expandability o f computer systems, printer types for fast printouts, and costs. Anticipating that other facility management applications w i l l be used on the same P C , it is suggested that the P C be an IBM-Compatible with a pentium processor; 16 M B (Megabyte) of R A M (32 M B or more is recommended); 2 Gigabyte or higher hard drive; V G A monitor and a laser printer o f 2 M B memory or higher; and a scanner. The operating  134  system would be Microsoft Windows ™95. It is further recommended that a commercial database management software package, such as Microsoft Access be also loaded on the system, because this application requires the least amount o f programming.  6.8.2  Sources of Data Input  The data input to the system will be through the following documents and sources:  •  The Facilities Data shall be acquired from the Facilities Department. In our case, from U B C Campus Planning and Development register of Facilities.  •  Contacts Data shall be acquired from the Turn-over documents and Operating and Maintenance Manuals, which are created at the time o f facility turn-over to the Plant Operations Department o f U B C . These documents are available in Plant Operations bounded in hard cover folders and are known as operations and maintenance manuals.  •  Commissioning Data shall be obtained from the Commissioning Reports which are created when the plants and equipment installed in the facility are operated for a trial run.  •  Contracts Data shall be obtained from the register o f "Contracts Awarded" as maintained in the U B C Campus Planning and Development office.  •  Drawings data will be obtained from the drawings folders, C A D files o f the facility, Shop drawings approved by consultants and located in Operations and Maintenance Manuals, and as built drawings as found in 0 & M manuals.  •  Permit documents are stored in Operations and Maintenance Manuals o f the facility.  •  Warranty documents are found in the Operation and Maintenance Manuals o f the Facility.  135  •  Test Reports Data is located in the Operations and Maintenance Manual o f the facility.  •  W B S will be based on the C S I M A S T E R F O R M A T .  •  Products Data will be obtained from the Operations and Maintenance Manuals o f the Facility. These Manuals, which serve as maintenance manuals o f a particular facility are created when a facility is completed and handed over to Plant Operations Department o f UBC.  •  Location data would be obtained from all possible locations where facility  project  documentation is kept. These include O & M Manuals, Drawing Folders, C A D Files Located in Managers Desk, File Racks etc. •  The photographic data will be obtained from photographs o f various products. These images will then be scanned and integrated with the database.  6.8.3  System Data Output  Figure 6.9 shows the data output organization for the proposed system. The system output will be forms and printout reports. Data output on screen will be form-oriented and the graphical user interface will incorporate various features o f the windows operating system, such as fields, menus, buttons, combo boxes, and scroll bars etc.  Following forms and reports will be created:  •  Commissioning Data entry form  •  Contacts data entry form  136  •  Contracts data entry form  •  Drawings data entry form  •  Drawings view form  •  Products data entry form  •  Products view form  •  Permits data entry form  •  Products and Associated Records form  •  Drawing and Products Browser  •  Permits Document V i e w form  •  Warranties Data entry form  •  Warranty Document view form  •  Test Reports Data entry form  •  Test Document V i e w form  •  Facilities Data Entry form  •  Contacts Information Report  •  Warranties Information Report  System Data Organization  Data Input  Collect Input Data  Data Output  Edit Database  Output to Screen  Output to Printer  Printouts  View Table  Figure 6.9  View Query  View Form  View Report  System Data Organization Diagram  138  6.9  Physical Implementation  In this section, the physical development o f the system is explained. Section 6.9.1 presents the Microsoft Access terminology, and section 6.9.2 will present the prototype development.  6.9.1  Microsoft Access Terminology  Some o f the key terms as used in Microsoft Access are explained as follows:  •  Microsoft Access: Microsoft Access is a relational database management system ( R D M S ) for Microsoft Windows ™.  •  Table: A table is a Microsoft Access object that stores data in rows (records) and columns (fields). The data describes a particular subject such as Drawings or Products. A l l data in a table describe the subject o f the tables. The entities and relationships, as listed in section 6.7, will be represented as tables.  •  Query: A query is a Microsoft Access object that asks a question or defines a set o f criteria about data from the tables. That data that answers the questions can be from one table or from more than one table. A query brings requested questions together. The tables which contain the desired data are added to the Query window. The Query window is a query-by-example ( Q B E ) tool. The tables in a query are joined by a line that connects one of the fields o f a table. The join line tells Microsoft Access how the data in the tables are related. A Q B E grid is used to accomplish a variety o f tasks in a database, such as :  139  •  Combining and displaying records from related tables.  •  Retrieving subsets o f records that match specific selection criteria.  •  Updating fields o f data according to updated expressions.  Form: A form is a Microsoft Access object that is used to enter, change and view records o f data. It is used to display data, from one or more tables/and or queries, on screen. A well-designed form provides a familiar, consistent, and reliable visual tool for performing a variety o f database tasks, such as:  •  Viewing data o f one record at a time.  •  Viewing existing records in a table.  •  Entering new records into the table, often in a format designed to resemble a familiar paper format.  •  Printing individual records.  Subform: Subform is a form within a form. The primary form is called the main form, and the form within the form is called the subform. A form/subform combination is often referred to as a hierarchical form, a master/detail form, or a parent/child form. Subforms are especially effective when we want to show data from tables or queries with a one-tomany relationship. For example, one could create a form with a subform to show data from Locations table and Products table. The data in the Locations table is the "one" side o f the relationship. The data in the Products table is the "many" side o f the relationship. Each category can have more than one product.  140  Report: A report is a Microsoft Access object that is used to print records in a customized layout. A report could be used to group records and show totals for groups and grand totals for the entire report. A report is the ultimate presentation from a database. A report often provides summaries o f data, listings o f records, and information gathered together in meaningful groups and subgroups.  M a c r o : A macro is a set o f one or more actions that perform a particular operation, such as opening a form or printing a report. Macros can help to automate common tasks. F o r example, to run a macro that prints a report when a user clicks a command button. Each task that Microsoft Access is asked to perform is called an action. Microsoft Access provides a list o f actions to select from to create a macro. When a macro is run, Microsoft Access carries out actions in the sequence they are listed, using the specified objects or data.  Field: A field is a column o f data contained in a table. The attributes o f the entities as described in section 6.7 will become fields o f a particular table.  Type: The term 'type', used in tables o f Appendix-B, denotes the degree o f relationship between the tables. For example, one-to-one (1-1) and one-to many (1-M). Enforce: The term 'enforce', used in table o f Appendix B , shows the referential integrity requirements. This column shows 'yes' i f referential integrity is required. Referential integrity is a system o f rules that Microsoft Access uses to ensure that relationships between records in related tables are valid, and that the user can not accidentally delete or  141  change related data. One can set referential integrity when all o f the following conditions are met:  •  The matching field from the primary table is a primary key or has a unique index.  •  The related fields have the same data type. There are two exceptions. A n AutoNumber field can be related to a Number field with a Field Size property setting o f L o n g Integer, and an AutoNumber field with a Field Size property setting o f Replication ID can be related to a Number field with a Field Size property setting o f Replication ID.  •  Both tables belong to the same Microsoft Access database. I f the tables are linked tables, they must be tables in Microsoft Access format, and one must open the database in which they are stored to set referential integrity. Referential integrity can't be enforced for linked tables from databases in other formats.  •  Default Relationships: Microsoft Access is a relational database and data can be used from more than one table at a time. If a database contains tables with related data, the data can be related in queries, forms, and reports. It is always useful to create a default relationship between related data o f two tables to allow the D B M S to automatically associate data from different tables.  6.9.2  Prototype Development  This section discusses the various steps followed to produce a prototype o f the system will be discussed. The steps followed were in the following sequence: develop tables, set default 142  relationships, design queries, create forms and subforms, produce reports, and  create  applications with macros. A brief description o f the steps is presented as follows:  6.9.2.1 Developing Tables  In all, twenty-five (25) tables were developed for the prototype database. E a c h table was developed by adding all the fields and their data types, as listed in the data dictionary (Appendix A ) . Setting the primary key(s) for each table was performed, during the course o f individual table development. A part of Drawings table is shown in figure 6.10.  6.9.2.2 Setting Default Relationships between Tables A s the purpose o f database is to create queries, forms, and reports that retrieve data from more than one table, setting default relationships between is an important task. Default relationships between tables, as listed in Appendix B , were set before designing the queries, forms and reports.  143  6.9.2.3 Designing Queries  After analyzing some o f the requirements o f the user, a list o f thirty queries was developed for the database. Each query was intended for a particular form, subform or report. Fields containing data required to appear on a form or subform were selected, and their tables were identified. A set o f relationships, as listed in Appendix B were used to create Q B E grids. A slightly different naming convention than that o f the tables, was used to name queries in order to facilitate the designing o f forms. S Q L view o f two sample queries is shown as follows:  S E L E C T Locations. [Doc Location Name], Contacts.[Contact Name],  Contacts.[Contact  Address], Contacts.[Contact Phone#], [Contact Locations].[Doc Location I D ] , [Contact Locations].[Contact ID], [Contact Trades].Trade FROM  (Locations I N N E R  JOIN  (Contacts  INNER  JOIN  [Contact  Locations] O N  Contacts.[Contact ID] = [Contact Locations],[Contact ID]) O N Locations.[Doc Location ID] =  [Contact  Locations].[Doc  Location  ID])  INNER  JOIN  [Contact  Trades]  ON  Contacts.[Contact ID] = [Contact Trades].[Contact ID];  S E L E C T Products.[PBS ID], Products.[Product Name], Sub_Systems.[Sub_System Name], Commissioning. [Product  Location],  Commissioning. Serves,  Drawings. [Drawing  #],  Contacts.[Contact Name], Product_Warranties.[Warranty ID], Warranties.[Warranty Period], Product_Tests.[Test ID], Tests.[Test Name], Tests.[Testing Method], Tests.[Approval] F R O M Tests R I G H T J O I N ((Warranties R I G H T J O I N ((Contacts I N N E R J O I N (Drawings I N N E R J O I N (((Sub_Systems I N N E R J O I N Products O N Sub_Systems.[S_System ID] =  145  Products. [S_System  ID])  LEFT  JOIN  Commissioning O N  Products. [PBS  ID]  =  Commissioning.[PBS ID]) I N N E R J O I N Product_Drawings O N Products.[PBS ID] = Product_Drawings.[PBS ID]) O N Drawings. [Drawing #] = ProductJDrawings. [Drawing #]) O N Contacts. [Contact ID] = Products. [Supplier ID]) L E F T J O I N Product_Warranties O N Products.[PBS ID] = Product_Warranties.[PBS ID]) O N Warranties.[Warranty ID] = Product_Warranties. [Warranty ID]) L E F T J O I N Product_Tests O N Products.[PBS ID] = Product_Tests.[PBS ID]) O N Tests.[Test ID] = Product_Tests.[Test I D ] ;  6.9.2.4 Creating Forms  Three different types o f forms were created for each user view. The first type o f forms is for data entry and editing a table. The second type is for viewing information on the screen, and the third type uses subforms to show result from two related tables. F o r the purpose o f prototype, the following forms were created: Twenty-three for data-entry (one form for each table), seven on-screen view forms (one for each user view), and subforms (one for each user view). Some other forms created are as follows: Start up o f F M T I S and print-report switch board, drawings and products browser and products and related records browser. A l l together forty forms were created. Some o f these forms are shown in figures 6.11 to 6.20.  146  C o m m i s s i o n i n g D a t a Entry: F o r m  Commissioning ID  CR-1  Product ID  020-157290-0077  Product Location' ::.: Serves  Penthouse Laboratory  Performed By.  Kevin May  Commissioning Date  . .• TallinCammissianinti;  Figure 6.11  9/8/95  Bavk.Tu F M T I S  h-xit  Data Entry Form Commissioning  C o n t a c t s Data Entry  Form  Contact ID  Contact-1  Contact Name  Rotair Industries  Contact Address 7445 Lowland Drive Burnaby B . C . V 5 J 5 C 4 Contact Phone#  604-431-8436  Contact Fax#  604-431-5122  Contact Person  David Chrsrnenko  .Table-Contact:  Figure 6.12  Back To FMTIS  Exit  Data Entry Form Contacts 147  Drawings Data Entry Form  M-29  Drawing # Drawing Title  Building Section (High Headroom Lab)  Drawing Type  Mechanical Drawing  Issue Date  8/1/93  Revision tt  2  Prepared By  Contact-126 Contact-3  Approved By  -TR  r  V i e w Drawing  Bs»ck To F&ATI5,  Figure 6.13  'Exit,  Data Entry Form Drawings  Drawing: and: Products Browser:  Drawing #  PBS ID  020-163260-0001  Product Name  15 Kv Switchgear  FMTfS  Figure 6.14  ABD-1  Exit  Drawings and Products Browser  Products and:Associated Records PBS ID Product Name  020-016420-0001  Sub_System Name Product: Location: :: Serves  Compressed Air  Drawing # Supplier Name  ABD-2  Warranty ID :: Warranty: Period: ••.  Test ID Test Name Testing Method Approval!?  Basement Mechanical RoomLab air compressor  RotairJndustries;:  Not available::  1  Nat available::  Test-10 Curtis GompressorStart up Pressure Test; Air Pressure Testing  il  Not available  FMTIS  Figure 6.15  1  Air Compressor-1: AC-1  1  ;£  FXIT  Products and Related Records Browser  Facilities M a n a g e m e n t T u r n o v e r Information S y s t e m "fable  Icomaas^lT  :: M I S ^ ^ ^ :Cummissiuriiritj>:  j* Commissioning  i  Warranties  W i n d o w  Figure 6.16  J  H«lp  l-ind  All Contacts  Exit  :;illi  FMTIS Switch Board  149  Products Data Entry Form  Product ID  020-155671-0001  Product Name  Expansion Tank-1 :EXT-1  Product Rating  300 Litres  Product Weight  102 Kg  Product Model  AL-300 V  ''I H I I I K - I ' I I I I I U K K  Figure 6.17  Back To FMTS !  I xit  Data Entry Form Products  Facilities Data Entry: Form::  Facility ID  UBC-020  :: Facility Name  AMPEL  Facility Owner  UBC Campus Planning & Development  Facility Address  2355 East Mall UBC Vancouver  ITable-' F a c i l i t i e s i  Figure 6.18  L  Back To F M TIS  Data Entry Form Facilities  Ixil  Tests Data Entry Form Test Id  Test-1  Test Name  Backfluw Prevention Assembly Test Report  Date Conducted  3/22/95  Test Contractor  Contact-24  : Test Loc Description  Mechanical Room AMPEL UBC  Testing Method  Water Pressure Testing  Approval^  14350  Remarks  The Assembly meets the performance requirements of the City otVancover Water Works Standard 419.  FMTIS  ^ VjiJWJTf«:?i.l,- D»c.  Figure 6.19  r.xn  Data Entry Form Tests  View Information Form Drawings, Products, WBS and Subsystems  Drawing Title  15kV8AA10 & 8BJ20 M.E. SWGR General ARR'T and Single Line  PBS ID  020-163260-0001  Product Name  15 Kv Switchgear  Sub_System Name  High Voltage Power Distribution  WBS ID  163260  Contact Name  SIEMENS  Don Location ID  E2_8.0  Back to FMTIS  Figure 6.20  Exit  A View Information Form  6.9.2.5 Producing Reports A report is an effective way to present our data in a printed format. Because we have control over the size and appearance o f everything on a report, we can display the information the way we want to see it. In the prototype, the intended reports are the same as those of the user views 6.8.3. Each report provides summaries o f data and information as contained in its respective user view. Seven reports were created and designed. T w o o f the reports are depicted in figure 6.21 and figure 6.22.  ^SBii^kbisiV..,  Contact Information Report  .SiS  !0  :;p '  II,  :«8  Contact Name  A Goulds Pumps Compan  Trade  : Contact Phone#Conta ct A d dress:  MMMMMM!MMHUH!M^^^s'Mviifetctn'Jilex ;j!h!^  (1  240 Fall Street Seneca Falls, N Y 1 Scrubber Pumps  -  Contact Name  Doc L ocati on Nam e  A<BB Paving Company L t  Trade  :Cuntact:Phone#Contact Address  Subcontractor Contact Name  604-42C-1342  Doc Location Name  14C3 Blaine Ai'enue 3urnaby, B C Project Directory  ABUS  I;  ::fe Trade  Conta ct Phone# Conta ct Address  Manufacture: Contact Name  02261-273  D-5; C'47 Curamcrsbach Germany  Doc Location Name  Bridge Crane  Acuthenn  :ifl ::#  Trade: Pace:  W  j]  Figure 6.21  Contact Phone#Contact Address  Doc Location Name  '•••ms\  iTTTTn JT  Contacts Information Report Image  152  H E IS  Warranties_Report Item Warrante Warranty Start Da Warranty Period  Supplier :  Manufacturer:  50 KW Generator Set  list ••Mi  8/1/95  .  12monfcs frcnHhitiM sta  All finish hardware ; Sub Stan ti al=F;; 2 kYears;;  McGregor &fhompsnn  ;  Glynn-JohnsonIi  Rridge Craiie DateofDdiv  !-Yearcr23Cahoursofo  ?IaveritS:eel&CraheLt  ABUS  Earthquake Pendant Mount • .  Fully Hydraulic Dock Leveller  Incandescent Limiting Fixtures  Lighting Fixtures  Fa  omii  Figure 6.22  Date of Pure  ^EULT^I  m 1-Year  •.  NEDCO...  i :  ;  ^.  .2aaiQ.Photon  1  Warranties Information Report Image  6.9.2.6 Creating Applications With Macros  F M T I S contains a large number o f user views, and therefore, automation o f actions was considered as a desirable feature. Macros were used to create database applications, such as opening and closing a form, printing a report, exiting the Microsoft Access window. Some o f the macros created for the prototype were Auto Execute, Open Table Macro, Open F o r m Macro, Close Table macro, Close Form macro, Open Report macro, Close Report macro and Exit Application macro.  153  CHAPTER 7: CONCLUSION 7.1  Thesis Review  The first objective o f this work was to analyze the information needs o f the project and facilities management personnel. T o achieve this objective a review o f literature was done to determine what type o f documents are turned over by project management groups at the time o f turnover o f a facility to facility management groups. The desired result was to identify the documents that contain information used by facility managers for facility operations.  The second objective was to develop a computer-based Facilities Management Turnover Information System capable o f providing information and enhancing the problem solving capabilities o f facility managers. This objective was achieved by developing a data model based on findings o f literature review and discussion with facility managers o f U B C Plant Operations.  The first part o f the research was based on conditions and methodologies for designing databases for construction industry as proposed by [Scarponcini 89], that information function.  follows  The functions executed by facilities managers dictate the information that these  personnel need and provide. These functions need to be understood before the information could be efficiently modeled.  A framework as described in chapter 5, was developed for designing the information system. Based on information requirements, user views were developed and presented in chapter 6. A  154  conceptual data model was developed for each relation o f the user views. The tool used for data modeling was entity-relationship (E-R) diagram. Integrating all the individual models in a global data model was carried out, which helped in identifying various entities, including their attributes and relationships. A data dictionary was also prepared to define all the attributes and as a guide for future reference and amendments.  After understanding and modeling the facilities information environment, a prototype design was started. The global model was mapped to relational database model. The entities became tables, and the attributes their fields. With the help o f the global model, default relationships between tables were established. The database was implemented on a commercial relational database management system ( R D B M S ) called Microsoft Access.  After implementation o f the database a graphical user interface was developed. This allows ease to users o f this system to have multiple views o f data. These graphical interfaces included front-end forms for data entry, deletion, manipulation and querying.  7.2  Benefits and Applications of FMTIS  F M T I S is a prototype facilities-management turnover information control system aimed at information control requirements o f project and facilities managers. The followings benefits can be derived from the F M T I S :  155  •  FMTIS  can provide the  information  facilities managers with  a facility  documentation  storage and retrieval database to facilitate the task  o f facility  operation.  •  F M T I S can provide facilities managers with a desktop tool to identify certain problems in various components o f the facility, locating their source and taking immediate remedial measures such as contacting the supplier o f the faulty equipment.  •  F M T I S can generate a wide variety of reports, e.g., contact names and phones numbers, products and their drawings and product warranties etc.  •  F M T I S can smoothen the task o f facilities turnover, both for construction management  and facilities management  groups by reducing the  turned-over  documents load and automating the turnover process.  •  7.3  F M T I S is user friendly and can be easily incorporated in existing facility groups.  Experiences and Observations  The development o f the F M T I S prototype posed many challenges. The biggest problem faced in the development o f this system was modeling facility management functions o f a real world project. The selection o f a project as a test case was critical, because only a fairly complex project could test the efficacy o f the system. This problem was resolved by the selection o f 156  A M P E L , a n e w l y constructed facility i n U B C . A M P E L is regarded as a fairly c o m p l e x facility by U B C Plant O p e r a t i o n s f r o m a facility operations point o f v i e w . A l t h o u g h a relatively small n u m b e r o f turned-over documents w e r e considered, the analysis turned out to be fairly r i g o r o u s . It consists o f seven user v i e w s and the same number o f user reports. S o m e o f the experiences and observations are listed b e l o w :  •  A g l o b a l conceptual data m o d e l is very useful f o r an integrated i n f o r m a t i o n system. O n e g l o b a l data m o d e l representing entity and relationships has been presented i n figure 6.8a  •  A  and  6.8b.  detailed analysis and design at an early stage is v e r y essential f o r s m o o t h  implementation o f the system.  •  S o m e t i m e s it becomes difficult to update the design w h e n one has progressed deep into the implementation phase. T h i s observation dictates the creation o f the data dictionary.  •  P r o t o t y p e development is a useful t o o l to point out the deficiencies i n the design o f data structure.  •  E n t e r i n g data into the database is a time-consuming process. It t o o k a major p o r t i o n o f the development time o f p r o p o s e d system.  157  •  F M T I S has been developed by using relational database as design foundation and implemented in M S Access Software. This software has proved  sufficiently  capable to handle the application development for such projects. The only limitation observed was its capability in handling and processing images. There was no in-built capability in Access to process the images and place them at the required place. The loading o f images also reduced the speed o f processing the information.  •  The database consumed a lot o f disk space when images were loaded on it. Its final version took more than 160MB o f disk space.  7.3.1  Validation and Testing  The control and assurance o f software quality is an essential and critical component o f the software development process. There are two reasons for the demands for improved software quality: Firstly, the considerable cost in software usage and maintenance is due primarily to errors introduced in earlier stages and to difficulties in making changes. Secondly, there is an increasing number o f computer application fields where unreliability can have an impact on human life (flight control systems etc.). In some other fields, unreliability can result in loss o f important data or excessive unavailability o f key resources.  The software quality is no longer only determined by the issues o f correctness and efficiency, but more difficult properties such as user friendliness, modifiability and robustness must also be considered. Methods and tools are being developed that attempt to locate errors in systems 158  or to demonstrate the absence o f such errors. Although additional research on validation is necessary, [Hausen 84] identifies following methods and tools for software validation:  •  Inspection  •  Program testing  •  Verification  •  Alternative methods, in which validation is carried out at each stage in the life cycle.  F r o m the point o f quality assurance throughout the system life cycle, most o f the existing methods and tools are only suitable for specific phases and error classes. B y suitable combinations o f methods and tools, quality assurance and control should become more effective.  After completion o f the F M T I S prototype it was considered desirable to get the feedback and observations o f facility managers o f U B C Plant Operations. F o r this purpose, F M T I S was downloaded on the computer o f M r . Rob Seversen, the facility manager o f U B C Plant Operations. A small demonstration o f the system functionality was provided before seeking the opinion o f facility operators. M r . Seversen provided some useful suggestions which are listed as follows:  •  The system should have the ability to call all related drawings o f systems, subsystems, and controls.  159  •  In order to handle the complex facility management functions such as facility maintenance, this system needs to go down the level o f hierarchy from product level to component level.  •  F M T I S should be able to combine with C A D and other C A F M systems to produce drawings, reports and perform numerical calculations.  •  F M T I S should be secure against any unauthorized use.  Some o f the above observations like system security were already incorporated but others, like going deeper in hierarchy to component level, requires modification and extension in data model. The observation regarding integration with other C A F M systems to perform other facility management functions could be an interesting topic for future research.  7.4  Contributions  The contributions to the research work include the following:  •  Exhaustive literature search and survey o f information management for facility operation.  •  A thorough case study o f U B C ' s project A M P E L , which helped in modeling the systems, subsystems and products in the data model.  •  The development o f a global data model for documents o f interest to facility managers.  160  •  The  identification  of  methodologies  for  designing  a  prototype  facilities  management information system, which might be useful for the design o f similar systems for other facility management functions. •  The development o f a classification scheme based on a core entity named product breakdown structure. This classification scheme is partially based on C S F s M A S T E R F O R M A T . The classification scheme is a three-segment code o f which one segment corresponds to C S F s M A S T E R F O R M A T  to identify building  systems. The proposed scheme could support most o f the products and processes involved in facilities. •  7.5  A n d last, but not the least, the F M T I S itself.  Extension and Future Research  In terms o f extension and future development the next logical step should be the refining and redefining the proposed prototype which should serve as a template for more detailed functions o f facilities management such as annual facility planning, facility financial forecasting and budgeting, interior space planning, and work place specifications. Another area o f interest could involve creating a more tightly knit product model capable o f performing detailed integrated facilities management functions. This would allow the development o f a more comprehensive computer-based  Facilities Management Information System capable o f  providing information and solving the problems o f facility managers.  161  BIBLIOGRAPHY [Aoki et al 93] A o k i , T. Kimura, T., Momozaki, K . , Osaka, H . , and Suzuki, A . (1993) Information Integrated Construction (IIC). Proc. Computing in Civil Engineering,  A S C E . pp.  145-52. [ A P R A 92] Advanced Planning and Research for Architecture. (1992) Facilities Program Volume 2 Technical Appendices. [Bhandari 78] Bhandari, Narinder (1978). Interaction o f Information F l o w with C M Systems. J. of the Construction Division, A S C E , September, pp. 261-267. [Bowler 94] Bowler, Charles E . (1994) Database use in the Engineering Office. Proc. Computing in Civil Engineering.,  A S C E . pp. 1874-79.  [Burger & Halpin 77] Burger, Amadeus M . , and Halpin, Danial W . (1977) Database Method for Complex Project Control../. of the Construction Division, September, pp. 453-463. [Carlson et al 89] Carlson, Robert C , Ji, Wenguang and Arora Adarsh K . (1989). The Nested-Relationship M o d e l . A Pragmatic Approach to E - R Comprehension and Design. Proc. Of  the  Eight  International  Conference  on  Entity-Relationship  Approach  Toronto.  Reproduced by Lochovsky Frederick H . (1990), Elsevier Science Publishing Company Inc. N e w Y o r k . pp. 43-57. [Christian & Pandeya 97] Christian John and Pandeya Amar (1997).Cost Predictions o f Facilities. J. of Management in Engineering  pp. 52-61.  [Coker 85] Coker, G . Bilent (1985). Information Systems For Building Products. J. of Construction Engineering  and Management, December, pp. 411-425.  162  [El-Bibany et al 1997] El-Bibany Hossam; Bechtel John; Branch Ben; Ault Douglas (1997) Facility Management Value Adding Functional Analysis M o d e l . J. of Engineering,  Architectural  A S C E , December, pp. 170-175.  [Fanous & Samara 94] Fanous, Gamil F., and Samara, Mufid F . (1994).  Management  Information System Application on Mult-Million Overseas Project. Proc. Computoing Engineering,  in Civil  A S C E . pp. 2157-2174.  [Feldman & Miller 86] Feldman, P., and Miller, D . (1986). Entity M o d e l Clustering. Structuring a Data M o d e l by Abstraction. The Computer Journal, Vol. 29, No. 4 pp. 348-359. [Fisher et al 94] Fisher, M . , Froese, T., and Phan, D . (1994). H o w do Integration and Data Models add Value to a Project. Computing in Civil Engineering,  pp. 922-997.  [Froese 93] Froese, T. (1993). Product Modeling and Data Standards for A E C , Proc. Of the Fifth International  Conference  (V-ICCCBE).  Computing in Civil Engineering, Anaheim, Cal.  U S A , pp. 1730-37. [Ganeshan et al 94] Ganeshan, R., K i m , S., L i u , L . , and Stumpf, A . (1994). System for Organizing Construction Documents. Proc. Computing  in Civil  A Multimedia Engineering,  A S C E . pp. 1381-88. [Goldhaber et al 77] Goldhaber, Stanley, Jha, Chandra K . , and Macedo, Manuel C . Jr. (1977). Project Principles  Management  and Practices,  Information  Systems  (PMIS).  Construction  Management  John Wiley & Sons, N e w York. pp. 67-188.  [Goldstein & Storey 89] Goldstein Robert, C , and Storey Veda C. (1989). Some Findings on the Intuitiveness Conference  o f Entity Relationship Constructs. Proc.  on Entity-Relationship  Approach  Of the Eight  International  Toronto. Reproduced by Lochovsky Frederick  H . (1990), Elsevier Science Publishing Company Inc. N e w Y o r k . pp. 9-23.  163  [Grimshaw et. al., 1992] Grimshaw Robert W . , Keefe G (1992). Proceedings International  of the 2  nd  Symposium on Facilities Managemnent, Barret P(Ed.) University o f Salford.  [Hamilton 91] Hamilton, Dennis O. (1991). Records Management in Engineering Firms. J. of Management in Engineering  October. pp. 346-355.  [Hiroshi & Nobuoh 93] Hiroshi, N . , and Nobuoh, H . (1993) Filing o f Construction Photos Linked with Database. Proc. Computing in Civil Engineering,  A S C E . pp. 718-21.  [Howard et al 1989] Howard, H . C . , Levitt R . E . , Paulson B . C . , Pohl, J . B . and Tatum C B . (1989) Computer Integration: Reducing Fragmentation in A C E Industry. J. of Computing Civil Engineering [Huff 87] Huff,  in  pp. 18-32. Scott E . (1987)  Management in Engineering  Standardization  o f Construction Documents. J.  of  July. pp. 232- 238.  [Kang & Paulson 97] Kang, Leen S. and Paulson, B o y d C , (1997) Adaptability o f Information Classification Systems For Civil Works. J. of  Construction  Engineering  and  Management A S C E . December, pp. 419-426. [Kangari 95] Kangari, Roozbeh (1995). Construction Documentation in Arbitration. J. of Construction Engineering  and Management, June. A S C E . P P . 201-208  [Kent 89] Kent William (1989). The Leading Edge o f Database Technology. Proc. Of the Eight International  Conference  on Entity-Relationship  Approach  Toronto. Reproduced by  Lochovsky Frederick H . (1990), Elsevier Science Publishing Company Inc. N e w Y o r k . pp. 37. [Konsynski 79] Konsynski, B . R . , (1979). Data Base Driven Systems. University o f Arizona.  164  [Law & Scarponcini 91] L a w , K . H . , and Scarponcini, P. (1991). A view Object Approach for Managing Design/Built Information. Proc. Computing  in Civil Engineering,  A S C E . pp. 192-  201. [Maher 78] Maher, Richard P. (1978). Photographic Records and Time Delays. J. of the Construction Division, A S C E , September, pp. 341-349. [O'Connor  93]  O'Connor James T.  (1993).  Need  Accommodates Engineered Products. J. of Construction  For  Specification Format  Engineering  and  That  Management,  A S C E , December, pp. 757-768. [Rasdorf &Herbert 88] Rasdorf, W . J . , and Herbert, M . J . (1988) C I M S : A Construction Information Management System. Proc. Computing in Civil Engineering,  pp. 33-45.  [Riley & Sabet 94] Riley, Michael J., and Sabet, Hamid H . R . (1994). Building Product M o d e l , A First B r i c k in Computer Integrated Construction. Proc. Computing  in Civil  Engineering,  A S C E . pp. 767-777. [Sanvido & Paulson 92] Sanvido V . E . , and Paulson, B o y d C , (1992) Site Level Construction Information System. J of Construction Engineering  and Management, December, pp. 701-15.  [Scarponcini, 96]. Scarponcini, P. (1996) Time For Integrated Approach to Facilities Management. J. o f Computing in Civil Engineering , A S C E . p. 3. [Tenah 84] Tenah, K w a k u A . (1984). Management Information Organization and Routing. J. of Construction Engineering and Management A S C E , March, pp. 101-118. [Tenah 84] Tenah, K w a k u A . (1984). Management Information Organization and Routing. J. of Construction Engineering  and Management, A S C E March, pp. 101-118.  [Tenah 86] Tenah, K w a k u A . (1986). Construction Personnel Role and Information Needs. J. of Construction  Engineering,  March, pp. 33.  165  [Teorey et al 86] Teorey, T.J., Yang, D . and Fry  J.P., (1986). A L O G I C A L Design  Methodology for Relational Databases Using the Extended Entity-Relationship M o d e l , A C M Computing Survey, Vol.18. N o . 2 June. pp. 197-222. [Toker 90] Toker, Michael D . (1990) Utilizing on site Computer Based Information System. Excellence in the Constructed Project, Proc. of Construction  Congress 1990, Canadian  Society o f Civil Engineers, pp. 272-277 [Vanier et al 93] Vanier, D j , Mellon, B S , Thomas, R , and Worling, J L . (1993) Management o f Construction Information Technology for Construction, k.s. Mathur et al (Eds), World Scientific Publishing C o . Singapore, pp. 75-84.  Books [Atre 80] Atre, S. (1980). Database:  Structured Techniques for Design, Performance,  and  Management. John Wiley & Sons N e w York. [Bamford & Curran 91] Bamford Carl, and Curran Paul (1991) Database Management Systems. Data Structure, Files and Databases, Macmillan Education L t d . , L o n d o n , U . K . C h . 9, pp. 155-160. [Barton 85] Barton, Paul (1985). Information Systems - A n Overvie. Information Systems in Construction  Management,  Edited by Paul Barton, Bartsford Academic and Educational,  London. [Baynon-Davies 93] Baynon-Davies Paul (1993) Information System Development, Macmillan Press L t d . London U . K . [Becker 90] Becker F (1990). The Total Workplace: Facilities Management and the Total Organization.  V a n Norstrand Reinhold Company N e w York.  166  [Bengtsson & Bjornsson 87] Bengtsson, Sten and Bjornsson, Hans C , (1987). Production Data Capturing, Managing  Construction  Worldwide, V o l . One, Lansley, Peter R., et al.,  (Eds.), E . & F . N . Spon, London, pp. 426-436 [Brodie 84] Brodie, M . L . , (1984). On the Development o f Data Models, Brodie M . L . , Mylopoulos J., Schmidt J.W. (Eds) On Conceptual Data Modeling, Springer-Verlag. [Bull 90] B u l l , M a l c o m (1990). Students' Guide to Databases. Heinemann Newnes, Oxford, UK. [Cary & Michael 97] Cary N . Prague and Michael R. Irwin (1997) Access 97 Bible. I D G B o o k s Worldwide, Inc. Foster City California. [Codd 70] Codd, E . F . A Relational  Model of Data for Large Shared Data Banks  (1970).IBM Research Laboratory, San Jose, C A , . Communications o f the A C M 13(6), June, 1970 pp. 337-387. [Date 90] Date, C.J. (1990). A n Introduction to Database Systems. V o l . 1 5  th  E d . Addison-  Wesley Publishing Company, Inc., Reading Mass. Ch.22. [Hamer 88] Jaffery M . Hamer (1988). Facility Management Systems. V a n Norstrand Reinhold Company N e w York. [Hausen 84] Hans-Ludwig Hausen (1983). Software Validation. Elsevier Science Publishers B . V 1000 B Z Amsterdam, The Netherlands. [Kiang 91] Kiang, Q . L . (1991) Building Maintenance and Modernization. Research and Practice Trends. Management,  Quality and Economics  in Buildings.  A . Bezelega and P.  Brandon, eds. E & F N S P O N , London , England, pp. 1167-1177 [Lock 92] L o c k , Dennis (1992). Information Management-] &2. Handbook o f Engineering Management, C h . 20 & 27.  167  [McFadden & Hoffer 88] MaFadden, Fred R., and Hoffer, Jeffery A . 1988. Database Management.  C h . 6 to Ch.9. The Benjamin/ Cummings Publishing Company, Inc., California.  [Mintzberg 73] Mintzberg, H . (1973). The nature of Managerial  Work, Harper and R o w ,  New York. [Murdick & Ross 75] Murdick, R . G . , and Ross, J.E. (1975). Information Modern Management.  Systems for  Prentice-Hall, Inc., N e w Jersey, pp. 436-465.  [Paulson 95] Paulson B o y d C , (1995) Computer Applications in Construction, M c G r a w - H i l l Inc. [Pierce 88] Pierce, David R. (1988). Project Planning & Control for Construction, R . S . Means Company, Inc. Kingston, M a . [Rob & Coronel 95] Rob, P. and Coronel, C , (1995) Database System: Design, Implementation  and Management  (Second Edition). B o y d & Fraser Publishing Company,  Danvers, Massachusetts, C h . 2,5,11 12 [Salzberg 86], Salzberg Betty Joan (1986) An Introduction  To DataBase  Design. Chapter 2.  Academic Press Inc. Orlando, Florida. [Schneiderman 92] Schneiderman, B .  (1992) Designing the User Interface. Strategies for  Effective Human Computer Interaction  .2  nd  Edition, Addison-Wesley, Reading, Mass.  [Silberschatz et al 97] Silberschatz Abraham; Korth Henri F . ; Sudarshan; (1997) Database System Concepts,  3  rd  ed., M c G r a w - H i l l Companies Computer Science Series  [Teicholz 92] Teicholz Eric (1992), Computer Aided Facilities Management. M c G r a w - H i l l , Inc. N e w Y o r k Chapter 1,2. [Townsend 92] Townsend, James J., (1992) Introduction to Databases. Que Corportation, Carmel. I N U S A Chapters 1-4  168  [Tsichritzis et al 82] Tsichritzis, Dionysios C . and Lochovsky (1982). Data Models. PrenticeH a l l Inc., Englewood Cliffs, N . J . [Vetter 87] Vetter, M . (1987) Strategy For Data Modelling.  Jonh Wiley and Sons L t d . N e w  York. [Yeo et al 78] Y a o , S.B., Navathe, S.B., and Weldon J.L., (1978). A n Integrated Approach to Database Design. Y a o , S B . , Navathe, S.B., and Weldon J . L (Eds), Database Design Techniques I: Requirements and Logical Structures Proceedings, N e w Y o r k ; M a y (1978) in Goos, G and Hartmanis J. (Rds). Lecture Notes in Computer Science, Springier-Verlag, 1982.  169  APPENDICES Appendix A: Data Dictionary  This appendix contains the tables describing the attributes o f each entity as presented in section 6.7. Each attribute contains following information: field name, data type, index and comments. Field name is same as the name o f attribute. Data type represents the type o f data the field will store, e.g., text, number, date/time, currency, yes/no. The item number is further categorized into long integer, byte, integer, single, double, replication I D Length represents the storage space required for the values stored in he field. Index represents the setting o f the index property. A n index speeds up queries on the indexed fields as well as sorting and grouping operations. Comments show a brief description o f the field.  The term 'list o f data elements' is used as a title in this appendix. The following abbreviations and legends have been used through out the tables: Bold field name(s)= key field(s); L o n g =Long Integer, D O K = Duplicate O K ; N o D = N o Duplicate.  170  Table A . l  List of Data Elements for Commissioning  Field Name  Data Type  Length  Index  Comments  Commissioning ID  Text  50  Yes(NoD)  PBS ID Product Location  Text Text  50 50  Yes(DOK) No  Performed B y  Text  Text  No  Commissioning Date  Date/Time  Short Date  No  Unique identity o f commissioning Process Product identifier Where commissioned product id located The person who performed commissioning Date o f commissioning  Table A.2  List of Data Elements for Contacts  Contact ID  Data Type Text  Length 50  Index Yes(NoD)  Comments Unique identity o f contact  Contact Contact Contact Contact Contact  Text Text Text Text Text  150 150 20 20 50  No No No No No  Company's legal name Company's address Company's phone number Company's fax number The contact person in the organization  Field Name Name Address Phone# Fax# Person  Table A.3  List of Data Elements for Contracts  Contract Id  Data Type Text  Length 50  Index Yes(NoD)  Comments Unique identifier o f contract  Facility I D  Text  50  Yes(DOK)  The facility where contract will be performed  Contract Name Contract Start Date Contract Finish Date Contract Cost Contractor Name  Text Date/Time Date/Time Currency Text  150 Short Date Short Date Auto 150  No No No No Yes(DOK)  Field Name  The start date o f contract The finish date o f contract The total value o f contract The company which is awarded contract  171  \ Table A.4  List of Data Elements for Drawings  Drawin2 #  Data Type Text  Length 50  Index Yes(NoD)  Comments Unique identifier  Drawing Title Drawing Type Issue Date Revision # Prepared B y Approved B y Draw-Picture  Text Text Date/Time Text Text Text O L E Object  150 50 Short Date 10 50 150  No No No No No No No  The drawing name The drawing category The date o f issue Whether revised or not? Person preparing drawing Approving Authority The drawing picture  Field Name  Table A.5  List of Data Elements for Facilities  Field Name  Facility ID  Data Type Text  Length 50  Index Yes(NoD)  Comments Unique Identifier  Facility Facility Facility Facility  Text Text Text O L E Object  50 50 150  No No No No  The The The The  Name Owner Address Photo  Table A.6  name o f facility owner o f facility location o f facility facility photograph  List of Data Elements for Permits  Field Name  Data Type  Length  Index  Comments  Permits  Text  50  Yes(NoD)  It is the unique identifier  Occupancy Date Permit Type Permit Issue Date Permit Fee Issued T o  Date/Time Text Date/Time Currency Text  Short Date 50 Short Date Auto 150  No No No No No  The Type o f permit, e.g., gas etc. The date o f permit issue The fee paid by applicant Issued to which party  Permit-Image  O L E Object  No  The image o f permit document.  Table A.7  List of Data Elements for Products  Field Name  Data Type  Length  Index  Comments  Product Name  PBS ID  Text Text  150 50  Yes(DOK) Yes(NoD)  S_System I D  Text  50  Yes(DOK)  Supplier I D Manufacturer I D  Text Text  150 150  No No  The name o f equipment The unique identifier o f products or equipment Same as S_System I D in Sub System table The supplier identification The manufacturer 172  Product Rating Product Weight Product Model  Text Text Text  Product-Image  OLE Object  Table A.8  100 50 50  No  identification The product capacity The product weight The model number of product Product Photo Image  No No No  List of Data Elements for Tests  Field Name  Data Type  Length  Index  Comments  Test Id  Text  50  Yes(NoD)  The unique identifier  Test Name Date Conducted Test Contractor  Text Date/Time Text  150 No Short Date No 150 No  Test Loc Description  Text  150  Testing Method Approval#  Text Text  Text Text  Remarks Test Report-Image  Text OLE Object  Text  The name of test process The date of testing The contractor responsible for carrying out test Yes(DOK) The place, area or location where test was performed The method used for testing No No The UBC approval # showing the test was verified The remarks on test report No The image of test report No  173  Table A.9  List of Data Elements for Warranties  Field Name  Data Type  Length  Index  Comments  Warranty ID  Text  50  Yes(NoD)  It is the unique identifier  Warranty Start Date  Text  50  No  Warranty Period  Text  150  No  Warranty Contact Person Item Warranted  Text  50  Yes(DOK)  Text  100  No  Warranty Doc-Image  O L E Object  It represents start o f warranty date The total coverage period o f warranty The person to be contacted in case o f any problem The product, equipment or sub-system warranted The image o f warranty document  Table A.10  No  List of Data Elements for WBS  WBS ID  Data Type Text  Length 50  Index Yes(NoD)  W o r k Item  50  50  No  Field Name  Table A . l l  Comments It represents the unique identifier It represents the item o f work associated with W o r k Break D o w n Structure  List of Data Elements for Commissioning Locations  Field Name  Data Type  Length  Index  Comments  Doc Location ID  Text  50  Yes(DOK)  Commissioning ID  Text  50  Yes(DOK)  Same as in D o c Location I D in Locations Table Same as in Commissioning ID in Commissioning Table  Table A.12  List of Data Elements for Locations  Doc Location ID  Data Type Text  Length 50  Index Yes(NoD)  D o c Location Name Remarks  Text Text  50 100  No No  Field Name  Comments It is unique identifier o f Locations Table Individual location names The explanation o f location names  174  Table A.13  List of Data Elements for Contact Locations  Field Name  Data Type  Length  Index  Comments  Doc Location TD  Text  50  Yes(DOK)  Contact ID  Text  50  Yes(DOK)  Same as in D o c locations I D in Locations table Same as Contact I D in Contacts Table  Table A.14  List of Data Elements for Contract Doc Locations  Field Name  Data Type  Length  Index  Comments  Doc Location ID  Text  50  Yes(DOK)  Contract Id  Text  50  Yes(DOK)  Same as in D o c locations I D in Locations table Same as Contract I D in Contracts Table  Table A.15  List of Data Elements for Drawing Locations  Field Name  Data Type  Length  Index  Comments  Doc Location TD  Text  50  Yes(DOK)  Drawing #  Text  50  Yes(DOK)  Same as in D o c locations I D in Locations table Same as Drawing # in Drawings Table  Table A.16  List of Data Elements for Permit Locations  Field Name  Data Type  Length  Index  Comments  Doc Location ID  Text  50  Yes(DOK)  Permit #  Text  50  Yes(DOK)  Same as in D o c locations I D in Locations table Same as Permit # in Permits Table  Table A.17  List of Data Elements for Product Locations  Field Name  Data Type  Length  Index  Comments  Doc Location ID  Text  50  Yes(DOK)  PBS ID  Text  50  Yes(DOK)  Same as in D o c locations I D in Locations table Same as P B S I D in Products Table  175  Table A.18  List of Data Elements for Product Drawings  Field Name  Data Type  Drawine#  Text  PBS ID  Text  Table A.19  Length 50  Yes(DOK)  Length 50  PBS ID  Text  50  Index Comments Yes(DOK) Same as Test ID in Tests table Yes(DOK) Same as PBS ID in Products Table  List of Data Elements for Test Doc Locations  Test ID  Data Type Text  Length 50  PBS ID  Text  50  Field Name  Index Comments Yes(DOK) Same as Test ID in Tests table Yes(DOK) Same as PBS ID in Products Table  List of Data Elements for Warranties Locations  Field Name  Data Type  Length  Index  Warranty ID  Text  50  Yes(DOK)  Doc Location ID  Text  50  Table A.22  Same as PBS ID in Products Table  List of Data Elements for Product Tests Data Type Text  Table A.21  Comments Same as in Drawings Table  Field Name TestrD  Table A.20  Index  Comments  Same as Warranty ID in Warranties table Yes(DOK) Same as Doc Location ID in Locations Table  List of Data Elements for WBS  Field Name  Data Type  Length  Index  Comments  WBS ID  Text  50  Yes(NoD)  The unique Identifier  Work Item  Text  150  No  Represents the WBS item description  176  Table A.23  List of Data Elements for SubjSystems  Field Name  Length  Index  S System ID  Data Type Text  50  Yes(NoD)  Sub_System Name  Text  50  No  System ID  Text  50  Represents the Sub_Systems as noted in AMPEL Yes(DOK) Same as in Systems table  WBS ID  Text  50  Yes(DOK) The same as in WBS table  Table A.24  List of Data Elements for Facilities Locations  Field Name  Length  Facility ID  Data Type Text  Doc Location ID  Text  Table A.25  Comments The unique Identifier  50  Index Yes(NoD)  Comments Same as in Facilities table  50  Yes(DOK)  Same as Doc Location ID in Locations Table  Comments The unique Identifier Represents the Sub_Systems as noted in AMPEL  List of Data Elements for Systems  Field Name System ID  Data Type Text  Length 50  Index Yes(NoD)  System Name  Text  50  No  177  Appendix B: Default Relationships Table App.2.1 represents the default relationships between tables in the database system. The column 'primary table' denotes one-end o f the one-to-many (1-M) relationship. The 'related table' column shows the table is at the many-end o f the relationship. The column 'fields' contain the attribute values as already explained in section 6.7. The column 'type' shows the relationship between entities as shown in section 6.6.1 to 6.6.7. The column enforce shows whether referential integrity has been enforced or not.  Table B.l  Default Relationships  Primary Table  Related Table  Field(s)  Type  Enforce  Locations Locations Locations Locations Locations Locations Locations Commissioning Contacts Contracts Drawings Products Permits Tests Warranties Sub Systems Products Products Contacts  Commissioning Location Contacts Location Contracts Location Drawings Location Products Location Permits Location Warranties Location Commissioning Location Contact Locations Contracts D o c Location Drawing Locations Products Location Permit Locations Test D o c Locations Warranty Locations Products Product Drawings Commissioning Products  D o c Locations I D D o c Locations I D D o c Locations I D D o c Locations I D D o c Locations I D D o c Locations I D D o c Locations I D Commissioning I D Contact I D Contract ID Drawing # P B S ID Permit # Test I D Warranty I D Sub System I D P B S ID PBS ID Contact I D / Manufacturer I D  1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M 1-M  Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes  178  Primary Table  Related Table  Field(s)  Type  Enforce  Products Contacts  Product Tests Warranties  1-M 1-M  Yes Yes  Drawings Contacts WBS Contacts  Product Drawings Contact Trades Sub Systems Products  PBS ID Contact I D / Warranty Contact Person Drawing # Contact I D W B S ID Contact I D / Supplier I D  1-M 1-M 1-M 1-M  Yes Yes Yes Yes  Table B.2  Queries and Join Tables  Primary Table  Related Table  Field(s)  Type  Enforce  Contacts Trade Contact Locations  Contact I D D o c Locations I D  1-M 1-M  Yes Yes  Contact Trades  Contact I D  1-M  Yes  Contracts Information Contracts Locations Contracts  Contracts D o c Location Contracts D o c Location Contacts  Contract I D D o c Location I D Contractor Name/ Contact I D  1-M 1-M 1-1  Yes Yes Yes  Drawings and Products Drawings Drawings Contacts  Product_Drawings Product_Drawings Products  1-M 1-M 1-M  Yes Yes Yes  Drawings  Contacts  Drawing # PBS ID Contact I D / Manufacturer I D Prepared by/ Contact I D  1-M  Yes  Drawings Locations Locations Drawings  Drawing Locations Drawing Locations  D o c Location I D Drawing #  1-M 1-M  Yes Yes  Drawing Numbers and Products Drawings Products Primary Table  Product_Drawings Product Drawings Related Table  Drawing # PBS ID Field(s)  1-M 1-M  Yes Yes Enforce  Contacts Information Contacts Locations Project Consultants Contacts  Type  Drawings Products W B S & Subsystems 179  Drawings Products Sub Systems WBS Drawings  Product_Drawings Product_Drawings Products Sub_Systems Contacts  Drawing # PBS ID Sub System I D W B S ID Prepared by/ Contact I D D o c Location I D  1-M 1-M 1-M 1-M 1-M  Yes Yes Yes Yes Yes  Locations Manufacturer and his Product Contacts Contacts  Drawing Locations  1-M  Yes  Contact Trades Products  Contact I D Contact I D / Manufacturer I D  1-M 1-M  Yes Yes  P B S and Subsystems Sub Systems WBS Contacts  Products Sub_Systems Products  1-M 1-M 1-M  Yes Yes Yes  Contacts  Products  Sub System I D W B S ID Contact I D / Manufacturer I D Contact I D / Supplier I D  1-M  Yes  Product D o c Location Info Products Locations  Product Locations Product Locations  P B S ID D o c Location I D  1-M 1-M  Yes Yes  Products Tested their Suppliers and M a n u Products Tests Contacts  Product_Tests Product_Tests Products  1-M 1-M 1-M  Yes Yes Yes  Contacts  Products  P B S ID Test I D Contact I D / Manufacturer JJD Contact I D / Supplier I D  1-M  Yes  180  Primary Table Product Tested Location Products Tests Locations Tests  Related Table  Field(s)  Type  Enforce  Product_Tests Product_Tests Test Doc Locations Test Doc Locations  PBS ID Test ID Doc Location ID Test ID  1-M 1-M 1-M 1-M  Yes Yes Yes Yes  Test Locations Tests Locations Warranty Start and. Finish Date Warranties Products Contacts  Test Doc Locations Test Doc Locations  Test ID Doc Location ID  1-M 1-M  Yes Yes  Product_Warranties Product_Warranties Products  1-M 1-M 1-M  Yes Yes Yes  Contacts  Products  Warranty ID PBS ID Contact ID/ Manufacturer ID Contact ID/ Supplier ID  1-M  Yes  Warranty Locations Warranties Locations Contacts  Warranty Locations Warranty Locations Warranties  Warranty ID Doc Location ID Contact ID/ Warranty Contact Person  1-M 1-M 1-M  Yes Yes Yes  PermitJLocations Locations Permits Locations  Permit Locations Permit Locations  Permit# Doc Location ID  1-M 1-M  Yes Yes  Suppliers and Products Supplied Contacts Contacts  Contact Trades Products  Contact ID Contact ID/ Supplier ID  1-M 1-M  Yes Yes  181  Appendix C: System Generated Reports and Printouts  This appendix presents some o f the system generated drawings, test and permit reports to demonstrate the functionality o f the proposed system.  •  Figure C. 1  System Generated Drawing o f High Head R o o m Lab  •  Figure C.2  System Generated Image of Natural Gas System Permit  •  Figure C.3  System Generated Test Report Image  •  Figure C.4  System Generated Drawing o f Safety R o o f Anchor & Tie Back System  Drawing tt  Figure C . l  System Generated Drawing of High Head Room Lab  182  Perm it Type  Natural Gas Installation Permit  Pfovtnce of;.; Briifsh Columbia;!  M-iiiiYa- MUI'J CiPAl AFFAIRS., i\KFCRcAT|0>l A.NU jji!jUSW\i;:!! :: 3>"Xi :£i«i'IM!:i:JUNS^EWIC5E 51V ? &S::  GAS PERP  ;  FEES PAYABLE TO MIMtSTEp D.F FINANCE AND CORPORATE RELAl I0N$  , A P P U C A N T : C O N T R A C T 0 1 OF (HC-VEOW\En I?" MAlt.no ;;i::::::^: • \ ADDRESS 3:FFFq|t4T FnOU INSTAU.AlflO?)) I|N<VE • • • DOCTORS l i j KHQ B Q L S CumgaffY i L I H I T E P , YiiiLnr:«i]:>iK;s 7 P . O . B o * 33919, S t a t i o n D j - I I i • ' '• 1 '  •••;;;;;::;:; :;-::;: ::;::!:~ J L. :  WIL  I  :COE  •PROVISOS :  I  B.C|.  C O N T R A C T O R COMPLETETI'IS SFirriOKi  .  N A T U R A L GAS  HEHVIT c u s s  _;  li\DU$rRIAL I APT/DOS DO  \  I S I N G L E FAMILY  20*  ._ COMME^CIM. .^.::::INSLSTSiftt!^  20S  :  ^-.'CONGO  4. UN.T>EATF^ 3. E.'ACS I I F A T F R 6. TIRCPLACF 7. y.U/. &IRPCT c. V.U.A. » i f l t c r .  *J6 ME  J. I  CODC  [ H O MEOWN'ER':COMPLETE THS SECTON •  :  u  '  |  NATURAL GAS  :JiiJ"^™'a=;;rr=\o  TO:I  OH  I  i  i  I  I...!  L  PCRMT TVPF COl^b -.aOILER 9.flOOFTOP UNT| 2. WATER HF«T=R IP. DriYtfn  !; i: I NiiyyeH or G A S I vET=R$.  2«  - U,».C. •_ , „ i :  P E R M I T DETAIL A L L A . P P L I L ^ S T S CO<  NO.  L  1355 B a s t K a l i -J^-I—i—i—i— i  liMiyiiiiiiyiyy  :  .  , :::::: Ljgiyragny.o* BHiTi-m coui  j rtx,TH. CODE  :;li;;;;l:;:::LMi;  ftl:SI3~ERE0  INSTALLATION ADDRESS 'f!lM;iTOl.P.',ST  :  I _Lai  T  PERMIT V.AY |?E OBTAI.VtD AT AMY C OK SAFETY FN-GINEEF.IN8 StKVICC  PROPANE  •  •X7.  I:;IIm;TIISSE .raj xt.ni;v*- •-..••T > :  M !  :  :  NUMBER o^- JVIlS 3  INPUT  :::BrgH:  ttoi  iiiiiWSiljii  y  ;;rn..N MrSfcfW*.<KJ::.-;:va.-2-TWT-WOtftffcw1-yVH'3 = '* vv xllVJtnA::E:W*:V:'ML.:;:*:7tt l:«lirjT:-Ml «FL47 CH, A^i^llM-'MT- T>-E\tD;iC ::^HU':fS:lW.«!»;5s.rrE;«^^ ::&lr!V:F0Fl iHsftAI I: IV. Mr! MOFER F.MiTlOM H:i 111::i I:~r,!-^,; H GITM" M ") 'IV-  ••Z. RAS3CTOP '3. WLL OVEN V- DEEF TAT T R Y E | 15 BARBEOLC 16 CHINESCCOOKFt  :  :  H  C  *!.L APPLJCAWT:S COMPI ?"t IMS SECTION GAfi PPfcSSL'RE : TOT*:; CONN ±C •"• ED LOAD •'HOr^hE SUPPLER(lr APP...C4RL F| ;  MOM  ir  LOW  2 FSIC RT.l.'MH  : 1:igRJE.TO:MEt.1MKY: »HX :hjWB:W.=t,'iE8S ~nE:ami.".:t>: fx:M^NCI?--.L .<."-HKl••••••If-:  Figure C.2  TOT*  System Generated Permit Image of Natural Gas Subsystem  183  Test Name  Heating System and Chilled Water System  Close  ;:::::::::::::::!:;:::;;:::  33 ll  •  T  S3  ;.Tcr.cc-atur6: ; :  •  ^  ^  ^  ^  3p«ra^in<j P r a c c J X n i  ir'i'hCCi  r ~  '[""r^'y  •  3*  ^  "  r  V»r£^:;.:::  Actual lest A c e s ' j r o : f i n e R<j3Mlfca ?uiu l e s L avarUed: fc.rrx.Jl Vijao Test 3a*i?lc-cd ; ft*j^4_  ••  r.TrrTTTTTTTTrT  10 f-s-\.  : £: u H w i r L t j m r N I : : :Dtl L C L 4 S : | . 1 S » £ C T I C H FtJPCMT :  • *••* : ujf : »Mtu ; p i  Fitness:  Figure C.3  ^fiCf  *t»" 'I  Jcit.il IM Jpi-vhtp 'S^  03fifi  £ a!H. J KJJQ rV^1>:r*(>i\jAr«»irKT:::  IsZiAWttiL  System Generated Test Report Image  184  : Drawing; it  Bill! :1? m i ;  iiaS;;:! iiiEay::;:::  r  : litiNiil^L.; Figure C.4  .  'ft  : i;;!!:; h U N:! f  ;  System Generated Drawing of Safety Roof Anchor & Tie Back System  185  Appendix D: List of C A F M Vendors  Accugraph Corp.  U  Mountain Top  >  HP; SUN;  IBM  W  Achieve! Technology, Inc.  D  Telecommunication s/ Cable  Space Inventory Mana gement  Space Allocation/ Forecasting  Security  Room Scheduling  Maintenance/Operatio ns Management  Lease/ Property Management  Integrated CAFM  Furniture Inventory /S pecifications  Operating System  Construction Management  Software Name/Model  Platform  Company Name  Architecture/ Interior 1banning  CAFM  Facility Budgeting /Coist Accounting  Source: Automation (May 1996) pp. 38-48  1  1  Fast Regs PC  W  A E C Data Systems, Inc  w  Facility Management  &  D E C ; HP; IBM; S U N  u  American Computer Software  D  Property Management Series  &  PC  W  Apperture Technologies, Inc  M  Apperture Visual Information Manager  &  M A C ; PC  W  1  I  1  1  1  2  1  1  1  1  2  2  1  1  1  186  U;  Platform  2  1  1  2  2  1  2  2  2  1  1  1  1  2  Telecommunication s/ Cable Management  D E C ; HP; I B M ; SGI; S U N  1  Space Inventory Mana gement  1  1  Space Allocation/ Forecasting  D;  1  Security  Autodesk, Inc.  Room Scheduling  1  Maintenance/Operatio ns Management  W  Apple Computer Inc.  Lease/ Property Management  1  Operating System  Integrated CAFM  1  Software Name/Model  Furniture Inventory /S pecifications  Construction Management  M  Company Name  Facility Budgeting /Coist Accounting  Architecture/ Interior Planning  CAFM  2  1  1  2  2  2  MAC  A R C H I B U S , Inc. A R C H I B U S / F M 10 PC  2  w Bentley Systems, Inc.  D;  MicroStation  M;  D E C ; HP; I B M ; ITG; M A C ; PC; SUN  U;  1  1  W Buildings Systems Design Inc.  1  W  1  SpecLink; Costlink PC CADapult Ltd.  D;  CADapult F o r Windows  W  1  2  2  1  2  2  2  1  1  2  PC  187  60  1  1  2  tions Man  ble Managem  1  «3 o  2  2  2  2  2  1  1  1  }-i 1> O .  2  •a  Telecornmunication  2  inagement  2  Space Inventorj  1  2  CO  Room Schedulii  1  Lease/ ' Property  2  Integr ated CAF  2  "a  CO  Maint enance/O]  nagement  /Specifica  2  s  orecasting  W  s  Space Allocatio  OnRequest  & o  1  Securi  M;  60 c  c < L) 60  Furnit;ure Inven  CAData Corp.  •a  Facililty Budgeti  Operating System  Platfo  Software Name/Model  c o  =s  Const ruction M  Company Name  ArchilLecture/ In  •c  gement  ar Plannin  60  Cost Acco  CAFM  MAC; PC C A D C A M , Inc.  D;  ITG; P C  W  C A D Systems Unlimited, Inc.  W  1  1  2  SLICK! For Windows V 4.0  Cambino Networks, Inc.  1  U  COMMAND HP; S U N C A S I - R U S C O , Inc.  D;  Entry Perfect, Picture Perfect  U;  IBM; PC; 0  W  Classical Real Estate Systems, L . C .  D;  The Office Administrator  W  1  1  1  1  1  PC  188  Classical Real Estate Systems, L . C .  D;  The Compliance Administrator  W  1  1 1  1  1  1 1  1  Telecommunication s/ Cable  Space Inventory Management  Space Allocation/ Fore:casting  Security  Room Scheduling  Maintenance/Operatio ns Management  Lease/ Property Management  Integrated CAFM  Furniture Inventory /S pecifications  Facility Budgeting /Co ist Accounting  Operating System  Construction Management  Software Name/Model  Platform  Company Name  Architecture/ Interior 1banning  CAFM  PC Classical Real Estate Systems, L . C .  D;  Corporate W o r k  W  PC Cyco International  D;  AutoManager View; AutoManager  W;  WorkFlow  0  2  PC Data One, Inc.  w  1  2 2  1 2  2  2  Design Express PC Data Stream Systems Inc.  D;  MP2 for Windows  W  PC  0  2 2 2  2  1  189  Software Name/Model  Operating System  Drawbase Software  The Davis Co.  EQ2, Inc.  PC;0  A u r o r a Phoenix  Company Name  PC W  Dranetz Technologies, Inc. W  u  W  W  1 1  Lease/ Properly Management  1 1  1 1  D R A N - V I E W ; D R A N - S C A N 2000  PC  D  H E M S 2000 1 1  1 1  Telecommunication sf Cable  Space Inventory Management  Space Allocation/ Forecasting  Security  Room Scheduling  Maintenance/Operations Management  Integrated CAFM  1  Furniture Inventory /Specifications  Facility Budgeting /Cost Accounting  Construction Management  Architecture/ Interior Planning  Platform  CAFM  Drawbase  D  Y a r d i ; Skyline; Custom  1  Ericksons Systems  1  HP; P C  w  190  Operating System  FM:  C. CURE  /Vision  MAC; 800;  Company Name  Software Name/Model  Inspection Manager D  PC >  Fields and Screens Inc.  W o r k O r d e r Wonder for Windows  F M : Systems  w  Software House M 2 1  Facilities Management Systems Inc.  2  2 1  2  Telecommunication s/ Cable Management  Space Inventory Management  Space Allocation/ Forecasting  Security  Room Scheduling  Maintenance/Operations Management  Lease/ Property Management  Integrated CAFM  Furniture Inventory /Specifications  Facility Budgeting /Cost Accounting  Construction Management  Architecture/ Interior Planning  Platform  CAFM  1  W  1  D  PC  w  0  2  SPACE  PC  1  C.CUREStastion  w  PC  0  191  CAFM  1 1 1«  u.  3  to  c B  1  E g o oi  M  •c  3 C/3 <D  1 8  s s >mmunication s/ C  1  ' Property Manage:  'tj  s  00 .S  Inventory Manage  Software House  a  o O  S  Allocation/ Foreci  El  '£  a  Scheduling  1  i  '5  ure Inventory /Spe  Operating System  <  y Budgeting /Cost  Software Name/Model  tiction Manageme  ecture/ Interior P1E  §  Company Name  C .2 13  itedCAFM  c  13= O o o  60  aiance/Operations  00  1  1  o J£ H  1  1  1  o.  1  C . C U R E 750; C.CURESystem 1 Plus M A C ; PC  W  0  w  Strohl Systems LDRPS; BIA  1  Professional  PC Interprise  D  I  1  1  1  I  1  1  1  1  ARCHIBUS / F M 1 PC  w  0 J.D.Edwards World Solutions Co.  M  J.D.Edwards Construction Solutions  u  Multiple Operating Systems  lt  1  i  192  CAFM 60  d '2 3  cd  o  •c  Company Name  c 3  Software Name/Model Operating System  cd  Maxwell Systems Inc.  D  The Contractor by Maxwell  >  PC; O  W|  2  oo 3 c ocd 3 o O o g u eo 3 <: c u 6 o oa. o S cd  I o =  3  o O  y  00  a  OO T3 3  o cd  UH  & 3 a  |  d  1  00 cd  3  £  cd  00  3  TO.  •a  §  CD CL  o  3 3  C  O  "S o 3 3  cd 4>  cd (D  00  T3  a)  o c§  E  o •a cd o o  a "3 •d ooo  3  cn Cd  o o  o  2  3°  •c 3  o  <D  CO  (L> O cd  CH  CO  a > o o cd  •s O  d o  Q  d  1  1 8 cd  OH  CO  u M I C R O m A I N Corp.  D  Maintenance Supervisor II PC Microwest Software Systems, Inc.  W I D  AMMS PC Raish Enterprises, Inc.  I  W| D  W o r k Order  PC;0  U  w 0  193  D  Raish Enterprises, Inc.  2  Telecommunication s/ Cable  Space Inventory Management  Space Allocation/ Forecasting  Security  Room Scheduling  Maintenance/Operations Management  Lease/ Property Management  2  Integrated CAFM  1  Operating System  Furniture Inventory /Specifications  Facility Budgeting /Cost Accounting  Software Name/Model  Construction Management  Company Name  Architecture/ Interior Planning  Platform  CAFM  2  Job Costing for Construction  U  Management PC;0  w  0 Resterex / E x p e r t ™ Graphics  w  1  2  w  1  2  w  1  2  RxAutoImage P r o ™ ; R x H i g h l i g h t ™ Combo PC Resterex / E x p e r t ™ Graphics Rx Index ™ / R x V i e w ™  Combo  RxSpotlight™ PC Resterex/ E x p e r t ™ Graphics R x V e c t o r y ™ ; RxVectory P l u s ™ PC  194  Operating System  Systems Specialists, Inc.  Property Management & Accounting  System (pmas  IBM  0  Ten M a n Systems Inc.  IBM  Timberline Software  MAC; PC D  2 1 2  0 1 1  D  1 1  PC  w  T M A Systems, Inc. M  1 2 1 2  Telecommunication sf Cable  Space Inventory Management  Space Allocation/ Forecasting  Security  Room Scheduling  Integrated CAFM  Furniture Inventory /Specifications  Facility Budgeting /Cost Accounting  Construction Management  Architecture/ Interior Planning  Maintenance/Operations Management  Software Name/Model  Lease/ Property Management  Company Name Platform  CAFM  W  1  Precision Collection; Gold Collection  2  T M A - T h e Maintenance Authority  W  0  195  Operating System Touchcom, Inc.  lu  Teleconlmunication s/Cable  Space Inventory Marlagement  Security  om Scheduli  a  CO  1  W  §>  Space Al location/ Fo recasting  C  intenance /Operations Manageme  -4—>  Lease/ Property Management  c  egrated CAI  Limiture Iiwentory /Speducations  cility Bud geting /Cost Accountin  Software Name/Model  Constniction Mana gement  Company Name  Platform  CAFM  Architecture/ Interior Planning  6D  1  2  PC  ViaGrafix  D  DesignCAD  >  MAC;P  M  1  W >  0  • • •  Facility Management Applications: l=Primary Application; 2=Secondary Application Platform: D = D O S ; M = Macintosh; U = U N I X ; W = Windows; 0 = Others Operating Systems: D E C = D E C N o n P C ; H P = Hewlett-Packard, Series 9000; I B M = I B M N o n - P C M o d e l ; I T G = I N T E R G R A P H ; P C = I B M P C / Compatible; M A C = Macintosh; S G I = Silicon Graphics I N C ; S U N - S U N S P A R C Station; 0 = Others  196  

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-0050186/manifest

Comment

Related Items