Bridging the gap: a tool to support bim data transparency for interoperability with building energy performance software

PDF

Download

Open document

Flip pages

Copy asset link

Request this asset

Request accessible transcript

Transcript (if available)

Content i BRIDGING THE GAP: A TOOL TO SUPPORT BIM DATA TRANSPARENCY FOR INTEROPERABILITY WITH BUILDING ENERGY PERFORMANCE SOFTWARE A Thesis Presented to The Faculty of the School of Architecture University of Southern California In Partial Fulfillment of the Requirements for the Degree Master of Building Science By Mohammed Omar Hijazi May 2015 ii Mohammed Omar Hijazi Email: hijazi@usc.edu Tel: 213-610-1001 Prof. Karen Kensek, Committee Chair Email: kensek@usc.edu Prof. Kyle Konis, Committee Member Email: kkonis@usc.edu Prof. Douglas Noble, Committee Member Email: dnoble@usc.edu Mr. Jeffrey W. Ouellette, Assoc. AIA, IES, Advisor Email: jouellette@vectorworks.net Prof. Douglas Noble, Department Director Email: dnoble@usc.edu University of Southern California iii TABLE OF CONTENTS Acknowledgements 1 Abstract 2 Chapter 1: BIM, BEM and BIM Gaps 3 Importance of the research 4 1.0 Terminology 4 1.1 Building Energy Consumption 6 1.2 Building Energy Modeling (BEM) 7 1.3 Building Information Modeling (BIM) 7 1.3.1 Introduction 7 1.3.2 BIM Standards 7 1.3.3 The Models 8 1.4 BIM Gaps 9 1.4.1 The Survey 9 1.4.2 What is causing the gaps? 11 1.4.3 Overcoming the Gaps 13 1.5 Research Scope 19 1.6 Deliverables 19 1.7 Summary 19 1.7.1 Chapter structure and outline 19 1.7.2 Research objectives 20 iv Chapter 2: The GAP between BIM and BEM 21 2.1 Introduction 22 2.2 BIM/BEM workflow 22 2.2.1 The Models: Design Model vs. BEM 22 2.2.2 Data Transfer: interoperability and round-‐tripping 22 2.3 Interoperability and data transfer 24 2.3.1 File Formats: neutral versus vendor-‐specific 25 2.4 Neutral file format: gbXML 26 2.4.1 Organization of information within the gbXML schema 26 2.5 Neutral file format: IFC 27 2. 5.1 IFC file format 27 2. 5.2 Interpreting the IFC file 28 2. 5.3 Information Delivery Manual (IDM) of energy analysis 28 2.5.4 IFC compliance and certification process 30 2.6 Background literature research contributing to the study 30 2.6.1 HVAC calculations from Revit MEP model utilizing gbXML 30 2.6.2 “Some Advice for Migrating to IFC” (Delfosse et al. 2012) 32 2.6.3 “ Interoperability between BIM and BEM; (Sumedha 2008) 33 2.7 Determining potential problems in data flow 33 2.7.1 Test runs using gbXML 34 2.7.2 Test runs using IFC 36 2.8 Conclusion 37 Chapter 3: Methodology 38 3.1 Introduction: overview of the methods and processes 39 3.2 Defining the required variables 40 3.3 Defining the test case model 41 3.3.1 Modeling 41 3.3.2 Exporting the data models 41 3.3.3 Checking the building form for accuracy and completeness 42 3.4 Proposed tool to help resolve the problem 43 3.4.1 Data Transparency Tool (DTT) 43 3.5 Creating the DTT 44 v 3.5.1 Matching variable set with data model enumerations 45 3.5.2 Mapping data model scheme with new XML schemes 46 3.5.3 Presenting the scheme in Excel 48 3.6 Testing 49 3.7 Conclusion 49 Chapter 4: BIM to BEM Dataflow testing 50 4.1 Introduction 51 4.2 Test case model 51 4.2.1 The model 51 4.2.2 Case study building, subset of critical parameters 52 4.2.3 Choice of Building Elements 56 4.2.4 Revit Rooms versus Spaces 57 4.3 Dataflow testing 59 4.3.1 Checking the building geometry for accuracy and completeness 59 4.3.2 Checking the parameters for accuracy and completeness 59 4.4 The results 60 4.4.1 Building geometry accuracy and completeness 60 4.4.2 Building data’s accuracy and completeness (not geometry) 63 4.5 Comparing the data capacity of the different data models 67 4.5.1 Test runs using gbXML 67 4.5.2 Test runs using IFC 67 4.6 Conclusion 67 Chapter 5: Developing the Data Transparency Tool 69 5.1 Introduction to the chapter 70 5.2 Matching variable set with data model enumerations 70 5.2.1 gbXML 71 5.3 Mapping DTT’s new XML schema 75 5.4 Developing user interface functions 76 5.5 Conclusion 81 vi Chapter 6: Presenting the Data Transparency Tool 82 6.1 Introduction 83 6.1.1 Presenting the relevant data 83 6.1.2 Analyzing the data 83 6.1.3 Reporting 83 6.1.4 Data Model Comparison 83 6.2 A guide to tool use 84 6.2.1 Setup, Startup, and the user interface 84 6.2.2 Importing data models and understanding the data 88 6.2.3 Analyzing the data 89 6.2.4 Reporting 89 6.2.5 Data Model comparison 90 6.3 Coupling DTT with geometry viewers 92 6.4 Conclusion 94 Chapter 7: Future work and Conclusion 95 7.1 Introduction 96 7.2 Future Work 96 7.2.1 Pressure on Software Developers 96 7.2.2 Open source formats 96 7.2.3 Development on the DTT 97 7.2.4 Developing further tools; A IFC to gbXML converter 97 7.3 Conclusion 98 References 100 Bibliography 102 vii Appendices 105 Appendix A: BIM GAP Survey 106 Appendix B: IDM for Precast Concrete enlarged image 113 Appendix C: Philip Cunningham research figures 114 Appendix D: Window and wall element exchange table 116 Appendix E: Enlarged diagram of gbXML original structure 118 Appendix F: DTT additional reports 120 viii LIST OF FIGURES Figure 1.1: 3D model to energy software via gbXML 5 Figure 1.2: Partial diagram of an IDM 5 Figure 1.3 (Left): A partial composition structure for defining an MVD 6 Figure 1.3 (Right): MVD forming a subset of IFC for a specific data exchange. 6 Figure 1.4: Buildings share of U.S. primary energy consumption. 6 Figure 1.5: BIM gaps; a number of causes of data loss at project exchange points. 9 Figure 1.6: Federated model versus a single centralized data model. 10 Figure 1.7: Modeling the same wall with differing amounts of information. 11 Figure 1.8: Responses to how the gap between BIM can be bridged. 14 Figure 2.1: The process of building modeling. 23 Figure 2.2: Type of data models (IFC or gbXML) that BIM Authoring tools and Energy Simulation tools import and export. 24 Figure 2.3: Two data transfer methods between BIM and BEM. 25 Figure 2.4: Partial structure of gbXML file. 26 Figure 2.5: The partial textual representation of project location in gbXML. 27 Figure 2.6: The partial textual representation of project data in IFC. 28 Figure 2.7: Partial diagram of an IDM specifying different exchange files in a specific project phase. 28 Figure 2.8: Architectural Precast Project process Map, IDM for Precast Concrete 29 Figure 2.9: gbXML elements and highlighted in blue are the specific elements supported by Revit MEP. 31 Figure 2.10: gbXML elements and highlighted in green are the specific elements supported by Trace700. 32 Figure 2.11: ArchiCAD® trimming tool and its IFC export 33 Figure 2.12: Results of exchange data of the location, building, and space elements 35 Figure 2.13: The results of the exchange data of the window element and the wall assembly of the material element. 36 Figure 3.1: The textual representation of the materials of a floor assembly from Revit represented in gbXML. 39 Figure 3.2: Building energy modeling variables categorized into Program, Form, Fabric, and Equipment. 40 ix Figure 3.3: Schedules customized to match IDF file exact requirements. 41 Figure 3.4: IFC export window; Revit IFC built in export supports limited schemes of IFC, IFCXML is not one of them. 42 Figure 3.5: IFC export window. 42 Figure 3.6: gbXML export process. 43 Figure 3.7: Diagram of the Data Transparency Tool (DTT). 44 Figure 3.8: gbXML elements. 45 Figure 3.9: Diagram of methodology; matching gbXML and IFCXML enumerations with the defined variable set. 46 Figure 3.10: Diagram of methodology; Utilizing gbXML and IFCXML template schemes as a source to create new schemes. 47 Figure 3.11: Diagram of methodology; Mapping new XML schemes based on the defined variable set and then presenting the scheme in an excel tool. 48 Figure 4.1: Image of the reference office-‐building model from Revit. 52 Figure 4.2: A number of parameters that were included in the representative sample test. 53 Figure 4.3: The layers making up the structure of the wall were part of the representative sample test. 53 Figure 4.4: The wall properties. 54 Figure 4.5: List of gbXML elements. 55 Figure 4.6: Schedules customized to match requirements that were in the IDF file. 56 Figure 4.7: The room-‐bounding property for elements for walls, floors, and roofs. 57 Figure 4.8: Rooms versus spaces in exporting gbXML settings. 58 Figure 4.9: The export gbXML window within Revit (left). Errors in geometry are reported within Revit’s export mechanism (right). 58 Figure 4.10: The base case model in Revit (left). gbXML import was done using gModeller extension to Sketchup (Right). 59 Figure 4.11: The textual representation of a floor assembly in Revit (left), the representation in gbXML (center), the structure of the file (right) 60 Figure 4.12: The created test cast model in Revit. 61 Figure 4.13: Imported model in SketchUp after transferring through IFC. 62 Figure 4.14: Imported model in SketchUp after transferring through gbXML. 62 Figure 4.15: Imported model in IES Pro after transferring through gbXML. 62 x Figure 4.16: Results of the exchange data of the location, building, and space elements. 64 Figure 4.17: The results of the exchange data of the window element and the wall assembly of the material element. 65 Figure 4.18: The results of the exchange data of the space attributes. 66 Figure 5.1: Diagram of the Data Transparency Tool (DTT). 70 Figure 5.2: Diagram of methodology. 71 Figure 5.3: Diagram of gbXML’s original hierarchical structure. 72 Figure 5.4: gbXML elements mapped with DOE’s defined group variables. 74 Figure 5.5: Importing the gbXML template file as source to map the DTT. 75 Figure 5.6: Using the gbXML template file as source to map the DTT. 75 Figure 5.7: Mapping new XML schema based on the defined variable and presenting the schema in DTT’s Excel interface. 76 Figure 5.8: Command buttons are inserted via the developer tab. 77 Figure 5.9: Visual Basic for Applications. 77 Figure 5.10: The five command buttons that were created in the DTT. 77 Figure 5.11: The complete code of “Import” command button.: 78 Figure 5.12: The partial code of “Check Missing Data” command button. : 78 Figure 5.13: DTT’s generated PDF report. 79 Figure 5.14: The partial code of “Generate Report” command button. 80 Figure 5.15: The partial code of “Refresh” command button. 80 Figure 5.16: The code of the “Compare” macro. 81 Figure 6.1: The reference DOE office-‐building model from Revit used for tutorial. 84 Figure 6.2: “Program” sheet encompasses building program variables. 85 Figure 6.3: “Form” sheet encompasses only Building Story variables of the Form. 85 Figure 6.4: “Fabric” sheet encompasses building fabric variables. 86 Figure 6.5: “Equipment” sheet list the power usage. 86 Figure 6.6: “File Spec” presents the meta data of the file. 87 Figure 6.7: “Other Data” sheet. 87 Figure 6.8: File selection window emerges when the user clicks the “import gbXML” button. 88 Figure 6.9: DTT automatically sorts the data into their specified fields. 88 Figure 6.10: Missing data are highlighted in red to alert the user. 89 xi Figure 6.11: The generated (PDF) completeness report of the “Modern Family Home” gbXML file. 90 Figure 6.12: The spreadsheet Compare tool is launched once “Compare” is clicked. 91 Figure 6.13: The user is promoted to select the desired files to compare. 91 Figure 6.14: Both files are brought up and presented side by side. 91 Figure 6.15: The table in the lower center summarizes the differences. 92 Figure 6.16: The medium office model in Revit (left) and the geometrical representation of the exported data model in SketchUp (right). 93 Figure 6.17: A more complex geometry “Modern Family Home” created in Revit. 93 Figure 6.18: The imported model in SketchUp after transferring through gbXML. 93 Figure 7.1 : Type of data models (IFC or gbXML) that BIM Authoring tools and Energy Simulation tools import and export. 98 Figure F.1 : Generated report from DTT reporting function of a 28% model. 120 Figure F.2 : Generated report from DTT reporting function of a 49% model. 121 Figure F.3 : Generated report from DTT reporting function of a 96% model. 122 1 ACKNOWLEDGEMENTS I am using this opportunity to express my gratitude to everyone who supported me throughout the course of this thesis. First off my family, especially my lovely mother Dr. Randa Abu-‐Zarour and amazing father Dr. Omar Hijazi for their undivided support and interest who inspired me and encouraged me to pursue higher education, without whom I would be unable to complete my project. A thank you to my three wonderful sisters; Ayah, Leen, and Shahd whom stood by my side motivating me and to God who made all the things possible. This thesis will not have been possible without the continuous guidance and support of my spectacular committee chair Prof. Karen Kensek. I could not have wished for having a better advisor and mentor than her. I would like to express my deep gratitude to Prof. Kyle Konis and Prof. Douglas Noble, my research supervisors, for their guidance, enthusiastic encouragement and valuable critique of the thesis work. I would also like to thank Mr. Jeffrey Ouellette, for sharing his pearls of wisdom with me during the course of this research. Thanks for Prof. Mark Schiler for being an excellent thesis advisor. In addition, a thank you to Arch. Tim Kohut, who introduced me to Building Energy Modeling, and whose passion for Energy Efficiency had a lasting effect on my work. I want to thank to the King Abdullah Scholarship Program for their financial support. Thanks to Skanska USA Building, Inc., especially Greg Smith and Anthony Colonna, and University of Southern California graduate research program for supporting the BIM gap research. My special thanks to our extended MBS family, especially Bo, Chao, Fahd, Geoffrey, Hui Ling, Sebanti, Shang, Spurthy, and Yiyi whom made the past two years an exciting experience. 2 ABSTRACT Many gaps exist between (BIM) authoring software and Building Energy Modeling (BEM) tools. One gap is due to loss of data in the exchange between the design and energy simulation models. Energy efficiency is now, more than ever, a top concern that should be addressed in the earliest of the design stages. Explaining, understanding, and enhancing the data transfer between software would allow better design decisions through more accurate coordination between energy simulation and building modeling. The data exchange is done mainly using either Green Building XML (gbXML) or Industry Foundation Classes (IFC). Both offer geometrical and thermal data transfers; however they are structured and function differently. Their structure, ability to encode, and ability transfer relevant data from BIM authoring software to the BEM tools were examined. A simple model was exported from BIM authoring software using both file formats and then imported to selected energy simulation tools. The export functionality of the BIM-‐authoring software and the import functionality of the BEM tools was “validated” by comparing the values with the original inputted data in the BIM authoring tool. Special consideration was given to understanding and testing the structure of the data models to encode both geometric data and information, the ability of BIM authoring tools to export, and energy software to import the appropriate data. In many cases, the exchange of data was not complete and in several cases inaccurate or not transparent to the user. A major failing in the data transfer was also user expectations. A user might assume that the data transfer is accurate and therefore base on its export from the building information modeling software; another assumption might be that because it is not, it is useless. It would be extremely helpful to show exactly not only what is being transferred, but also what is actually input as the file is loaded into the energy software. Transparency is critical, especially for inexperienced users. A Data Transparency Tool (DTT) was developed to allow the user to verify the data in the gbXML files and then correct inaccuracies. This is done by applying a transparency layer upon the gbXML data model so users can easily understand what is being transferred. The process of creating the tool was divided into three steps: 1) Matching gbXML enumerations with a defined set of critical building variables that affect energy consumption. These variables were grouped under four main categories: program, form, fabric and equipment. 2) Utilizing the gbXML XML schema to map new XML schemes that match the variable set. 3) Presenting the scheme in a Data Transparency Tool that would automatically populate and analyze the data. HYPOTHESIS One can add a layer of transparency to the data exchange between the design and energy simulation models would allow users to observe what values are being transferred from BIM to BEM. 3 CHAPTER 1 BIM, BEM, AND BIM GAPS 4 The exchange of information between a digital building model and analytical software should be seamless so that designers understand the implications of their changes in designs. However, many gaps exist between Building Information Modeling (BIM) authoring software and Building Energy Modeling (BEM) tools. One gap is the loss of data in the exchange between the design and energy simulation models. This causes a major flaw in perceived software interoperability and failure to uphold user expectations. A user might assume that the data transfer is accurate and base design decisions on faulty values, or that because not all values are being transferred; a BIM to BEM data exchange process is useless. It would be extremely helpful to show exactly not only what is being transferred, but also what is actually input as the file is loaded into the energy software Adding a layer of transparency to the data exchange between the design and energy simulation models would allow for more informative decision making process and therefore reduce the current gap that exists between them and better support the building energy performance simulation and analysis workflow. 1.0 TERMINOLOGY: Below are common terms in the BIM and energy simulation sectors and that are used throughout the document. Building Information Modeling (BIM): “Building Information Modeling is the development and use of a multi-‐faceted computer software data model to not only document a building design, but to simulate the construction and operation of a new capital facility or a recapitalized (modernized) facility. The resulting Building Information Model is a data-‐rich, object-‐based, intelligent and parametric digital representation of the facility, from which views appropriate to various users’ needs can be extracted and analyzed to generate feedback and improvement of the facility design”(GSA 2007). Building Energy Modeling (BEM): Also called Building Energy Simulation (BES) is the use of software tools to predict new energy consumption and costs. Data Model: A structure of symbols and text set to accurately translate and transfer real data (both geometrical and non-‐geometrical) between different applications. DOE Variable Categories: Four categories that group the different parameters that energy software use for simulation; Program, Form, Fabric, and Equipment (Deru et al. 2011). gbXML: gbXML is an open schema developed specifically to transfer building geometrical and thermal data enabling interoperability between BIM authoring software and energy simulation tools. 5 Interoperability: “The ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE Std 610 1991) (Fig. 1.1). Data exchange can be done through different workflows, 5 of which are explained in Chapter 2. Figure 1.1: 3D model to energy software via gbXML using Autodesk Revit/Vasari and Green Building Studio as an example (Autodesk 2014). Industry Foundation Classes (IFC): Industry Foundation Classes (IFC) is an open standard data specification that is object based, vendor neutral, open source, and freely available to the public and software developers. It is intended for BIM interoperability and is used for describing building components and construction data. It is actively being developed by the buildingSMART International organization, (http://www.buildingsmart.com and http://www.buildingsmart- tech.org/), (Kensek 2014). Information Delivery Manual (IDM): A standard within IFC that specifies when and what information is needed at each exchange point. IDM specifies specific details of the exchange requirements and is created with the input of focus groups from the industry (Fig. 1.2). Figure 1.2: Partial diagram of an IDM specifying different exchange files in a specific project phase, for example this diagram can resemble an IDM for concept design phase for energy analysis. Model View Definition (MVD): The formal translation of the IDM and the prerequisites into software language, which forms a subset of the IFC for a specific data exchange (Fig. 1.3). 6 Figure 1.3: Left: A partial composition structure for defining a Model View Definition (MVD) (Chuck Eastman, Manu Venugopal, Rafael Sacks 2015). Right: Example of MVD forming a subset of the IFC for a specific data exchange. 1.1 BUILDING ENERGY CONSUMPTION Building design, construction, and operation consume a large amount of energy and resources and create substantial amount of waste. Building energy consumption has been steadily increasing and reaches significant percentages in developed countries. In the US, residential and commercial buildings account for almost 39 percent of total U.S. energy consumption and 38 percent of U.S. carbon dioxide (CO2) emissions (DOE 2008). The population growth and increasing demand on building will assure this upward trend unless dramatic changes are made (Fig. 1.4). Figure 1.4: Buildings Share of U.S. Primary Energy Consumption (DOE 2008). This continuous increase in demand for energy is a result of industrialized development and population growth. This triggered research for more efficient energy methods. Europe faced the energy crisis earlier this century and is now well ahead of the US in in energy conservative measures in most if not all of the sectors. These measures include stricter building regulations as well as the industry reply of advanced technological systems and techniques. The International Energy Efficiency Scorecard ranks the countries with leading economies depending on their energy efficiency policies and programs, USA ranked #13 behind most of the EU countries (ACEEE 2014). 7 1.2 BUILDING ENERGY MODELING (BEM) BEM is the use of software to predict the energy consumption of a building. BEM takes many attributes of the building geometry, location, internal loads, end user, and weather file to generate the energy consumption charts. BEM has applications in building design, life-‐cycle cost analysis, and energy retrofit analysis. To become effective, energy efficiency should be a determining factor in the design of buildings and therefore should be carefully analyzed at the very first of the design stages. However the lifecycle energy efficiency and corresponding cost savings are not main factors in building design process, which makes unlikely that every building is designed to maximize use of energy efficient design. Therefore, incorporation of energy efficient methods often comes in late stages. (Stanford 2014). Many designers do however, realize the importance of energy efficient measures and embed its concepts in the building design but these concepts are rarely properly evaluated. This is sometimes caused by the inability of software to assess these concepts, such as effect of vegetation, and in other cases user related. 1.3 BUILDING INFORMATION MODELING (BIM) 1.3.1 Introduction The building industry makes up a large portion of the US market share and is an ever-‐ growing industry that continues to evolve. It is a complex process and goes through many stages and involves different firms and individuals. They are tasked with partial tasks that eventually unite to create the project whole. BIM is an emerging technology that attempts to addresses this gap by creating a workflow process that serves the whole building life, starting from design throughout all its phases until demolition. BIM emphases on data management and the ability to access and transfer correct information between project models and phases. It utilizes 3D representation to improve the input and utilization of the data within the model. BIM enhances project coordination and collaboration between the various professionals involved to support more informative decision-‐ making. It has proved to be very successful in the industry and most, if not all, major firms have already adopted it. “Since its inception in 1970s, the industry-wide adoption of BIM has increased from 28% in 2007, 49% in 2009, to 71% in 2012 in the North America” (McGraw-Hill 2012). 1.3.2 BIM Standards “A major part of managing BIM is establishing standards against which the organization can measure itself including both its products and processes. BIM standards have come from a variety of sources; three common ones are from the American Institute of Architects (AIA), BIMForum, and the National Institute of Building Sciences (NIBS). The AIA is the US’s professional organization for architects, offering education, government advocacy, community redevelopment, and public outreach to support the architecture profession. AIA collaborates with the other organizations in the AEC field in an effort to coordinate the AEC industry and produces many regulatory documents and aims to set standards to manage the design and construction process (AIA 2014). BIMForum is a professional organization for facilitating and accelerating the adoption of BIM in the AEC industry. Its umbrella covers ten sub-‐forums that address the different industry sectors and topics by collaborating with each other and other industry organizations (AIA, NIBS, NIST, IAI, C3T, 3xPT, CURT, etc.) (BIMForum 2014). NIBS is a non-‐profit organization that aims to improve 8 the performance of buildings by supporting advances in building science and technologies. NIBS recognized the importance of BIM and accordingly created the National BIM Standards Project Committee (NBIMS) with a mission to "improve the performance of facilities over their full life-‐ cycle by fostering a common, standard and integrated life-‐cycle information model for the AEC and FM industry” (NIBS 2014).” (Kensek, Becker, and Hijazi 2014) 1 1.3.3 The different Models “Different theories and expectations exist as to whether or not it is possible to have a single BIM for the lifecycle of a building. In current professional practice, there rarely exists a single unified project BIM. Instead, there are many BIMs used for diverse purposes that evolve over time: • Design BIM. This is a building project BIM held by the architect that links the design intent model with those of the consultants. • Consultant BIMs. This includes those models created by the consultants: structure, MEP, fire protection, etc. • Constructability BIM. This is a building project BIM developed by the contractor that links the design BIM and those from sub-contractors and fabricators if they exist. Often this includes a range of file types from 2D CAD drawings to fully 3D BIMs. • Facilities Management BIM. This BIM can be used towards using the design and construction information and incorporating it into a computerized maintenance management system.” (KBH 2014) “Partial BIMs come into existence for a specific purpose. For example, designers might use part of the design BIM for a conceptual energy model. This implies that the users know what they need to run the analysis software and employ the appropriate subset of data useful for completing that task. This is in contrast to “fragmented BIMs” where not all the information that is needed is contained in the BIM, and it is unclear who is responsible for including that data. Fragmented BIMs have led to gaps in the handoff of models (Fig. 1.5). Determining ways of bridging gaps provides opportunities for future development of building information modeling and provides tangible benefits for the design-‐construction industry.” (KBH 2014) 1 (Kensek, Becker, and Hijazi 2014): This is a white paper titled “BIM Gaps: major issues that are preventing seamless integration of building information modeling in the AECO industry” that has been developed by Kensek, Becker and Hijazi (The thesis author) in conjunction and at the same time of this thesis. The paper therefore is quoted extensively in Chapter 1 as an introduction to the BIM gaps. It will be referred to as (KBH 2014) as a shorthand. 9 Figure 1.5: BIM gaps; A number of causes of data loss at project exchange points. 1.4 BIM GAPS The acronym BIM might be accurately described as building information management as a strong component of BIM is to support the flow of data and connect the different disciplines and phases throughout the lifecycle of a building. However, there are still gaps in the data transfer between the different phase-‐specific models of the project; they interrupt the flow of data. In order to understand the nature of the gaps, a survey was taken targeting professionals in the design and construction industry with specific question aiming to understand the flow of data between BIM models. The results were tabulated, and problems and potential solutions identified. 1.4.1 The Survey BIM increases the collaboration and makes data communication more effective but it introduces new challenges on how the data will be shared, using which platform and which team members will have access and to what extent. Through interviewing professionals and sending a survey about these gaps, it was shown that many professionals believe that gaps exist and that there is a technology aspect to it. The survey was sent to 3,300 individuals in the building industry. 172 people responded with information about their organization, their role in the firm, and their organization’s use of BIM. The survey questions can be found in the Appendix A. “This survey focused specifically on the problems that individuals were having the models themselves, existing BIM standards, and perceived BIM gaps.” (KBH 2014) The results of the survey led the researchers to further examine a number of topics, starting from the different BIM models, their data structure and how they are linked. Focus was then put on the existing gaps between the models; the causes behind the gap and ways to overcome it. The Models: 10 “BIM management is an important and growing part of the AEC industry” (Azhar 2011). Professionals fully dedicated to this management are becoming more common, demonstrating a shift in the industry and the importance of data management (Deutsch 2011). Organizations handle BIM in many different ways with varying degrees of commitment, complexity, and success. One of the key questions in determining (and eliminating) the BIM gap stems from the number of models used for each project. More than half of the respondents (53%) indicated that their organizations use multiple building information models for each project. The vast majority of these (49%) use discipline-‐specific models, whereby the architect has a model, separate from the structural engineer’s model and mechanical engineer’s model. “Although separate, these models are often linked so that each model is not made from scratch (Fig. 1.6). Typically, this provides the needed functionality while keeping the file size down (a concern due to technological restrictions). The benefits of this method include a clear division of responsibility (or perhaps even more importantly, liability). Separate models make it easy to see who did what, and there is a clear hierarchy for decision-‐making. The remaining 4% used separate models, differentiated by design phase. This means that all of the project team members work together on a single model during each phase of design. A challenge with this method is that responsibility and liability are harder to determine when entities are all working on the same model at the same time. It raises questions of how mistakes and changes are responded to and how this changes the scope of work for each party. ” (KBH 2014) Figure 1.6: Federated model versus a single centralized data model. “One third (33%) of the respondents indicated usage of a single, centralized model. With this method, one model is worked on by all members of the project team throughout the life of the project. For this method to be feasible, an adequate sharing platform must be selected, and the team must have computers capable of handling the very large file size of the model. Responsibility and liability must be clearly defined contractually. The remaining respondents (14%) selected “Other.” Two primary reasons were given for choosing this option. The first reason was that their organization does not use BIM. The second reason given was that the model type changed from project to project. Knowing how an organization uses and shares models makes the gaps between the models more apparent. It is essential to understand the purpose and composition of the many types of BIMs used in the industry. The intent of a building information model is a very important factor when determining how BIM is to be used. Project team members must consider the model at each stage of development and its purpose. For example, a design intent model is used to express the form and defining characteristics of the project. If all of the data for execution of the project (for example, including shop drawings) are included from the beginning, the model is no longer for design intent, but for execution. This can cause unnecessary confusion. By embracing 11 the intent of the model in each phase, timing for the expression of data is clearer. To avoid confusion, this might involve using placeholder data in stages where the actual data is not relevant to the decisions being made (Ouellette 2013). If the intent of the model is clear, the expectations of the team creating it are clearer as well.” (KBH 2014) Does the Gap Exist, and Is It a Problem? “Research into the BIM gap and associated problems was initiated based on two critical assumptions. The first was that gaps exist. Although experience and anecdotal evidence reaffirmed this conjecture, it was important that the assumption be validated with information from the industry. When asked if the gap between BIM used for design and BIM used for construction existed, more than 4 out of 5 respondents (81%) said “yes.” Only 11% said “no,” and 8% said they did not know. These findings were in line with the initial assumption and serve to support the existence of the BIM gap. The second critical assumption was that the gap was detrimental to projects in terms of time, efficiency, money, technological resources, or any combination of these or any other issues. When asked if the gap caused a problem, 63% of respondents responded “yes”, while 23% said “no.” The remaining 14% did not know. While not as definitive as the first question, these responses also seem to validate the assumption that the gap is in some way detrimental (although having nearly a quarter say it was not a problem, and another 15% not know was somewhat surprising and dismaying).” (KBH 2014) 1.4.2 What is Causing the Gap(s)? “Survey respondents were asked to select from a list the possible causes of the gap. They were not limited in the number of selections they could make. The top responses were very close in terms of total respondents. Half of all the survey participants listed lack of knowledge of construction methods as a contributor to the BIM gap. When participants were then asked to indicate which issues they believed to be most critical in causing the gap, lack of knowledge of construction methods was again the most popular response, with 34% of all respondents citing it. According to Jeffrey Ouellette, the problems facing BIM are inter-‐professional; rooted in a lack of understanding among the architecture, engineering, and construction disciplines. There is a clear knowledge gap in the BIM process, evidenced by how models are made and the different expectations of each party (Ouellette 2013). A simple example of this is a wall. A contractor wants to see every layer and material, how the finishes begin and end, and how the wall connects to the rest of the structure. An architect however, only needs to see the form of the wall and will often make the wall a single component (Ouellette 2013). The question becomes, how much do AEC professionals need to know about each other, and with increasing specialization, how to share that knowledge that is needed at the appropriate detail level for the stage of design/construction that is underway (Fig. 1.7). “((KBH 2014) Figure 1.7: Two ways of modeling the same wall with differing amounts of information. 12 “Unclear responsibilities ranked as the second most selected contributor to the gap (with 49%) and the second most critical contributor (with 30%). Clarity is important because the current conventional workflows and BIM design and modeling processes differ. The conventional process is linear. It moves from one team to the next and is easy to assign responsibility to members of the project team (Larsson 2004). The BIM process can be more open-‐ended. The model could be influenced by a large number of players, so finding a way to control its information content is essential. Questions faced by project teams include: Who makes the decisions in cases of value engineering? How are data and the model(s) to be shared? How is quality control maintained? In an environment with many authors/editors, who is responsible? These questions address the way many people work together more than the actual work itself, but they are essential to successful BIM (Ouellette 2013). In fact, one of the most important elements of BIM is not unique to BIM at all and can be used to define all of the responsibilities of a project team: the legal contract. However, a contract is not a simple or guaranteed solution. A) Legal Issues The legal issues that accompany BIM are numerous and complicated. While there is little doubt that BIM can enhance the design process and assist in the execution of a project, it raises many issues. The multiplayer nature of BIM begs questions about party liability and who assumes which risks. Proper ownership of intellectual property also comes into question, if multiple parties have been working on and changing the same design. Unfortunately as of this writing, there is no clear precedent by which to interpret matters of BIM and the law (Koenig 2014). The current doctrine presiding over construction cases is United States vs. Spearin, a 1918 case finding that there was “an implied warranty of design accuracy” meaning that fault lies with the contractor unless the problem can be traced to the plans and specifications (Koenig 2014). This aligns nicely with the more traditional construction delivery method of design-‐bid-‐build, in which distinct parties (for example architect and contractor) perform specific and separate tasks (design the building and construct the building), in a set order (the design is completed before construction begins) (Sabo and Zahn 2005). However the utility of this doctrine diminishes as more and more projects use collaborative media (such as BIM) in delivery systems which are not so compartmentalized (like design-‐build), so the law needs to catch up with the industry (O’Conner 2007). The building departments of most local governments add to this problem, since the documents of record are the traditional two-‐dimensional plans. It is the 2D plans that are legally binding, and until these building departments can start assessing and approving BIMs (which will lead to more wide-‐spread right of reliance for these models) bridging the gap will be an uphill battle (Koenig 2014).” (KBH 2014) B) Communication Issues “Although BIM’s goal is to increase project collaboration and communication efficiency, it introduces new challenges on how the data will be shared, using what hardware and software, and which team members will have access and to what extent. The second-‐most selected (tied with unclear responsibilities at 49%) and third-‐most critical contributor to the BIM gap (with 26%) was a lack of knowledge about standards and processes. A large number of participants (65%) indicated that their organizations use standards of some 13 kind, so this seems to indicate that the standards are not strongly enforced within the organizations. BIM is a project wide process that delivers through technology. Unfortunately this process is far from being governed by a single standard. “BIM standards are as varied as railroad track widths were in the early 1800s” (Shapiro 2014). Different projects and firms have different specific activities and properties that make their case unique – however, this does not imply that everything associated with a BIM-‐based project is unique. The concept of a BIM Execution Plan (BEP) arose to regulate BIM processes. The intent is that a firm would have a BEP to cover recurring issues and adapt it with project specific alterations.” (KBH 2014) C) Interoperability Issues “Interoperability is defined as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE 1990). Therefore BIM software, ideally, should support the seamless flow of data in all exchange points. However, software interoperability is an issue that faces the industry in all of its activities (Bazjanac 2008). The survey results support this as a staggering (77%) of the respondents indicated that their organization faces software interoperability issues that may cause incompatibility between the different building information models. Project losses caused by interoperability are apparent; however evaluating and quantifying monetary losses has not been an easy task. The US National Institute of Standards and Technology (NIST) issued a report in August 2004 that estimated that $15.8 billion was lost annually by the U.S. capital facilities industry due to inadequate software interoperability. The research included "design, engineering, facilities management and business processes software systems, and redundant paper records management across all facility life-‐cycle phases." The cost of inadequate interoperability was reached by quantifying the efficiency loss caused by interoperability issues. The value was reached by comparing the actual costs with a hypothetical scenario in which the data exchange, management, and access were seamless (Gallaher et al. 2004). Finally, 11% of the survey participants indicated that a lack of knowledge of BIM-‐related software was a contributor to the gap. BIM is a process supported by technology; understanding the software commands is not enough to practice correctly. “ (KBH 2014) 1.4.3 Overcoming the Gaps Many organizations believe that the gap between design and constructability building information models is a problem, and they have not sat idly by waiting for a solution. Survey participants indicated what their organization currently does to address the problem (Fig. 1.8). Early contractor involvement, dedicating more time to early phases of design, and employee training topped the list of responses. 14 Figure 1.8: Participants responses to how the gap between building information models can be bridged. Drawn from the overall survey, but augmented by interviews and other sources, several methods of overcoming the gap have been categorized into communication, technology, and legal methods in the following sections. A) Legal Methods Although only one survey participant expressly stated a law-‐related method for bridging the gap, the authors believe that they could be very powerful in making the handoff of models from designers to builders much faster and smoother. Although adopting various standards and technologies in firms is optional, fulfilling the contract is mandatory. Two specific examples where this might be improved through contracts are the right of reliance and the record BIM (or BIM to facilities management). 1. Right of Reliance: In some cases the 3D BIM might actually be part of the documentation; there might be a “right of reliance” on it. Right of reliance is a term that refers to whether or not one can use the 3D model (in addition to the drawings or specifications) for questions about what is to be built” (Kensek 2014). Since the right of reliance is not guaranteed in most contracts, it is difficult to fully use the information in the BIM including the 3D geometry to its fullest advantage without re-‐doing a lot of work, a major gap in the handoff between the architect and contractor. Until legal policy develops to better accommodate BIM and the evolving construction industry, the contract tying parties together will be the single most important document of the project. The contract should define (typically on a case-‐by-‐case basis) the scope of work required of each party, and the associated responsibilities and risks. Other issues must also be addressed in the contract, such as who is responsible for the cost of corrections in the event of an incorrect model, who retains ownership of the model, and how changes are tracked and documented (Guangbin, Xuru, and Wei 2011). 2. Record BIM: The record BIM is a deliverable to the client at closeout, specified in the contract, that is used as a virtual description of the building, its systems, and associated data (either within the model or linked to it), which can be used as a source of documentation about the building throughout its life cycle (Kensek 2014). Some owners require the use of BIM and the handover of the model to them at the end of the project. This model is typically used for facilities maintenance, and the owner may have very specific instructions as to how models are to be built, naming conventions, and how the model/s are to be shared. Owners with large portfolios (like universities) set their own requirements for BIM. However, although these standards may be rigorous, they are designed for the owner and might not have any effect on how a designer and contractor 15 exchange information during the design and construction process. Establishing the terms of a contract as an owner is not difficult. The problem is that it is very rare for a contract to require a BIM to be used for execution, even though it could easily be done (Koenig 2014). The ConsensusDOCS 301 BIM Addendum has been created to begin to promote the use of BIM through supportive legal documentation (Lowe and Muncey 2009b). Clearly defined contractual responsibilities and expectations as they relate to BIM would go far to bridge the gap between design and construction professionals and their models, but contracts do not remove every barrier.” (KBH 2014) B) Communication Methods “Communication in one form or another is the most widely used method for bridging the gap. Since the cause of the gap was reported to be due to, at least in part, a lack of understanding between the design and construction disciplines, greater and more effective communication may help to alleviate problems. More than half of the survey’s participants indicated that their organization holds regular coordination meetings with all members of the project team including those with on-‐site “big room” BIM-‐based gatherings. Additionally, more than half of the participants also indicated engagement with the contractor at the very earliest stages of the project has helped to bridge the gap. Other communication methods include project delivery methods, standards, AIA documents, level of development, and The National BIM Standard-‐ United States™ (NBIMS-‐US). 1. Project Delivery Methods One of the biggest influences on the BIM gap and its effects is the way teams are set up to work together and deliver a project. The traditional delivery method of design-‐bid-‐build and the existing insurance tools and legal precedents that accompany it have put considerable effort into clearly differentiating the parties of a construction project, explicitly stating where responsibilities and liabilities lie (Ashcraft 2008). This creates adversarial roles among members of the team and can add to costs, both in terms of time and money. Because the full benefits of BIM are only realized in a more collaborative work environment, more flexible and supportive delivery methods are needed (AIA / AIA CC 2007). In some cases, the industry appears to be moving this way Yunnan Allen revealed in an interview that all but one of her recent projects with HMC Architects utilized the design-‐build delivery method, a method which contractually joins design and construction entities from the start. A single contract minimizes liability for the owner and typically reduces the timeline by allowing design and construction services to be performed simultaneously. This necessitates increased communication and, according to Allen, leads to less of a BIM gap because everyone is on board and working on models from the beginning and “guarantees the maximum good for the client” (Allen 2013). A design-‐build project would make sharing information easier and more effective, since it effectively joins the design and construction entities into a single unit, at least in terms of the contract (Ashcraft 2008). Integrated project delivery (IPD) is another delivery method conducive to a BIM-‐based process that effectively reduces problems by encouraging information interchange through the project. According to the AIA / AIA CC Guide, “the full potential benefits of both IPD and BIM are achieved only when they are used together” (AIA / AIACC 2007). Lean Construction is a “way to design production systems to minimize waste of materials, time, and effort in order to generate the maximum possible amount of value," (Koskela et al. 2002). It is a specific process, meant to better align team members working toward mutually 16 beneficial goals, and when used in conjunction with IPD can reduce waste and increase the reliability of planning. This is demonstrated by Integrate Project Delivery Inc.’s use of IPD and Lean Construction to deliver an Events Center for the Orlando Utilities Commission at a savings of over $1 million on a $7.5 million guaranteed maximum price contract (IND. Inc. 2014).” (KBH 2014) “2. Standards Since the second-‐most selected and third-‐most critical contributor to the BIM gap was a lack of knowledge about standards and processes, producing unifying standards would be one of the most important ways to bridge the gap. Part of the challenge that faces the construction industry comes from the nature of its projects. The AECO industry deals with distinctive projects and cannot be compared to other industries such as the automotive where the process is recurring repetitive for mass production (Simmonds 2014). The concept of a “One Unified Standard” therefore is difficult if not impossible to achieve, but many efforts exist to govern aspects and clarify attributes of the workflow. These include the AIA documents, level of development (LOD) classifications, and The National BIM Standard-‐United States™. AIA Documents: The AIA produces documents that serve as tools to support and govern the use of BIM across the project. These documents are produced from collective input from practitioners from across the industry. An example is the E202-‐2008 BIM Protocol document that specifies who is responsible for creating each model element and to which detail. It also clarifies model intent, authorized use, model reliance and legal aspects as well as model ownership. Another important document is the G202–2013, Project Building Information Modeling Protocol Form. “Its purpose is to document the agreed upon protocols and procedures that will govern the development, transmission, use and exchange of building information models on a project” (AIA 2013). Below is a list of AIA digital practice documents. A document that explains the purpose of each document and guides their use can be found at following link. (http://www.aia.org/groups/aia/documents/pdf/aiab095711.pdf) Level of Development: Another issue that faces BIM and contributes to the gap is the lack of standards that manage model expectations (Ouellette 2014). When a BIM deliverable is required by the contract at an exchange point or phase handover (at the end of the design development phase, for example), what exactly the model should include and how far it should be developed might be undetermined. The Level of Development Specification was created to tackle this issue by establishing a standardized content requirement at various stages of the design and construction process (BIMForum 2014). The LOD Specification was developed by the BIMForum expanding on AIA initial definitions that were set for the AIA G202-‐2013 Building Information Modeling Protocol Form (AIA 2013). BIMForum made a clear distinction between the level of development and level of detail. The level of detail is how geometrically complex the components are. Level of development is how much reliable data can be interpreted about the element. The document defines six levels of element development that progress from generic symbols at LOD 100 to reach field verified representations at LOD 500. Assigning LOD specifications at each stage of the BIM process aids in standardizing the models and therefore supports informed communication and expectation management. LOD’s role in bridging the gap is advocated by many professionals. Brok Howard of HOK considers LOD an integral tool for successful communication in the AECO industry. He encourages the thoughtful use of LOD documents as an agreed upon dictionary for the industry 17 use. In that sense it becomes the reliable reference for defining contractual terms. Howard argues that emphasis should not be on what needs to be modeled and instead the notion of what information needs to be communicated and at which stage of the design process (Howard 2014). Elizabeth Chodosh of CannonDesign expressed that the LOD definitions by themselves are not enough. Even though the LOD document contains the level definitions, different interpretations of the same item can be made. She explained that CannonDesign take a further step by introducing BIM authoring tools they use to LOD definitions by identifying families and family types as layers within the LOD. These refined LOD definitions are clearly articulated and set as part of the BIM execution plan (Chodosh 2014).” (KBH 2014) “The National BIM Standard-‐United States™ (NBIMS-‐US) The National Institute of Building Sciences buildingSMART alliance™ developed the NBIMS-‐ US in an effort to resolve the gap in data exchanges for facility information. NBIMS-‐US™ is consensus document that aims to provide standards to facilitate efficient life-‐cycle management of the buildings with the aid of BIM technology. Ouellette explains that this was done by providing the standard elements and mechanisms for creating and transferring the BIM data. “These elements and mechanisms include reference standards of technology and classification systems; information exchange standards that describe the processes and exchange requirements for tasks during different parts of a building’s life-‐cycle” (Ouellette 2014). These definitions will form the foundation for effective communication in the industry. C) Technological Methods Solutions for these will be discussed in two categories: increasing people’s knowledge of BIM technology and increasing software interoperability. BIM has been adopted by most of the major firms in today’s AEC industry. “Since its inception in 1970s, the industry-‐wide adoption of BIM has increased from 28% in 2007, 49% in 2009, to 71% in 2012 in the North America” (McGraw-‐Hill 2012). 88% of the survey respondents stated that they were proficient with BIM, 11% where individuals who knew of BIM but didn’t use it, and only 1% stated that they are not familiar with BIM at all. 1. Education Although BIM adoption levels are high among the firms, it is unmatched with proper education at schools. Many believe that BIM is not rooted properly in the education system. Howard complains of the lack of knowledge of the people that are coming out of school and argues that it is one of the main contributors of the gap. He sees that the burden of educating BIM is currently transferred to and put upon the firms (Howard 2014). Therefore the post-‐ professional educational tactics including trainings, in-‐firms meeting, professional conferences and education modules require graduates to be aware of the concepts to work properly. Kymmell identified the main obstacles in introducing BIM to the education curriculum and categorized them in three groups. The first related to understanding the BIM tools, the second related to understanding BIM concepts and processes, and the third related to circumstances of the academic environment (Kymmell 2008). Some schools have overcome these obstacles and introduced BIM in their curricula. BIMForum conducted an academic survey on 8 US and 3 international universities in July, 2007. Result show that 82% of them formally teach BIM in courses and projects. The survey shows that these efforts are quite recent as most responses (55%) stated that BIM was just introduced during or after 2005. Today, schools such as Pennsylvania State University, Georgia Tech, University of Southern California, Montana State 18 University, and University of Wyoming are acknowledged as leaders in BIM education (Barison and Santos 2010). ” (KBH 2014) 2. Software Interoperability Industry neutral file formats are being developed to support data exchange. Industry Foundation Classes (IFC) were created for BIM interoperability as “an object-‐oriented file format with a data model developed to facilitate interoperability in the building industry and a commonly-‐used format for BIM.” (buildingSMART 2014). The IFC file format was developed by the International Alliance of Interoperability (IAI), now known as buildingSMART. IFC provides an object-‐oriented file-‐format solution that is interoperable with different software functioning at different stages of the project. By doing so the flow of data is continuous through one file structure from the initial design stage all the way to project execution. In that sense IFC is more practical than gbXML as the latter is specifically developed for energy simulation and does not function for other BIM interoperability concerns. IFC also has a strict software certification program that ensures reliability and interoperability that gbXML lacks (Ouellette 2014). As the seamless flow of data through the lifecycle of a project is essential for BIM effectiveness, it has been argued that the term “building information management” is a better description of the role of the technology and processes that it changes in an office. The correct data should be successfully transmitted between the different participants in the project at appropriate exchange points. A standard formally known as the Information Delivery Manual (IDM) in IFC specifies when and what information is needed. The IDM defines the different exchanges through the project/product lifecycle and describes the details requirements of each exchange. The IDM is created with the input of professional organization and focus groups from the related industry (buildingSMART 2014). The output of the IDM is basically the industry’s description of data flow. This is balanced with the software capabilities and then transferred into IFC-‐based language solutions (Aram et al. 2010). These solutions are the Model View Definitions (MVD), which become subsets of the IFC for a specific data exchange. The MVD is the source for software requirement specification to satisfy an exchange requirement as it defines all the required definitions and implementation requirements for IFC concepts (buildingSMART 2014). One example of a collaborative effort to address such industry-‐wide exchanges is being done as part of the Precast Concrete National BIM standard where specific information exchanges were defined. The standard was formed by input from the Precast/Prestressed Concrete Institute and the Charles Pankow Foundation with technical support from a team from Georgia Tech and the Technion. Twenty-‐six exchanges were identified between the different professionals acting on the precast elements throughout the product lifecycle (Eastman et al. 2011). By identifying where the exchanges occur, what information needs to be passed, and how to encode that information in IFC, many gaps in file interoperability can be filled. ” (KBH 2014) Survey Conclusion “Gaps exist between building information models used for design and models used for assessing constructability and energy simulation. That these gaps are detrimental to industry efficiency, collaboration, and profits is also a widely accepted notion, though the true extent of the problem has not been determined. ” (KBH 2014) The survey respondents grouped these gaps into various categories including legal, communication, technology, and discipline silos. “Undoubtedly there has been significant progress for BIM, both in bringing it to prominence in the AECO industry and in trying to minimize the gaps between project team members. Interoperable data formats, industry standards, and execution plans all seek to assist designers, builders, and owners in providing and maintaining the best possible building. But more is necessary if BIM is to be used to its full potential and transform the industry. ” (KBH 2014) 19 1.5 RESEARCH SCOPE The survey identified many causes of the BIM gaps. These causes were categorized into legal issues, communication issues, and interoperability issues. The interoperability gap between BIM and BEM will be the focus Chapter 2. Energy is now more than a top concern that should be addressed in building design. Research on this gap was chosen to enhance the data exchange quality between the BIM authoring software and the building energy simulation tools. This will be by proposing and evaluating potential tool and methods to address interoperability. As there are many geometrical visualization tools such as OpenIFC, RDF, and FZKViewer it would be valuable to complete the transparency by coupling these visualization tools with a Data Transparency Tool (DTT). The DTT would complete this verification process working in conjunction with these model viewers as it presents all the variables essential for the energy simulation as identified by DOE. The tool would address a major flaw in perceived software interoperability and the failure to uphold user expectations. It would show exactly not only what is being transferred, but also what is actually input as the file is loaded into the energy software. The tool would allow the user to verify the data in the data models and then correct inaccuracies. 1.6 DELIVERABLE The decision-‐making process will be improved using building information modeling workflows and technologies through better coordination of data between digital building models and the energy simulation and analysis methodologies and technologies. A Data Transparency Tool (DTT) was developed to report the completeness and accuracy of the data transfer. Even the inexperienced user would be able to identify issues in the data exchange such as missing or manipulated data. The tool would first import the data model and present it to the user under the DOE’s defined categories (Form, Program, Fabric, and Equipment). Built in functions would then analyze the file and alert the user of any missing or incorrect data. The DTT also incorporates a scoring system that generates an overall completeness report. The overall score reports the overall percentage of variables that have been provided. This function enables instant review of content and assists the user in determining the relative validity of simulations if the file was used. 1.7 SUMMARY 1.7.1 Chapter Structure and Outline Chapter 1: BIM, BEM and BIM Gaps: An introductory chapter to BIM, BEM and their role in energy efficient designs. The main gaps between BIM models are discussed with emphasis on the causes and potential solutions. Chapter 2: The GAP between BIM and BEM Focus is put on the interoperability gap particularly between the BIM and BEM workflow. The data flow is investigated and potential problems are identified. 20 Chapter 3: Methodology The methodology that was undertaken to develop a tool that would assist in enhancing interoperability between BIM and BEM is discussed. Chapter 4: Results A series of geometrical and data inspections were conducted on the data exchange between BIM and BEM using the common data formats and the results were tabulated. Chapter 5: Developing the Data Transparency Tool The methodology of creating the DTT is followed and test cases were run on its validity. The results were inspected and analyzed, particular attention was given to highlighting the capabilities and limitations of the data transfer and effect of the DTT. Chapter 6: Presenting the Data Transparency Tool This chapter explains how to use the DTT and describes its different functions. Chapter 7: Future work and Conclusions. Includes a discussion of potential future work that could support the data flow but has not been undertaken as well as the concluding remarks. Hypothesis: One can add a layer of transparency to the data exchange between the design and energy simulation models that would allow users to observe what values are being transferred from BIM to BEM. 1.7.2 Research Objectives • Understand the structure of the workflow between BIM and BEM and identify current limitations. • Understand the structure, similarities, and differences between the two exchange platforms: Green Building Extensible Markup Language (gbXML) and Industry Foundation Classes (IFC) • Test, prototype, and demonstrate data exchanges between the BIM-‐authoring and energy performance building information models on various platforms using IFC and gbXML. • Develop a Data Transparency Tool that reveals the accuracy and completeness of the data exchange for gbXML files. 21 CHAPTER 2 THE INTEROPERABILITY GAP BETWEEN BIM AND BEM 22 2.1 INTRODUCTION BIM must be seen as a complete process rather than a set of software, a process that affects the workflows of the design and construction profession (KBH 2014). Chapter 1 reported the perceived gaps, their causes, types, and proposed solutions. These gaps could result in data loss, miscommunications, and inaccurate results, which would inevitably disturb design and construction process. This chapter will focus on the interoperability gap particularly between the BIM and BEM workflow. 2.2 BIM / BEM WORKFLOWS “Energy is a design topic, not a technology topic, but there are few of us who have always believed this” (AIA 2012). Therefore to become effective, energy efficiency should be a determining factor in the design of buildings and consequently should be carefully analyzed at the very first of the design stages. The BIM/BEM workflow should be seamless to support this analysis; unfortunately and as reported by the survey, it is not. Design models and building energy models are built for different purposes and contain different data. Moving data between these models could save the designer time, reduce redundant work, and lead to greater accuracy as the models reflect the same data. 2.2.1 Design Model versus BEM A design BIM is “the building project BIM held by the architect that links the design intent model with those of the consultants” (KBH 2014). The architect uses it as a tool of communication and collaboration between the different parties. BEM on the other hand as defined by AIA is “the predicts of a building’s anticipated energy use and corresponding energy savings, as compared to a standard baseline. In so doing, it demonstrates project compliance with local, regional or national energy codes.”(AIA 2012). BEM allows the architects to explore the factors that contribute to the performance of a building-‐ in doing so it becomes a powerful tool for reducing building energy consumption. The design model is created mainly to serve the architect’s role. For example, room labels and section cuts may be important in the architecture model, but not directly important for energy analysis. An energy simulation specialist must then manually transform the architectural building information, and add missing required information to create the model required for energy simulation (Bazjanac and Kiviniemi 2007). 2.2.2 Interoperability and Round-‐tripping Deru suggested a data flow that occurs between the architectural and simulation software (Fig. 2.1). Two concepts are apparent: the first is the transfer of data between the BIM software and the BEM tools (interoperability) and the second in the round-‐tripping back to BIM software. 23 Figure 2.1: The process of building modeling (Deru et al. 2011) Deru showed that the data entry to simulation software could be either entered completely manually: in the form of text entry via the simulation tools or partial data transfer in addition to manual entry. The import of partial thermal data and simple mesh zones via data models created in the architectural software and then manual entry of the missing data. Deru therefore excludes the possibility of a complete transfer of data (geometry + building data) via a data model such as IFC or gbXML in his scenarios. Two explanations are possible, either Deru is unaware of the data models (which is unlikely) or Deru among others believes that the data transfer through data models is incomplete. Second, and in reference to round-‐tripping; Deru states that the direct data transfer back to the architecture software from the simulation doesn’t exist (Deru et al. 2011) . Any changes made to the data in the simulation software need to be entered back manually in the architecture tool. To better understand the previous diagram and the causes for the interoperability a survey of BIM and energy simulation software was performed. The objective was to determine the current compatibility levels between them. The type of data models (IFC or gbXML) that BIM authoring tools export and the data models that the BEM tools import and export vary (Fig. 2.2). A number of issues can be observed: the first is in the direct data exchange between BIM and BEM, and the second is in the limited possibility of “roundtripping” of data back to the BIM authoring software from the BEM tools. It is observed that neither IFC nor gbXML have unanimous software support of to complete the data exchange between the BIM authoring software. IFC has better support between the BIM authoring tools as 81% enable the export of data through it compared to 44% enable export through gbXML. While gbXML on the other hand has better support between the BEM tools as 88% support its import vs only 12% are certified for IFC import. This means that the user has very limited options to transfer the data between BIM and BEM making the file transfer itself a challenge. A tool is proposed in Chapter 3 to support interoperability between the two file formats. 24 Figure 2.2: Type of data models (IFC or gbXML) that BIM Authoring tools and Energy Simulation tools import and export; data from a web-‐search performed November 2014 2.3 INTEROPERABILITY AND DATA TRANSFER Interoperability is defined as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE 1990). As per this definition, manual data entry into the BEM tools doesn’t qualify as an interoperability method. This exchange of information could be done through many electronic forms, five have been described; One central model; two 3D models, one for conceptual design and another for energy simulations; 3D model to energy software via gbXML or IFC; 3D model with a direct plugin to energy software; and 3D model to energy software within a visual scripting environment.: 1. One model that holds all the information for BIM and BEM – no data transfer necessary. This is a theoretical method that doesn’t currently exist. 2. Two separate 3D models, one created by designer for conceptual design and another created by energy consultant for energy simulations. The data exchange is minimum, and somewhat disconnected as this would require manually modeling a new model in the energy simulation software interface. 3. Transfer of model from 3D authoring software to energy simulation tool and this can be in 3 different forms: a. 3D model to energy software via a common file format that both use (Fig. 2.3 right). gbXML and IFC are commonly used examples of such data files. This method is achieved through exporting and importing data models, b. 3D model with a direct plugin to energy software. BEM is integrated within BIM software and the export/import stage is hidden (Fig 2.3 left). For example, direct plug-‐ins exist to move data from Revit to IES <VE. 25 c. 3D model to energy software within a visual scripting environment. Software such as Grasshopper, Python, and Ladybug import the model along with other variables (such as weather file) and run it through a workflow. The energy simulation tools are “nodes” within the workflow and this enables the automation of the simulation workflow. This method enables the user to simulate alternate designs in little time and subsequently optimizing the design. Figure 2.3: Two data transfer methods between BIM and BEM, on the left BEM is a plugin within the BIM software such as (Sefaira) and on the left the transfer is done through exporting and importing data models. Interoperability through data models will be the focus for further research. It has become the industry standard and already has the support of leading 3D BIM vendors such as Autodesk, Bentley, and Graphisoft (gbXML 2014). These data models could either be vendor-‐neutral such as gbXML and IFC or vender specific such as RVT files. In Vendor specific each vendor defines its own trademarked data formats, analysis tools and viewers. This creates issues in interoperability. Vendor-‐neutral files are in a standard format, such that they can be accessed by other software. Allowing the user to convert data directly to and from other product software. This holds many advantages such as exceptional flexibility, efficient and more accurate data transfers. 2.3.1 File formats: neutral vs software specific Two of the most common neutral file formats for BIM to BEM are the Green Building Studio XML (gbXML) format and the Industry Foundation Classes (IFC) scheme using either the STEP (.ifc) or XML (.ifcxml) formats . Both offer geometrical and thermal data transfers however they are uniquely semantically structured and have significant functional differences. These differences arise from variances in development, structure, and organization of the data models. 26 2.4 NEUTRAL FILE FORMATS: GBXML gbXML is an open schema developed specifically to transfer building geometrical and thermal data enabling interoperability between BIM authoring software and energy simulation tools. The development of this scheme was initiated by Green Building Studio, Inc in early 1999. The development was funded by the California Energy Commission PIER Program, Pacific Gas and Electric, and Green Building Studio. The first version of the schema was published in 2000 and continued to be developed, as of current date the most recent is version 5.12 (gbXML 2014). gbXML is now supported by the majority of the software vendors including Autodesk, Bentley, and Vectorworks; a complete list of software can be found on-‐line (http://www.gbxml.org/software.php, last accessed May 2014). 2.4.1 Organization of information within the gbXML schema The gbXML file is in textual data format based on the XML schema (Fig. 2.4 and Fig. 2.5). “It’s structure is a treelike hierarchy of elements. Each element has one or more values and children attributes. Elements can repeat, but the structure is always enforced. The schema defines fixed values that follow the elements and are called enumerations.” (Cunningham 2009) These elements define the document, the geometry and the materials of the project. Software providers choose the elements in which their software supports. This is exceptionally important for interoperability as only mutually supported elements can be transferred between two software. Figure 2.4: Partial structure of gbXML file; 27 Figure 2.5: The partial textual representation of project location in gbXML. 2.5 NEUTRAL FILE FORMATS: IFC The IFC file format is derived from earlier efforts by the International Standards Organization, released in 1984 called STEP (STandard for the Exchange of Product Model Data). IFC uses several definitions similar to that of STEP, and is based on the same modeling language, EXPRESS (Sumedha 2014). IFC file format was developed by the International Alliance of Interoperability (IAI), now known as buildingSMART. IFC provides an object-‐oriented file-‐format solution that is interoperable with different software functioning at different stages of the project. (BuildingSMART 2014). By doing so the flow of data is continuous through one file structure from the initial design stage all the way to project execution. In that sense IFC is more practical than gbXML as the latter is specifically developed for energy simulation and does not function at other stages. IFC also has a strict software certification program that ensures reliability and interoperability that gbXML lacks. There has been several releases since the initial version 1.0 IFC was launched in 1997, today the latest is IFC 4. (BuildingSMART 2014) 2.5.1 IFC file formats buildingSMART develops and maintains IFC specifications as a “Data Standard;, this standard is registered with ISO as ISO16739. The IFC data files are exchanged between applications using the following formats (buildingSMART 2014) 1. ifc: The IFC EXPRESS long form schema which is the default IFC exchange format used to exchange data between applications. 2. ifcXML: The ifcXML XSD schema: It is IFC’s data file using the Extensible Markup Language (XML) document structure. Since XML defines a set of rules for encoding documents in a format which is both human-‐readable and machine-‐readable, this is larger data file (normally 300-‐ 400% larger than an IFC file). This scheme is automatically generated by the application or converted from the main EXPRESS schema. 3. ifcZIP: A compressed version of the .ifc file using he PKzip 2.04g compression algorithm (compatible with e.g. Windows compressed folders, winzip, zlib, info-‐zip, etc.). A common data structure between gbXML and IFC is ifcXML, both are built upon XML structure and it was therefore selected for the development of the DTT. 28 2.5.2 Interpreting the IFC file The ifcXML XSD schema was selected for practical purpose as it is based on the same scheme as gbXML, which is the XML scheme. This will enable the use of one tool to interpret both the data models. Therefore the proposed Data Transparency Tool (DTT) that is proposed in the next chapter will map out the elements based on XML scheme structure. The latest generation of IFC is IFC4 which was released on 12. March 2013. However it has not yet received sufficient software support; software certification for the IFC4 is an ongoing process, but at the date this thesis was written most of the software were certified for IFC2X3. For that reason the DTT will structure based upon IFC2X3 (Fig. 2.6). Figure 2.6: The partial textual representation of project data in IFC. 2.5.3 Information Delivery Manual (IDM) of energy analysis The correct data about the building, both geometry and other non-‐geometric data, should be successfully transmitted between the different participates in the project at the exchange points. The developers at buildingSMART realize this and created a standard formerly known as the Information Delivery Manual (IDM), which specifies when and what information is needed. The IDM defines the different exchanges through the project/product lifecycle and describes the details requirements of each exchange. The IDM is created with the input of professional organization and focus groups from the related industry (Fig. 2.7). Figure 2.7: Partial diagram of an IDM specifying different exchange files in a specific project phase, for example this diagram can resemble an IDM for concept design phase for energy analysis. 29 An example collaborative effort to address such industry-‐wide exchanges is the one made to produce the Precast Concrete National BIM standard where these exchanges were defined. The standard was formed by input from the Precast/Prestressed Concrete Institute (PCI) and the Charles Pankow Foundation (CPF) with technical support from a team from Georgia Tech and the Technion. The IDM for Precast Concrete has twenty-‐six exchanges that were identified between the different professionals acting on the precast elements throughout the product lifecycle. The columns represent the phases of the project and the main rows represent the different disciplines acting upon the project; in this case they are the Architecture, Engineering, Manufacturing and Contracting. The identified twenty-‐six exchanges are done in the rows between the discipline processes and are colored in green and yellow. Arrows define the path the generated file follows (Fig. 2.8) (Eastman, Venugopal, Manu, and Aram, Shiva, 2011). Figure 2.8: Architectural Precast Project process Map, IDM for Precast Concrete, (Eastman, Sacks , and Panushev 2009) A larger version of this figure is in Appendix B. The output of the IDM is basically the industry’s description of data flow. This needs to be balanced with the software capabilities and then transferred into IFC-‐based language solutions. These solutions are the Model View Definitions (MVD), which becomes a subset of the IFC for a specific data exchange. The MVD is the source for software requirement specification to satisfy an exchange requirement. This is because it defines all the required definitions and implementation requirements for IFC concepts. For example, Autodesk Revit followed the requirements specified in the MVD for the BIM to BEM data exchange and was then therefore certified for this particular exchange. 30 2.5.4 IFC compliance and certification process The certification process is an advantage to the IFC data model over other data models. It offers an additional layer of quality control in all the applications that use it. Each software goes through the applicable certification procedure depending on the subset of the IFC data schema its supports (AKA the MVD). In other words the certification is linked to specific MVD that support one or more exchange requirements. Software developers would run tests of their implementation; buildingSMART stringent certification user organizations would then perform a detailed quality control. The current procedure is the IFC Certification 2.0 procedure as of 2010 and is organized into three parts. First, verifying the software’s IFC export conforms to the latest IFC standard. Second, verifying that import mechanism of the software of IFC files conforms to latest IFC standards. Finally a general conformance assessment that inspects the used IFC terminology, the documentation and help files, the completion of IFC support statements, and adhering to online publication requirements of the certification logo and certificate (Buildingsmart 2014). IFC Certification 2.0 is provided with a conformance test suite containing : • “Model creation guideline sets to create comparable export test files with test instructions for export checking • Automated export file testing based on validation rules that formalize the constraints imposed by the model view definition • Calibration test files for import checking based on test instructions, i.e. check-‐lists and templates with testing criteria” (Buildingsmart 2014). Although the certification process is an advantage to the IFC data model it does not eliminate issues in interoperability. It merely adds a layer of quality control in a sense that buildingSMART along with the software developers would verify the export or import of IFC files but that does not guarantee compliance on all geometry and data or overcome user related issues in modeling and data input. 2.6 BACKGROUND RESEARCH CONTRIBUTING TO THE STUDY A close look was taken at three previous research projects: Cunningham addressed gbXML capability of data transfer and exploited it’s XML structure; Delfosse explored IFC as a data transfer model and focused solely on the geometrical issues; Kumar investigated the thermal data transfer using DXF, IFC and gbXML and then enhanced the MEP-‐IES interface by designing a patch file. 2.6.1 “Heating and Cooling Load Calculations and Energy Model Development” Phillip Cunningham researched gbXML capability to transfer data between Revit MEP and Trace 700. He started by visualizing gbXML structure, how it organizes and represents the data, as well as typical challenges that are encountered creating accurate gbXML files. Here he investigated the Extensible Markup Language (XML) scheme of gbXML and highlighted its properties. XML is a treelike hierarchy of elements; these elements have attributes and values within an enforced structure. He reported that gbXML structure ensures compatibility only if the sending application and the receiving application support the same XML elements. Only 62% of the elements supported by Revit MEP (highlighted in blue) export mechanism were mutually supported by Trace 700 (highlighted in green) (Fig 2.9) (Cunningham 2009). Only mutually information is transferred and that could explain part of the 31 data loss. Attributes defined in Revit such as the Design Cooling Temperature would therefore not be transferred, as this element is not supported by Trace 700 import mechanism (Fig 2.10). Figure 2.9: gbXML elements and highlighted in blue are the specific elements supported by Revit MEP (Cunningham 2009). A larger version of this figure is in Appendix C. 32 Figure 2.10: gbXML elements and highlighted in green are the specific elements supported by Trace700(Cunningham 2009). A larger version of this figure is in Appendix C. 2.6.2 “Some Advice for Migrating to IFC” (Delfosse et al. 2012) This study investigated the use of IFC as a data transfer model and focused solely on the geometrical issues. Some geometrical issues were discovered in ArchiCAD’s export mechanism and the authors offered advices to navigate away. Particular issues when using dynamic tools in ArchiCAD were highlighted such as the "trim/join wall to roof". This tool specifies a relationship between a wall and the adjoining roof and conveys the model as a result of the trim operation. The IFC did not encode this relationship and interpreted the wall and roof in their original shape without the trim (Fig. 2.11). When modeling using the standard conventional tools of wall and roof the IFC export was correctly encoded (Delfosse et al. 2012). For an accurate simulation the model should be complete and correct with no errors in geometry -‐ spaces and space boundaries. Inconsistent geometry in some cases creates gaps in the model, which shouldn't be there, affecting the results. The authors highlighted some issue that may occur and noted precautions that should be taken and stressed that the model should be verified before attempting any analysis. They also encouraged the use of IFC as open-‐source vendor free data model. 33 Figure 2.11: ArchiCAD® trimming tool and its IFC export, (Delfosse et al. 2012) 2.6.3 “Interoperability between BIM and Energy Analysis Programs” by Kumar. Kumar investigated the interoperability gap between BIM and BEM for her master thesis at the University of Southern California. The intent of her study was to “test whether BIM software, specifically Revit, was robust enough to allow seamless interoperability with analysis programs such as Ecotect and IES<VE>.” (Kumar 2008) Her research tested the data transfer, apart from geometry, using three neutral file formats: DXF, gbXML and IFC. Kumar’s research showed varying data loss between the properties of the selected families in Revit and their representation in IES<VE>. She then enhanced the Revit-‐IES interface by designing a “patch” file. This patch file was a Revit template that defined a set of Revit families that derived their values from the IES construction database and could be imported into a Revit project. Kumar identified a particular issue in the BIM to BEM and decided to develop a solution for a specific software. By using the families identified in her patch file the user would be guaranteed an accurate precise data transfer between Revit and IES<VE>.. The disadvantage of this approach is again in its particular nature. It would only support a part of the data transfer and only when using those specific tools. The DTT defers in direction in its wholeness approach as it targets the neutral data formats, the known standards and therefore holds potential in effecting the dataflow as a whole. 2.7 DETERMINING POTENTIAL PROBLEMS IN DATA FLOW The results of a previous research conducted in the BIM to BEM data exchange are reported. Numerous tests on the file exchange between BIM and BEM using gbMXL were conducted. The objective of this step was to determine potential problems in the data transfer to better understand the gap(s) and the causes and then propose potential tools to resolve the problems in the next chapter (section 3.5). Further detailed tests with a defined base model and fixed variable set are reported in Chapter 4. 2.7.1 Test runs using gbXML 34 The scope investigates gbXML’s capability to transfer the building thermal data and not the geometry; therefore the model created in Revit had a simple geometry to simplify the translation of the gbXML file. The model is of a 180 sq.ft single-‐family one story house with one interior space. The gbXML generated form the Revit model was utilized for the test. The data flow was inspected at each step to determine the effect (if any) of the following three on the data exchange. • The export mechanism of the BIM authoring tool • The structure of the data model and the way it represents the data as well as the elements/ properties of the building it supports. • The import mechanisms in the energy simulation tools. The data inspection was conducted by comparing the values of the parameters at each step and logging them in a compatibility assessment chart; the original values taken from the Revit model were listed in a chart and compared with the exported gbXML file, and the energy tools interpretation of these file. The results are described in two groupings; the first includes location, building, and space elements and the second the window and door elements: 1 Location, building, and space elements 2 Window and door elements 1. Location, building, and space elements Green Building Studio, EnergyPro, and IES Pro generally worked well in importing the location, building, and space elements of the gbXML file. The weather file is was not included in the gbXML data, and users are required to input it manually (Fig. 2.12). • Export Functionality: The data was exported correctly from Revit to the gbXML file except the weather file which was not included in the gbXML data therefore users are required to input it manually. • Import Functionality: EnergyPro and IES Pro translated the address of the project however GBS and DesignBuilder required manual input of the address before even attempting to import the gbXML 35 Figure 2.12: Results of the exchange data of the location, building, and space elements 2. Window and door elements There was sporadic success with transferring the attributes of window and wall elements with Green Building Studio and IES Pro performing much better than EnergyPro (Fig. 2.13). • Export. The thermal data inputted in Revit was exported correctly into the gbXML file. As a trial, fire-‐rating info was inputted manually into the door properties however this was not exported, as it does not relate to thermal properties. In other words gbXML does not attempt to export any data that is not related specifically to geometry or thermal properties. • Import. GBS and Energy imported the main thermal data correctly, DesignBuilder and IES didn’t. The assemblies themselves were changed to the default values of the software as if no data has been inputted. 36 Figure 2.13: The results of the exchange data of the window element and the wall assembly of the material element A few findings could be concluded from the results. First, there are gaps in the transfer between the BIM authoring software and the energy simulation tools. The gaps are both of inaccurate and incomplete transfer of data. Second, the different energy simulation varied in their capability to translate the thermal data embedded in the gbXML file, GBS was the most compatible and IES the least. It appears that the BIM authoring software export is functioning correctly to gbXML in most cases. However, the building energy software is not always translating the complete information in the gbXML file and importing it correctly. 3.4.2 Test runs using IFC Similar tests were attempted using the same reference building of DOE and utilizing IFC as the data transfer model. A few findings were concluded from the results. First, IFC is still in 37 developing stage when it comes to the BIM to BEM data flow. This is not caused by the export mechanism of the BIM authoring tools to IFC, nor IFC ability to transfer data but rather the software import support it has. IFC has very limited support between the BEM tools, at the time of this report only three tools (Riuska, IES, and IDA ICE) were certified to import IFC. Complete list could be found here: http://www.buildingsmart-‐tech.org/implementation/implementations. This makes the data transfer between BIM and BEM using IFC unlikely to happen as the options open to the user are very limited. Second, IFC is as gbXML is an adequate file format for geometry transfer but occasionally has problems with more confusing geometry (for example, it might not be able to tell the difference between a window shade and a small roof). 2.8 CONCLUSION BIM software should be able to export necessary information, and energy programs should be able to import it. This allows for efficiencies and time savings that could be used for the simulations themselves. However and as observed in this chapter many gaps exist in this transition. To help alleviate some of these interoperability issues, it was decided to develop a tool that clearly showed what values were in a gbXML file. Unlike other gbXML readers, it would not show all the data in the data model original hierarchy, but instead isolate the parameters that energy simulation software use and group them into the four DOE categories: program, form, fabric, equipment -‐-‐ program (location, total area, internal loads, operating schedules, hot water demand, and ventilation requirements), form (geometry and orientation), fabric (construction types and thermal properties of the building elements), and equipment (the types, specification, and efficiency of the lighting, HVAC, and SWH systems) (Deru et al. 2011). This should make it easier for designers to understand how their models are being imported into energy programs. 38 CHAPTER 3: METHODOLOGY 39 Chapter 1 and 2 highlighted the gap between BIM and BEM, the implications of the loss of data, and the critical need for tools and methods to bridge the gap. This chapter discusses the methodology that was undertaken to develop a tool that would assist in enhancing interoperability. 3.1 OVERVIEW OF THE METHODS AND PROCESSES The data of the model including the geometry and the variable set should be accurately represented in the data models to produce an accurate simulation. However this data doesn’t essentially transfer the way the user would expect it to (KKH 2014) 2 .. Verifying the accuracy and completeness of a data model is challenging due to the structure and representation of the data models. The data models are extremely long and complex files; An example is shown of Revit representation of a wall assembly compared with gbXML representation of the same data (Fig 3.1). Figure 3.1: The textual representation of the materials of a floor assembly from Revit represented in gbXML. There are a number of factors that could affect the data exchange between BIM and BEM; the following three filters were investigated. • The export mechanism of the BIM authoring tool • The structure of the data model including the way it represents the data as well as the elements/ properties of the building it supports. • The import mechanisms in the energy simulation tools. The main objective is to guarantee the accuracy and completeness of data that is exported from the BIM authoring software to the energy simulation. To address the goals and objectives of the study the following steps were done: 1. Defining the required variables for energy simulation and categorizing them. 2 (Kensek, Konis, and Hijazi 2014): This is a white paper titled “Assessment of File Interoperability between BIM and Energy Analysis Software Using gbXML” under a grant from SoCal Gas Company that has been developed by Kensek, Konis, and Hijazi (The thesis author) in conjunction and at the same time of this thesis. The paper therefore is quoted extensively in Chapter 2 to report the results of the tests. It will be referred to as (KKH 2014). 40 2. Defining a test case model. 3. Modeling using a BIM authoring tool and exporting both IFC and gbXML files. 4. Determining potential issues in the data flow. IFC and gbXML files were exported and imported and compared for accuracy and completeness versus the data in the BIM using the test case building. 5. Developing a tool that could reveal the transferred data mapped by the categories defined in step 2. 3.2 DEFINING THE REQUIRED VARIABLES In order to test the data exchange for purpose of energy modeling the required variables that affect the BEM should be identified. There are a broad number of parameters that relate to different aspects of the building and program. Unfortunately these variables are not clearly identified in standard data sources (Deru et al. 2011). The U.S. Department of Energy made an effort to populate these variables and categorize them in their document titled “Commercial Reference Building Models of the National Building Stock”. DOE groups these variables into four categories: Program, Form, Fabric, Equipment (Fig 3.2) (Deru et al. 2011). “Program” includes variables of location, total area, internal loads, operating schedules, hot water demand, and ventilation requirements. The second category “Form” includes variables reflecting the geometry and orientation. Third category “Fabric” includes the construction types and thermal properties of the building elements. The final category “Equipment” contains the types, specification, and efficiency of the lighting, HVAC, and SWH systems. DOE’s list of “variables” are at a high level and each can contain multiple variables to be correctly defined in the energy software (Fig 3.2). For example, “Location” can include: The project’s longitude, latitude, altitude, the address, the closest weather Station ID...etc. Figure 3.2: Building energy modeling variables categorized into Program, Form, Fabric, and Equipment (Deru et al. 2011) This list has been utilized as a standard in this research. Three of the four categories (Program, Fabric, Equipment) will be used were used to organize the data in the reference model in the next step, then to map the new XML scheme, and finally to present the data for the 41 user in the proposed Data Transparency Tool (DTT). The scope of the research doesn’t include geometry; therefore a number of the variables under the “Form” category will not be addressed. 3.3 DEFINING THE TEST CASE MODEL For this section the test model of a previous research will be utilized. That research was performed by Kensek, Konis and Hijazi titled “Assessment of File Interoperability between BIM and Energy Analysis Software Using gbXML” (KKH 2014). The medium office building was chosen as the reference building. It was obtained from the U.S. Department of Energy (DOE) reference buildings database (http://energy.gov/eere/buildings/new-‐construction-‐ commercial-‐reference-‐buildings). 3.3.1 Modeling The data from DOE was used to make a model using Autodesk Revit. “The Revit model slightly defers from the original (the area of the Revit model is 4924 square feet versus 4982 square feet in the original IDf file). This difference, however, will not affect the results as this deliverable is concerned with data transition, and not the total energy consumption.” (KKH 2014) The values of the variables set defined in section 3.2 were obtained from the DOE reference and replicated in the Revit model. These variables will later be crosschecked to determine if their values were affected during the exporting/ importing process between the BIM authoring tool and the BEM. Some of the values were changed from the original IDF file to facilitate the data transfer (Fig. 3.3). An example is the number of zones, which was decreased from three to one zone per floor. The main concern is validity of the different data in the model exchange in terms of accuracy and completeness; verifying one zone per floor that encompasses the different variables instead of three zones would make the verification process quicker. Figure 3.3: Schedules customized to match exact requirements that were in the IDF file 3.3.2 Exporting the data models After the model was completed it was exported in two formats; IFCXML and gbXML. Autodesk Revit has a built in capability to export gbXML and IFC files. The exporting process is straightforward and is accessed via the File tab. The IFC export built in Revit however supports 42 limited options and schemes (Fig. 3.4); The XML scheme (which is required for the following steps) is not one of the supported schemes. It was essential therefore to download and install a plugin called (IFC 2015) from Autodesk Exchange that allows additional options. “This application seamlessly replaces the built-‐in IFC import and export mechanisms, so users do not have to perform any additional steps while opening, linking or exporting their models to the IFC format using the Autodesk Revit UI.” (Autodesk, Inc. 2014) (Fig. 3.5) shows the additional export options supported by the (IFC 2015) plugin. The plugin can be found on the following link: https://apps.exchange.autodesk.com/ALIAS/en/Detail/HelpDoc?id=appstore.exchange.autodesk.c om:ifc2015_windows32and64:en&mode=live#inunininfo Figure 3.4: IFC export window; Revit IFC built in export supports limited schemes of IFC, IFCXML is not one of them. Figure 3.5: IFC export window; additional export options supported by the (IFC 2015) plugin 3.3.3 Checking the Building Form for Accuracy and Completeness Accuracy of the geometry is essential for an effective data exchange and a valid simulation. Energy simulation tools require a model of closed volumes for the spaces. Any error in the geometry export will essentially mean invalid simulation results. Although the scope of this research doesn’t incorporate geometry, it does include other variables related to it under the Form and Program categories such as number of floors, areas, and volume. Revit’s gbXML export incorporates a geometry review that allows the user to evaluate the geometry that will be considered for the simulation before attempting to export it. The geometry check for gbXML was 43 done through software’s built in review as well as manual numeric and visual inspections. However Revit’s IFC export does not encompass such review neither in the built-‐in nor the extended (IFC) plug-‐in and the form review was done after the export using Solibri and manual inspection of the file. Revit’s gbXML export mechanism highlights the spaces that will be considered for energy simulation (Fig. 3.6). If Revit finds any inconsistencies in the spaces then it will highlight the room and note the error. It is important to resolve the issue and recheck the export window before attempting to create the gbXML file, or else any error will remain in the energy simulation software. Figure 3.6: gbXML export process; Revit highlights the spaces that will be considered for energy simulation. 3.4 PROPOSED TOOL TO HELP RESOLVE THE PROBLEM In Chapter 1 different aspects and causes of the BIM Gap were discussed. Chapter 2 highlighted compatibility issues in the transfer. In this section a tool was proposed to assist in resolving the gap caused by technological and compatibility issues. The data transparency tool would assist in overcoming the compatibility gap by revealing the actual information that is transferred and comparing it with the users initial input. 3.4.1 Data Transparency Tool (DTT) Another solution to the program was the development of the data transparency tool. The test runs in section 3.4.1 revealed that the values inputted in the BIM authoring software do not always transfer correctly to the BEM tool. Some data is transferred correctly, some values are left out, and some values get changed. This could be fatal depending on users’ expectations. The user may assume that the exchange is complete and accurately presenting the data from the BIM authoring tool. “Another assumption might be that because it is not, it is useless. It would be extremely helpful to show exactly not only what is being transferred, but what is actually input as the file is loaded into an energy software. Transparency is critical, especially for inexperienced users. A goal should be to have the user understand the applicability and appropriateness of the file transfer.” ( KKH 2014) 44 3.5 CREATING THE DTT IFC and gbXML are text files. However, they are complicated and extremely long files, and the reality is that they are seldom opened (Oullette 2014). The DTT’s goal is to allow the user to verify the data in the data models and then correct inaccuracies. This is done by applying a transparency layer upon the IFC and gbXML files so that even the inexperienced user could understand them (Fig. 3.7). This process was divided into three steps: 1. Matching IFC and gbXML enumerations with the selected variable set (variables defined in section 3.2), 2. Utilizing the IFC and gbXML XML schemes to map new XML schemes that match the variable set 3. Creating the Excel tool that would automatically populate the data. Figure 3.7: Diagram of the Data Transparency Tool (DTT) (Credited to author) BIM authoring software and the export mechansim The diagram of the BIM authoring software encompasses the user interface, import, and export mechanisms. The import and export mechanism include “data filters” that “select” partial data for export. When exporting from BIM to BEM not all the data in the model is exported because some of it is irrelevant. As an example of the filtering is the exclusion of elements such as furniture and attributes such as costs which are irrelevant for energy analysis and therefore the software does not attempt to export them. However and as observed in section 3.4.1 some essential data is left out. BEM tool and the import mechanism The diagram of the energy simulation software encompasses theses import and export mechanisms as well. In addition to the filters there are a set of assumption (defaults) that the BEM tool would use to fill out missing data in the data model and in some cases even override existing data in the data model. (KKH 2014) With a tool that shows the user in a simple manner exactly what is being exported from the building information modeling software and imported into the energy software, a designer could have more confidence about the values of parameters. 45 3.5.1 Matching data model enumerations with selected variable set. gbXML is based on the XML scheme while IFC could be represented in three different schemes: the STEP , IFCXML, and IFC ZIP. The DTT is based on XML, therefore the IFCXML scheme was selected. Both data models, IFCXML and gbXML structures were studied. As they are both based on the XML scheme they both have a hierarchal structure that encompasses a number of elements and attributes. These elements and attributes however differ completely between the two data models. Therefore all the steps are explained for both. Figure 3.8: gbXML elements obtained from http://www.gbxml.org/currentschema.php This step involves matching of gbXML and IFCXML enumerations with the defined variable set in (section 3.2). gbXML encompasses a large number of elements that represent the geometry and data of a building (Fig. 3.8). These elements were then “matched” with their corresponding variable in the defined variable set. An example is buildingstorey, which is gbXML representation of the number 46 of floors in the building (Fig. 3.9). This step is necessary to pull out the information in the data model and present it in the tool. Figure 3.9: Diagram of methodology; Matching gbXML and IFCXML enumerations with the defined variable set in (section 3.2) (Credited to author) 3.5.2 Mapping data model scheme with new XML schemes Two new XML schemes were created, one for gbXML and another for IFC using the original data model schemes as a source for new scheme mapping. The original XML was accessed by opening a template gbXML and IFC file in Microsoft Excel and following this procedure: • Through the Developer tab, in the XML group, Source tab was used to open the XML Source task pane. • This pane contains XML Maps where excel enabled the selection of the IFC and gbXML files and mapped their structure as shown below (Fig 3.10) 47 The new XML schemes where then created by dragging the element nodes from the XML Source pane to the workspace cells adhering to the defined variable set as basis for hierarchy. Program, Form, Fabric and Equipment therefore create the top levels of the hierarchy and encompass under them the related variables (Fig 3.10). The schemes elements build upon the previous section that matched the data models enumerations and attributes with the variable set. Figure 3.10: Diagram of methodology; Utilizing gbXML and IFCXML template schemes as a source to create new schemes that adhere to the defined variable set in (section 3.2) (Credited to author) 48 Only the information relevant to energy simulation and precisely the variables of the defined set were extracted. This excludes the variables under the Form category, as the DTT will not include geometrical representation at this stage. It is proposed that the DTT work with and complete the readily available geometrical viewers such as Solibri, Simple BIM. The DTT would complete this verification process working in conjunction with these model viewers as it presents all the variables essential for the energy simulation as identified by DOE. 3.5.3 Presenting the scheme in Excel The two new schemes where then used as source schemes to present the data model values in Excel. The Excel interface of the tool contains 4 tabs each of which correspond to the variable set and its underlying elements (Fig 3.11). The user would simply import the gbXML file or IFCXML file to their corresponding DTT and the tool would automatically populate the values. Figure 3.11: Diagram of methodology; Mapping new XML schemes based on the defined variable set in (section 3.2) and then presenting the scheme in an excel tool, (Credited to author). Unlike other gbXML readers, DTT excel interface would not show all the data in a hierarchy, but instead isolate the parameters that energy simulation software use and group them into the four DOE categories: program, form, fabric, equipment -‐-‐ program (location, total area, internal loads, operating schedules, hot water demand, and ventilation requirements), form (geometry and orientation), fabric (construction types and thermal properties of the building elements), 49 and equipment (the types, specification, and efficiency of the lighting, HVAC, and SWH systems) (Deru et al. 2011). 3.6 TESTING The DTT in both its versions (IFC, gbXML) was extensively tested using different data models. There were a set of tests performed; the first is the data representation test, the second the scoring tests. • Data representation tests: The values of the variables was properly populated and mapped into the specified field under one of the categories (Program, Form, Fabric and Equipment). Transparency is the main goal; hence the tool was developed to enable even the inexperienced user to view and understand the data model content. • Scoring tests: The scoring system rates the data models depending on their accuracy and completes. It is not meant to show an accurate score but more as an estimate of data completeness and correctness. This would give the user a sense of the level of development of the data model. Completeness of data: The tool examines the inputted file and verifies that all the variables essential for the energy simulation as identified by DOE are identified. Appropriateness of data: The tool verified that the values of data of the imported files fall within their accepted range. Solar Heat Gain Coefficient (SHGC) is an example of a variables that have specific data range. 3.7 SUMMARY OR CONCLUSION The development of a data transparency tool could help solve some of the data transfer problems by showing the user in a simple manner exactly what is being exported from the BIM software and imported into the energy tools. Then designers could have more confidence about the values of parameters that are being transferred from BIM to BEM. 50 CHAPTER 4 BIM TO BEM DATAFLOW TESTING 51 4.1 INTRODUCTION The exchange of information between a digital building model and analytical software should be seamless so that designers can easily use their 3D models for simulation. However, many gaps exist between Building Information Modeling (BIM) authoring software and Building Energy Modeling (BEM) tools. An initial step was to check that the data was actually being transferred correctly and completely between the BIM and energy analysis software before simulation. To test this, a reference model was exported from the BIM authoring software using gbXML and IFC and then imported into the selected energy simulation tools. In some cases, the exchange of data was not complete or was inaccurate, and it was not transparent to the user what was being exported or imported. Generally, the biggest problem was the inability of the simulation software to import the necessary parameters. This is a major flaw in perceived software interoperability and a failure to uphold user expectations. Users might assume that the data transfer is accurate and base design decisions on faulty values, or users might decide that because not all parameters are being transferred, a BIM to BEM data exchange process is useless (Hijazi, Kensek, Konis 2015). 4.2 TEST CASE MODEL The medium office building was chosen as the reference building. It was obtained from the U.S. Department of Energy (DOE) reference buildings website that contained IDF (EnergyPlus) descriptions for whole building energy analysis (DOE 2015). The IDF files from the DOE website specified all the relevant data relevant to energy simulation. Tests were run using gbXML and IFC with both data models test followed the same methodology. Since the workflows are identical, only one (gbXML) was documented in detailed steps hereafter; however both the IFC and gbXML test results are shown and discussed. 4.2.1 The model The medium office building is 3-‐storey, rectangular shaped with a steel frame structure, and has continues strip windows with a 0.33 window to wall ratio. The IDF files from the DOE website were opened in EnergyPlus and DXF files were exported with the geometry. The DXF files were imported into Autodesk Revit, both as a conceptual mass and detailed building model. The model was then completed by entering the data provided in DOE’s spreadsheet. This spreadsheet accompanied the reference model and contained all the data relevant to energy modeling. This was done in the detailed building mode of Revit (Fig. 4.1). Revit has two ways that building models can be analyzed in: detailed building, and conceptual design. Conceptual design, as the name suggests, is commonly used in early design stages to give rough feedback on energy performance when little details are known. The detailed building mode allows comprehensive data entry and is therefore more accurate simulation. Since the purpose of this exercise is inspecting the data exchange between BIM and BEM it was necessary to inspect all relevant data and therefore utilize the detailed building mode. 52 Figure 4.1: Image of the reference office-‐building model from Revit. The Revit model has slight differences compared to from the original IDF file (the area of the Revit model is 4924 square feet versus 4982 square feet in the original IDF file). This difference, however, will not affect the results as this deliverable is concerned with data transition and not the total energy consumption. A subset of critical parameters was chosen for testing the data transfer. 4.2.2. Case study building, subset of critical parameters. Some critical parameters were selected to form a representative sample; not all parameters were tested. These were used to determine whether or not the data was being transferred properly. The selected parameters are gbXML and IFC elements including campus (location, building elements – areas, building story), space (ID, areas, volume), layer (R-‐value, thickness, conductivity, specific heat), window (overall conductance – U-‐Value, solar heat gain coefficient -‐ SHGC, transmittance), Zone (occupancy density, lighting and power occupancy) and Schedules (Fig. 4.2 and 4.3). 53 Figure 4.2: A number of parameters (highlighted in yellow) that were included in the representative sample test. Figure 4.3: The layers making up the structure of the wall were part of the representative sample test. 54 Figure 4.4: The wall properties; highlighted in yellow the parameters part of the representative sample test. The selected elements (in dark red) are a subset of the elements Revit export mechanism supports (in all shades of red) (Fig. 4.5). These specific parameters were chosen as the most likely to be impactful and form a representative sample of each of the four categories that effect energy analysis; Form, Program, Fabric and Equipment. 55 Figure 4.5: List of gbXML elements; highlighted in light red are the elements supported by Revit export mechanism, highlighted in dark red are the elements supported by Revit and tested for interoperability. The values were identified in the IDF file provided and then were replicated in the Revit model. These values were then compared in the following steps with the energy simulation software imported values. Some values were simplified from the original IDF file to facilitate the data transfer. An example is the number of zones, which was decreased to one zone per floor. Other items had to be customized to match the values in the IDF file. Autodesk Revit is one of 56 the software programs that allows the user to create custom settings for variables. This is necessary when the software provided options do not match the specified values for the project. An example of customizable variables in Revit is Occupancy Schedules that was utilized in the medium office case study by specifying the working hours, days of operation, and the holidays that match DOE values (Fig. 4.6). Figure 4.6: Schedules customized to match exact requirements that were in the IDF file. In order to choose the relevant parameters, the IDF, gbXML, and IFC files structures were studied to link the parameters with the enumerations in the data model. However, not all BIM software exports all the same parameters. In order for the transfer to be successful, the BIM authoring software and the BEM tools should support the same elements. The results show that Revit successfully exports some elements; however the BEM tools don’t support all of these elements, which means the some of the data is not transferred (KKH 2014). 4.2.3 Choice of Building Elements As Revit was selected as the BIM authoring software, the following were the selected data elements. As previously mentioned the choice of elements was dependent on the software: • gbXML element specifies the default attributes for the entire gbXML document and the units used. • Campus element incorporates the following children and acts as the base for all physical exports: o Location element is the value specified for the project address. The location is defined in the IDF by the latitude and longitude, and this can also be defined in Revit. One thing to note is that it doesn't load in the weather information. so that will have to be manually selected in the software tool itself by use of a weather file. o Building elements ! Area, total floor area ! Building storey, which is specified for each level element in the project that has spaces. • Space elements that will be included in the simulation. o ID 57 o Area o Volume • Layer element defines the layer which encompasses the Material Element. Material elements are defined as a function for the complete assembly and not as individual material layers. o R-‐value o Thickness o Conductivity o Specific heat • Window elements o Overall conductance (U-‐Value) o Solar heat gain coefficient (SHGC) o Transmittance • Schedule Element(s): Defines the different schedules. 4.2.4 Revit Rooms versus Spaces The concept of rooms and spaces needs further elaboration, as they are critical for the establishment of zones for energy calculations. Rooms are the main space definition label in Revit Architecture while Revit MEP uses spaces instead. Rooms and spaces are defined by the architectural enclosure elements such as walls, floors and ceilings. When selected as room-‐ bounding elements then Revit computes the room perimeter, area, and volume referring to the face of these elements. This property can be found within the property window and under the constraints ribbon (Fig. 4.7). Figure 4.7: The room-‐bounding property for elements for walls, floors, and roofs. When exporting from Revit to gbXML the user is prompted to select either spaces or rooms. Room exports the basic architectural data inputted in the model. This export has the option to include the thermal properties when “Include thermal properties” is checked in the gbXML setting window (Fig. 4.8). 58 Figure 4.8: Rooms versus spaces in exporting gbXML settings. Spaces was used to generate the gbXML file. This is because Spaces exports additional data relevant to energy consumption and analysis such as internal loads, project schedules, and MEP equipment. The space-‐type settings tool in Revit is powerful and allows the user to link each zone with its specific use. This determines the density of people, the activity, sensible and latent heat loads, lighting and power loads density. Moreover the different schedules are also classified such as the occupancy, lighting and power schedules. “Office-‐ Open Plan” space setting was selected. In both cases an effective energy analysis can only be performed if the entire volume of the building model is included in exported data. All the rooms or spaces in the model should be highlighted when attempting the export functionality (Fig. 4.9, left). Any errors in geometry and definition of space will be reported within the details tab of Revit’s gbXML export mechanism (Fig. 4.9, right). Figure 4.9: The export gbXML window within Revit enables the verification of the geometry by highlighting the spaces that will be considered in the gbXML file (left). Errors in geometry are reported within Revit’s export mechanism (right). If the “Export Defaults” box in Revit is unchecked in the gbXML export settings then elements such as the Material Element, Layer Element, Construction Element and the Schedule Element(s) will not be exported. 59 4.3 DATAFLOW TESTING 4.3.1 Checking the building geometry for accuracy and completeness. Energy simulation tools require a model of closed volumes for the spaces. Any error in the geometry export will likely result in invalid simulation results. A series of geometrical and data inspections were conducted. For geometry, numeric and visual inspections were conducted; “The numeric inspection means manually verifying that the area and volume of the model created in Revit remains the same in the gbXML and IFC export file and the BEM software interpretation of that gbXML file. The visual inspection would compare the 3D model from the Revit file with the BEM software.” (KKH 2014). The Revit gbXML export process verifies that the model is proper and ready for energy simulation. If Revit finds any inconsistencies, then it will highlight the room and note the error. It is important to resolve the issue and recheck the export window before attempting to create the gbXML file, otherwise any error will remain in the energy simulation software. The numeric inspection means manually verifying that the area and volume of the model created in Revit remains the same in the gbXML export file and the BEM software interpretation of that gbXML file. The visual inspection compared the 3D model of both the IFC and the gbXML files using third party viewers such as SketchUp Pro. This visual inspection was made to compare the geometrical representations of the gbXML and IFC files that are exported from the same model. To complete this, it was necessary to simplify the case study model and clear all the non-‐geometry data. First, a room made up of only walls with no floor or roof was modeled in Revit and then immediately exported into both gbXML and IFC formats. The IFC was directly imported into SketchUp Pro. To enable the import of gbXML file, gModeller was installed as an extension to Sketch-‐up. gModeller enabled the import of the gbXML file on the same project. The two models were then compared and found to be identical simulation (Fig. 4.10). Figure 4.10: The base case model in Revit (Left). The DWG geometry and the gbXML geometry were identical and perfectly overlap. gbXML import was done using gModeller extension to Sketchup, (Right). 4.3.2 Checking the parameters for accuracy and completeness (data). The data inspection was conducted by comparing the values of the parameters at each step and logging them into a compatibility assessment chart. This chart compared the original values 60 taken from the DOE reference file with the Revit data that was inputted, the exported gbXML file and IFC files, and the energy tools interpretation of these file. The gbXML and IFCXML files are text based file, which enabled the manual verification of their content. They are divided into elements that define the document, the geometry, and the materials of the project in a hierarchical structure (Fig. 4.11, right). The DOE data was taken from their reference file and was logged in the 1 st row; the 2 nd row contained the data inputted in the Revit model; the values listed in IFC and gbXML were logged in the 3 rd and 4 th row respectively; the following rows contained the different energy tools interpretation of the parameters values (Fig. 4.16). The compatibility assessment chart proved to be effective in determining the flow of data and the effects (if any) of the exporting mechanism of Revit and the importing mechanism of the energy tools on the data. Figure 4.11: The textual representation of a floor assembly from Revit (left), the representation in gbXML (center), the structure of the gbXML file (right). The results are highlighted in the following divisions: 1 Location, building, and space elements 2 Window and wall elements 3 Space attributes, density, load intensities, and schedules 4.4 THE RESULTS The building geometry and a subset of data parameters were checked for completeness and accuracy. 4.4.1 Building geometry accuracy and completeness. Using gbXML the geometry visually imports correctly, but there has been reports in some cases of missing surfaces, incorrect surface orientations, and other problems. These issues are sometimes due to a modeling or configuration error by the user; and in other cases it may be an error in the exporting application. McCallum of IES gave one example of a particular limitation with data models that did not work well with energy modeling requirements: “The geometry intended for energy modeling analysis –spaces and space boundaries-‐ is drawn at the inside surfaces of walls and floors.” When that geometry is imported to the energy simulation tools the spaces are separated by air gaps (McCallum 2014). Having gaps which should not be there affect the simulation and produce eventually inaccurate results. Other issues have occurred where window shades were being misinterpreted as roofing elements. 61 Though the base case building works correctly, a more complex geometry was created in Revit to check for geometric errors; the model contained a variety of elements, custom shapes and families (Fig. 4.12). It was then exported to both IFC and gbXML data models and then imported to SketchUp to examine the transferred geometry. The gbXML model was further imported and examined in BEM tool (IES Pro). IFC is aimed to serve the complete building lifecycle and therefore attempts to export all of the model data. The IFC data model contained all the geometry even the objects unrelated to energy simulation such as trees and furniture. The transfer of geometry appeared to be complete and accurate (Fig. 4.13). There was, however, an issue in the pool as it was interpreted as a space. This was a repeated issue in both gbXML and IFC exports. This wasn’t an issue in the data model export but rather a result of an improper definition by the user in Revit; the pool was defined as a space, and IFC therefore exported it a part of the spaces considered for energy simulation. When the user error was corrected by correctly defining the pool (changed from a space into an element), then it was transferred correctly. Unlike IFC, gbXML is selective in its export process as it only exports defined spaces and the properties of the fabric enclosing those spaces. This simplifies the geometry and therefore translates well to the energy simulation modeling-‐interface. However, a number of issues were observed in that approach. Objects that act as shading devices in many cases were not exported because they don’t directly relate with the space. The cylinder shaped shading on the skylights is disregarded in gbXML export (Fig. 4.14 and 4.14). Another issue was noted when using dynamic tools in Revit such as the " Window placement ". This tool specifies a relationship between a wall and a window placed within it and conveys the model as a result of the join operation. The gbXML did not encode this relationship and interpreted the window incorrectly (Fig. 4.14 and 4.14). These issues were observed in both Sketchup’s and IES Pro interpretation of the gbXML file. Figure 4.12: The created test case model in Revit. 62 Figure 4.13: Imported model in SketchUp after transferring through IFC; the transfer of geometry appeared to be complete and accurate. The pool was imported as a space because it was improperly defined in Revit. Figure 4.14: Imported model in SketchUp after transferring through gbXML; gbXML attempts to transfer only the defined spaces and the space-‐bounding surfaces. Also in this case the pool was imported as a space because it was improperly defined in Revit. Figure 4.15: Imported model in IES Pro after transferring through gbXML; Similar observations were made of geometry flaws as noted in the Sketchup import above. For an accurate simulation the model should be complete and correct with no errors in geometry -‐ spaces and space boundaries. Users should take necessary precautions and verify the model before attempting any analysis. 63 4.4.2 Building data’s accuracy and completeness (not geometry) For the representative sample of parameters, the data models were compared against the original data input in Revit and the results are highlighted in the following divisions: 1) location, building, and space elements; 2) window and wall elements; and 3) space attributes, density, load intensities, and schedules. 1. Location, building, and space elements Green Building Studio, EnergyPro, and IES Pro generally worked well in importing the location, building, and space elements of the gbXML file (Fig. 4.16). The weather file was not included in the gbXML data, and users are required to input it manually. • Export. The data was exported correctly from Revit to the gbXML and IFC files. • Import. Upon importing the gbXML file EnergyPro and IES Pro translated the address of the project. However GBS required manual input of the address before even attempting to import the gbXML. eQuest does not have the capability to import a gbXML file. 64 Figure 4.16: Results of the exchange data of the location, building, and space elements 2. Window and wall elements There was sporadic success with transferring the attributes of window and wall elements with Green Building Studio and IES Pro performing much better than EnergyPro (Fig. 4.17). 65 • Export. The thermal data in Revit was exported correctly into the gbXML and IFC files. Roughness and function of layer data however were not exported, as it does not relate to thermal properties. The gbXML file does not attempt to export any data that is not related specifically to geometry or thermal properties. • Import. GBS and IES Pro imported the main thermal data correctly, but EnergyPro did not. The attributes of the assemblies were changed to the default values of the software as if no data has been inputted in the building information model. Figure 4.17: The results of the exchange data of the window element and the wall assembly of the material element (larger image placed in Appendix D) 3. Space attributes, density, load intensities, and schedules Revit exported the data into the gbXML and IFC files, but for the most part, these parameters were not imported into any of the energy simulation programs (Fig. 4.18). 66 Figure 4.18: The results of the exchange data of the space attributes; people density, lighting and power load intensities and building schedules 67 4.5 COMPARING THE DATA CAPACITY OF THE DIFFERENT DATA MODELS 4.5.1 Test runs using gbXML Looking at this subset of parameters has led to a few conclusions. First, gbXML is adequate file format for geometry transfer, but occasionally has problems with more complex or confusing geometry (for example, they might not be able to tell the difference between a window shade and a small roof). For data transfer, the results were worse. The gaps are both of inaccurate and incomplete transfer of data. It appears that the BIM authoring software export is functioning correctly to gbXM. However, the building energy software is not always taking full advantage of the information in the gbXML file to import it correctly. This is effected by the data filters and default values that act upon the file during import. In some cases the data is not imported at all and requires manual re-‐entering such as the location and schedules in Green Building Studio. In other cases when the data is not being imported from the BIM, a default value for that variable is substituted instead. An example is IES behavior towards the project schedules; the originals defined in the data model are disregarded and replaced with the software default schedule of “On continuously.” 4.5.2 Test runs using IFC Similar tests were attempted using the same reference building of DOE and using IFC as the data transfer model. IFC is still in development stage when it comes to the BIM to BEM data flow. This is not caused by the export mechanism of the BIM authoring tools to IFC, nor IFC’s ability to transfer data but rather the support that IFC currently has in the BEM software industry. IFC has very limited support between the BEM tools; at the time of this report only three tools (Riuska, IES, and IDA ICE) were certified to import IFC. A complete list could be found here: http://www.buildingsmart-‐tech.org/implementation/implementations . This makes the data transfer between BIM and BEM using IFC unlikely to happen, as the options open to the user are very limited. Second, IFC encodes the complete geometry as represented in the BIM software, and has proved to be an adequate data model for geometry transfer. 4.6 CONCLUSIONS From looking at the results, a few conclusions can be drawn about both the transfer of geometry and energy data. gbXML is an adequate file format for this purpose, but occasionally has problems with more complex or confusing geometry (for example, it might not be able to tell the difference between a window shade and a small roof). For data transfer, the results were worse. The gaps are both of inaccurate and incomplete transfer of data. In the case study conducted, it appears that the BIM authoring software export is functioning correctly to gbXML. However, the building energy software is not always taking full advantage of the information in the gbXML file to import it correctly. This is due to ineffective import mechanisms and with how the energy program is handling each specific piece of datum as it is input. To help alleviate some of these interoperability issues, it was decided to develop a tool that clearly showed what values were in a gbXML file. Unlike other gbXML readers, it would not show all the data in a hierarchy, but instead isolate the parameters that energy simulation software use and group them into the four DOE categories (Deru et al. 2011).. These are program, form, fabric, equipment -‐-‐ program (location, total area, internal loads, operating schedules, hot water demand, and ventilation requirements), form (geometry and orientation), 68 fabric (construction types and thermal properties of the building elements), and equipment (the types, specification, and efficiency of the lighting, HVAC, and SWH systems). 69 CHAPTER 5: DEVELOPING THE DATA TRANSPARENCY TOOL (DTT) 70 5.1 INTRODUCTION The Data Transparency Tool’s (DTT) job is to present the data in the data models allowing the user to verify it and correct inaccuracies. This is done by applying a transparency layer upon the IFC and gbXML files so that even the inexperienced user could understand them (Fig. 5.1). Four steps were needed to create the tool: matching data model elements with the selected variable set; creating a new XML schema that matches the variable set; presenting the schema in a Microsoft Excel tool that would automatically populate the data; and finally programming the different features. Figure 5.1: Diagram of the Data Transparency Tool (DTT) 5.2 MATCHING DATA MODEL ELEMENTS WITH VARIABLE SET Matching of gbXML and IFCXML elements with DOE’s defined variable set is done by connecting the data model enumeration (element) with its corresponding variable name in DOE’s set. An example is “DesignHeatT” which is gbMXL’s element code for the heating design temperature (outdoor dry bulb temperature that is exceeded during at least 99% of the hours in a typical weather year) (Fig 5.2). IFCXML and gbXML each structure the data in a particular proprietary hierarchy. This hierarchy encompasses a number of elements and attributes that make up the complete project data. Both structures were examined and presented, however, since gbXML is the commonly accepted format for simulation tools it was chosen as a base to develop the DTT (Fig. 2.2). 71 Figure 5.2: Diagram of methodology; matching data model enumerations with DOE’s defined variable set. 5.2.1 gbXML. gbXML’s original hierarchical structure is comprised of a large number of elements that represent the geometry and data of a building. The hierarchy starts with “gbXML” on the top level and under it the elements representing the building are grouped as “Children” and “Attributes” (Fig. 5.3). These elements were examined and then “matched” with their corresponding variable in DOE’s defined variable set. An example is buildingstorey, which is gbXML representation of the number of floors in the building (Fig. 5.4). Matching of gbXML and IFCXML elements with DOE’s defined variable set is necessary to pull out the information in the data model and present it in the tool. 72 Figure 5.3: Diagram of gbXML’s original hierarchical structure. temperatureUnit lengthUnit areaUnit volumeUnit useSIUnitsForResults xmlns version Attributes Id Name Latitude Longitude Id buildingtype Area InfiltrationFlow BuildingStorey spaceType ZoneIdRef lightScheduleIdRef equipmentScheduleIdRef peopleScheduleIdRef conditionType buildingStoreyIdRef Name Id lightingSystemIdRef CoefficientOfUtilization PhotometryOrientation Area Volume PlanarGeometry id unit Children ClosedShell CADObjectId Attributes surfaceRef PlanarGeometry PolyLoop PeopleNumber PeopleHeatGain LightPowerPerArea EquipPowerPerArea id surfaceType constructionIdRef Name AdjacentSpaceId RectangularGeometry PlanarGeometry id Name openingType constructionIdRef RectangularGeometry PlanarGeometry CADObjectId CADObjectId Id Manufacturer NumberOfLamps LumensPerLamp Dimensions InputWatts Lamp Luminaire Photometry Attributes Id Children LayerId Attributes Id Children MaterialId Attributes Id RKvalue Thickness Conductivity Density SpecificOHeat Attributes Id UKValue SolarHeatGainCoeff Transmittance Attributes Id Name YearSchedule Id type Children Day Id typw Children ScheduleValue Attributes Id Name AirChangesPerHour OAFlowPerArea OAFlowPerPerson DesignHeatT CoolingHeatT CADObjectId TypeCode ProgramInfo CompanyName ProductName Version Platform PersonInfo LastName CreatedBy Opening Attributes Children Space Attributes Children Lighting Attributes Children ShellGeometry Attributes SpaceBoundary Children gbXML Children Location Children Building Attributes Children Surface DaySchedule Attributes Zone Children Children DocumentHisto ry Attributes Children WindowType Children Schedule Children Attributes WeekSchedule Children Material Attributes Campus LightingSystem Construction Layer Children Children 73 The Design BIM model is created primarily to serve the architect’s role. In many cases critical energy data is left out; an energy simulation specialist must then manually add missing required information to create the model required for energy simulation (Bazjanac and Kiviniemi 2007). This is partially due to missing data input from the user side and partially to the BIM software’s themselves as some do not offer all energy simulation variables entry. To become accurate the simulation tools must contain complete and correct data. DTT would streamline this process by warning of any missing data. DOE’s list contains broad variables and each can contain multiple variables to be defined in the energy software (Fig. 3.2). For example, “Location” can include: The project’s longitude, latitude, altitude, the address, the closest weather Station ID… etc. gbXML representing elements were grouped under DOE’s variables (Fig. 5.4). 74 Figure 5.4: gbXML elements mapped with DOE’s defined group variables (Deru et al. 2011). This structure will be the basis of DTT new XML scheme. 75 5.3 MAPPING DTT’S NEW XML SCHEMA A new schema was created that follows the hierarchy of variables defined by DOE. Using the new schema, the data is presented to the user in a Microsoft Excel interface. The original XML was accessed by opening a template gbXML file in Excel and accessing the source panel through the developer tab. When opening the gbXML template file the user is prompted to select how the file will be opened. Selecting “Use the XML Source task pane” enables the use of the template gbXML as a source to map a new schema for the DTT (Fig. 5.5). Figure 5.5: Importing the gbXML template file as source to map the DTT. The new XML schema was then created by dragging the element nodes from the XML Source pane to the workspace cells adhering to the defined variable set as basis for hierarchy (Fig. 5.6). Figure 5.6: Using the gbXML template file as source to map the DTT. Program, Form, Fabric and Equipment therefore create the top levels of the hierarchy and encompass under them the related variables. This schema was then used to present the data model values. The Excel template contains four main tabs each of which corresponds with the variable set and its underlying elements (Fig. 5.7). 76 Figure 5.7: Mapping new XML schema based on the defined variable (left and upper right) and presenting the schema in the DTT Excel interface – partial screenshot (lower right corner). Five tabs along the bottom for the program itself and the four categories. At this stage, the DTT is capable of importing the gbXML data model and presenting the data; however, the import functionality requires familiarity with Excel’s XML tools. Steps were taken to automate DTT’s import functionality and add additional functions enabling the analysis, scoring and reporting of data. Refer to Chapter 6 for more detailed information on using the software. 5.4 DEVELOPING DTT’S USER FUNCTIONS DTT functions are made possible via the use of Visual Basic for Applications (VBA). Excel VBA allows the automation of tasks by writing macros. This is accomplished by using the tools in Excel’s developer tab. This tab arguably contains the most powerful tools in Excel. It provides an interface for running and recording macros. It also contains Excel’s form controls that enable designing and inserting command buttons. The first step was inserting command buttons of the functions that DTT would execute (Fig. 5.8). Then these buttons were programed by assigning codes that would be executed once these buttons are clicked (Fig. 5.9). 77 Figure 5.8: Command buttons are inserted via the developer tab. Figure 5.9: Visual Basic for Applications, code is written in this interface and assigned to the command buttons. Five command buttons were created that correspond to the main functions of DTT: “Import gbXML,” “Check Missing Data,” “Refresh,” “Generate Report”, and “Compare”(Fig. 5.10). Figure 5.10: The five command buttons that were created in the DTT: “Import gbXML,” “Check Missing Data,” “Refresh,” “Generate Report,, and “Compare.” 78 Import File The first step is to import a gbXML file; this function allows the user to browse, select, and import a gbXML file. Once this code is executed a pop-‐up window appears allowing the user to select the specified file. Once the user confirms and clicks “import” DTT would then automatically map the gbXML file and place the data under the corresponding predefined categories (Fig. 5.11). Figure 5.11: The complete code of “Import” command button; this function allows the user to browse, select, and import a specific gbXML file. Check Missing Data DTT analyzes the completeness of data and alert the user of any missing data necessary for energy simulation by checking for blank cells. This is accomplished via the “Check Missing Data” command. This command applies a conditional formatting rule on the whole range of cells. If the cell contains a value then it is accepted; if the cell is empty or out of the accepted range of values then the cell is highlighted in red (Fig. 5.12). Figure 5.12: The partial code of “Check Missing Data” command button; this function alerts the user of missing data. The complete code is in Appendix B. 79 Reporting the Data Model completeness The DTT reports the completeness of data required for energy simulation. The “Report” function generates a PDF file that illustrates individual completeness scores for the variable categories (Program, Fabric, Form, and Equipment) as well as an overall score. The overall score reports the overall percentage of variables that have been provided. This function enables instant review of content and assists the user in determining the relative validity of simulations if the file was used. A simulation run using a 90% complete data model would be much more reliable than a 20% one (Fig. 5.13). Figure 5.13: DTT’s generated PDF report illustrates individual completeness scores for the variable categories (Program, Fabric, Form, and Equipment) as well as an overall score. To achieve this report, conditional codes and a macro were used. Conditional formatting is applied to specified cells, when the data in these cells meet the conditions specified, then the selected formats are applied. In the DTT case red highlight is applied when data is missing and green highlight is applied when there is a defined value. Some conditional codes: =IF(Program!M4=0, "No Value", "Has Value") =IF(Fabric!A4=0, 0, 1) The macro assigned to the reporting command prints a PDF file of the Report sheet (Fig. 5.14). 80 Figure 5.14: The partial code of “Generate Report” command button, this function generates a report that summarizes the completeness of the file and produces a “completeness” score. Refresh This command button clears the data and must be performed prior to any import (Fig. 5.15). Figure 5.15: The partial code of “Refresh” command button, this command clears the data and must be performed prior to any import. Complete code found in Appendix B. Compare The compare command compares two data models and reports any differences. It is used to determine the effects of the energy simulation tools’ import mechanisms. As observed in chapter 4, it is common for some data to be left out or even altered in some cases (Fig. 4.17). When exporting from BIM to BEM not all the data in the model is exported because some of it is irrelevant. As an example of the filtering is the exclusion of elements such as furniture and attributes such as costs which are irrelevant for energy analysis and therefore the software does 81 not attempt to export them. However and as observed in section 3.4.1 some essential data is left out. This tool would enable the user to observe these changes and update the model in the BEM tool for accurate results. The macro programmed to the “compare” button executes a tool “SpreadSheetCompare” that allows the user to select the two files and then performs the comparison (Fig. 5.16). Figure 5.16: The code of the “Compare” macro; this codes executes the “SpreadSheetCompare” tool. 5.5 CONCLUSION One of the main issues in data transfer is lack of transparency. The DTT tackled this by the following methods: communicating what is actually being transferred to the user in a simple clear format; analyzing the data and alerting user of missing information; generating reports and developing a file scoring system; and revealing the effect of the BEM tools’ import functionality by comparing the original gbXML with the one that is actually used for simulation. The import and export mechanism include “data filters” that “select” partial data for export. 82 CHAPTER 6 PRESENTING THE DATA TRANSPERANCY TOOL (DTT) 83 6.1 INTRODUCTION The Data Transparency Tool’s (DTT) job is to present the data in the data models allowing the user to verify it and correct inaccuracies. The tool has four main functions; data presentation, data analysis, and generating data reports. 6.1.1 Presenting the relevant data The tool shows the user in a simple manner exactly what is being exported from the building information modeling software and imported into the energy software. Then designers could have more confidence about the values of parameters that are being transferred from BIM to BEM. Unlike other data model readers that show all the data in a hierarchy, the DTT isolates the parameters that energy simulation software use and group them into the four DOE categories. Program, Form, Fabric and Equipment therefore create the top levels of the hierarchy and present under them the related variables in an Excel interface. 6.1.2 Analyzing Data DTT analyzes the completeness of data and alert the user of any missing data necessary for energy simulation. It then reviews and validates the range of data. This is done by confirming that the variables are within accepted variable range. An example is Solar Heat Gain Coefficient (SHGC) that must have a value between 0 and 1; if the entered value is out of the range the tool will highlight the cell alerting the user. 6.1.3 Reporting The tool has the capability of generating a report that summarizes the data highlighting any issues. It also generates a score (percentage) for the imported gbXML file depending on the completeness and validity of data. 6.1.4 Data Model Comparison DTT reveals the effects of the “filters” imposed by the energy-‐modeling tools. These filters are part of the import mechanism of these tools and act upon the imported file. In some case, and as observed in Chapter 4, the original data is altered (Fig 4.17). DTT reveals any change by comparing the data model exported from the BIM software and the actual data that is used in the tool. 84 6.2 A GUIDE TO USING THE DTT DTT imports, inspects, analyzes and reports on the gbXML data model. gbXML is now supported by the majority of the software vendors including Autodesk, Bentley, and Vectorworks; a complete list of software can be found on-‐line (http://www.gbxml.org/software.php, last accessed May 2014). The gbXML export of the case study building of DOE medium office building (developed in Chapter 4) was used as a reference building (Fig .6.1). Figure 6.1: The reference DOE office-‐building model from Revit used for tutorial. 6.2.1 Setup, Startup, and the user interface The tool is bundled together in one macro-‐enabled Excel file. No installation is required, simply copy from source and paste into desired location. However, DTT must be run on a Microsoft® Windows® compatible computer with Excel already installed. The Microsoft® suite on Macintosh does not currently support some of the macros required for tool functionality. Once the tool is opened, an empty Excel template is displayed. The variables are represented under the four categories defined by DOE (Program, Form, Fabric and Equipment). The categories are each on a separate sheet (Fig 6.2, 6.3, 6.4 and 6.5). 85 Figure 6.2: “Program” sheet encompasses building program variables (location, total area, internal loads, operating schedules, hot water demand, and ventilation requirements). Figure 6.3: “Form” sheet encompasses only Building Story variables of the Form. 86 Figure 6.4: “Fabric” sheet encompasses building fabric variables (construction types and thermal properties of the building elements). Figure 6.5: “Equipment” sheet list the power usage. 87 Figure 6.6: “File Spec” presents the meta data of the file which includes data such as originated software, user name, date exported The DTT does not discard any data from the data model, data of the geometry as well as data that isn’t directly related to energy simulation and doesn’t fall within the defined variables (such as geometry) is presented in the “other data” sheet (Fig. 6.7). Figure 6.7: “Other Data” sheet The opening page of the tool is the Program sheet that contains the different function buttons that allow the importing, analysis, and reporting of the data. 88 6.2.2 Importing data models and understanding the data It is essential to refresh always prior to importing. The “Refresh” button clears all cells and prepares the tool for import of a new file. Next import a gbXML data model; this is done by clicking on the “import gbXML” button. A pop-‐up window then emerges that allows the user to browse, locate ,and then open the specified file. DTT would then import the file and map the data under their corresponding categories. The case study file of DOE office building was imported, and the variables were correctly mapped (Fig. 6.8 and 6.9). Further trials were made using other gbXML files and were all successfully represented (generated reports can be found in Appendix F). Figure 6.8: File selection window emerges when the user clicks the “import gbXML” button. Figure 6.9: DTT automatically sorts the data into their specified fields. 89 6.2.3 Analyzing the data DTT analyzes the completeness of data and alerts the user of any missing data necessary for energy simulation. This is done via the “Check Missing Data” function that highlights the cells with absent data in red (Fig. 6.10). It also reviews and validates the data by confirming that the variables are within accepted variable range; for instance the value of the Solar Heat Gain Coefficient (SHGC) should be with the range (0-‐1). Figure 6.10: Missing data are highlighted in red to alert the user. 6.2.4 Reporting DTT generates a file completeness report through clicking on the “Generate Report.” This function creates a PDF file that reports the missing data and produces completeness scores for the variable categories individually and for the file as a whole (Fig. 6.11). This function enables instant review of content and assists the user in determining the relative validity of simulations if the file was used. A simulation run using a 90% complete data model would be much more reliable than a 20% one. 90 Figure 6.11: The generated (PDF) completeness report of the “Modern Family Home” gbXML file. It is essential to refresh always prior to importing. The “Refresh” button clears all cells and prepares the tool for import of a new file. 6.2.5 Data Model comparison This function reveals the effects of the energy tools import mechanism “filters.” These filters are part of the import mechanism and act upon the imported data model. This function can be utilized to check a file that was exported from BIM to one that was exported from BIM, imported to BEM, and exported from BEM. This would check if the BEM has the same values that BIM exported. DTT launches a file comparison tool (Spreadsheet Compare) once the “Compare” button is clicked. The user would then select “Compare Files” on the upper left hand corner of the launched window (Fig. 6.12), which would then promote the user to select the desired data models (Fig. 6.13). 91 Figure 6.12: The spreadsheet Compare tool is launched once “Compare” is clicked. Figure 6.13: The user is promoted to select the desired files to compare. Once the user select the files and clicks compare the tool would then proceed with the comparison and presents the results. Both files are brought up and presented side by side, one sheet at a time; “Program”, “Form”, “Fabric”, “Equipment”, and “File Specs”. Any differences are highlighted to alert the user (Fig. 4.14). Figure 6.14: Both files are brought up and presented side by side. 92 A table in the lower center summarizes the differences (Fig. 6.15). Figure 6.15: The table in the lower center summarizes the differences. 6.3 COUPLING TOOL WITH GEOMETRY VIEWERS. DTT displays and analyzes non-‐geometrical data; the geometric data is made available only in textual format in the “Other Data” sheet. In order to optimize transparency it is recommended to use it along with geometry visualization tools that translate the textual geometry. Tools such as Solibri, FZKViewer, and DDS-‐CAD and plug-‐ins such as gModeller for Google SketchUp, can be used along the DTT for geometrical visualization of data models and would enhance the data transfer transparency. Coupling DTT with geometry viewers is especially required with complex geometry and would allow the user to examine the transferred geometry and fix any issues. Reference is made to the previous exercise in section 4.4.1 where two case studies were used to examine gbXML’s capability of geometrical representation. The first was the medium office building, and the second was the “Modern Family Home” (Fig 6.16 and Fig 6.17). The latter comprises of a more complex geometry where issues where found and therefore better establishes the necessity of geometry visualization. Both projects were exported into gbXML from Revit and then imported to SketchUp via the gModeller plug-‐in. The medium office building, being simple in its form, had no issues in the data model representation of geometry. That said, examining the geometry is essential even in the simplest of models. On the other hand the “Modern family home” had a number of issues. Objects that act as shading devices in many cases were not exported; the cylinder shaped shading on the skylights is disregarded in gbXML export (Fig. 6.18). Another issue was noted when using dynamic tools in Revit such as the " Window placement." This tool specifies a relationship between a wall and a window placed within it and conveys the model as a result of the join operation. The gbXML did not encode this relationship and interpreted the window incorrectly (Fig. 6.18). 93 Figure 6.16: The medium office model in Revit (left) and the geometrical representation of the exported data model in SketchUp (right). Figure 6.17: A more complex geometry “Modern Family Home” created in Revit. Figure 6.18: The imported model in SketchUp after transferring through gbXML; gbXML attempts to transfer only the defined spaces and the space-‐bounding surfaces. Also in this case the pool was imported as a space because it was improperly defined in Revit. The above cases examine and report the geometrical representation capabilities of gbXML through visual matching. It would be extremely useful to have tools that examine the actual 94 geometry and report mismatches. This is discussed further in Chapter 7 as part of future proposed work to enhance the BIM to BEM data exchange. At this stage DTT isn’t capable of detecting any geometrical issues in the transfer such as the ones highlighted in above cases, it is proposed as future work to have a built in geometrical viewer that would eliminate the need for other tools. Accurate geometry and data are required for accurate simulation; the model should be complete and correct with no errors in geometry -‐ spaces and space boundaries. Therefore users should take necessary precautions and verify not only the data through DTT but also the geometry before attempting any analysis. 6.4 CONCLUSION The DTT attempts to address the interoperability gap between BIM and BEM by showing the user in a simple manner exactly what is being exported from the building information modeling software and imported into the energy software. DTT imports, inspects, analyzes and reports on the gbXML data model allowing users to have more confidence in their simulations. 95 CHAPTER 7 FUTURE WORK AND CONCLUSION 96 7.1 INTRODUCTION BIM has proved to be a valuable tool, yet there still are issues in its execution. The interoperability gap between BIM and building energy simulation tools is one of these issues that needs further research. BIM software should be able to export necessary information, and energy programs should be able to import it. This allows for efficiencies and time-‐savings that could be used for the simulations themselves. Steps were taken to understand the current limitations of file transfer and how transparency of data interoperability and “open” structured BIM data can be used to help bridge many of the BIM gaps that exist in the handover of information. 7.2 FUTURE WORK Future work could be in several directions including BIM interoperability, open source formats, development on the DTT, and interoperable file formats. 7.2.1 Pressure on Software Developers The interoperability tests concluded that major issue lie in the import mechanism of the energy simulation tools. In many cases the data was incomplete and in some cases even altered. More pressure needs to be put on software developers to improve this capability of their software. The DTT’s comparison tool could be used to aid software developers in pinpointing issues in their data import mechanisms as a first step in resolving them. 7.2.2 Open Source Formats The industry is moving towards open source formats. Numerous options of open source formats for the same data transfer could be found. IFC is one of these formats that provides an object-‐oriented file-‐format solution that is interoperable with different software functioning at different stages of the project (BuildingSMART 2014). By doing so the flow of data is continuous through one file structure from the initial design stage all the way to project execution. In that sense IFC is more practical than gbXML as the latter is specifically developed for energy simulation and does not function at other stages. IFC also has a strict software certification program that ensures reliability and interoperability that gbXML lacks. gbXML on the other hand is developed specifically to transfer building geometrical and thermal data. Neither IFC nor gbXML have unanimous software support of to complete the data exchange between the BIM authoring software, but gbXML does have better support between the BEM tools as 88% support its import versus only 12% are certified for IFC import (Fig 7.1). Future work could help determine whether IFC or gbXML are better choices for building energy modeling. Another approach is to advocate a range of open source formats that are applicable to the specific set of data that needs to be transferred. 97 7.2.3 Development on the DTT: The following are a few functions that could improve the tool. 1. Incorporating geometry The current technique is using DTT along one of the commercially available graphic viewers. The next step would be to provide a built-‐in graphic representation of the model within DTT interface. That would increase DTT ‘s functionality in presenting the model. 2. Visualization Create a color-‐coded visualization corresponding to the defined energy categories. 3. Adding and editing data DTT does not currently have the capability of editing the data model. It merely informs the user of any issues and the user would have to go back to the original source of the data model to edit or add any data. To become a comprehensive tool, it is suggested as part of future work to enable the user directly to correct and append data to the data models. 4. DTT as a plug-‐in to BIM software Currently DTT is an external tool that requires the import of a gbXML file to present and analyze the data. It would be easier if the tool was incorporated directly in the BIM software, presenting the data, highlighting issues and reporting completeness. 5. Developing an IFC based DTT The DTT was based on gbXML as it has extremely higher support between the energy simulation tools. However, it is important to develop an IFC based version of DTT as neither IFC nor gbXML have unanimous software support to complete the data exchange (Fig 2.2). 6. Transferring to an executable stand alone software DTT is currently nested in Mircosoft Excel, that inherits it with some limitations. It must be run on a Microsoft® Windows® compatible computer with Excel already installed. Moreover, the Microsoft® suite on Macintosh does not currently support some of the macros required for tool functionality. It is proposed as future work to convert the DTT into a free standing software. 7.2.4 Developing other tools: a gbXML to IFC converter Reference is made to the discussion on data model formats (gbXML and IFC) interoperability between BIM and BEM in Chapter 2 (Fig. 7.1). 98 Figure 7.1: Type of data models (IFC or gbXML) that BIM Authoring tools and Energy Simulation tools import and export; developed according to a web-‐search performed November, 2014. A valuable tool to assist in this issue is a format converter between IFC and gbXML, making the two standards themselves interoperable. This tool would increase the data transfer possibility tremendously and would reduce the restriction of choices for both the designer and the energy analyst. It would also reduce or completely eliminate manual data entry making the data flow seamless with a great reduction on the possibility of human error. 7.3 CONCLUSION Although there has been significant progress for BIM, both in bringing it to prominence in the AECO industry and in trying to minimize the gaps between team members and project phases, more is necessary if BIM is to be used to its full potential and transform the industry. Many gaps still exist in the data exchange between BIM models that could result in data loss, miscommunications, and inaccurate results, which would inevitably disturb the design and construction process Energy efficiency is now, more than ever, a top concern that should be addressed in the earliest of the design stages. Explaining, understanding, and enhancing the data transfer between software would allow better design decisions through more accurate coordination between energy simulation and building modeling. To become effective, energy efficiency should be a determining factor in the design of buildings and consequently should be carefully analyzed at the very earliest of the design stages. The BIM/BEM workflow should be seamless to support this analysis, which is not the case at present. A prominent one of these BIM gaps is the loss of data due to interoperability. Tools need to be introduced to manage the data flow and the user expectations. Many designer lost faith in this workflow and opt for re-‐modeling adding work and introducing additional human input that is far from being immune to error. Others consider this workflow accurate and complete basing their simulation on the BIM export. 99 DTT is a patch tool addressing a fault in the current system and answering an issue in the data transfer. It was developed to tackle the issue of data loss by allowing the user to make more informative decisions. It added a layer of transparency to the data exchange allowing users to observe what values are being transferred, to analyze their validity, and to report their completeness. With more confidence in knowing exactly what is being transferred, it is hoped that designers will better utilize BIM to BEM for evidence-‐based design. 100 REFERENCES ACEEE. 2014 “The 2014 International Energy Efficiency Scorecard” Accessed November 29. http://aceee.org/files/pdf/summary/e1402-‐summary.pdf AIA. 2012. “An Architect’s Guide to INTEGRATING ENERGY MODELING IN THE DESIGN PROCESS.” Autodesk, Inc. 2014. IFC 2015. Accessed November 8. https://apps.exchange.autodesk.com/ALIAS/en/Detail/HelpDoc?id=appstore.exchange. autodesk.com:ifc2015_windows32and64:en&mode=live#inunininfo. Buildingsmart. 2014. Accessed September 29. http://www.buildingsmart-‐tech.org/news/ifc4-‐ officially-‐released. Cunningham, Philip. 2009. “HEATING AND COOLING LOAD CALCULATIONS AND ENERGY" Last accessed September 27. http://forums.augi.com/showthread.php?159634-‐MP308-‐3-‐ Heating-‐and-‐Cooling-‐Load-‐Calculations-‐and-‐Energy-‐Model-‐Development-‐From-‐an-‐ Autodesk-‐Revit-‐MEP-‐Model-‐Utilizing-‐gb Delfosse, Vincent, John Schrayen, Roland Juchmes, and Pierre Leclercq. 2012. “Some Advice for Migrating to IFC.” In . http://orbi.ulg.ac.be/handle/2268/121709. Deru, Michael, Kristin Field, Daniel Studer, Kyle Benne, Brent Griffith, Paul Torcellini, Bing Liu, et al. 2011. “US Department of Energy Commercial Reference Building Models of the National Building Stock.” http://digitalscholarship.unlv.edu/renew_pubs/44/?utm_source=digitalscholarship.unl v.edu%2Frenew_pubs%2F44&utm_medium=PDF&utm_campaign=PDFCoverPages. DOE. 2008. Buildings Share of U.S. Primary Energy Consumption Source: U.S. Department of Energy (DOE), 2008 Buildings Energy Data Book, Section 1.1.1, 200. http://www.c2es.org/technology/overview/buildings. Eastman, Chuck, Sacks, Rafael, and Panushev, Ivan. 2009. “Information Delivery Manual for Precast Concrete.” http://dcom.arch.gatech.edu/pcibim/documents/IDM_for_Precast.pdf. Eastman, Chuck, Manu Venugopal, Sacks, Rfael. 2015. “SEMANTIC EXCHANGE MODULES.” Accessed January 29. http://www.dbl.gatech.edu/sem. Eastman, Chuck, (first), Venugopal, Manu, and Aram, Shiva. “Industry-‐Wide National BIM Standard: A Progress Report.” AECbytes “Building the Future” Article, no. November 30, 2011. http://www.aecbytes.com/buildingthefuture/2011/NBIM-‐ProgressReport.html. gbXML. 2014. "Green Building XML Schema" Accessed November 20. http://www.gbXML.org. gbXML. 2015. "History of gbXML". Accessed February 20 http://www.gbxml.org/history.php GSA. 2007. “GSA Building Information Modeling Guide Series 01 -‐ Overview DRAFT.” http://www.gsa.gov/graphics/pbs/GSA_BIM_Guide_v0_60_Series01_Overview_05_14_0 7.pdf. Hijazi, Mohammed, Kensek, Karen, Konis, Kyle. 2015. “Bridging the Gap: Supporting Data Transparency from BIM to BEM.” In . White Paper. IEEE Std 610. 1991. “IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries,” January, 1–217. doi:10.1109/IEEESTD.1991.106963. IFC. 2014. “Industry Foundation Classes: IFC 2x Edition 2 addendum 1” Last accessed September 20. http://www.iai-‐ international.org/Model/R2x2_add1/index.html Karen Kensek, Kyle Konis, and Mohammed Hijazi. 2014. “Assessment of File Interoperability between BIM and Energy Analysis Software Using gbXML.” White Paper, Not yet Published. 101 Kensek, Karen, Becker Geoffrey, and Hijazi, Mohammed. 2014. “BIM Gaps: Major Issues That Are Preventing Seamless Integration of Building Information Modeling in the AECO Industry.” White Paper. Kensek, Karen M. 2014. Building Information Modeling. 1 edition. London ; New York: Routledge. Oullette, Jeffrey. 2014. Interview with Jeffrey Oullette. Sefiera. 2014. Why Sefaira?. Accessed November 14. http://sefaira.com/why-‐sefaira/. Sumedha, Kumar. 2014. “Interoperability between Building Information Models (BIM) and Energy Analysis Programs :: University of Southern California Dissertations and Theses.” Accessed September 4. http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll127/id/64743. 102 BIBLIOGRAPHY The references in the section above include only the sources that have been directly used and cited. The bibliography however, consists of all resources (books, journals, online resources) examined during the course of the project and includes even those sources that have not been cited. ACEEE, 2014 “The 2014 International Energy Efficiency Scorecard” Accessed November 29. http://aceee.org/files/pdf/summary/e1402-‐summary.pdf AIA. 2012. “An Architect’s Guide to INTEGRATING ENERGY MODELING IN THE DESIGN PROCESS.” Autodesk, Inc. 2014. IFC 2015. Accessed November 8. https://apps.exchange.autodesk.com/ALIAS/en/Detail/HelpDoc?id=appstore.exchange. autodesk.com:ifc2015_windows32and64:en&mode=live#inunininfo. Autodesk 2014. “Building Solutions, Building Performance Analysis Using Revit, Autodesk, accessed August 23. <http://images.autodesk.com/adsk/files/building_performance_analysis_usin g_revit.pdf Autodesk Revit. 2014. “Revit Help Wiki”. Accessed November 20. 08/11/2014http://help.autodesk.com/view/RVT/2014/ENU/?guid=GUID-‐418D5435-‐ B95E-‐4C84-‐8EF5-‐C2962E313D79 Bazjanac, V. 2001. Acquisition of Building Geometry in the Simulation of Energy Performance“. Building Simulation 2001, Proc. intern. conf., Rio de Janeiro, Vol. 1: 305-‐311. ISBN 85-‐ 901939-‐2-‐6. Bazjanac, V. 2002. “Early Lessons From Deployment of IFC Compatible Software.” eWork and eBusiness in Architecture, Engineering and Construction, Proc. fourth Euro. conf. product process modelling, Portoroz, SLO: 9-‐ 16. Balkema. ISBN 90 5809 507 X. Bazjanac, V, 2003. “Improving Building Energy Performance simulation with Software interoperability” Eighth International IBPSA Conference, Netherlands. Bazjanac, V., and D.B. Crawley. 1999. “Industry Foundation Classes and Interoperable Commercial Software in Support of Design of Energy-‐Efficient Buildings” In Proceedings of Building Simulation ’99, Kyoto. Buildingsmart. 2014. Accessed September 29. http://www.buildingsmart-‐tech.org/news/ifc4-‐ officially-‐released. BLIS. 2000. “Building Lifecycle Interoperable Software .” Accessed November 29. http://www.blis-‐project.org. Cunningham, Philip. 2009. “HEATING AND COOLING LOAD CALCULATIONS AND ENERGY" Delfosse, Vincent, John Schrayen, Roland Juchmes, and Pierre Leclercq. 2012. “Some Advice for Migrating to IFC.” In . http://orbi.ulg.ac.be/handle/2268/121709. Deru, Michael, Kristin Field, Daniel Studer, Kyle Benne, Brent Griffith, Paul Torcellini, Bing Liu, et al. 2011. “US Department of Energy Commercial Reference Building Models of the National Building Stock.” http://digitalscholarship.unlv.edu/renew_pubs/44/?utm_source=digitalscholarship.unl v.edu%2Frenew_pubs%2F44&utm_medium=PDF&utm_campaign=PDFCoverPages. DOE. 2008. Buildings Share of U.S. Primary Energy Consumption Source: U.S. Department of Energy (DOE), 2008 Buildings Energy Data Book, Section 1.1.1, 200. http://www.c2es.org/technology/overview/buildings. Eastman, Chuck, Sacks, Rafael, and Panushev, Ivan. 2009. “Information Delivery Manual for Precast Concrete.” http://dcom.arch.gatech.edu/pcibim/documents/IDM_for_Precast.pdf. 103 Eastman, Chuck, Venugopal, Manu, and Aram, Shiva. “Industry-‐Wide National BIM Standard: A Progress Report.” AECbytes “Building the Future” Article, no. November 30, 2011. http://www.aecbytes.com/buildingthefuture/2011/NBIM-‐ProgressReport.html. Eastman, 2011, BIM Handbook, A Guide to Building Information Modeling, 2 nd edition, Chapter 1& 3 Eastman, Chuck, Manu, Venugopal, Sacks, Rafael. 2015. “SEMANTIC EXCHANGE MODULES.” Accessed January 29. http://www.dbl.gatech.edu/sem. gbXML. 2014. "Green Building XML Schema" Accessed November 20. http://www.gbXML.org gbXML. 2015. "History of gbXML". Accessed February 20 http://www.gbxml.org/history.php Goldstein, H 2001, 'FOUNDATION CLASSES BRIDGING DIGITAL GAP',. ENR: Engineering News-‐ Record, 246, 13, p. 23, Business Source Complete, EBSCOhost. GSA. 2007. “GSA Building Information Modeling Guide Series 01 -‐ Overview DRAFT.” http://www.gsa.gov/graphics/pbs/GSA_BIM_Guide_v0_60_Series01_Overview_05_14_0 7.pdf. Hyunjoo, Kim and Anderson, Kyle. 2013. ”Energy Modeling System Using Building Information Modeling Open Standards.” J. Comput. Civ. Eng., 27(3), 203–211. IEEE Std 610. 1991. “IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries,” January, 1–217. doi:10.1109/IEEESTD.1991.106963. IFC, 2014. “Industry Foundation Classes: IFC 2x Edition 2 addendum 1” Last accessed September 20. http://www.iai-‐ international.org/Model/R2x2_add1/index.html Jeffrey Oullette. 2014. Interview with Jeffrey Oullette. Karola, A., H. Lahtela, R. Hänninen, R.J. Hitchcock, Q. Chen, S. Dajka and K. Hagström. 2002. BSPro COM-‐Server -‐ Interoperability between software tools using industry foundation classes. In Energy and Buildings, No. 34: 901-‐907. Kensek, Karen. Konis, Kyle. and Hijazi, Mohammed 2014. “Assessment of File Interoperability between BIM and Energy Analysis Software Using gbXML.” White Paper, Not yet Published. Kensek, Karen, Becker Geoffrey, and Hijazi, Mohammed. 2014. “BIM Gaps: Major Issues That Are Preventing Seamless Integration of Building Information Modeling in the AECO Industry.” White Paper. Krygiel, E., & Nies, B., 2008. “Green BIM: successful sustainable design with building information modeling, Wiley Pub, Indianapolis, Ind. Kensek, Karen M. 2014. Building Information Modeling. 1 edition. London; New York: Routledge. Lappalainen, V., S. Karjalainen, T. Salsbury and D. Sucic. 2000. “HVAC Performance Validation: Process definitions, Information requirements Analysis and Object Type Definition IFC R3.0 Domain Project Documentation, VTT.” Mohammed Hijazi, Karen Kensek, Kyle Konis. 2015. “Bridging the Gap: Supporting Data Transparency from BIM to BEM.” In . White Paper. MODEL DEVELOPMENT FROM AN AUTODESK® REVIT® MEP MODEL UTILIZING GBXML.” Autodesk University. Onuma, K. 2014, “IFC Train Wreck”. E-‐mail note about the appropriate use of IFC versus other standards, 8/24/2014. In response to a presentation by Kurt Komraus (Buro Happold), Eric Queen (Clark Construction), and Becher (NEME Design Solutions), ARTIC: The Evolution of a BIM Model Through Design, Construction, and Fabrication, USC BIM Symposium BIM GAP + BIM EDGE, August 2014. Paola C. Ferrari, Neander F. Silva, Ecilamar M. Lima, 2009 “Building Information Modeling and Interoperability with Environmental Simulation Systems” Innovations and Advances in Computer Sciences and Engineering Sefiera. 2014. Why Sefaira?. Accessed November 14. http://sefaira.com/why-‐sefaira/. 104 Sumedha, Kumar. 2014. “Interoperability between Building Information Models (BIM) and Energy Analysis Programs :: University of Southern California Dissertations and Theses.” Accessed September 4. http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll127/id/64743. Teicholz, P, 2013. "Labor-‐Productivity Declines in the Construction Industry: Causes and Remedies" 105 APPENDENCIES 106 APPENDIX A: BIM GAP SURVEY The survey was sent to 3,300 individuals in the building industry. 172 people responded with information about their organization, their role in the firm, and their organization’s use of BIM. The survey questions can be found in the Appendix A. “This survey focused specifically on the problems that individuals were having the models themselves, existing BIM standards, and perceived BIM gaps.” (KBH 2014) 107 108 109 110 111 112 113 APPENDIX B: IDM FOR PRECAST CONCRETE Figure 2.6: Architectural Precast Project process Map, IDM for Precast Concrete, (Eastman 2009). 114 APPENDIX C: PHILLIP CUNNINGHAM RESEARCH FIGURES Figure 2.7: gbXML elements and highlighted in blue are the specific elements supported by Revit MEP (Cunningham 2009). 115 Figure 2.8: gbXML elements and highlighted in green are the specific elements supported by Trace700(Cunningham 2009) A larger version of this figure is in Appendix B. 116 APPENDIX D: WINDOW AND WALL ELEMENT EXCHANGE TABLE Figure 4.17A: The results of the exchange data of the window element and the wall assembly of the material element 117 Figure 4.17B: The results of the exchange data of the window element and the wall assembly of the material element 118 APPENDIX E: DIAGRAM OF GBXML ORIGINAL STRUCTURE Figure 5.3A: Diagram of gbXML’s original hierarchical structure, 119 Figure 5.3B: Diagram of gbXML’s original hierarchical structure surfaceType constructionIdRef Name AdjacentSpaceId RectangularGeometry PlanarGeometry id Name openingType constructionIdRef RectangularGeometry PlanarGeometry CADObjectId CADObjectId Id Manufacturer NumberOfLamps LumensPerLamp Dimensions InputWatts Lamp Luminaire Photometry Attributes Id ChildrenLayerId Attributes Id ChildrenMaterialId Attributes Id RBvalue Thickness Conductivity Density SpecificFHeat Attributes Id UBValue SolarHeatGainCoeff Transmittance Attributes Id Name YearSchedule Id type ChildrenDay Id typw ChildrenScheduleValue Attributes Id Name AirChangesPerHour OAFlowPerArea OAFlowPerPerson DesignHeatT CoolingHeatT CADObjectId TypeCode ProgramInfo CompanyName ProductName Version Platform PersonInfo LastName CreatedBy DaySchedule Attributes Zone Children DocumentHisto ry Children Children WindowType Children Schedule Children WeekSchedule Attributes Attributes Children Opening Attributes Children LightingSystem Children gbXML Children Campus Children Surface Construction Layer Material 120 APPENDIX F: DTT ADDITIONAL REPORTS This reporting function of DTT enables instant review of content and assists the user in determining the relative validity of simulations if the file was used. A simulation run using a 90% complete data model would be much more reliable than a 20% one. 3 gbXML sample data models were analyzed in DTT. The first generated report is of only 28% completeness (Fig. F.1). It is easily inferred from the report that only the basic data such as location, areas and basic form are defined. This report could represent an early conceptual phase model. The 2 nd and 3 rd report are of more developed stages as they more complete (Fig. F.2 and F.3). The higher the completeness percentage the more reliable the model is for energy simulation. Figure F.1: Generated report from DTT reporting function of a 28% model. Data Transperancy Tool - Data Completness Report 3/18/2015 Has Value No Value Has Value id No Value Has Value U-value No Value Longitude Has Value SHGC No Value Latitude Has Value solarIncidentAngle No Value Elevation Has Value Transmittance No Value Has Value Type No Value Total Area Has Value U-value No Value Level Area Has Value Absorptance No Value Level Volume Has Value type No Value spaceType No Value Name No Value lightScheduleIdRef No Value Description No Value equipmentScheduleIdRef No Value Name No Value peopleScheduleIdRef No Value R-value No Value conditionType No Value Thickness No Value No Value Conductivity No Value No Value Density No Value BeginDate No Value SpecificHeat No Value EndDate No Value Description No Value weekScheduleIdRef No Value LightPowerPerArea No Value Name No Value EquipPowerPerArea No Value DesignHeatT No Value Has Value DesignCoolT No Value Has Value Has Value 43% 0% 0% 100% Total 28% Program id Name Level Form Zone Schedule Space campus Location Station ID Area & Volume People Number People Heat Gain buildingType Infiltration Window Construction Equip. Material Fabric Completeness score Program Fabric Equipment Form 1 121 Figure F.2: Generated report from DTT reporting function of a 49% model. Data Transperancy Tool - Data Completness Report 3/18/2015 Has Value No Value Has Value id Has Value Has Value U-value No Value Longitude Has Value SHGC No Value Latitude Has Value solarIncidentAngle No Value Elevation Has Value Transmittance No Value Has Value Type No Value Total Area Has Value U-value No Value Level Area Has Value Absorptance No Value Level Volume Has Value type Has Value spaceType Has Value Name Has Value lightScheduleIdRef No Value Description No Value equipmentScheduleIdRef No Value Name Has Value peopleScheduleIdRef No Value R-value Has Value conditionType Has Value Thickness Has Value No Value Conductivity No Value No Value Density No Value BeginDate No Value SpecificHeat No Value EndDate No Value Description No Value weekScheduleIdRef No Value LightPowerPerArea No Value Name No Value EquipPowerPerArea No Value DesignHeatT Has Value Has Value DesignCoolT Has Value Has Value Has Value 61% 32% 0% 100% Total 49% Program id Name Level Form Zone Schedule Space campus Location Station ID Area & Volume People Number People Heat Gain buildingType Infiltration Window Construction Equip. Material Fabric Completeness score Program Fabric Equipment Form 1 122 Figure F.3: Generated report from DTT reporting function of a 96% model. Data Transperancy Tool - Data Completness Report 3/18/2015 Has Value Has Value Has Value id Has Value Has Value U-value Has Value Longitude Has Value SHGC Has Value Latitude Has Value solarIncidentAngle Has Value Elevation Has Value Transmittance Has Value Has Value Type Has Value Total Area Has Value U-value Has Value Level Area Has Value Absorptance Has Value Level Volume Has Value type Has Value spaceType Has Value Name Has Value lightScheduleIdRef Has Value Description No Value equipmentScheduleIdRef Has Value Name Has Value peopleScheduleIdRef Has Value R-value Has Value conditionType Has Value Thickness Has Value Has Value Conductivity Has Value Has Value Density Has Value BeginDate Has Value SpecificHeat Has Value EndDate Has Value Description No Value weekScheduleIdRef Has Value LightPowerPerArea Has Value Name Has Value EquipPowerPerArea Has Value DesignHeatT Has Value Has Value DesignCoolT Has Value Has Value Has Value 100% 89% 100% 100% Total 96% Program id Name Level Form Zone Schedule Space campus Location Station ID Area & Volume People Number People Heat Gain buildingType Infiltration Window Construction Equip. Material Fabric Completeness score Program Fabric Equipment Form 1

Asset Metadata

Creator Hijazi, Mohammed Omar (author)

Core Title Bridging the gap: a tool to support bim data transparency for interoperability with building energy performance software

Contributor Electronically uploaded by the author (provenance)

School School of Architecture

Degree Master of Building Science

Degree Program Building Science

Publication Date 04/17/2015

Defense Date 03/23/2015

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag BEM,BIM,building energy modeling,building information modeling,data exchange,gbXML,IFC,interoperability,OAI-PMH Harvest

Format application/pdf (imt)

Language English

Advisor Kensek, Karen M. (committee chair), Konis, Kyle (committee member), Noble, Douglas (committee member)

Creator Email hijazi@usc.edu,mohammad.o.hijazi@gmail.com

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c3-551289

Unique identifier UC11297702

Identifier etd-HijaziMoha-3319.pdf (filename),usctheses-c3-551289 (legacy record id)

Legacy Identifier etd-HijaziMoha-3319.pdf

Dmrecord 551289

Document Type Thesis

Format application/pdf (imt)

Rights Hijazi, Mohammed Omar

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA

Abstract (if available)

Abstract Many gaps exist between (BIM) authoring software and Building Energy Modeling (BEM) tools. One gap is due to loss of data in the exchange between the design and energy simulation models. Energy efficiency is now, more than ever, a top concern that should be addressed in the earliest of the design stages. Explaining, understanding, and enhancing the data transfer between software would allow better design decisions through more accurate coordination between energy simulation and building modeling. ❧ The data exchange is done mainly using either Green Building XML (gbXML) or Industry Foundation Classes (IFC). Both offer geometrical and thermal data transfers