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.Sc . Engineering (Civil), University of Engineering & Technology Lahore, Pakistan 1980 A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T O F 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 O F A P P L I E D S C I E N C E in T H E F A C U L T Y OF G R A D U A T E S T U D I E S Department of Civi l 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 B R I T I S H C O L U M B I A July, 1998 © W a q a r Ahmad, 1998 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. The University of British Columbia Vancouver, Canada Department DE-6 (2/88) 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 1.2 Problem Identification 1 1.3 Defining Facilities Management 2 1.4 Research Obj ectives 5 1.5 Research Methodology 5 1.5.1 An Overview of Information Control Process 6 1.5.2 Literature Review 6 1.5.3 Study of Turnover Documentation of a Selected Project 6 1.5.4 The Framework To Model Facilities Management Turnover System 7 1.5.6 System Development 7 1.5.7 Conclusion and Discussion of Results 8 CHAPTER 2: INFORMATION CONTROL PROCESS 9 2.1 Construction Projects and Information Management 9 2.2 Data Sources 10 2.2.1 Information Routing and Information Users 10 2.3 Overview of Databases and Database Management Systems 12 2.3.1 Database Concepts and Relational Database Systems 12 2.4 Evolution of Data Models 14 2.4.1 Data Modeling Process 16 2.4.2 Data Analysis 18 2.4.3 Database Terminology 20 2.4.4 Definition of Relational Database Terms 24 2.5 Normalization 24 2.6 Resolution of Problem 26 CHAPTER 3: LITERATURE REVIEW 27 3.1 Introduction 27 3.2 Role of Information in the Construction Process 28 3.2.1 Traditional Information Flow Framework 29 3.2.2 Information Flow Requirements 30 3.3 Project Documents and Records in the Construction Industry 30 iii 3.3.1 Why the Records Should be Stored 31 3.3.2 Types of Engineering Documents/Records 32 3.3.3 Project Photo Records 34 3.4 Information and Information Systems 35 3.4.1 Information Management and the Construction Industry 36 3.4.2 Computer Based Information Systems 39 3.5 Information Model 39 3.5.1 Entity-Relationship Model 41 3.5.2 Structural Data Model 43 3.6 User Interface 47 3.7 An Integrated Approach to Facility Management 48 3.7.1 Computer Aided Facility Management Applications 49 3.7.2 Zoser Systems Group 51 3.7.3 CAFM Market and Related Works 54 CHAPTER 4: ADVANCED MATERIALS AND PROCESS ENGINEERING LABORATORIES (AMPEL) 57 4.1 Introduction 57 4.2 Organizing Concept of the AMPEL Building 57 4.3 AMPEL: The Seven Domains 59 4.3.1 Domain 1: High Head Dirty Laboratories 59 4.3.2 Domain 2: Standard Dirty Laboratories 59 4.3.3 Domain 3: Standard Laboratories Group one 59 4.3.4 Domain 4: Standard Laboratories Group Two 60 4.3.5 Domain 5: Standard Clean Rooms 61 4.3.6 Domain 6 & 7: Support Services and Faculty Rooms 61 4.4 A Brief Description of Various Laboratories 61 4.4.1 High Head Dirty Laboratories 61 4.4.2 Pyrometallurgical Processing 62 4.4.3 Microstructural Engineering (Pilot Rolling Mill Facility) 62 4.4.4 Composites 63 4.4.5 High-Temperature Combustion Research Facility 63 4.4.6 Powder Metallurgy (Plasma Processing) 64 4.4.7 Fabrication of Ceramic Components Laboratory 64 4.4.8 Shared Advanced Metals Facility (Solid Preparation Laboratory) 64 4.4.9 Shared Advanced Metals Facility (Physical Modeling Laboratory) 65 4.4.10 Computer Facility 65 4.4.11 Surface Analysis and Structure 65 4.4.12 LEED & Auger Electron Spectroscopy 66 4.4.13 SIMS & SAM 66 4.4.14 X-ray Photoelectron Spectroscopy 66 4.4.15 Laser Desorption Microprobe FT-ICR Spectrometer 66 4.4.16 Polymers (Polymer NMR and ESR Spectroscopy and Imaging) 67 4.4.17 Magnetism 67 4.4.18 Opto-Electronics 67 4.4.19 Superconductivity 67 iv 4.4.20 Thin Film and Surfaces 68 4.4.21 Surface Physics 68 4.4.22 Semiconductor Processing 68 4.5 AMPEL Project Systems 69 4.5.1 Architectural System 69 4.5.2 Mechanical System 70 4.5.2.1 Domestic Water Subsystem 71 4.5.2.2 Sanitary & Acid Drainage Subsystems 72 4.5.2.3 Storm Drainage Subsystem 73 4.5.2.4 Fire Sprinkler Subsystem 73 4.5.2.5 Natural Gas Subsystem 74 4.5.2.6 Fuel Oil Subsystem 75 4.5.2.7 Steam/Water Heating Subsystem 75 4.5.2.8 Chilled Water Subsystem 76 4.5.2.9 Ventilation Subsystems 77 4.5.2.10 Exhaust Air Subsystem 79 4.5.2.11 Control Subsystem 79 4.5.2.12 Compressed Air Subsystem 80 4.5.3 Electrical System 80 4.5.3.1 High Voltage Power Distribution Subsystem 81 4.5.3.2 Emergency Generator Subsystem 81 4.5.3.3 Lighting Subsystem 82 4.5.3.4 Total Lighting Control Subsystem 82 4.5.3.5 Voice Data Subsystem 82 4.5.3.6 Fire Alarm Subsystem 82 CHAPTER 5: A DEVELOPMENT FRAMEWORK FOR A FACILITIES MANAGEMENT TURNOVER INFORMATION SYSTEM 89 5.1 Introduction ....89 5.2 Framework for FMTIS Development 89 5.2.1 Project Selection 91 5.2.2 Feasibility Study 92 5.2.3 Analysis Phase 94 5.2.4 Design Phase 97 5.2.5 Implementation Phase 99 5.2.6 Performance Evaluation and Review 100 5.3 FMTIS: Facilities Management Turnover Information System 100 5.3.1 Objectives of FMTIS 101 5.4 Planning for FMTIS 101 CHAPTER 6: SYSTEM ANALYSIS AND DESIGN 102 6.1 Brief Description 102 6.1.1 Proposed Users of the System 103 6.2 Objectives and Scope of the FMTIS 103 6.3 User Views 104 6.4 Database Design 105 6.5 File Organization Schemes 106 6.5.1 Core Entity- Product Breakdown Structure 106 6.5.2 Other Basic Entities 108 6.6 System Views 112 6.6.1 View 1: Facilities 113 6.6.2 View 2: Contacts 115 6.6.3 View 3: Products and Warranties 117 6.6.4 View 4: Tests 120 6.6.5 View5: Drawings 122 6.6.6 View 6: Permits..... 124 6.6.7 View 7: Commissioning 126 6.6.8 Integrated View 128 6.7 Entity and Relation Attributes 130 6.7.1 Entities 131 6.7.2 Data Dictionary 133 6.8 Suggestions for Implementation Environment 134 6.8.1 System Hardware and Software Options 134 6.8.2 Sources of Data Input 135 6.8.3 System Data Output 136 6.9 Physical Implementation 139 6.9.1 Microsoft Access Terminology 139 6.9.2 Prototype Development 142 6.9.2.1 Developing Tables 143 6.9.2.2 Setting Default Relationships between Tables 143 6.9.2.3 Designing Queries 145 6.9.2.4 Creating Forms 146 6.9.2.5 Producing Reports 152 6.9.2.6 Creating Applications With Macros 153 CHAPTER 7: CONCLUSION 154 7.1 Thesis Review 154 7.2 Benefits and Applications of FMTIS 155 7.3 Experiences and Observations 156 7.3.1 Validation and Testing 158 7.4 Contributions 160 7.5 Extension and Future Research 161 BIBLIOGRAPHY 162 APPENDICES 170 Appendix A: Data Dictionary 170 Appendix B: Default Relationships 178 Appendix C: System Generated Reports and Printouts 182 Appendix D: List of CAFM Vendors 186 vi LIST OF FIGURES Figure 2.1 Data Analysis 19 Figure 2.2 System Structure 23 Figure 2.3 Steps in Normalization 25 Figure 3.1 Decision making in a Traditional Framework 30 Figure 3.2 An Example of Entity-Relationship Data Model 42 Figure 3.3 Structural Data Model Example 45 Figure 4.1 The AMPEL Seven Domains 58 Figure 4.2 AMPEL UBC Balancing Schematic Basement Floor Plan 84 Figure 4.3 AMPEL UBC Balancing Schematic Main Floor Plan 85 Figure 4.4 AMPEL UBC Balancing Schematic Second Floor Plan 86 Figure 4.5 AMPEL UBC Balancing Schematic Third Floor Plan 87 Figure 4.6 AMPEL UBC Balancing Schematic Fourth Floor Plan 88 Figure 5.1 Proposed System Development Framework 90 Figure 5.2 Phase 1 & 2: Project Selection and Feasibility Study 93 Figure 5.3 Phase 3: Analysis Phase 96 Figure 5.4 Phase 4: System Design 98 Figure 5.5 Phase 5 & 6: Implementation & Review Phases 100 Figure 6.1 E-R Diagram of Facilities View 114 Figure 6.2 E-R Diagram of Contacts View 116 Figure 6.3 E-R Diagram of Products and Warranties View 119 Figure 6.4 E-R Diagram of Test View 121 Figure 6.5 E-R Diagram of Drawings View 123 Figure 6.6 E-R Diagram of Permits View 125 Figure 6.7 E-R Diagram of view Commissioning 127 Figure 6.8a E-R Diagram of Integrated View (Part A) 128 Figure 6.8b E-R Diagram of Integrated View (Part B) 129 Figure 6.9 System Data Organization Diagram 138 Figure 6.10 A Part of Drawings Table 144 Figure 6.11 Data Entry Form Commissioning 147 Figure 6.12 Data Entry Form Contacts 147 Figure 6.13 Data Entry Form Drawings 148 Figure 6.14 Drawings and Products Browser 148 Figure 6.15 Products and Related Records Browser 149 Figure 6.16 FMTIS Switch Board 149 Figure 6.17 Data Entry Form Products 150 Figure 6.18 Data Entry Form Facilities 150 Figure 6.19 Data Entry Form Tests 151 Figure 6.20 A View Information Form 151 Figure 6.21 Contacts Information Report Image 152 Figure 6.22 Warranties Information Report Image 153 Figure C. 1 System Generated Drawing of High Head Room Lab 182 Figure C.2 System Generated Permit Image of Natural Gas Subsystem 183 vii Figure C.3 System Generated Test Report Image 184 Figure C.4 System Generated Drawing of Safety Roof Anchor & Tie Back System 185 LIST OF TABLES Table 3.1 A Partial List of CAFM Vendors 54 Table A. 1 List of Data Elements for Commissioning 171 Table A. 2 List of Data Elements for Contacts 171 Table A.3 List of Data Elements for Contracts 171 Table A.4 List of Data Elements for Drawings 172 Table A. 5 List of Data Elements for Facilities 172 Table A. 6 List of Data Elements for Permits 172 Table A.7 List of Data Elements for Products 172 Table A. 8 List of Data Elements for Tests 173 Table A.9 List of Data Elements for Warranties 174 Table A. 10 List of Data Elements for WBS 174 Table A. 11 List of Data Elements for Commissioning Locations 174 Table A. 12 List of Data Elements for Locations 174 Table A. 13 List of Data Elements for Contact Locations 175 Table A. 14 List of Data Elements for Contract Doc Locations 175 Table A. 15 List of Data Elements for Drawing Locations 175 Table A. 16 List of Data Elements for Permit Locations 175 Table A. 17 List of Data Elements for Product Locations 175 Table A. 18 List of Data Elements for Product Drawings 176 Table A. 19 List of Data Elements for Product Tests 176 Table A.20 List of Data Elements for Test Doc Locations 176 Table A.21 List of Data Elements for Warranties Locations 176 Table A.22 List of Data Elements for WBS 176 Table A.23 List of Data Elements for Sub_Systems 177 Table A.24 List of Data Elements for Facilities Locations 177 Table A.25 List of Data Elements for Systems 177 Table B. 1 Default Relationships 178 Table B.2 Queries and Join Tables 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 of information management in the construction and facilities management industry and gives an overview of the information generation and control problem. The objectives of the thesis are given and the adopted research methodology is explained. Finally, an overview of the thesis is given. 1.2 Problem Identification Accurate and comprehensive information is a necessity for making informed decisions. In the absence of sound and timely decisions even a well-planned building project can run into many problems during construction or even completion of 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 of project turnover. Construction projects are becoming more complex with the progress of technology. During the project development phase, the project team generates a large body o f information about the facility. This information is of 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 times find themselves 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 of this thesis are as follows: • The first objective is to analyze the information needs of the project and facilities management personnel, to gather information by literature review and to determine what type of 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 of providing information and solving the problems of 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 wil l enhance the problem solving and operational capabilities o f the facility management groups. The thesis wil l focus on the facility management information required to maintain the facility. 1.5 Research Methodology The research consisted of five main components. The following sections summarize these steps which are discussed in the following chapters of this thesis. 5 1.5.1 An Overview of Information Control Process Chapter 2 wi l l examine in some detail the fundamental issues of the information control process. Some of the key concepts for assuring quality and value in the development of an information system are discussed. A n overview of 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 of the information control problem resulting from a thorough search of the literature of various fields of 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 of 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 of project information from the construction phase to the operation phase of 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 of 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 of 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 of the project, that is the end product itself, but do not inform us about the dynamics of the processes involved. The inadequacy of 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 of 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 of time. Organizations in every industry, from educational institutions to industrial firms, are faced with the challenge of 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 of the project information begins the day he bids for the project, and the volume of information keeps on increasing with the evolution of 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 of 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 of 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 of 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 00 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 of 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 of constraints and rules for implementation to the physical database. For 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 [Beynon-Davies 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 Model Figure 2.1 Data Analysis (Source: [Beynon-Davies 93], p. 99) Conducting top-down data analysis reflects the use of a diagramming technique to map what the developer thinks of the things of interest to the enterprise and the relationship between these things of 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 of table structures called a relational schema via a straight-forward process of translation or accommodation. In bottom-up analysis, the developer deals with concrete data. To do bottom up analysis, we must have a pool of data items extracted from the examination of existing enterprise documentation. To this pool of data, the developer applies a series of 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 of system tables that contain the data definitions of the database objects. It is independent of any database management system ( D B M S ) . Indices: provide fast access to data items that hold particular values. Schema: the overall design of the database is called schema. Instance: the collection of 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 of entities of 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 of 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 of the same type. I f E i , E 2 , . . . . E n are entity sets, then a relationship set R is a sub set of {(ei,e2,... .e„) / ei G E i , e2 e E 2 , . . . . , en G E n } where (ei,e2,...e„) is a relationship. The degree of relationship is the number of entity sets that participate in a relationship. Key attribute o f an entity: has the property that identifies the data values of other attributes of the same key. Key attributes can also be called entity identifier. Mapping Cardinalities: or cardinality ratios, express the number of 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 of 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 sophisticated users database administrators Users application interface application programs application program object code query 4 embedded D M L precompiler ^ ^ D M L compiler query evaluation engine transaction manager buffer manager file manager indices database scheme D D L interpreter data files D B M S disk storage data dictionary Figure 2.2 System Structure (Source: [Silberschatz et al 96], p. 18) 23 2.4.4 Definition of Relational Database Terms A relational database consists of collection of tables, each of 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 of table and the mathematical concept of relation, from which the relational data model takes its name. Mathematicians define a relation to be a subset of a Cartesian products of a list of domains whereas a domain is defined as a permitted set of 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 of tuples is not important, each attribute must have a unique name; the order of attribute is significant; at the intersection of 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 of 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 of 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 Normalized Relations(lNF) I Remove repeating Groups Normalized Relations (2NF) "Remove Partial dependencies Normalized Relations (3NF) Remove Transitive dependencies 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 of the literature that is relevant to this thesis. The discussion wi l l revolve around a review of the issues of information and information systems, information needs in construction and facilities management, and documents which are of interest to both construction and facilities managers. Finally, a brief description of a few facility management systems in the market is provided. [Howard et al 1989] have highlighted the importance of 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 of the capital investment of manufacturing industries in the United States. [Christian & Pandeya 97] provide us some vital statistics which have emerged in several countries regarding operation and maintenance of facilities. They estimated that about 30% of 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% of the total construction output in 1986, whereas for Singapore, with about 50% of its building stock below 10 years of age, such works accounted only for about 21% of 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 Information Computer 4 Network Systems Top Management Middle Management Project Management I Project Staff < • System Staff Figure 3.1 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 of 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 of 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 of 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 of 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 of 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 of various parts of 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 of contract; (4) Specifications. 32 Contract Documents are those items that w i l l be used to bind the owner and contractor together for the durat ion o f the project. The contract documents include all the graphic and wr i t ten construct ion documents, except for the b idding requirements, that exist at the t ime bids are sol icited. There are two other general categories o f contract documents, wh i ch a l low for changes to be made: (1) Addenda ; (2) modif icat ions. Addenda are changes in contract documents that are made pr ior to bids being submitted. A contractor's b id must reflect these changes. Mod i f i ca t ions are changes to contract documents, wh i ch are made after the agreement between the owner and contractor has been executed. Mod i f i ca t i ons include f ield orders for minor items not requir ing a change in contract price or t ime and change orders for revisions affecting price or time, [Hu f f 87]. [Hami l ton 91] suggests that engineering organizations have several unique types o f records in addit ion to the records that are common wi th other f irms. The c o m m o n records are minutes o f the meetings, daily correspondence files and insurance documents. The unique types in engineering f irms include drawings, specifications, project files, and shop drawings. [Ganeshan et al 94] has listed the contract document, contract drawings, shop drawings, test reports, manufacturers data, warranty information, correspondence, change orders, and inspect ion reports as documents o f interest for a construct ion project. Addi t iona l l y , there cou ld be some other documents generated as a part o f project contro l process such as daily site reports and project photographs. 33 [Kangari 95] focuses on the results of poor project documentation from the point o f view of arbitration processes. He has reported the results of 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 of 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 of 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 of 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 of tracking the pictorial 34 developmental v i ew o f the project. A l ibrary o f these photographic objects can be kept in a database appl icat ion for use by the facil ity manager at the appropriate t ime. [H i roshi & N o b u o h 93] describe a f i l ing system o f construct ion pictures and their integration w i t h a database. The proposed facil ities turnover informat ion system uses this capabil ity o f supply ing construct ion information through joint operation w i th exist ing databases wh i ch can per form multi-phase retrieval and index transaction. Keep ing in v i ew the importance o f informat ion f low, this thesis w i l l also focus on the different sources o f informat ion and documentat ion used at construct ion sites, their purposes, their or ig in , destination, and content. 3.4 Information and Information Systems The concept o f informat ion is related to data, facts and knowledge. A fact is something that has happened in the real wo r l d and that can be verif ied [Barton 85]. D a t a are facts obtained through empir ical research or observation. K n o w l e d g e is facts or data represented in some way (e.g., reports, lists, letters, etc) and stored for future reference. Informat ion represents data or knowledge evaluated for specific use. Consequently, facts or data are processed to prov ide information. [Mu rd i ck & Ross 75] defines information as "the behavior-initiating st imuli between sender and receiver and in the fo rm o f signs that are coded representations o f data." [Tenah 84] states that informat ion is behavior-affected data. Da t a differ f rom informat ion in a sense that data are 35 considered signs, usually recorded observations that do not affect the behavior of men or machines. However, data may become information i f behavior becomes affected. For example, the database for computer systems consists of masses of such signs that are not affecting behavior. Unti l 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 of a particular project or job, as well as the organization as a whole. [Aoki et al 93] defines information not only as measurement of 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 of the facilities or to the construction components of the operations. It is important to standardize the information so that it can be used as common information throughout the design, construction, and management of a project. Systematic information enables management of similar projects by a standardized method and facilities application of a computer system for information management. [Rasdorf & Herbert 88] have emphasized the importance of accurate and timely information for construction project management and status of project resources. Other issues of 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 of 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 of individuals, firms, and organizations and generate a considerable amount of information. [Fanous & Samara 94] and [Pierce 88] describe that the successful management of engineering and construction projects require coordination and control of many diverse activities performed by specialists assigned to the project. Successful coordination and control of these activities require the project manager and his staff to have access to accurate and current information regarding all facets of project activities. It is also essential that the specialists in each area of 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 of 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 of the total project team decision-making and implementation process is a direct result of the availability and reliability of information. 37 [Vanier et al 93] describe the importance of 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 of 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 of our endeavors, and for the smooth functioning of our institutions. Information is one of the resources not in danger of exhaustion on the shrinking planet. It is unique because it is limitless. One of 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 of information management for project managers. The information at the project level is enormous and traditional methods of information handling are not adequate to meet the needs of new management in this environment. Hence, new tools are required between project personnel and the participating groups for the management of information. It is in the recent years that the construction industry has started to take advantage of new developments in information technology, particularly in the field of project and construction management. 3.4.2 Computer Based Information Systems [Lock 92] states that the purpose of computer based information systems for engineers is to integrate the collection, processing and transmission of information so that engineering professionals can gain systematic insight into the operation and functions they are managing. This approach wil l minimize guesswork and isolated problem solving in favor of 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 of a computer based information system for the provision and interchange of 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 of such an information system represents a major task. This is due to substantial amount and different types of information generated within a project, the variety of project types, the considerable amount of different experts involved, the complicated links and processes involved in the project and diversity of client cum facility owners requirements. [Froese 93] defines an information model as a collection of information about a specific real-life object, and states that the information model should fulfill the following requirements: • General Usefulness: many different applications wil l use the models for performing different functions. • Richness: the model must capture a significant level of detail. • Comprehensiveness: the scope of the model must include a wide breadth of 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 of information modeling is shaped by the purpose at hand. General models of knowledge and cognition are the most diverse and debatable, having the least defined criteria for correctness or adequacy. Models and methodologies in support of current and emerging information processing technologies are tractable, being governed by the forms and capabilities of such technologies. These approaches can at least be judged by pragmatic measures of usefulness, i f not correctness. The Entity-Relationship (E-R) Model is one of the best known tools for logical database design [Goldstein & Storey 89]. It is generally considered to be a very natural, easily understood way of conceptualizing the structure of a database. Many other researchers have claimed the benefits of the E - R model, some of 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 of representing a user's information requirements [Brodie 84]. Entity-relationship diagrams are one means of 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 between entities, wh i ch are represented as rectangles. Attr ibutes are associated w i t h entities and represented w i th an ellipse. Figure 3.2 An Example of Entity-Relationship Data Model General ly graphical or diagram-based object model ing techniques convey more meanings than textural specif icat ion techniques [Car lson et al 89]. Howeve r , d iagram techniques are not w i thout their problems. [Feldman & M i l l e r 86] c la im that " the usefulness o f any diagram is inversely proport ional to the size o f the model depicted." It has also been not iced that a modest size database such as the Faci l i t ies Turnover system contains too many semantic connections between objects for easy comprehension. E v e n i f tools to display a complete E-R mode l are available, the l imitations imposed by the screen size restrict the number o f available objects wh i ch can simultaneously be displayed. The ability to shrink, z o o m , expand or pan the E-R diagram offers a l imited solut ion to this, the database design layout problem. [Feldman and M i l l e r 86] proposed using multi-level E-R diagrams to deal w i t h the above problems. A multi-level E-R model is a hierarchy o f successively more 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 of Nested E - R model is given as follows. A simple Entity is a collection of simple attributes. It is graphically denoted by a single lined rectangle. A simple relationship is also a collection of 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 of simple and complex attributes which may be derived from the lower level diagram. The pictorial representation of 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 of 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 of an integrated system [Law & Scarponcini 91]. A data model is a collection of 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 of data intensive applications. In addition to facilitating the design of database design process, a data model needs to provide the integrity rules to ensure consistency among the entities. The ultimate objective of the semantic modeling activity is to make systems more intelligent [Date 90]. The aim of selecting a semantic data model is to represent directly, and in an easy form as many of the objects and their relationships of interest as possible. The structural data model (example shown in figure 3.3) that is used is an extension of 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 of 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 of connections, namely ownership, reference, and subset connections [Law & Scarponcini 91]. 44 Relationship Symbol Insert/Delete Constraints Ownership Reference Subset Employee Employee Employee Skills Dept. ^Salesman Skills need employee/skills go with employee Employee needs department/department stays Salesman must be employee/salesman goes with employee Figure 3.3 Structural Data Model Example [Law & Scarponcini 91] has explained the structural data model as follows: The connection between two relations R l and R2 is defined over a subset of their attributes X I and X 2 with common domains. A n ownership connection between an owner relation R l and an owned relation R2 describes the dependency of 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. As an example, a facility consists of systems such as architectural systems, mechanical systems, electrical systems etc. The component systems exist only i f the facility exists. This type of connection specifies following constraints: • Every tuple in R2 must be connected to an owning tuple in R l . • Deletion of an owning tuple in R l requires deletion of all tuples connected to that tuple in R2. 45 • Mod i f i c a t i on o f X I in an owning tuple requires either propagat ing the modi f i ca t ion to 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 fore ign (referenced) relation R 2 describes the dependency o f mult iple pr imary tuples on the same fore ign tuple. A s an example, an architectural space, wh i ch may be an off ice, elevator, opening, etc., is located on a f loor. The f loor cannot be removed wi thout first remov ing the space defined on that f loor. This connect ion type specifies the fo l l ow ing constraints: • Eve ry tuple in R 2 must either be connected to reference tuple in R I or have nul l values for its attributes X I . • De le t ion o f a tuple in R 2 requires deletion o f its referencing tuples in R I , assignment o f null values to attributes X I o f all the referencing tuples i n R I , or assignment o f new val id values to attributes X I o f all referencing tuples corresponding to an existing tuple in R 2 . • Mod i f i c a t i on o f X 2 in a referenced tuple R 2 requires propagat ing the modi f icat ion to attribute X I o f all referencing tuples in R I , assigning nul l values to 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 relat ion R 2 l inks general classes to their subclasses and describe the dependency o f a single tuple in a subset o n a single 46 general tuple. For 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 of structural element must delete the corresponding instance existing in the subclass. The subset connection specifies the following constraints: • Every tuple in R2 must be connected to one tuple in R I • Deletion of a tuple in R I requires deletion of the connected tuple in R 2 . • Modification of X I in a tuple of R I requires propagating the modification to attributes X 2 of its connected tuples in R2 or deleting the tuple in R I . 3.6 User Interface [Beynon-Davies 93] describes the user interface as everything concerning the human side of information systems, an area sometimes referred to as human factors. In another more limited sense, the user interface is usually defined in terms of screen based interfaces to information systems. [Schneiderman 92] defines five broad categories of interface: • Menu: This consists of 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 of 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 of 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 of Science's National Research Council Building Board ( B R B ) recommended to the Federal Construction Council that an integrated database (IDB) was a cost effective way of managing facilities [Scarponcini, 96]. B y looking across the entire life cycle of 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 of 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 of 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 of 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 of facility management. According to [Teicholz 92], there are three basic approaches to the implementation of 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. As an example of 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 of 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 of 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 of 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 wil l 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 Dr . Thomas Froese, Assistant Professor in the Department of Civi l Engineering at University of 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 of a series of reports. These include: • A list of Units of Functionality ( U of F's): A listing of the units of Functionality, which are the concepts or topics addressed by the data model. • A U of F Report: A report of the details of 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 of all entities along with full description and full details of all attributes for each entity. • A n Issues List: A listing of issues raised during model development. • A Modification List: A chronological list of modification made to the data model. Some of the features and functions of facilities management turnover system as claimed by Zoser Systems Group are listed as follows: • Automated links from one specific data information source to another wi l l be provided where data relationships exist. M u c h of the project development data wi l l be interrelated by the work breakdown structure (WBS) . • The system wil l 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 wil l 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 wil l be an open architecture system, compliant with O B D C (open database connectivity) and O L E (object linking). F M T S wil l establish hooks into third party products and all major databases. 52 • A user-friendly G U I interface wil l be provided. • F M T S wil l be developed using J A V A and Visual C + + . These tools are effective, stable, widely accepted and widely used. • The system wil l be able to zoom into memo field of a world processor. • The system wil l 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. • Work task can be easily coded with a W B S code. A t the start of 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 of 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 of this project. This situation led me to work independently to develop my own data model, (based, in part on some of 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 of 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) C A F M Company Name Software Name/Model Operating System g '3 •a a •a •a 3 m ~3 si o CO B o s 3 00 •a o o 8 CO S3, a, co Accugraph Corp. Mountain Top HP; SUN; I B M U W A E C Data Systems, Inc Facility Management D E C ; HP; IBM; SUN W & U American Computer Software Property Management Series P C D & W 54 C A F M • Planning Construction Management -*-» o Lease/ Property Management CO a o recasting agement Telecommunication sJ Cable Company Name Software Name/Model Operating System Platform Architecture/ Interior Construction Management Facility Budgeting/C Furniture Inventory 1 Integrated CAFM Lease/ Property Management Maintenance/Operati Room Scheduling Security Space Allocation/ Foi Space Inventory Man Telecommunication sJ Cable Apple Computer Inc. M 1 1 M A C ARCHIBUS, Inc. W 1 1 1 1 2 1 1 2 1 1 2 A R C H I B U S / F M 10 PC Autodesk, Inc. D; 1 2 2 2 1 2 2 2 2 2 D E C ; HP; IBM; SGI; SUN U; W Bentley Systems, Inc. D; 1 1 1 1 1 MicroStation M ; D E C ; HP; IBM; ITG; M A C ; PC; U; SUN W CADapult Ltd. D; 1 2 2 1 1 2 2 2 2 1 1 2 CADapult For Windows W P C • Facility Management Applications: l=Primary Application; 2=Secondary Application • Platform: D=DOS; M= Macintosh; U = UNIX; W= Windows; 0= Others • Operating Systems: DEC= D E C Non PC; HP = Hewlett-Packard, Series 9000; IBM= I B M Non-PC Model; ITG= INTERGRAPH ; PC= I B M PC/ Compatible; M A C = Macintosh; SGI = Silicon Graphics INC; S U N = SUN SPARC Station; 0= Others 55 It can be seen from the table 3.1 that all commercially available systems are capable of performing a part of 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 of 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 of the commercial systems that none of these systems have claimed the capability of 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 of 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 components, integrated opto-electronics and femtosecond optical technology, thin film technology, surface physics and infrared Raman spectroscopy, superconducting ceramics and inorganic polymers, and molecular beam epitaxy ( M B E ) . Most 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 AMPEL 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 of developers of this project, the building plan and spatial organization should reflect this organization model. Domains one through five makes up the laboratory areas of the building. The seven domains are shown in figure 4.1. 57 Standard Dirty Lab High Head Dirty Labs 2 1 Group 1 Standard Lab Group 2 Standard Labs Support Services 7 6 Administration & Faculties Standard Clean Rooms Figure 4.1 The AMPEL Seven Domains 58 4.3 AMPEL: 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 of this thesis. These domains are explained as follows. 4.3.1 Domain 1: High Head Dirty Laboratories The High Head labs enable pilot scale operations of 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. Two 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 of 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 of 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 of university research laboratories, although with a high proportion of floor mounted equipment, some of it rather tall (3.0 m). This domain represents the largest single category of space in the program and should have the potential for the highest degree of 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 of 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 of equipment, and generally, wil l 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 of much the apparatus in this domain with respect to vibration, a location on grade is preferred by many of the researchers involved. Also, some of 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 of extremely sensitive nature of 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 of office room space for administrative staff and faculties. 4.4 A Brief Description of Various Laboratories A brief description of various laboratories in A M P E L is given in the following sections. 4.4.1 High Head Dirty Laboratories High Head Dirty Laboratories accommodate a range of research activities for metallurgical and process engineering applications. Seventy percent of the floor area have a clear overhead height to structure of 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 of these labs is a controlled environment room. Both 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 High 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 work areas and tool storage. 4.4.3 Microstructural Engineering (Pilot Rolling Mill Facility) The intention of the developers is to develop a new pilot rolling mill facility at A M P E L building to conduct research and development of rolling processes and rolled materials. The 62 mill simulates industrial production conditions and provides automatic control of mill operations, and ancillary facilities for controlled re-heating prior to rolling and phase transformation monitoring during or following completion of 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 of 160 mm diameter. 4.4.4 Composites The Composites discipline occupies laboratory space in the High Head and Medium Head areas. The Pressure Tester and the controlled Environment Laboratory are in this location because of 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 Room, Chemical Wet-Laboratory plus Storage Room, Instrumentation and Control R o o m for Autoclaves, Autoclave/Hot Press Room and Specimen Machining and Preparation Room. 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 of processing on the mechanical behavior of composites. 4.4.5 High-Temperature Combustion Research Facility In the high temperature combustion research laboratory, the study of emissive and heat transfer characteristics of the flames is conducted. The data is incorporated into the mathematical models being developed for various industrial furnaces. 63 4.4.6 Powder Metallurgy (Plasma Processing) The overall objective of the powder metallurgy laboratory is to develop detailed understanding of 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 of 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 of the fast reaction is approximately 1.0 kg of material out of the bottom of the unit. 4.4.7 Fabrication of Ceramic Components Laboratory In the ceramic component laboratory research is conducted for the development of 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 of 37.0 m 2 , and a drying area of 9.0 m 2 . A n outdoor covered solids storage area of 28.0 m 2 is provided to hold 4-20 barrels of material from industry for flash smelting. 64 4.4.9 Shared Advanced Metals Facility (Physical Modeling Laboratory) One of the research tools available to study metallurgical process is use of scale models of physical plants. The physical modeling laboratory is used to build and study a wide variety of physical plant models with the measurements being applied to elucidate the fundamentals. Mode 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 of mathematical models. The laboratory is in two parts, a computer room of 10.0m 2, and a workstation area of 21.0m 2. 4.4.11 Surface Analysis and Structure The chemical characterization of 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 wood 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 LEED & Auger Electron Spectroscopy The L E E D & Auger electron spectroscopy laboratory carries out research on the structure of significant surfaces of single crystal materials at the atomic level. 4.4.13 SIMS & SAM The SIMS 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 (SIMS) provide much higher sensitivity for trace element analysis with dynamic SIMS and polymer surface characterization with static SIMS. 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 of materials. This facility combines a number o f special features, including a mono-chromatized X-ray source, ion 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 of materials. This facility is used for impurity tracing in 66 semi conductors and requires two major pieces of 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 of physical, mechanical and electronic properties of polymer materials. 4.4.17 Magnetism The magnetism facility consists of two separate research areas, L o w Temperature Magnetism and Superconductivity, and N M R (the study of single crystals o f metals, alloys and intermetallic components by nuclear magnetic resonance) of metals. These two laboratories require a sample preparation area. 4.4.18 Opto-Electronics The Opto-electronics facility consists of two research areas, integrated opto-electronics and femtosecond Optical Technology. 4.4.19 Superconductivity High Temperature Superconductivity research consists of material preparation and analytical facilities. The analytical facilities are composed of 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 Fi lm Technology Laboratory is used to develop new processes and specialized equipment for the fabrication of 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 of Surface Physics is research into electronics, optical and structural properties of 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 of 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 AMPEL Project Systems For the purpose of 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. • Architectural System • Mechanical System • Electrical System 4.5.1 Architectural System Architectural System has been divided into following Sub-systems: • General Requirements • Site Work • Concrete • Masonry • Metals • Wood and Plastics • Thermal and Moisture Protection • Doors and Windows • Finishes • Specialties i 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 of mechanical systems and instrumentation is involved. Figures 4.2 to 4.6 show the schematic drawings of some of 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 Oil 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 re-circulation 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 of the building is drained via sanitary drainage piping that runs through the ceiling space of the basement. The main 150mm sanitary drainage pipe exits the West side of the basement at the North end of the high head laboratory. The sanitary piping from the washroom fixtures and floor drains of 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 of the building. The waste liquid from the laboratory sinks in the main North-East section of the building is carried by acid waste drainage piping that drains into an acid neutralizer in room 5 of the basement. The acid neutralizer is comprised of 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 of the receiving area. Any 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 of 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 of 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 Road to provide natural gas to the building. The pipe to the building connects to a gas meter and a seismic gas valve which wil l automatically shut off gas supply to the building i f an earthquake occurs. The gas supply pipe enters the West side of the building at the North end of the basement and runs Westward through the ceiling space of 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 of 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 of 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 Model 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 of 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 of 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 of 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 of 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 of 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 of 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 of 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 of 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 of the West section of 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 of the building. Each unit is comprised of return and outdoor air dampers, filter section, supply air fan, gas fired burner section and heat exchanger. Supply fans SF-4A and SF-4B are Aerofoil Model 38K1/2 1750 axial fans. Both fans have been installed in the North-East section of the basement to draw outdoor air through louvres installed on the main through fourth floors of the North-East corner of the building and blow the air through the crawlspace corridor into transformer room 42 of the basement. The fans are connected to ductwork which contains backdraft dampers, silencers and filter sections. A relief air louvre on the south side of 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 of 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 of the main stairways. The fans are each installed to blow outdoor air into the stairway. SF-6 and SF-7 are each Cook Model 150SQUTB fans which are suspended from the ceiling of the stairway, while SF-8 is a Cook Model 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 of 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 of electric/electronic controls has been installed to operate the air handling units, pumps and main exhaust fans of 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 of the equipment, make changes to the control programs, be warned of 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 of 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 of the building. 4.5.3 Electrical System The electric portion of the A M P E L project has been divided into following sub-systems: • High Voltage Power Distribution Subsystem • Secondary Power Distribution Subsystem • Emergency Generators Subsystem • Lighting Subsystems • Total Lighting Controls Subsystem • Voice Data Subsystem 80 • Fire Alarm Subsystem • Time Keeping Subsystem 4.5.3.1 High Voltage Power Distribution Subsystem This system is comprised of the following products: • 15 k V H K Indoor Switchgear Assembly • 15 k V Ai 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 • Wal l 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 • System Test Procedures 4.5.3.7 Time Keeping System: This system has been treated as an integrated subsystem. i 6 B g § 11 g 1 II m *• u !- CO' I I I s i lis X z. .a= P i Si ' Figure 4.2 AMPEL UBC Balancing Schematic Basement Floor Plan 84 85 I I Figure 4.4 AMPEL UBC Balancing Schematic Second Floor Plan 86 o I 1 1 ( 1 I i i, 3 I BP i § m 11 11 I si si 1 ? S I f : j ~ i i i J5£ —I ^ . 0.. _ i 4_ 5j §) ii © * . * a? IIP" ^1 ^3 rri I S H e —€ —g -HI --4 -Hi —-<§ —(§ Figure 4.5 AMPEL UBC Balancing Schematic Third Floor Plan 87 • i I i i i m © J - = — = i Si r-> % m i — = -~ -i j <m> g; ••-€> --€> -•-© ~ © --a •--© — © --<§> --<§ na --© —«—! CDu s1 ^  i s f » ^ » 1 1 8 jr^ s m m 9 =3 m ^ Figure 4.6 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 of Facilities Management Turnover Information System (FMTIS) . The approach which is synthesized from the study of 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 [Baynon-Davies 93], Proposed Conceptual Integrated System model [Sardi & Kangari 93], 'Design and Implementation of 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 Request Project Selection Project Report Projects Feasibility StudyK Processing Requirements Feasibility Report Analysis User Requirements Document Design System Specification Implementation ^ 5 Enterprise Data Model Database management System Characteristics Hardware/software operating System _ Characteristics Evaluation Information System 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 of the most developed contemporary paradigms for information systems development [Baynon-Davies 93]. Structured information system development is usually seen as being made up of a series of 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 of a database application for an information control system in a facilities environment requires a through understanding of all data sources and their uses. Figure 5.1 is a graphical representation of 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 of 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 of 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 of its intended users, user demands, capabilities of 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 of the organization. The technology constraints to develop the application should also be sorted out at this stage. • Comments Solicitation: the end product of 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 of the development team to consider the comments and to incorporate the relevant portions which are technologically possible and of interest to the user. 92 Project Selection y ^ — - — - o f Feasibility Study 1 * Identification of Frame-Work: 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 back into the feasibil ity study and a revised report is produced. In a sense, the project selection process and feasibility study act as two filters at the beginning o f the development life cycle. Project selection is a course-grained filter wh i ch rejects the projects wh i ch are patently unsuitable. The feasibility study is the fine-grained filter and scrutinizes the projects on minute scale. 5.2.3 Analysis Phase The analysis phase can also be termed as the requirement formulat ion phase. It identifies and describes the data requirements o f the organizat ion. The end result o f this phase is the user specif icat ion or user requirements. E lements o f this requirement are continual ly rev iewed w i t h end users unti l they are satisfied that the requirements adequately describe their needs. The fo l lowings steps, shown in F igure 5.3, are taken to provide informat ion for the next phase. • Database Requirements: this process involves defining the goals, aims and objectives o f the database requirements for the organizat ion. Th is , in turn, requires establishing a scope for the database in terms o f business functions. • Data Source Identification: involves an analysis o f the data generator, data classif ication, wh ich includes data type and format, forming a l ink between 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 of 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 of 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 of 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 of 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 View 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 of the requirements set by the three previous phases into a system specification and design of 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 of 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 of a database starts with the definition of the requirements and produces a conceptual schema of the data. This is the most important aspect of the data base design because it describes the organization and scope of the information to be stored in the implemented database. This is independent of any particular Database Management System ( D B M S ) implementation. The steps in conceptual design include data 97 model ing (using Entity-Relat ionship methodology) , v i ew integration, conceptual schema development (semantic data methodology) , design rev iew, and log ica l access mapping. • Technology Identification: involves identifying available technology and the incorporat ion o f future technology into the system. A t this stage the most suitable hardware and software for the proposed system is identif ied. From Analy: Phase F i le Organizat ion Scheme Deve lopment Use r V i e w Def in i t ion Conceptual Da t a M o d e l Deve lopment I Technology Identif ication 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 of 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 of software wil l be based on the choice of 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 of the finished application that fulfills most of the system's requirements. The purpose of prototype is to demonstrate the idea of using a F M T I S for information handling during project turnover phase. The prototype will be a simplification of a complete F M T I S , but wil l realistically demonstrate all database functions. A t this stage all the forms, reports, and queries will be designed. Following the results of evaluation of 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 r Review To System Development Performance Evaluation Figure 5.5 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 of this research is to develop a prototype facilities management turnover information control system for facilities managers. The developed system focuses on one of the support functions, namely information control in a larger domain of 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 of the University of British Columbia at the turnover phase of recently completed project, A M P E L . As 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 of this system was acquired, the pace was set for the actual planning and implementation of 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 of the project. This information includes, but is not limited to, the selection of a team of 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 of 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 of this information is a vital managerial task. In this day of rapid automation, most of the construction companies and facility management groups use personal computers for cost accounting and data manipulation. With the advancement of computer technology and popularity of 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 of 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. As 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: • To understand the information needs of a construction project team; • To develop a data flow model of a construction project; • To develop an information model for the selected user views; • To design and implement the database and F M T I S application • To provide specifications for future research in similar system development; • To bring into focus the project information management functions; • To gain and maintain control of the project documentation at project execution stage so that the turnover phase is smooth; • To reduce the time spent on assembling all the project information, available in various formats and locations at the crucial time of 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. On the basis of information gathered so far, several user views are identified. However, only seven wil l be implemented in the system due to time constraint. The views considered important for the application are as follows: • Facilities View • Drawings View • Contacts View • Products and Warranties View • Commissioning View • Permits View • Tests View 6.4 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 of 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 of the proposed system. Section 6.5 deals with the 105 description of the basic files and their organization schemes. Section 6.6 deals with the description of user views, identification of information requirements, identification of entities and their attributes including primary keys, description of relationships between entities, and presentation of an entity -relationship diagram. Section 6.7.2 deals with the issue of 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 wi l l 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 of the important and basic entities required for the proposed system, and their organization in the database, will be discussed. One of the core entities identified in the system is the Product Breakdown Structure (PBS). Most of the entities in the system are associated this entity. Other basic entities are Products, Locations, Contracts, Documents, Drawings, Commissioning, Warranties, Permits, Tests and Work Breakdown Structure (WBS); 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 of the construction industry [O'Connor 93]. [Froese 93] states that classification schemes such as CSI 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 of 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 CSI M A S T E R F O R M A T is not an industry-wide standard, it has been the basis of 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 of specific items or categories titles, usually hierarchical or nested and numbered according to a specific coding scheme. This is a form of classification, and is modeled on a generalized classification mechanism. This meets all the requirements of the three breakdowns mentioned, and provides flexibility for the future. The possibility of 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. For the proposed F M T I S , most of 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 of interest for the facility manager. Any 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 of project completion, most of the documents which are of 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 of 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 of 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 of 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 of 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 of 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 of interest is Drawings. A construction project usually generates a large number of drawings. These graphical records are of great value for facility owners and managers. The utility of 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. From the perspective of facility manager, the products located in the facility are of tremendous interest. A l l systems and sub-systems found in the facility are represented by these products and they need on going attention of facility managers during the useful life of the facility. I f the building envelope is the skeleton, then these products are the heart, lungs, and nervous system of that skeleton. The attributes of 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. To 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 of the equipment, products and processes. A s there was an actual commissioning in case of 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, performed-by, and commissioning date. The next entity of 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 of 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 of the warranties entity are warranty id, item warranted, warranty start date, warranty contact person. I l l The next entity of 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 of 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 of the test entity include test id, test name, date conducted, test location description, testing method, approval #, document picture, and remarks. The next entity of interest is permits. Permits are documents issued by statutory bodies to either contractor or owner of 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 of 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 of 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 of 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 of the general queries for this view of 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? • Who was the main contractor/consultant of 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 ID, Facility name, Facility owner, Date of Completion, Date of turnover, Facility photo) Systems(System ID, System Name, Facility ID) Facility Location(Facility ID, Doc 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 of 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. • Who are the designers of this project? • Who are the Contractors of this project? • Who are the subcontractors of this project? • Who are the suppliers or vendors of this project? • What are the contracts / subcontracts issued on this project? • For a given contract / Subcontract, who is the contractor? • H o w well did a company or vendor perform on the project? • For 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 ID, Trade) Contact Locations (Doc Location ID, Contact ID) Drawings(Drawing #, Drawing Title, Issue Date, Revision #, Prepared By , Approved By , Draw-Picture) Products (PBS,_Product Name, Supplier ID, Manufacturer ID, 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 • Who 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? • Who supplied the product? • What is the supplier's address? • What is the supplier's phone number? • Show a picture of the product. • Where is the product located in the facility? • What is the product's CSI specification number? • What is the warranty start and expiry date? • Where is the warranty for the specific component? • What is the text of the warranty? • Who is the warranty contact person? The entity relation diagram of this view is shown as figure 6.3. Product Locations 4 V Product _Drawings > Products r Contacts ^.Product_Warranties Sub_systems have Warranty_Locations Warranties Figure 6.3 E-R Diagram of Products and Warranties View The Products and Warranties view is represented by the following relations: Products (PBS, Product Name, Supplier ID, Manufacturer ID, Product Rating, Product Weight, Product Model) Warranties(Warranty ID, Warranty Start Date, Warranty Period, Warranty Contact Person, Item Warranted) Commissioning (Commissioning ID, P B S , Product Location, Serves, Performed By, Commissioning Date) Product Locations(Doc Location ID, P B S ID) Product_Warranties(PBS ID, Warranty ID) Sub_systems(Sub_System ID, W B S ID, System ID) Product_Drawings( P B S ID, Drawing #) 119 Product_Tests(PBS ID, Test ID) Warranty Locations(Warranty ID, Doc Location ID) Contacts (Contact ID, Contact Name, Contact Address, Contact Phone #, Contact Fax #, Contact Person) 6.6.4 View 4: Tests In order to ensure that the specifications of 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 of 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? • Who performed the test? • What were the remarks of the authorized person inspecting the test? • Where are the test documents located? • Show me the approval document of a particular test. • When is this system or product to be retested during operation? The entity relation diagram of this view is shown as figure 6.4. 120 Contacts Product Tests Tests have^> • Test Doc Locations Figure 6.4 E-R Diagram of Test View The tests view is represented by following relations: Test (Test ID, Test Name, Date Conducted, Test L o c Description, Testing Method, Approval #, Test Contractor, Remarks, Doc-Picture) Contacts(Contact ID, Contact Name, Contact Address, Contact Phone #, Contact Fax #, Contact Person) Product_Tests(PBS ID, Test ID) Test Doc Location(Test ID, Document LocationJD) 121 6.6.5 View5: Drawings The drawings are graphical construction documents which show the size and physical relation of various parts of 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 of 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? • Who approved these drawings before they were submitted for construction? • List the drawing of 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 of 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 of 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 By , Approved By , Draw-Picture) Drawing Locations(Drawing #, Doc Location ID) Product_Drawings(PBS ID, Drawing #) Contacts(Contact ID, 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 of work, installation of a system or product before or during the construction process. From a facility manager's point of 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 of this view is shown as figure 6.6. 124 Permit Locations Permits < ^ h a v e ^ > 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 of all the systems, subsystems and products to verify and check the combined operation of all these systems. During this process, the efficiency of all the individual products is also checked. In the case of 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 of its importance for facilities point of 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? • Who performed the commissioning? • This product is located where in the facility? • This product is serving which area of the facility? • Which electrical circuit is feeding this product/system? • On what date the commissioning of facility performed? The entity relation diagram of 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 (PBS, Product Name, Supplier ID, Manufacturer ID, Product Rating, Product Weight, Product Model) Commissioning Location(Commissioning ID, Doc Location ID) 127 6.6.8 Integrated View The E - R diagram of integrated view is shown as follows: Warranties I 1 Permits | < W > Jiave Warranty Permit Contact Locations Locations Locations A Contact Trades Commissioning Locations V Product Drawing v Facility Locations Locations Locations Commissioning | Product Tests have Products "\ | Drawings | | Facilities") WBS ^have. Legend One to One One to Many have Product Drawings Sub_systems < have Systems User View Figure 6.8a E-R Diagram of Integrated View (Part A) 128 One to One One to Many User View Figure 6.8b E - R Diagram of Integrated View (Part B) 129 6.7 Entity and Relation Attributes In this section, the translation of conceptual model to a logical model is discussed. A t the beginning of this report, section 2.4.1 explains the data modeling stages and the data model environment of 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 of a normalization procedure explained in section 2.5. A n attribute or a number of attributes from these relations represent the primary key(s). The primary key for the relations is underlined. Additional attributes have been added to some of 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 ( INF) , attributes of entities with more than one identifying attribute (2NF) or functionally dependent on a non-key attribute of 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 wil l be mapped into physical models in a real D B M S environment, the tables wil l have the same title as that of the relations presented in this section. The attributes of these relations wi l l be termed as fields. The local data models of 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 ID. P B S , Product Location, Serves, Performed By , Commissioning Date) Commissioning Locations (Doc Location ID. Commissioning ID) Contacts (Contact ID. Contact Name, Contact Address, Contact Phone #,Contact Fax #, Contact Person) Contact Trades (Contact ID. Trade) Contact Locations (Doc Location ID, Contact ID) Contracts (Contract Id. Facility ID, Contract Name, Contract Start Date, Contract Finish Date, Contract Cost, Contractor Name) Contract Doc Locations (Doc Location ID. Contract Id) Drawings (Drawing #. Drawing Title, Drawing Type, Issue Date, Revision #, Prepared By , Approved By , Draw-Picture) 131 Drawings Locations (Doc Location ID, Drawing #) Facilities (Facility Id, Facility Name, Facility Owner, Facility Address, Facility Photo) Locations (Doc Location ID. Doc Location Name) Permits (Permit #. Occupancy Date, Permit Type, Permit Issue Date, Permit Fee, Issued To, Permit-Image) Permit Locations (Permit #, Doc Location ID) Products (PBS ID. Product Name, Supplier ID, Manufacturer ID, Product Rating, Product Weight, Product Model , Product-Image) Product_Warranties (PBS ID. Warranty ID) Product Locations (Doc Location ID, P B S ID) Product_Tests (PBS ID. Test ID) Product_Drawings (PBS 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 • the name of the attribute • the data type • the length or width of the attribute • indexing requirements • a brief description of the attribute 6.8 Suggestions for Implementation Environment In this section, suggestions and recommendations are provided for implementation environment of 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 of hardware is based on the following needs of the facility managers: speed of 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 of computer systems, printer types for fast printouts, and costs. Anticipating that other facility management applications wi 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 of 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 of 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 of facility turn-over to the Plant Operations Department of 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 of "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 of 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 of the facility. • Warranty documents are found in the Operation and Maintenance Manuals of the Facility. 135 • Test Reports Data is located in the Operations and Maintenance Manual of the facility. • W B S wil l 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 of the Facility. These Manuals, which serve as maintenance manuals of a particular facility are created when a facility is completed and handed over to Plant Operations Department of U B C . • 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 of various products. These images wil l 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 wi l l be forms and printout reports. Data output on screen will be form-oriented and the graphical user interface will incorporate various features of 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 View form • Warranties Data entry form • Warranty Document view form • Test Reports Data entry form • Test Document View form • Facilities Data Entry form • Contacts Information Report • Warranties Information Report System Data Organization Data Input Data Output Collect Input Data Edit Database Output to Screen Output to Printer Printouts View Table View Query View Form View Report Figure 6.9 System Data Organization Diagram 138 6.9 Physical Implementation In this section, the physical development of 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 of 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 of the tables. The entities and relationships, as listed in section 6.7, wi l l be represented as tables. • Query: A query is a Microsoft Access object that asks a question or defines a set of 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 (QBE) tool. The tables in a query are joined by a line that connects one of the fields of 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 of tasks in a database, such as : 139 • Combining and displaying records from related tables. • Retrieving subsets of records that match specific selection criteria. • Updating fields of data according to updated expressions. Form: A form is a Microsoft Access object that is used to enter, change and view records of 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 of database tasks, such as: • Viewing data of 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-to-many 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 of the relationship. The data in the Products table is the "many" side of 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 of data, listings of records, and information gathered together in meaningful groups and subgroups. Macro: A macro is a set of 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. For 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 of data contained in a table. The attributes of the entities as described in section 6.7 will become fields of a particular table. Type: The term 'type', used in tables of Appendix-B, denotes the degree of relationship between the tables. For example, one-to-one (1-1) and one-to many (1-M). Enforce: The term 'enforce', used in table of Appendix B , shows the referential integrity requirements. This column shows 'yes' i f referential integrity is required. Referential integrity is a system of 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 of 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 of Long Integer, and an AutoNumber field with a Field Size property setting of Replication ID can be related to a Number field with a Field Size property setting of 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 of 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 of the system wil l 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 of the steps is presented as follows: 6.9.2.1 Developing Tables In all, twenty-five (25) tables were developed for the prototype database. Each 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 of 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 of 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 of the requirements of the user, a list of 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 of relationships, as listed in Appendix B were used to create Q B E grids. A slightly different naming convention than that of the tables, was used to name queries in order to facilitate the designing of forms. S Q L view of 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 ID], [Contact Locations].[Contact ID], [Contact Trades].Trade F R O M (Locations I N N E R J O I N (Contacts I N N E R JOIN [Contact Locations] O N Contacts.[Contact ID] = [Contact Locations],[Contact ID]) O N Locations.[Doc Location ID] = [Contact Locations].[Doc Location ID]) I N N E R J O I N [Contact Trades] O N 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 JOIN ((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]) L E F T 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 ID]; 6.9.2.4 Creating Forms Three different types of forms were created for each user view. The first type of 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. For the purpose of 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 of 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 of 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 Da ta Entry: F o r m Commissioning ID CR-1 Product ID 020-157290-0077 Product Location' ::.: Penthouse Serves Laboratory Performed By. Kevin May Commissioning Date 9/8/95 h-xit Figure 6.11 Data Entry Form Commissioning Contacts Data Entry Form . .• Tallin-Cammissianinti; Bavk.Tu FMTIS Contact ID Contact-1 Contact Name Rotair Industries Contact Address 7445 Lowland Drive Burnaby B .C. V5J 5C4 Contact Phone# 604-431-8436 Contact Fax# 604-431-5122 Contact Person David Chrsrnenko .Table-Contact: Back To FMTIS Exit Figure 6.12 Data Entry Form Contacts 147 Drawings Data Entry Form Drawing # M-29 Drawing Title Building Section (High Headroom Lab) Drawing Type Mechanical Drawing Issue Date 8/1/93 Revision tt 2 Prepared By Contact-126 Approved By Contact-3 View Drawing r-TR Bs»ck To F&ATI5, 'Exit, Figure 6.13 Data Entry Form Drawings Drawing: and: Products Browser: Drawing # ABD-1 PBS ID 020-163260-0001 Product Name 15 Kv Switchgear FMTfS Exit Figure 6.14 Drawings and Products Browser Products and:Associated Records PBS ID Product Name Sub_System Name Product: Location: :: Serves Drawing # Supplier Name Warranty ID :: Warranty: Period: ••. Test ID Test Name Testing Method Approval!? 020-016420-0001 Air Compressor-1: AC-1 ABD-2 RotairJndustries;: Not available:: Nat available:: Test-10 Curtis GompressorStart up Pressure Test; Air Pressure Testing Not available 1 Compressed Air Basement Mechanical Room-Lab air compressor 1 i l FMTIS 1 ;£ FXIT Figure 6.15 Products and Related Records Browser F a c i l i t i e s M a n a g e m e n t T u r n o v e r I n f o r m a t i o n S y s t e m j* Commissioning i Warranties "fable Icomaas l^T :: M I S ^ ^ ^ :Cummissiuriritj>: J A l l C o n t a c t s Window : ; i l l i H « l p Figure 6.16 FMTIS Switch Board l-ind Exit 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 Back To FMTS ! I xit Figure 6.17 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 I T a b l e - ' F a c i l i t i e s i L Back To FM TIS I x i l Figure 6.18 Data Entry Form Facilities 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. ^ VjiJWJTf«:?i.l,- D»c. FMTIS r.xn Figure 6.19 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 Exit Figure 6.20 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 of 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 of data and information as contained in its respective user view. Seven reports were created and designed. Two of the reports are depicted in figure 6.21 and figure 6.22. ^SBii^kbisiV.., . S i S Contact Information Report Contact Name A Goulds Pumps Compan Trade : Contact Phone#Conta ct Ad dress: Doc L ocati on Nam e MMMMMM!MMHUH!M^^^s'Mviifetctn'Jilex-;j!h!^ 240 Fall Street Seneca Falls, N Y 1 Scrubber Pumps Contact Name A<BB Paving Company Lt Trade :Cuntact:Phone#Contact Address Doc Location Name Subcontractor 604-42C-1342 14C3 Blaine Ai'enue 3urnaby, B C Project Directory Contact Name A B U S Trade Conta ct Phone# Conta ct Address Doc Location Name Manufacture: 02261-273 D-5; C'47 Curamcrsbach Germany Bridge Crane Contact Name Acuthenn Trade: Contact Phone#Contact Address Doc Location Name !0 :;p ' II, :«8 (1 I; : : f e : i f l ::# '•••ms\ Pace: W j] iTTTTn JT Figure 6.21 Contacts Information Report Image 152 H E IS Warranties_Report Item Warrante Warranty Start Da Warranty Period Supplier : Manufacturer: 50 KW Generator Set 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 Date of Pure 1-Year • . N E D C O . . . ; ^ . .2aaiQ.Photon F a omii ^EULT^I i : list ••Mi m 1 Figure 6.22 Warranties Information Report Image 6.9.2.6 Creating Applications With Macros F M T I S contains a large number of user views, and therefore, automation of 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 of the macros created for the prototype were Auto Execute, Open Table Macro, Open Form 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 of this work was to analyze the information needs o f the project and facilities management personnel. To achieve this objective a review of literature was done to determine what type of documents are turned over by project management groups at the time of turnover of 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 of providing information and enhancing the problem solving capabilities of facility managers. This objective was achieved by developing a data model based on findings of literature review and discussion with facility managers of U B C Plant Operations. The first part of the research was based on conditions and methodologies for designing databases for construction industry as proposed by [Scarponcini 89], that information follows function. 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 of 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 of 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 of the database a graphical user interface was developed. This allows ease to users of this system to have multiple views of 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 of project and facilities managers. The followings benefits can be derived from the F M T I S : 155 • F M T I S can provide the facilities managers with a facility documentation information storage and retrieval database to facilitate the task of facility operation. • F M T I S can provide facilities managers with a desktop tool to identify certain problems in various components of the facility, locating their source and taking immediate remedial measures such as contacting the supplier of 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 of facilities turnover, both for construction management and facilities management groups by reducing the turned-over documents load and automating the turnover process. • F M T I S is user friendly and can be easily incorporated in existing facility groups. 7.3 Experiences and Observations The development of the F M T I S prototype posed many challenges. The biggest problem faced in the development of this system was modeling facility management functions of a real world project. The selection of a project as a test case was critical, because only a fairly complex project could test the efficacy of the system. This problem was resolved by the selection of 156 A M P E L , a newly constructed facil ity in U B C . A M P E L is regarded as a fairly complex faci l i ty by U B C Plant Operat ions f rom a facil ity operations point o f v iew. A l t hough a relatively small number o f turned-over documents were considered, the analysis turned out to be fairly r igorous. It consists o f seven user v iews and the same number o f user reports. Some o f the experiences and observations are listed be low: • A global conceptual data model is very useful for an integrated informat ion system. One global data model representing entity and relationships has been presented i n f igure 6.8a and 6.8b. • A detailed analysis and design at an early stage is very essential fo r smooth implementation o f the system. • Sometimes it becomes difficult to update the design when one has progressed deep into the implementation phase. This observation dictates the creation o f the data dictionary. • Prototype development is a useful too l to point out the deficiencies in the design o f data structure. • Enter ing data into the database is a t ime-consuming process. It t o o k a major port ion o f the development t ime o f proposed 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 of images also reduced the speed of processing the information. • The database consumed a lot of disk space when images were loaded on it. Its final version took more than 160MB of disk space. 7.3.1 Validation and Testing The control and assurance of software quality is an essential and critical component of 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 of 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 of important data or excessive unavailability of key resources. The software quality is no longer only determined by the issues of 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 of 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. From the point of quality assurance throughout the system life cycle, most of the existing methods and tools are only suitable for specific phases and error classes. B y suitable combinations of methods and tools, quality assurance and control should become more effective. After completion of the F M T I S prototype it was considered desirable to get the feedback and observations of facility managers of U B C Plant Operations. For this purpose, F M T I S was downloaded on the computer of M r . Rob Seversen, the facility manager of U B C Plant Operations. A small demonstration of the system functionality was provided before seeking the opinion of 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 of systems, sub-systems, and controls. 159 • In order to handle the complex facility management functions such as facility maintenance, this system needs to go down the level of 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 of 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 of information management for facility operation. • A thorough case study of 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 of a global data model for documents of 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 of 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 of 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 of the products and processes involved in facilities. • And last, but not the least, the F M T I S itself. 7.5 Extension and Future Research In terms of 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 of facilities management such as annual facility planning, facility financial forecasting and budgeting, interior space planning, and work place specifications. Another area of interest could involve creating a more tightly knit product model capable of performing detailed integrated facilities management functions. This would allow the development of a more comprehensive computer-based Facilities Management Information System capable of providing information and solving the problems of 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 of Information F low 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 Model . 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 York. pp. 43-57. [Christian & Pandeya 97] Christian John and Pandeya Amar (1997).Cost Predictions of 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 Model . J. of Architectural Engineering, A S C E , December, pp. 170-175. [Fanous & Samara 94] Fanous, Gamil F. , and Samara, Mufid F . (1994). Management Information System Application on Mul t -Mil l ion Overseas Project. Proc. Computoing in Civil Engineering, A S C E . pp. 2157-2174. [Feldman & Mil ler 86] Feldman, P., and Miller, D . (1986). Entity Mode l Clustering. Structuring a Data Model 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 Civi l 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). A Multimedia System for Organizing Construction Documents. Proc. Computing in Civil Engineering, A S C E . pp. 1381-88. [Goldhaber et al 77] Goldhaber, Stanley, Jha, Chandra K . , and Macedo, Manuel C. Jr. (1977). Project Management Information Systems (PMIS). Construction Management Principles and Practices, John Wiley & Sons, New York. pp. 67-188. [Goldstein & Storey 89] Goldstein Robert, C , and Storey Veda C. (1989). Some Findings on the Intuitiveness of Entity Relationship Constructs. Proc. Of the Eight International Conference on Entity-Relationship Approach Toronto. Reproduced by Lochovsky Frederick H . (1990), Elsevier Science Publishing Company Inc. New York. pp. 9-23. 163 [Grimshaw et. al., 1992] Grimshaw Robert W. , Keefe G (1992). Proceedings of the 2nd International Symposium on Facilities Managemnent, Barret P(Ed.) University of 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 of 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 in Civil Engineering pp. 18-32. [Huff 87] Huff, Scott E . (1987) Standardization of Construction Documents. J. of Management in Engineering July. pp. 232- 238. [Kang & Paulson 97] Kang, Leen S. and Paulson, Boyd C , (1997) Adaptability of Information Classification Systems For Civi l 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 . PP. 201-208 [Kent 89] Kent William (1989). The Leading Edge of 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 York . pp. 3-7. [Konsynski 79] Konsynski, B .R . , (1979). Data Base Driven Systems. University of Arizona. 164 [Law & Scarponcini 91] Law , 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 For Specification Format That Accommodates Engineered Products. J. of Construction Engineering and 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 Model , A First Br ick in Computer Integrated Construction. Proc. Computing in Civil Engineering, A S C E . pp. 767-777. [Sanvido & Paulson 92] Sanvido V . E . , and Paulson, Boyd 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. of Computing in Civil Engineering , A S C E . p. 3. [Tenah 84] Tenah, Kwaku A . (1984). Management Information Organization and Routing. J. of Construction Engineering and Management A S C E , March, pp. 101-118. [Tenah 84] Tenah, Kwaku A . (1984). Management Information Organization and Routing. J. of Construction Engineering and Management, A S C E March, pp. 101-118. [Tenah 86] Tenah, Kwaku 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 Model , A C M Computing Survey, Vol.18. No.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 of Civi l Engineers, pp. 272-277 [Vanier et al 93] Vanier, Dj , Mellon, B S , Thomas, R, and Worling, JL. (1993) Management of Construction Information Technology for Construction, k.s. Mathur et al (Eds), World Scientific Publishing Co. Singapore, pp. 75-84. Books [Atre 80] Atre, S. (1980). Database: Structured Techniques for Design, Performance, and Management. John Wiley & Sons New York. [Bamford & Curran 91] Bamford Carl, and Curran Paul (1991) Database Management Systems. Data Structure, Files and Databases, Macmillan Education Ltd . , L o n d o n , U . K . Ch. 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 Ltd . London U . K . [Becker 90] Becker F (1990). The Total Workplace: Facilities Management and the Total Organization. Van Norstrand Reinhold Company New 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 of Data Models, Brodie M . L . , Mylopoulos J., Schmidt J.W. (Eds) On Conceptual Data Modeling, Springer-Verlag. [Bull 90] Bul l , Malcom (1990). Students' Guide to Databases. Heinemann Newnes, Oxford, U K . [Cary & Michael 97] Cary N . Prague and Michael R. Irwin (1997) Access 97 Bible. I D G Books 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 of the A C M 13(6), June, 1970 pp. 337-387. [Date 90] Date, C.J. (1990). An Introduction to Database Systems. V o l . 1 5 t h E d . Addison-Wesley Publishing Company, Inc., Reading Mass. Ch.22. [Hamer 88] Jaffery M . Hamer (1988). Facility Management Systems. Van Norstrand Reinhold Company New 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] Lock, Dennis (1992). Information Management-] &2. Handbook o f Engineering Management, Ch. 20 & 27. 167 [McFadden & Hoffer 88] MaFadden, Fred R., and Hoffer, Jeffery A . 1988. Database Management. Ch. 6 to Ch.9. The Benjamin/ Cummings Publishing Company, Inc., California. [Mintzberg 73] Mintzberg, H . (1973). The nature of Managerial Work, Harper and Row, N e w York . [Murdick & Ross 75] Murdick, R . G . , and Ross, J.E. (1975). Information Systems for Modern Management. Prentice-Hall, Inc., New Jersey, pp. 436-465. [Paulson 95] Paulson Boyd C , (1995) Computer Applications in Construction, McGraw-Hi 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). Boyd & Fraser Publishing Company, Danvers, Massachusetts, Ch. 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 n d Edition, Addison-Wesley, Reading, Mass. [Silberschatz et al 97] Silberschatz Abraham; Korth Henri F. ; Sudarshan; (1997) Database System Concepts, 3 r d ed., McGraw-Hi l l Companies Computer Science Series [Teicholz 92] Teicholz Eric (1992), Computer Aided Facilities Management. McGraw-Hi 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. Prentice-Hal l Inc., Englewood Cliffs, N . J . [Vetter 87] Vetter, M . (1987) Strategy For Data Modelling. Jonh Wiley and Sons Ltd . N e w York . [Yeo et al 78] Yao, S.B., Navathe, S.B., and Weldon J.L. , (1978). A n Integrated Approach to Database Design. Yao, S B . , Navathe, S.B., and Weldon J .L (Eds), Database Design Techniques I: Requirements and Logical Structures Proceedings, N e w York ; 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 of 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 of attribute. Data type represents the type of data the field wil l store, e.g., text, number, date/time, currency, yes/no. The item number is further categorized into long integer, byte, integer, single, double, replication ID Length represents the storage space required for the values stored in he field. Index represents the setting of 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 of the field. The term 'list of 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); Long =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) Unique identity o f commissioning Process P B S ID Text 50 Yes (DOK) Product identifier Product Location Text 50 N o Where commissioned product id located Performed B y Text Text N o The person who performed commissioning Commissioning Date Date/Time Short Date N o Date of commissioning Table A.2 List of Data Elements for Contacts Field Name Data Type Length Index Comments Contact ID Text 50 Yes(NoD) Unique identity o f contact Contact Name Text 150 N o Company's legal name Contact Address Text 150 N o Company's address Contact Phone# Text 20 N o Company's phone number Contact Fax# Text 20 N o Company's fax number Contact Person Text 50 N o The contact person in the organization Table A.3 List of Data Elements for Contracts Field Name Data Type Length Index Comments Contract Id Text 50 Yes(NoD) Unique identifier of contract Facility ID Text 50 Y e s ( D O K ) The facility where contract will be performed Contract Name Text 150 N o Contract Start Date Date/Time Short Date N o The start date of contract Contract Finish Date Date/Time Short Date N o The finish date o f contract Contract Cost Currency Auto N o The total value o f contract Contractor Name Text 150 Yes (DOK) The company which is awarded contract 171 \ Table A.4 List of Data Elements for Drawings Field Name Data Type Length Index Comments Drawin2 # Text 50 Yes(NoD) Unique identifier Drawing Title Text 150 N o The drawing name Drawing Type Text 50 N o The drawing category Issue Date Date/Time Short Date N o The date of issue Revision # Text 10 N o Whether revised or not? Prepared B y Text 50 N o Person preparing drawing Approved B y Text 150 N o Approving Authority Draw-Picture O L E Object N o The drawing picture Table A.5 List of Data Elements for Facilities Field Name Data Type Length Index Comments Facility ID Text 50 Yes(NoD) Unique Identifier Facility Name Text 50 N o The name o f facility Facility Owner Text 50 N o The owner of facility Facility Address Text 150 N o The location o f facility Facility Photo O L E Object N o The facility photograph Table A.6 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 Date/Time Short Date N o The Permit Type Text 50 N o Type of permit, e.g., gas etc. Permit Issue Date Date/Time Short Date N o The date of permit issue Permit Fee Currency Auto N o The fee paid by applicant Issued To Text 150 N o Issued to which party Permit-Image O L E Object N o The image of permit document. Table A .7 List of Data Elements for Products Field Name Data Type Length Index Comments Product Name Text 150 Yes (DOK) The name of equipment PBS ID Text 50 Yes(NoD) The unique identifier of products or equipment S_System ID Text 50 Yes (DOK) Same as S_System ID in Sub System table Supplier ID Text 150 N o The supplier identification Manufacturer ID Text 150 N o The manufacturer 172 identification Product Rating Text 100 No The product capacity Product Weight Text 50 No The product weight Product Model Text 50 No The model number of product Product-Image OLE Object No Product Photo Image Table A.8 List of Data Elements for Tests Field Name Data Type Length Index Comments Test Id Text 50 Yes(NoD) The unique identifier Test Name Text 150 No The name of test process Date Conducted Date/Time Short Date No The date of testing Test Contractor Text 150 No The contractor responsible for carrying out test Test Loc Description Text 150 Yes(DOK) The place, area or location where test was performed Testing Method Text Text No The method used for testing Approval# Text Text No The UBC approval # showing the test was verified Remarks Text Text No The remarks on test report Test Report-Image OLE Object No The image of test report 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 N o It represents start of warranty date Warranty Period Text 150 N o The total coverage period of warranty Warranty Contact Person Text 50 Yes (DOK) The person to be contacted in case of any problem Item Warranted Text 100 N o The product, equipment or sub-system warranted Warranty Doc-Image O L E Object N o The image of warranty document Table A.10 List of Data Elements for WBS Field Name Data Type Length Index Comments WBS ID Text 50 Yes(NoD) It represents the unique identifier Work Item 50 50 N o It represents the item of work associated with Work Break D o w n Structure Table A . l l List of Data Elements for Commissioning Locations Field Name Data Type Length Index Comments Doc Location ID Text 50 Yes (DOK) Same as in Doc Location ID in Locations Table Commissioning ID Text 50 Yes (DOK) Same as in Commissioning ID in Commissioning Table Table A.12 List of Data Elements for Locations Field Name Data Type Length Index Comments Doc Location ID Text 50 Yes(NoD) It is unique identifier of Locations Table Doc Location Name Text 50 N o Individual location names Remarks Text 100 N o The explanation of 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) Same as in D o c locations ID in Locations table Contact ID Text 50 Yes (DOK) Same as Contact ID 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) Same as in D o c locations ID in Locations table Contract Id Text 50 Yes (DOK) Same as Contract ID 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) Same as in Doc locations ID in Locations table Drawing # Text 50 Yes (DOK) 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) Same as in Doc locations ID in Locations table Permit # Text 50 Yes (DOK) 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) Same as in Doc locations ID in Locations table PBS ID Text 50 Yes (DOK) Same as P B S ID in Products Table 175 Table A.18 List of Data Elements for Product Drawings Field Name Data Type Length Index Comments Drawine# Text Same as in Drawings Table PBS ID Text 50 Yes(DOK) Same as PBS ID in Products Table Table A.19 List of Data Elements for Product Tests Field Name Data Type Length Index Comments TestrD Text 50 Yes(DOK) Same as Test ID in Tests table PBS ID Text 50 Yes(DOK) Same as PBS ID in Products Table Table A.20 List of Data Elements for Test Doc Locations Field Name Data Type Length Index Comments Test ID Text 50 Yes(DOK) Same as Test ID in Tests table PBS ID Text 50 Yes(DOK) Same as PBS ID in Products Table Table A.21 List of Data Elements for Warranties Locations Field Name Data Type Length Index Comments Warranty ID Text 50 Yes(DOK) Same as Warranty ID in Warranties table Doc Location ID Text 50 Yes(DOK) Same as Doc Location ID in Locations Table Table A.22 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 Data Type Length Index Comments S System ID Text 50 Yes(NoD) The unique Identifier Sub_System Name Text 50 No Represents the Sub_Systems as noted in AMPEL System ID Text 50 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 Data Type Length Index Comments Facility ID Text 50 Yes(NoD) Same as in Facilities table Doc Location ID Text 50 Yes(DOK) Same as Doc Location ID in Locations Table Table A.25 List of Data Elements for Systems Field Name Data Type Length Index Comments System ID Text 50 Yes(NoD) The unique Identifier System Name Text 50 No Represents the Sub_Systems as noted in AMPEL 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 of the one-to-many (1-M) relationship. The 'related table' column shows the table is at the many-end of 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 Commissioning Location Doc Locations ID 1-M Yes Locations Contacts Location Doc Locations ID 1-M Yes Locations Contracts Location Doc Locations ID 1-M Yes Locations Drawings Location Doc Locations ID 1-M Yes Locations Products Location Doc Locations ID 1-M Yes Locations Permits Location Doc Locations ID 1-M Yes Locations Warranties Location Doc Locations ID 1-M Yes Commissioning Commissioning Location Commissioning ID 1-M Yes Contacts Contact Locations Contact ID 1-M Yes Contracts Contracts Doc Location Contract ID 1-M Yes Drawings Drawing Locations Drawing # 1-M Yes Products Products Location P B S ID 1-M Yes Permits Permit Locations Permit # 1-M Yes Tests Test Doc Locations Test ID 1-M Yes Warranties Warranty Locations Warranty ID 1-M Yes Sub Systems Products Sub System ID 1-M Yes Products Product Drawings P B S ID 1-M Yes Products Commissioning P B S ID 1-M Yes Contacts Products Contact ID/ Manufacturer ID 1-M Yes 178 Primary Table Related Table Field(s) Type Enforce Products Product Tests P B S ID 1-M Yes Contacts Warranties Contact ID/ Warranty Contact Person 1-M Yes Drawings Product Drawings Drawing # 1-M Yes Contacts Contact Trades Contact ID 1-M Yes W B S Sub Systems W B S ID 1-M Yes Contacts Products Contact ID/ Supplier ID 1-M Yes Table B.2 Queries and Join Tables Primary Table Related Table Field(s) Type Enforce Contacts Information Contacts Contacts Trade Contact ID 1-M Yes Locations Contact Locations Doc Locations ID 1-M Yes Project Consultants Contacts Contact Trades Contact ID 1-M Yes Contracts Information Contracts Contracts Doc Location Contract ID 1-M Yes Locations Contracts Doc Location Doc Location ID 1-M Yes Contracts Contacts Contractor Name/ 1-1 Yes Contact ID Drawings and Products Drawings Product_Drawings Drawing # 1-M Yes Drawings Product_Drawings P B S ID 1-M Yes Contacts Products Contact ID/ 1-M Yes Manufacturer ID Drawings Contacts Prepared by/ 1-M Yes Contact ID Drawings Locations Locations Drawing Locations Doc Location ID 1-M Yes Drawings Drawing Locations Drawing # 1-M Yes Drawing Numbers and Products Drawings Product_Drawings Drawing # 1-M Yes Products Product Drawings P B S ID 1-M Yes Primary Table Related Table Field(s) Type Enforce Drawings Products W B S & Subsystems 179 Drawings Product_Drawings Drawing # 1-M Yes Products Product_Drawings P B S ID 1-M Yes Sub Systems Products Sub System ID 1-M Yes W B S Sub_Systems W B S ID 1-M Yes Drawings Contacts Prepared by/ 1-M Yes Contact ID Locations Drawing Locations Doc Location ID 1-M Yes Manufacturer and his Product Contacts Contact Trades Contact ID 1-M Yes Contacts Products Contact ID/ 1-M Yes Manufacturer ID P B S and Subsystems Sub Systems Products Sub System ID 1-M Yes W B S Sub_Systems W B S ID 1-M Yes Contacts Products Contact ID/ 1-M Yes Manufacturer ID Contacts Products Contact ID/ 1-M Yes Supplier ID Product Doc Location Info Products Product Locations P B S ID 1-M Yes Locations Product Locations Doc Location ID 1-M Yes Products Tested their Suppliers and Manu Products Product_Tests P B S ID 1-M Yes Tests Product_Tests Test ID 1-M Yes Contacts Products Contact ID/ 1-M Yes Manufacturer JJD Contacts Products Contact ID/ 1-M Yes Supplier ID 180 Primary Table Related Table Field(s) Type Enforce Product Tested Location Products Tests Product_Tests PBS ID 1-M Yes Locations Product_Tests Test ID 1-M Yes Tests Test Doc Locations Doc Location ID 1-M Yes Test Doc Locations Test ID 1-M Yes Test Locations Tests Test Doc Locations Test ID 1-M Yes Locations Test Doc Locations Doc Location ID 1-M Yes Warranty Start and. Finish Date Warranties Product_Warranties Warranty ID 1-M Yes Products Product_Warranties PBS ID 1-M Yes Contacts Products Contact ID/ 1-M Yes Manufacturer ID Contacts Products Contact ID/ 1-M Yes Supplier ID Warranty Locations Warranties Warranty Locations Warranty ID 1-M Yes Locations Warranty Locations Doc Location ID 1-M Yes Contacts Warranties Contact ID/ 1-M Yes Warranty Contact Person PermitJLocations Locations Permits Permit Locations Permit# 1-M Yes Locations Permit Locations Doc Location ID 1-M Yes Suppliers and Products Supplied Contacts Contact Trades Contact ID 1-M Yes Contacts Products Contact ID/ 1-M Yes Supplier ID 181 Appendix C: System Generated Reports and Printouts This appendix presents some of the system generated drawings, test and permit reports to demonstrate the functionality of the proposed system. • Figure C. 1 • Figure C.2 • Figure C.3 • Figure C.4 System Generated Drawing of High Head Room Lab System Generated Image of Natural Gas System Permit System Generated Test Report Image System Generated Drawing of Safety Roof 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:: 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 BQLS CumgaffY i L I H I T E P , YiiiLnr:«i]:>iK;s 7 •••;;;;;::;:;::;-::;::::;::!:~ P . O . B o * 3 3 9 1 9 , S t a t i o n D T j - I I i • ' '• 1 ' I _ L a i J L. W I L :COE I I :;li;;;;l:;:::L:Mi; •PROVISOS : B.C|. CONTRACTOR COMPLETETI'IS SFirriOKi ftl:SI3~ERE0 N O . . . N A T U R A L GAS _ ; li\DU$rRIAL 2 0 * I A P T / D O S DO 20S !; i: I NiiyyeH or G A S I vET=R$. HEHV IT c u s s \ L I S INGLE FAMILY . _ C O M M E ^ C I M . .^.::::INSLSTSiftt!^ : ^-.'CONGO *J6 ME J . I [ H O M E O W N ' E R ' : C O M P L E T E T H S S E C T O N • u OH PROPANE • •X7. 2 « ' | NATURAL GAS : :Ji iJ"^™'a=;;rr=\o TO:I I:;IIm;TIISSE:.raj xt.ni;v*- •-..••T > M 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,!-^,; C H GITM" M ") 'IV-*!.L APPLJCAWT:S COMPI ?"t IMS SECTION i r GAfi PPfcSSL'RE MOM LOW 2 FSIC : TOT*:; CONN ±C •"• ED LOAD RT.l.'MH •'HOr^hE SUPPLER-(lr APP...C4RL F| ; : 1:igRJE.TO:MEt.1MKY: »HX :hjWB:W.=t,'iE8S ~nE:ami.".:t>: fx:M^NCI?--.L .<."-HKl••••••If-: GAS PERP PERMIT V.AY |?E OBTAI.VtD AT AMY C OK SAFETY FN-GINEEF.IN8 StKVICC INSTALLATION ADDRESS 'f!lM;iTOl.P.',ST , :::::: Ljgiyragny.o* BHiTi-m coui 1355 B a s t K a l i - U , » . C . - J ^ - I — i — i — i — i •_ , „ i : L j rtx,TH. C O D E liMiyiiiiiiyiyy i i I I I...! P E R M I T DETAIL ALL A.PPL IL^STS CO< PCRMT TVPF COl^ b -.aOILER 2. WATER HF«T=R 4. UN.T>EATF^ 3. E.'ACS I IFATFR 6. TIRCPLACF 7. y.U/. &IRPCT c. V.U.A. » i f l t c r . NUMBER CODC o^ - JVIlS 3 iiiiiWSiljii H 9. flOOF TOP UNT| IP. DriYtfn ••Z. RAS3CTOP '3. WLL OVEN V- DEEF TAT T R Y E | 15 BARBEOLC 16 CHINESCCOOKFt INPUT :::BrgH: ttoi TOT* Figure C.2 System Generated Permit Image of Natural Gas Subsystem 183 Tes t Name Heating System and Chilled Water System Close ; : : : : : : : : : : : : : : : ! : ; : : : ; ; : : : 33 ll • TS3 ;.Tcr.cc-atur6: :; • ^ ^ ^ ^ • ^ 3p«ra^in<j PraccJXni 3* " r ir'i'hCCi r ~ '[""r^ 'y V»r£^ :;.::: • • r.TrrTTTTTTTTrT Actual lest A c e s ' j r o : f ine R<j3Mlfca ?uiu lesL avarUed: fc.rrx.Jl 10 f-s-\. Vijao Test 3a*i?lc-cd ; ft*j^4_ Fitness: ^fiCf IsZiAWttiL :Dtl LCL4S:|.1S»£CTICH FtJPCMT : : £: uHwirLtjmrN I : : 03fifi • *••* : ujf *t»" 'I Jcit.il IM Jpi-vhtp 'S^  : »Mtu ; p i £ a!H. J KJJQ rV^ 1>:r*(>i\jAr«»irKT::: Figure C.3 System Generated Test Report Image 184 : Drawing; it B i l l ! : litiNiil^ L.; : i;;!!:; h U N:! f; : 1 ? m i ; iiaS;;:! iiiEay::;::: r . 'ft Figure C.4 System Generated Drawing of Safety Roof Anchor & Tie Back System 185 Appendix D: List of C A F M Vendors Source: Automation (May 1996) pp. 38-48 C A F M banning Construction Management ist Accounting pecifications Lease/ Property Management ns Management Space Allocation/ Forecasting gement Cable Company Name Software Name/Model Operating System Platform Architecture/ Interior 1 Construction Management Facility Budgeting /Co Furniture Inventory /S Integrated CAFM Lease/ Property Management Maintenance/Operatio Room Scheduling Security Space Allocation/ Forecasting Space Inventory Mana Telecommunication s/ Accugraph Corp. U 1 Mountain Top > HP; SUN; I B M W Achieve! Technology, Inc. D 1 Fast Regs P C W A E C Data Systems, Inc w 1 1 1 1 2 Facility Management & D E C ; HP; IBM; SUN u American Computer Software D 1 1 Property Management Series & P C W Apperture Technologies, Inc M I 1 1 2 2 1 1 1 Apperture Visual Information Manager & M A C ; P C W 186 C A F M Architecture/ Interior Planning Construction Management ist Accounting pecifications Lease/ Property Management ns Management Space Allocation/ Forecasting gement Management Company Name Software Name/Model Operating System Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Co Furniture Inventory /S Integrated CAFM Lease/ Property Management Maintenance/Operatio Room Scheduling Security Space Allocation/ Forecasting Space Inventory Mana Telecommunication s/ Cable Apple Computer Inc. M 1 1 M A C ARCHIBUS, Inc. W 1 1 1 1 2 1 1 2 1 1 2 A R C H I B U S / F M 10 P C Autodesk, Inc. D; 1 2 2 2 1 2 2 2 2 2 D E C ; HP; IBM; SGI; SUN U; w Bentley Systems, Inc. D; 1 1 1 1 1 MicroStation M ; D E C ; HP; IBM; ITG; M A C ; PC; SUN U; W Buildings Systems Design Inc. W 1 1 SpecLink; Costlink PC CADapult Ltd. D; 1 2 2 1 1 2 2 2 2 1 1 2 CADapult For Windows W P C 187 60 C A F M 60 =s c o •a c <L) 60 CO 1 ar Plannin gement Cost Acco /Specifica nagement tions Man orecasting inagement ble Managem •c 60 c & o s s CO }-i 1> O . "a 2 «3 o •a Company Name Software Name/Model Lecture/ In ruction M ty Budgeti ;ure Inven ated CAF ' Property enance/O] Schedulii Allocatio Inventorj nmunication Operating System Platfo Archil Const Facilil Furnit Integr Lease/ Maint Room Securi Space Space Telecor CAData Corp. M ; 2 2 2 1 2 2 2 2 2 OnRequest W M A C ; P C C A D C A M , Inc. D; 1 2 2 1 1 1 1 2 2 1 1 1 ITG; P C W C A D Systems Unlimited, Inc. W 1 2 SLICK! For Windows V 4.0 Cambino Networks, Inc. U 1 COMMAND HP; SUN CASI-RUSCO, Inc. D; 1 Entry Perfect, Picture Perfect U; IBM; PC; 0 W Classical Real Estate Systems, L . C . D; 1 1 1 1 The Office Administrator W PC 188 C A F M banning Construction Management ist Accounting pecifications Lease/ Property Management ns Management :casting gement Cable Company Name Software Name/Model Operating System Platform Architecture/ Interior 1 Construction Management Facility Budgeting /Co Furniture Inventory /S Integrated CAFM Lease/ Property Management Maintenance/Operatio Room Scheduling Security Space Allocation/ Fore Space Inventory Mana Telecommunication s/ Classical Real Estate Systems, L . C . D; 1 1 1 1 The Compliance Administrator W PC Classical Real Estate Systems, L . C . D; 1 1 1 1 Corporate Work W PC Cyco International D; 2 AutoManager View; AutoManager W; WorkFlow 0 P C Data One, Inc. w 1 2 2 1 2 2 2 Design Express PC Data Stream Systems Inc. D; 2 2 2 2 1 MP2 for Windows W P C 0 189 C A F M Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Properly Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication sf Cable Company Name Software Name/Model Operating System Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Properly Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication sf Cable Drawbase Software Drawbase W 1 1 1 The Davis Co. Yardi ; Skyline; Custom PC D W 1 1 1 Dranetz Technologies, Inc. D R A N - V I E W ; D R A N - S C A N 2000 P C W 1 1 EQ2, Inc. H E M S 2000 P C ; 0 D W 1 1 Ericksons Systems Aurora Phoenix HP; PC u w 1 1 1 190 C A F M Company Name Software Name/Model Operating System Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Property Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication s/ Cable Management Facilities Management Systems Inc. 1 1 Inspection Manager D PC > W Fields and Screens Inc. 2 1 Work Order Wonder for Windows D PC w 0 F M : Systems w 2 1 2 2 2 F M : S P A C E PC Software House C . C U R E 800; C.CUREStastion /Vision M A C ; PC M w 0 1 191 C A F M 1 00 1 c 1= C .2 1 a s 60 3 O o o 13 « S 00 .S 1 s § < '5 i s 8 Company Name Software Name/Model ecture/ Interior P1E tiction Manageme y Budgeting /Cost ure Inventory /Spe itedCAFM ' Property Manage: aiance/Operations Scheduling Allocation/ Foreci Inventory Manage >mmunication s/ C Operating System 1 '£ 'tj 1 to B E g •c 3 1 1 o J£ El a o O u. 3 c 1 o oi <D C/3 o. H Software House M 1 C . C U R E 750; C.CURESystem 1 Plus M A C ; P C W 0 Strohl Systems w 1 L D R P S ; BIA Professional P C Interprise D I 1 1 1 I 1 1 1 1 1 1 1 A R C H I B U S / F M 1 P C w 0 J.D.Edwards World Solutions Co. J.D.Edwards Construction Solutions Multiple Operating Systems M u lt i 1 192 C A F M Company Name Software Name/Model Operating System cd 60 d '2 3 cd o •c c 3 2 3 6 S cd = I o 3 o O oo c 3 O o u <: o y 00 a OO T3 3 o cd UH 3 o cd o eg o cu a. oo & 3 a | 3 3 3 £ 00 § TO. CD CL o cd (D d 1 00 cd C cd 3 o •a 2 O "S o 3 cd 3 4> 00 a "3 T3 a) •d o oo o c§ •c 3 o <D CO 3° cn Cd o o o •a cd o o (L> O cd CH CO 3 E a> oo cd Q d 1 8 cd OH CO •s O d o 1 Maxwell Systems Inc. The Contractor by Maxwell PC; O D > W | u MICROmAIN Corp. Maintenance Supervisor II P C D W Microwest Software Systems, Inc. I D A M M S P C I W | Raish Enterprises, Inc. Work Order PC;0 D U w 0 193 C A F M Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Property Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication s/ Cable Company Name Software Name/Model Operating System Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Property Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication s/ Cable Raish Enterprises, Inc. Job Costing for Construction Management P C ; 0 D U w 0 1 2 2 2 Resterex /Expert™ Graphics RxAutoImage P r o ™ ; R x H i g h l i g h t ™ Combo P C w 1 2 Resterex /Expert™ Graphics Rx Index ™ / R x V i e w ™ Combo R x S p o t l i g h t ™ P C w 1 2 Resterex/ Expert™ Graphics R x V e c t o r y ™ ; RxVectory P l u s ™ PC w 1 2 194 C A F M Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Property Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication sf Cable Company Name Software Name/Model Operating System Platform Architecture/ Interior Planning Construction Management Facility Budgeting /Cost Accounting Furniture Inventory /Specifications Integrated CAFM Lease/ Property Management Maintenance/Operations Management Room Scheduling Security Space Allocation/ Forecasting Space Inventory Management Telecommunication sf Cable Systems Specialists, Inc. Property Management & Accounting System (pmas I B M D W 0 2 1 2 Ten Man Systems Inc. I B M 0 1 1 1 Timberline Software Precision Collection; Gold Collection P C D w 1 1 T M A Systems, Inc. T M A - T h e Maintenance Authority M A C ; PC M W 0 1 2 1 2 2 195 6D c C A F M Planning gement Accountin educations agement Manageme §> recasting lagement s/Cable Company Name Platform ure/ Interior iction Mana geting /Cost wentory /Sp egrated CAI roperty Man /Operations om Scheduli Security location/ Fo ventory Mar lmunication Software Name/Model Architect Constn cility Bud Limiture Ii -4—> C Lease/ P intenance a Space Al Space In Telecon Operating System lu CO Touchcom, Inc. W 1 1 2 P C ViaGrafix D 1 DesignCAD > M A C ; P M W > 0 • Facility Management Applications: l=Primary Application; 2=Secondary Application • Platform: D=DOS; 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 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 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:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0050186/manifest

Comment

Related Items