Ref. Ares(2019)5483631 - 30/08/2019

Project Acronym: BIMERR Project Full Title: BIM-based holistic tools for Energy-driven Renovation of existing Residences Grant Agreement: 820621 Project Duration: 42 months

DELIVERABLE D3.2 Survey of data models, ontologies and standards in the wider Energy Efficient Buildings domain

Deliverable Status: Final File Name: D3.2. Survey of data models ontologies and standards v1.0.docx Due Date: 31/08/2019 (M8) Submission Date: 30/08/2019 (M8) Task Leader: UPM (T3.2)

Dissemination level Public X Confidential, only for members of the Consortium (including the Commission Services)

This project has received funding from the European Union’s Horizon 2020 Research and innovation programme under Grant Agreement n°820621

The BIMERR project consortium is composed of: Fraunhofer Gesellschaft Zur Foerderung Der Angewandten Forschung FIT Germany E.V. CERTH Ethniko Kentro Erevnas Kai Technologikis Anaptyxis Greece UPM Universidad Politecnica De Madrid Spain UBITECH Ubitech Limited Cyprus SUITE5 Suite5 Data Intelligence Solutions Limited Cyprus Hypertech (Chaipertek) Anonymos Viomichaniki Emporiki Etaireia HYPERTECH Greece Pliroforikis Kai Neon Technologion MERIT Merit Consulting House Sprl Belgium XYLEM Xylem Science And Technology Management Gmbh Austria GU Glassup Srl Anonymos Etaireia Kataskevon Technikon Ergon, Emporikon CONKAT Greece Viomichanikonkai Nautiliakon Epicheiriseon Kon'kat BOC Boc Asset Management Gmbh Austria BX Budimex Sa Poland UOP University Of Peloponnese Greece EXE Exergy Ltd United Kingdom HWU Heriot-Watt University United Kingdom NT Novitech As Slovakia FER Ferrovial Agroman S.A Spain

Disclaimer BIMERR project has received funding from the European Union’s Horizon 2020 Research and innovation programme under Grant Agreement n°820621. The sole responsibility for the content of this publication lies with the authors. It does not necessarily reflect the opinion of the European Commission (EC). EC is not liable for any use that may be made of the information contained therein.

Deliverable D3.2n 08/2019 n UPM Page 2 of 96 BIMERR project n GA #820621

AUTHORS LIST Leading Author (Editor)

Surname First Name Beneficiary Contact email

Poveda-Villalón María UPM [email protected]

Co-authors (in alphabetic order) # Surname First Name Beneficiary Contact email

1 Biliri Evmorfia SUITE5 [email protected]

2 Bosché Fédéric UOE [email protected] [email protected] 3 Elmasllari Erion FIT .de 4 Fenz Stefan XYLEM [email protected]

5 García-Castro Raúl UPM [email protected]

6 Giannakis Giorgos HYPERTECH [email protected]

th.kakardakos@meritconsultin 7 Kakardakos Theodoros MERIT ghouse.eu

8 Katsifaraki Angelina HYPERTECH [email protected]

9 Kyprianidis Alexandros CERTH [email protected]

neubauer@xylem- 10 Neubauer Thomas XYLEM technologies.com

11 Ntalaperas Dimitrios UBITECH [email protected]

12 Papapolyzos Thomas HYPERTECH [email protected]

13 Parn Erika EXE [email protected]

e.rontogianni@meritconsulting 14 Rontogianni Evi MERIT house.eu

[email protected] 15 Tavakolizadeh Farshid FIT nhofer.de 16 Tiwari Sanju UPM [email protected]

17 Tsakiris Thanos CERTH [email protected]

18 Valero Enrique UOE [email protected] 19 Vergeti Danai UBITECH [email protected]

REVIEWERS LIST List of Reviewers (in alphabetic order) # Surname First Name Beneficiary Contact email 1 Hanel Tobias FER [email protected]

2 Walch Michael BOC [email protected] Deliverable D3.2n 08/2019 n UPM Page 3 of 96 BIMERR project n GA #820621

REVISION CONTROL Version Author Date Status

0.01 UPM 13 February 2019 Table of content 0.02 UPM, MERIT, CERTH, FIT, HYPERTECH, 23 July 2019 First integrated version SUITE5, UBITECH, UOE, EXERGY, from section 2 to 9. XYLEM 0.03 UPM 11 July 2019 Included sections 1, 10 and executive summary

0.04 UPM 19 July 2019 First complete and integrated version ready for editorial review

0.05 UPM, MERIT, CERTH, FIT, HYPERTECH, 31 July 2019 Initial Version after SUITE5, UBITECH, UOE, EXERGY, editorial comments XYLEM

0.06 UPM 7 August 2019 Quality Check

0.07 BOC, FER 21 August 2019 Final Draft reviewed

0.08 UPM 28 August 2019 Incorporated feedback from Reviewers 1.0 FIT 30 August 2019 Submission to the EC

Deliverable D3.2n 08/2019 n UPM Page 4 of 96 BIMERR project n GA #820621

TABLE OF CONTENTS

List of Figures ...... 7 List of Tables ...... 9 Executive summary ...... 11 1. Introduction ...... 12 2. Relevant information domains ...... 14 2.1 Building ...... 14 2.2 Materials ...... 16 2.3 Energy consumption ...... 16 2.4 Usage patterns and habits ...... 17 2.5 Weather ...... 17 2.6 Reality capture ...... 18 2.7 GIS ...... 18 3. Analysis of the building domain ...... 19 3.1 Relevant data models ...... 19 3.1.1 buildingSMART ...... 19 3.1.2 COBie ...... 26 3.1.3 CityGML ...... 29 3.1.4 BO-IDM ...... 31 3.1.5 BISDM ...... 33 3.1.6 GBXML ...... 36 3.2 Relevant ontologies ...... 39 3.2.1 ETSI SAREF ontology and its extensions ...... 39 3.2.2 oneM2M base ontology ...... 41 3.2.3 W3C SSN ontology ...... 43 3.2.4 W3C BOT ontology ...... 45 3.2.5 ifcOWL ...... 46 3.2.6 GML3 ...... 47 3.3 Relevant standardization initiatives ...... 48 3.3.1 buildingSMART Working Group ...... 48 3.3.2 ETSI SmartM2M ...... 48 3.3.3 W3C Linked Building Data Community Group ...... 49 3.3.4 buildingSMART ...... 49 3.3.5 ISO/Technical Committee 59/Subcommittee 13 ...... 51 3.3.6 ISO TC211 (GML3) ...... 52 3.3.7 NBIMS (COBie) ...... 53 4. Analysis of the materials domain ...... 55 4.1 Relevant data models ...... 55 4.1.1 Baubook.info database ...... 55 4.1.2 Eurobau.com database ...... 56 4.1.3 Oekobaudat.de database ...... 57 4.1.4 GaBi database ...... 57 4.2 Relevant ontologies ...... 57 4.2.1 Freeclass.eu ontology ...... 57 Deliverable D3.2n 08/2019 n UPM Page 5 of 96 BIMERR project n GA #820621

4.3 Relevant standardization initiatives ...... 58 4.3.1 S.R. CWA 16762:2014 - CEN Workshop Agreement ...... 58 5. Analysis of the energy consumption domain ...... 61 5.1 Relevant data models ...... 61 5.2 Relevant ontologies ...... 62 5.3 Relevant standardization initiatives ...... 63 6. Analysis of the usage patterns and habits domain ...... 65 6.1 Relevant data models ...... 65 6.1.1 Simulation Program Oriented Data Models ...... 66 6.1.2 Open-source Common Data Models ...... 67 6.2 Relevant ontologies ...... 71 6.2.1 E+OWL ...... 71 6.2.2 SimModel OWL ...... 71 6.3 Relevant standardization initiatives ...... 71 6.3.1 IEA – EBC Annex 66 – Definition and simulation of occupant Behavior in Buildings ...... 72 6.3.2 IEA – EBC Annex 79 – Occupant-Centric Building Design and Operation ...... 72 7. Analysis of the weather domain ...... 74 7.1 Relevant data models ...... 74 7.2 Relevant ontologies ...... 75 8. Analysis of the reality capture domain ...... 77 8.1 Relevant data models ...... 77 8.1.1 Basic data formats ...... 77 8.1.2 Enriched data formats ...... 78 8.2 Relevant ontologies ...... 80 8.2.1 Point cloud schema extension for the IFC model ...... 80 8.3 Relevant standardization initiatives ...... 82 8.3.1 ASTM E57 ...... 82 9. Analysis of the geographical domain ...... 83 9.1 Relevant data models ...... 83 9.1.1 Vector data model...... 83 9.1.2 Raster data model ...... 84 9.2 Relevant ontologies ...... 86 9.2.1 Geonames ...... 86 9.2.2 Geopolitical Ontology ...... 87 9.3 Relevant standardization initiatives ...... 87 9.3.1 ISO 6709 ...... 87 9.3.2 ISO 3166 ...... 87 9.3.3 Geonames ...... 88 10. Conclusions ...... 89 11. References ...... 92

Deliverable D3.2n 08/2019 n UPM Page 6 of 96 BIMERR project n GA #820621

LIST OF FIGURES Figure 1: Data model standards promoted by buildingSMART ...... 20 Figure 2. View of the IniClass 2015 table “System” ...... 22 Figure 3. View of the OmniClass table “Spaces by Function” ...... 22 Figure 4. IDM support for business process. a) IFC supporting all business requirements at all project stages and b) IDM supporting a business requirement at a project stage ...... 23 Figure 5. Conceptualisation of IFC and MVD Data Exchange in a Renovation Project (developed by E.Parn) ...... 25 Figure 6. COBie Schema (extracted from [Sabbagh, 2019]) ...... 27 Figure 7. COBie spreadsheet screeshot-1 ...... 28 Figure 8. CityGML Building Model ...... 31 Figure 9. BO-IDM object model [Isikdag et. al., 2013] ...... 32 Figure 10. BO-IDM visualization of two different building transformed from IFC model, within GIS software [Isikdag et. al., 2013] ...... 33 Figure 11. Relationships between BISDM, SDI and BIM data elements [extract from [Casazza, 2010]] ...... 34 Figure 12. Proposed BISDM Assets class names ...... 35 Figure 13. gbXML-Building Element ...... 38 Figure 14. The Current and envisioned modules of the SAREF ontology ...... 39 Figure 15. General overview of the SAREF ontology...... 41 Figure 16. OneM2M Base Ontology graphical overview. (Figure extracted from [oneM2M, 2018]) ...... 43 Figure 17. Overview of the core structure of the SSN ontology. (Figure extracted from [Haller et. al., 2018]) ...... 45 Figure 18. Classes and relationships involved in Zones. Image taken from https://w3c- lbd-cg.github.io/lbd/bot/ ...... 46 Figure 19. buildingSMART Basic Standard31 ...... 49 Figure 20. UML diagram of the Core 2D profile of INSPIRE Building Model ...... 53 Figure 21. baubook.info – reference values (example) ...... 56 Figure 22. Information included in the written specification ...... 59 Figure 23. Data models of Occupant Behaviour modelling for BEPE purposes ...... 65 Figure 24. Example of EMS classes’ instances in epJSON, used to override values of the cooling setpoint at each timestep ...... 66 Figure 25. gbXML´s XSD diagram of Equation class that could be used for simplified equation-based OB modelling ...... 68 Figure 26. XSD diagram of the main obXML´s topology for OB action´s modelling ...... 69 Figure 27. Express-G diagram of the IfcTimeSeries class for schedule-based OB modelling ...... 70 Figure 28. Sample response from OpenWeather (information clipped for visibility) ...... 75 Figure 29. WeatherOntology Class Diagram (Classes are not fully expanded for clarity) 76 Figure 30. Data structure for basic data formats ...... 77 Figure 31. Data structure for PLY data format ...... 78 Figure 32. Structure of a PTX file ...... 79

Deliverable D3.2n 08/2019 n UPM Page 7 of 96 BIMERR project n GA #820621

Figure 33. Structure of an E57 file. (a) File sections. (b) Hierarchical structure of the stored data ...... 80 Figure 34. EXPRESS-G diagram of the DURAARK schema extension [Beetz, 2015] ...... 81 Figure 35. EXPRESS-G diagram of the DURAARK proposed schema extension for attribute vector elements [Beetz, 2015] ...... 82 Figure 36. Sample representation of a river in vector data model ...... 84 Figure 37. Sample representation of a river in raster data model ...... 85 Figure 38. Class diagram depicting the main Entities of Geonames and their relation to entities from SKOS and FOAF ...... 86

Deliverable D3.2n 08/2019 n UPM Page 8 of 96 BIMERR project n GA #820621

LIST OF TABLES

Table 1: Characteristics of COBie ...... 26 Table 2: Characterstics of BO-IDM ...... 31 Table 3: Characteristics of BISDM ...... 33 Table 4: List of BIMERR relevant buildingSMART standard ...... 51 Table 5: Domain Coverage existing data model, ontologies and standardization initiatives ...... 89

Deliverable D3.2n 08/2019 n UPM Page 9 of 96 BIMERR project n GA #820621

ACRONYMS

Acronym Meaning AEC Automation Engineering Construction BEPE Building Energy Performance Estimation BIF BIMERR Interoperability Framework epJSON EnergyPlus JSON FM Facilities Management gbXML Green Building XML GIS Geographical Information System HVAC Heating, Ventilating and Air Condition IDD Input Data Dictionary IDF Input Data File IFC Industry Foundation Classes ISO International Organization for Standardization JSON JavaScript Object Notation MEP Mechanical, Electrical, and Plumbing OB Occupant Behaviour OWL obXML Occupant Behaviour XML PRUBS Profiling Resident Usage of Building System simXML SimModel XML XML eXtensible Markup Language XSD XML Schema Definition

Deliverable D3.2n 08/2019 n UPM Page 10 of 96 BIMERR project n GA #820621

EXECUTIVE SUMMARY

This deliverable presents a survey on existing data models, ontologies and standardization initiatives related to the domains involved in the BIMERR Interoperability Framework (BIF). More precisely these domains are: building (including structure and components), materials, energy consumption, usage patterns and habits, weather, reality capture and GIS. In total 31 data models, 15 ontologies and 14 standardization initiatives have been taken into account along the document.

This first analysis aims at providing an overview of existing resources to be reuse during the BIF development as well as the gaps regarding ontologies to be reused. In addition, this study aims at identifying non-ontological resources to be transformed into semantic models. It has been observed that in general there already exist ontologies related to the proposed domains while it should be further analyzed to what extent these ontologies could be reused once the specific BIMERR ontological requirements are defined.

A more in-depth analysis will be carried out taking as input this deliverable during T4.1 in which the specific coverage of the resources will be studied in order to understand whether they are only related to a given domain or they actually cover BIMERR needs in such domain. Such analysis together with the BIMERR architecture will drive the ontology requirements specification activity and its further development.

Deliverable D3.2n 08/2019 n UPM Page 11 of 96 BIMERR project n GA #820621

1. INTRODUCTION

Projects in construction and building renovation typically need collaboration and information exchange among different actors (for example clients, architects, engineers, etc.) and systems. During the projects many tools and systems for different phases, are normally provided by different vendors and typically address a subset of the BIM model to accomplish their individual objectives. As consequence, data sharing in BIM becomes a complex process in which interoperability plays a critical role. There is more than one definition of interoperability in literature, however they agree on a common point that is the ability of two or more systems to exchange information and operate with it. Interoperability could be applied to different levels in information systems, namely, technical interoperability, syntactic interoperability and semantic interoperability. Technical interoperability addresses the problems related to the hardware and software elements involved in the communications protocol, infrastructures and physical components to exchange data. Syntactic interoperability focuses on the exchange data formats between systems. Finally, semantic interoperability aims at providing successful exchange and processing of meaningful information in addition to raw data.

As identified in BIMERR challenges, there is a need for holistic ICT ecosystems that provide end-to-end support of building renovation for energy efficiency based on seamless, interoperable and standards-based information exchange. In order to achieve this, the BIMERR solution lies in the creation of a set of tools and digital models to aid the renovation process. To address the interoperability goal, such tools will be supported by the BIMERR Interoperability Framework (BIF) whose goal is to understand, correlate the semantics of the various domain specific data models through ontological linking.

For doing so, the different ontologies, data models and standardization initiatives in the domains involved in the BIMERR use cases are surveyed along this document. It is worth noting that the term “ontology” refers to a “formal, explicit specification of a shared conceptualization” [Studer et. al., 1998] which is implemented in an ontology implementation language, for example OWL1, the Web Ontology Language. Even though new specific domains might arise during the project development, at this incipient stage

1 https://www.w3.org/TR/owl-ref/ Deliverable D3.2n 08/2019 n UPM Page 12 of 96 BIMERR project n GA #820621

of the process the foreseen domains that are expected to be involved in the semantic modelling are: building (including structure and components), materials, energy consumption, usage patterns and habits, weather, reality capture and GIS. This deliverable provides an overview of the current state of the ontologies, data models and standardization initiatives for each of the above-mentioned domains. The deliverable is structured as follows:

• Section 2 presents the domains being analysed in this deliverable and provides contextual information about their relation with BIMERR. • Section 3 presents relevant data models, ontologies and standardization initiatives for the building domain. • Section 4 presents relevant data models, ontologies and standardization initiatives for the materials domain. • Section 5 presents relevant data models, ontologies and standardization initiatives for the energy consumption domain. • Section 6 presents relevant data models, ontologies and standardization initiatives for the usage patterns and habits domain. • Section 7 presents relevant data models and ontologies for the weather domain. • Section 8 presents relevant data models, ontologies and standardization initiatives for the reality capture domain. • Section 9 presents relevant data models, ontologies and standardization initiatives for the geographical domain. • Section 10 reports on the current situation of the existing resources for each domain and draws the conclusions and future steps for the BIMERR semantic framework.

Deliverable D3.2n 08/2019 n UPM Page 13 of 96 BIMERR project n GA #820621

2. RELEVANT INFORMATION DOMAINS

This section provides an overview of the domains foreseen to be involved in the BIF context including definitions, background information and the relation with the BIF. More precesily this section introduces the following domains: building (including structure and components), materials, energy consumption, usage patterns and habits, weather, reality capture and GIS.

2.1 BUILDING

During the last two decades, the Architecture Engineering and Construction (AEC) industry is evolving with the incorporation of various computer technologies enabling modelling of whole buildings/assets along with their components (structural and non- structural), providing the involved AEC stakeholders with a shared resource of information which can form a reliable basis for decisions and actions throughout a project’s lifecycle. The traditional paper-based information (e.g. drawings, specifications, etc.) collection and management is currently shifting to electronic documents, file-based drawings, and digital data recording and is driven towards the creation and utilisation of data rich n-dimensional digital models of buildings. Adoption of emerging technologies such as Building Information Modelling (BIM) is triggering a digital transformation of the global AEC industry; BIMs are becoming the official standard in the construction industry for encoding, reusing, and exchanging information about structural assets [Pătrăuceana et.al, 2015].

BIM can deliver a project with increased efficiency, enhanced coordination and improved outcomes even from the early stage of its lifecycle. Among its various capabilities, BIM enables users to exploit a virtual representation of a building/asset through the development of an accurate n-dimensional model and simulate the planning, design, construction and operation of the specific building/asset. BIM provides users with the means to assess different design simulations based on the selection of correct materials identifying the most appropriate energy strategy and systems from the initial stages of the design that can have great effect on the entire building life cycle; avoiding the laborious process of re-entering all the building geometry and other supporting information necessary to complete an energy analysis.

Deliverable D3.2n 08/2019 n UPM Page 14 of 96 BIMERR project n GA #820621

Automation of several tasks, such as the example mentioned above, enables a single virtual information model to be handled by different disciplines; thus enhancing productive collaborations and changing the way the different parties (designers, engineers, contractors, managers and also clients) interact with each other, from the early conceptual design to on-site works and post-construction building operation.

In this context, ISO 6707-1:20172 defines Building, “as construction works that have the provision of shelter for its occupants or contents as one of its main purposes, usually partially or totally enclosed and designed to stand permanently in one place”, i.e. the activities of forming a building structure.

Building’s components are further defined as the products manufactured as distinct units to serve a specific function/s and act as major functional parts of the construction of a building (i.e. the building’s structural and space separating system). These are for example the foundations, floors, roof, walls, beams, columns, doors, as well as services and installations (e.g.: water supply, electricity supply, drainage, services cupboards’, etc.) which form part of the building structure.

Considering the above definitions, a building along with its components can be seen as a ‘system of systems’ made of independent but interacting systems: the architectural, the structural, the mechanical and the electrical system [Matar et. al., 2017]. Although, these systems operate independently, during the building’s lifecycle they interact with each other to support the required functions of its occupants/users.

Within the scope of BIMERR and in relation to the renovation design selection of a building, BIM enables geometric alignment of these different systems enabling a thorough model analysis and collision control among its components. Incorporating also the physical parameters of the building’s elements (structural and nonstructural), BIM enables manipulation of the building model, which can be exported in different analysis applications and used in digital simulations for estimating energy consumption and efficiency. In addition, use of BIM and its available tools supports the communication among the involved stakeholders enhancing collaborative work based on a shared coordinated model, which can be used as the basis to form decisions for a fit for

2 ISO 6707-1:2017 “Buildings and civil engineering works” -Vocabulary - Part 1: General terms. Retrieved from: https://www.iso.org/standard/72244.html (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 15 of 96 BIMERR project n GA #820621

purpose renovation scenario selection. In BIMERR, all the necessary data exchanges to achieve semantic interoperability in the building industry can be managed via appropriate standardized open BIM and GIS data models.

2.2 MATERIALS

Materials are an integral part of the Architecture, Engineering and Construction (AEC) industry. They are used in many parts of the process of building and renovating and are distinguished by their properties in building and insulation materials. Energy consumption of a building varies over its life cycle and much of the consumption depends on the choice of materials used. Therefore, it is clear that the materials determine the energy efficiency of the construction. They are also an important parameter of the cost required for construction because of their price or availability in the area of interest.

In the context of BIMERR, the study on the selection of the materials to be used is necessary. Using the appropriate materials can lead to improvement in the energy performance of buildings. Moreover, the knowledge of the materials used is deemed important for the successful prediction of the investments required by a project. It is also important for the prediction of the energy cost of the building after renovation and for exploiting emerging opportunities in recycling materials at the end of the building's functionality lifetime.

2.3 ENERGY CONSUMPTION

BIMERR has it as part of its mission to improve building renovations under an energy- efficiency lens. To that effect, it is necessary to be familiar with all facets of energy provision and consumption in buildings. However, the provision of energy rarely affects a renovation so deeply as does the consumption -- or rather, the need to limit consumption. Better placement of living areas, better isolation and building materials, better planning of windows and air conditioning, or better designing the ambient outside a building to invite people to spend more time outside -- all of these renovation activities carry a large weight towards lowering energy consumption. On the other hand, you can't optimize what you can't describe -- highlighting the need to be able to examine and describe the residents' behavior and existing consumption patterns. The ontologies,

Deliverable D3.2n 08/2019 n UPM Page 16 of 96 BIMERR project n GA #820621

standards, and data models presented in this section enable BIMERR to measure and describe behavior, constraints, and their effect on the energy consumption of a building.

2.4 USAGE PATTERNS AND HABITS

It has been shown in various research works that energy consumption demonstrates patterns linked to the habitual behaviors that the occupants of a building develop over time. These behaviors reflect the occupants’ profile and every-day activities and demonstrate the usage of the building. Therefore, an understanding of the occupant behavior is a key factor for the effective building design and retrofit. Understanding the occupancy and usage patterns within a building’s context allows the accurate estimation of the energy usage patterns, offering an insight to major energy consuming activities and future energy requirements of the building. Therefore, the human factor should not be overlooked during the design, construction, operation and retrofitting of buildings.

Within the scope of BIMERR, the analysis of energy-related usage patterns and correlation with building and process models can offer an opportunity to not only improve the energy efficiency of buildings but to also run diagnostics, revealing undiscovered information about the building processes and envelop. Thus, underlying issues can be addressed during the renovation or retrofitting interventions and projections about the future energy usage of the building can be provided.

2.5 WEATHER

The weather domain refers to all weather information that can be available for a location. In temporal terms, this includes historical and current data, as well as forecasts. The data that a typical weather forecast provides contains a multitude of information concerning temperature, precipitation, wind, humidity etc.

Weather information, regarding both current state and forecasts, can be very helpful in optimizing strategies in smart housing. Energy consumption for example, can depend upon the weather. Utilizing weather information involves both the construction of suitable representation models as well as the utilization of services, which can reliably be used to obtain current and future information. In addition, weather conditions also have an important impact on the renovation construction works, for example helping to plan the works in a better way, thus reducing time and costs.

Deliverable D3.2n 08/2019 n UPM Page 17 of 96 BIMERR project n GA #820621

2.6 REALITY CAPTURE

Reality capture is the process of collecting information from the environment in its current state. This information may relate to perceivable parameters such as geometry or colour, or it can measure more complex properties like reflectance or temperature. Examples of technologies that play an important role in reality capture operations are cameras (in both visible and infrared spectrums) and laser scanners (static or mobile).

In the Architecture, Engineering and Construction (AEC) industry, reality capture technology is widely employed by surveyors for supporting documentation, quantity surveying, quality control and progress monitoring amongst other operations. With respect to the BIMERR project, reality capture is crucial for building information collection and enrichment, more precisely for acquiring ‘as-is’ information of the built environment that is then used for the generation of Building Information Modelling (BIM) models, a process commonly referred to as: Scan-to-BIM.

2.7 GIS

Geolocation coding allows the encoding of location in an unambiguous way. GIS services can treat the location either as a point in two-dimensional grid, in which case only latitude and longitude are considered, or include elevation information as well. Apart from location, a typical GIS service will provide additional information depending on the context and the needs it was designed to fulfil. This extra information may range from data concerning near points of interest (such distance from emergency facilities, from nearest transport stations etc.) to administrative details (population data) and so on.

In a typical scenario, GIS services are used by querying around a point of origin and retrieving information around a radius centered around this point.

Deliverable D3.2n 08/2019 n UPM Page 18 of 96 BIMERR project n GA #820621

3. ANALYSIS OF THE BUILDING DOMAIN

This section reviews relevant data models, ontologies and standardization initiatives for the building domain.

3.1 RELEVANT DATA MODELS

This section review building data models as the ones defined and promoted by buildingSMART, COBie, cityGML, BO-IDM, BISDM and GBXML.

3.1.1 buildingSMART

BuildingSMART (formerly International Alliance for Interoperability, IAI) is the leading international organisation on exchange of information between software in the Architecture, Engineering and Construction (AEC) industry. Since 1994, they have been developing open data models that are collectively referred to as the OpenBIM standards [Bazjanac, 1997].

The first column of Figure 1 represents how Building Information Modelling (BIM) data management is influenced by five capital concepts: data meaning, data format, data process, data requirement and data change. buildingSMART has developed open data models for all those five concepts (second column), and three of those data models are already ISO standards [buildingSMART, 2014]:

• International Framework for Dictionaries (IFD) (ISO 12006-3) • Industry Foundation Classes (IFC) (ISO 16739) • Information Delivery Manual (IDM) (ISO 29481)

We detail these and other existing data models for all five concepts in the following sub- sections.

Deliverable D3.2n 08/2019 n UPM Page 19 of 96 BIMERR project n GA #820621

Figure 1: Data model standards promoted by buildingSMART

While buildingSMART IFCs are advocated as a software vendor neutral solution to interoperability led data leakage, issues pertaining to data transference doggedly persist in the built environment [Cheng et al., 2016]. Advancements have since been made with interoperability issues in a number of asset data transference formats, namely: IFC schema specifications; COBie; i-models-; IFC readers; and initiatives such as the OpenInfra Platform [Singer and Borrmann, 2015]. [Kang and Choi, 2015] argue however, that COBie and IFC entail multiple limitations, including: additional expenses incurred; maintenance required; and advanced import/export functions - required by stakeholders to integrate asset data into shareable format.

3.1.1.1 DATA FORMAT: ISO 16739 (IFC)

As a consequence of the important number of technologies and processes involved in the lifecycle of buildings, different software packages with their own proprietary formats are used by partners. This variety of proprietary formats results in inadequate interoperability, increasing associated costs, mainly during the operations and maintenance phase [Chapman, 2005].

In the late 90s, buildSMART introduced the Industry Foundation Classes (IFC) as an open BIM standard that facilitates the exchange of data between software applications in a collaborative environment in the AEC/FM sector. IFC was proposed to various data (physical objects, people, programmes, etc.) and produced by various disciplines (e.g.

Deliverable D3.2n 08/2019 n UPM Page 20 of 96 BIMERR project n GA #820621

MEP, HVAC, structures…), over the entire lifecycle of construction assets. Regarding the storage of information about building components, note that the data model is able to record geometric information and a number of component properties. However, parametric relationships between components is still a limitation.

Currently, the data schema for IFC is regulated by the standard ISO 16739-1:2018 [ISO, 2018], which is defined in:

• EXPRESS data specification language, defined in ISO 10303-11; • XML Schema definition language (XSD), defined in XML Schema W3C Recommendation, where the EXPRESS schema definition is the source and the XML schema definition is generated from the EXPRESS schema according to the mapping rules defined in ISO 10303-28. The exchange file formats for exchanging and sharing data according to the conceptual schema are: • Clear text encoding of the exchange structure, defined in ISO 10303-21, • Extensible Markup Language (XML), defined in XML W3C Recommendation.

3.1.1.2 DATA MEANING (DICTIONARY AND CLASSIFICATION): ISO 12006 (IFD)

The standard ISO 12006 relates to the organisation of information in construction works. It is divided in two parts, which are devoted to the dictionary and classification of terms and attributes, as well as the relationships between them, for building components.

ISO 12006-2 “defines a framework for classification systems in the construction field” [ISO, 2007]. This standard, which applies to the entire lifecycle of buildings, proposes a variety of examples of tables organising vocabulary and attributes for building components.

As detailed in the following, various strategies have been recently presented towards the classification of construction elements at different levels (i.e. asset>assembly>component).

• Backed by the Royal Institute of British Architects (RIBA), the National Building Specification (NBS) proposed a new classification system – Uniclass 2015-, that consists in a hierarchical suite of tables (e.g. entities > elements > systems >

Deliverable D3.2n 08/2019 n UPM Page 21 of 96 BIMERR project n GA #820621

products) that support classification of all ‘things’, from a university campus or road network to a floor tile or kerb unit [Delany, 2015]. As shown in Figure 2 every element is labelled with a unique identification (UID) code.

Figure 2. View of the IniClass 2015 table “System”

• In North America, the Construction Specification Institute (CSI) and the Construction Specifications Canada promulgated, in 2006, OnmiClass [OCCS, 2017], based on previous tables such as MasterFormat and UniFormat. The proposed 15 tables (see example in Figure 3) cover several aspects of building elements, processes and actors.

Figure 3. View of the OmniClass table “Spaces by Function”

In ISO 12006-3, an object-oriented strategy is presented to establish libraries of objects, their attributes and relationships. More precisely, ISO 12006-3 specifies a “language independent information model that can be used for the development of dictionaries used to store or provide information about construction works” [ISO, 2007b]. Deliverable D3.2n 08/2019 n UPM Page 22 of 96 BIMERR project n GA #820621

• The buildingSMART Data Dictionary (bSDD) is an ISO 12006-3 based ontology (objects, their attributes and relationships) for objects in the built environment. It delivers a common framework of objects that can be organised in classification systems and models. It is important to recognise that bSDD is not itself a classification system.

3.1.1.3 DATA PROCESS: ISO 29481 (IDM)

Whereas previous standards, IFD and IFC, establish how information is organised in BIM models and exchanged among partners, Information Delivery Manual (IDM) is linked to mapping the flow of that information over time.

According to buildingSMART [Wix, 2010], IDM provides a reference to information requirements, identifying the different processes and the information required and specifying: where those processes fit, who are the actors involved, what is the information produced and exchanged and how software solutions will deal with that information. As illustrated in Figure 4, IDM aims to provide only the required information, with certain level of detail, at a particular stage of the project. With reference to the BS1192-2 standard, now becoming ISO 19650-2, IDM provides a standard means to define and exchange Model information flows developed in the Master Information Delivery Plan (MIDP) and constituting Task Information Delivery Plans (TIDPs).

a) b)

Figure 4. IDM support for business process. a) IFC supporting all business requirements at all project stages and b) IDM supporting a business requirement at a project stage

Deliverable D3.2n 08/2019 n UPM Page 23 of 96 BIMERR project n GA #820621

Information delivery manuals are regulated by means of the standard ISO 29481, which is presented in two parts. Part 1 [ISO, 2016] defines the methodology linking the construction processes with the specification of information required by those processes and details a strategy to map and describe the information processes during the lifecycle of buildings. On the other hand, Part 2 [ISO, 2016b] determines a methodology and format for describing coordination between actors, defining: an interaction framework; an appropriate way to map responsibilities and interactions, providing a process context for information flow; and a format in which the mentioned interaction framework should be specified.

3.1.1.4 MVD

A Model View Definition (MVD) defines a sub-set of IFC model file specifications akin to the published ISO29481-1:2016 that was used to map information processes across an asset’s entire life cycle stages. Central to MVD is the end user value chain driven approach, used to ensure that IFC implementation supports bespoke user requirements via tailored views of the semantic and geometric information (i.e. coordination view, asset information view and design view) [Hietanen, 2006]. These MVDs are representations of the specification based upon the demand and supply nature of information i.e. end user specific model views such as IFC and handover MVD (ibid.).

IFC data schema consists of four key constituents: entities, classes, instances and properties. Classes can be defined as a collection of entities –representing a single object (i.e. fencing), with a set of instances (such as variation of an object (i.e. vegetation fencing)). A class can therefore be characterised by a set of instances that define its properties (i.e. a set of attributes (i.e. fencing ID, fencing length)) [Ebrahimipour and Yacout, 2015]. MVD can be developed by tailoring the purposeful IFC structure based on its entities, classes, instances and properties [Hietanen, 2006].

MVD has been argued to overcome three major challenges confronting building information management, namely: i) data interoperability; ii) data leakages; and iii) lack of specialized structured IFC and MVD. Figure 5 presents a conceptual illustration of these three aforementioned challenges and the usefulness of MVD in relation to data leakage that occurs throughout a project lifecycle largely due to inappropriate data structures and interoperability challenges. These challenges can be mitigated if MVDs

Deliverable D3.2n 08/2019 n UPM Page 24 of 96 BIMERR project n GA #820621

are applied with IFC file exports throughout the project’s lifecycle stages iteratively when sharing model data iteratively.

Figure 5. Conceptualisation of IFC and MVD Data Exchange in a Renovation Project (developed by E.Parn)

3.1.1.5 BCF (EXERGY)

BIM Collaboration Format (BCF) also coined as the ‘little brother’ of IFC file format is an alternative means for building data file exchange for collaboration purposes. BIM Collab defines BCF as: “an open file format that allows the addition of textual comments, screenshots and more on top of the IFC model layer for better communication between

Deliverable D3.2n 08/2019 n UPM Page 25 of 96 BIMERR project n GA #820621

coordinating parties” [BIM Collab]. BCF enables communication of issues beyond the IFC file capabilities, namely by adding:

• a description of the issue; • a status; • links to a BIM model and objects, • a picture of the issue and • a camera orientation.

3.1.2 COBie

Table 1: Characteristics of COBie

Data Model Construction Operation Building information exchange (COBie) Available Formats spreadsheet, IFC (IFC SPFF, ifcXML), COBieLite Documentation NBIMS-US V2, updated for NBIMS-US V33 Version 2.44 Last Update 2014 Application Building asset information exchange Software tools Indicatively: Revit, ARCHICad, CAFM/CMMS software systems5

COBie (Construction-Operation Building information exchange) is a non-proprietary international technical standard (specification) for capturing and delivering asset data among the involved parties. It contains structured content from all members of the supply chain, aiming to support operation and maintenance (O&M) of built assets, by improving information handover. It is closely related to BIM, as it defines a Model View Definition in Figure 6 (a subset of the IFC6 schema for a particular application) with a focus on preventative maintenance.

3 https://www.nationalbimstandard.org/files/NBIMS-US_V3_4.2_COBie.pdf (Date of Access 15/7/2019) 4 https://www.nibs.org/page/bsa_infoexchange (Date of Access 15/7/2019) 5 https://www.designingbuildings.co.uk/wiki/File_formats_for_BIM#COBie (Date of Access 15/7/2019) 6 an ISO standard format that can be used for exchange of any building information Deliverable D3.2n 08/2019 n UPM Page 26 of 96 BIMERR project n GA #820621

Figure 6. COBie Schema (extracted from [Sabbagh, 2019])

The specification was introduced by the Construction Engineering Research Laboratory of the U.S Army, Corps of Engineers, in 20077, as a pilot standard and part of the work done by the National Building Information Model Standard (NBIMS) Committee. Since then, COBie has been revised to comply with international standards and is now internationally accepted. In 2011 it was approved as part of the NBIMS. In the UK there was a mandate8 for all projects to achieve BIM level 2 by 2016, and provide collaborative 3D BIM, with electronic project and asset information, following the COBie open standards. The BS EN ISO 19650-2 states that by 2019 non-geometric information should be structured in COBie format.

7 https://apps.dtic.mil/dtic/tr/fulltext/u2/a491932.pdf (Date of Access 15/7/2019) 8 https://www.thenbs.com/knowledge/what-is-cobie (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 27 of 96 BIMERR project n GA #820621

Figure 7. COBie spreadsheet screeshot-1 9

COBie can be exported in various formats: IFC (.ifc, .ifcXML), COBieLite (a lightweight XML format for COBie data), or simply as a spreadsheet10, thus enabling even less experienced users of the supply chain directly contribute with data. Data properly organized and compiled as COBie data, can automatically create a comprehensive facility O&M manual, capturing information regarding space and equipment. A COBie file in Figure 7 consists of multiple sheets storing various linkable built asset attributes. Indicatively, the information held within a COBie file can include equipment lists, product data sheets, spare parts lists, maintenance lists, hyperlinks to externally located documents etc. Each COBie file should contain a single building. In case a project contains more than one building, each should have its own file. COBie has been designed for a specific application: facility and asset management handover. Possible extension of the schema to serve other purposes is not supported, as it would infringe the COBie requirements. Plenty other standards, with their own MVD and following the same structure as COBie, are designed for other applications and should be used instead (e.g. BIMSie, Sparkie for electrical system information exchange, etc.).

9 COBie spreadsheet example. Retrieved from www.drupal.org/files/COBie-UK-2012-example1.xls 10 http://open.bimreal.com/bim/index.php/home/cobie/ (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 28 of 96 BIMERR project n GA #820621

There is a variety of free and commercial software for planning, design, construction and facility management, which support COBie. Many different CAFM11/CMMS12 systems currently import COBie data13. However, COBie is not bound to specific software, as long as the exported format meets the specifications and the content is accurately modelling the building14. COBie can be populated from a BIM model or by direct insertion of information in the spreadsheet.

The purpose of COBie is to eliminate the need for transferring tons of paper documents from constructors to facility operators, after the construction is completed, by recording asset data right at its origin, rather than searching for information during operation time, hence saving time and avoiding double work. BIMERR aims to deliver renovation support tools and facilitate interoperability among popular data models. With the adoption of BIM Level 2 in the UK and the BS EN ISO 19650-2, it is apparent that COBie is gaining popularity in the AEC industry. Additionally, COBie enables the consistent recording of asset information at key points throughout the building’s lifecycle, a really valuable task for renovation planning.

3.1.3 CityGML

CityGML is an open data model and it has been developed in order to reach a common definition of the basic entities, attributes and relations of a 3D, city or landscape, model. It has been used widely as it provides interesting features to share and manage the complexity of a city. Moreover, it offers a Level of Detail (LoD) concept, which presents the possibility to generalize CityGML features from a very detailed to a less detailed description. LoD concept of the building model of CityGML is illustrated in Figure 8.

Many efforts have been made in order to achieve a higher-level of geometric and semantic granularity in the modules, especially in the building and core module. The proposed model methodology introduces a new LoD that differentiates a Geometrical and a Semantical Level of Detail, which are separately defined for the interior features

11 Computer Aided Facility Management 12 Computerised Maintenance Management System 13 https://www.nibs.org/page/bsa_cobiemm (Date of Access 15/7/2019) 14 https://www.wbdg.org/resources/construction-operations-building-information-exchange- cobie (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 29 of 96 BIMERR project n GA #820621

and the exterior of a building. So, in this approach, the features of the real world are being modeled and two different kinds of representation are extracted. The combination of the aforementioned kinds provide even more detailed information about the Level of Details, a better description of the interior Level of Detail, a broadening of the opportunities for indoor modelling, and last, a better assignability to all other modules represented in CityGML. This kind of model is relevant to the BIMERR, especially to the urban planning module, as it can be used to model, in a greater detail, the structures and components of the exterior and interior of the buildings of interest. [Löwner, 2013]

Many projects have tried to merge geographic information models, such as CityGML, and building models, like IFC, in order to fulfill the application demands in construction analysis and urban planning. Most of them tried to convert from IFC to CityGML, but on this study a bidirectional method has been proposed. Specifically, the development of a Unified Building Model (UBM) has been introduced, which acts as an intermediate step for conversion of IFC to CityGML and vice versa. UBM is capable of capturing information about spatial structures and building objects from both IFC and CityGML building models. In order to cover all concepts from IFC and CityGML new concepts have been defined for building elements which are covering, level and wall. While external building installations have been defined as a subclass, to achieve the turning-off of building installations if a smaller model is desired. This approach is useful for BIMERR, as it makes possible to exploit CityGML's feature to model buildings. [El Mekawy, 2011]

Deliverable D3.2n 08/2019 n UPM Page 30 of 96 BIMERR project n GA #820621

Figure 8. CityGML Building Model

3.1.4 BO-IDM

Table 2: Characterstics of BO-IDM

Data Model BIM Oriented Indoor Data Model (BO-IDM) Available Formats Vendor specific formats (shapefile, geodatabase) Documentation N.A.15 Version N.A. Last Update 2013 Application Indoor data modelling, indoor navigation and orientation Software tools ESRI (ArcGIS + Geodatabase)

BO-IDM (BIM Oriented Indoor Data Model) is a BIM based model that has been developed to facilitate indoor navigation. BO-IDM complies with ISO 19107 for non- georeferenced structure and complex geometries, enabling both consistent geometric information exchange between applications and indoor navigation. These semantically rich 3D models can prove really valuable for indoor navigation, in comparison to traditional models.

The concept of BIM Oriented modelling was first devised from [Isikdag, 2006], where the potential of enriching BIM models with geospatial attributes was investigated. In 2013

15 https://www.nibs.org/page/bsa_infoexchange (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 31 of 96 BIMERR project n GA #820621

the BIM oriented modelling methodology and the deriving model, BO-IDM, were devised [Isikdag, Zlatanova, & Underwood, 2013].

Figure 9. BO-IDM object model [Isikdag et. al., 2013]

Starting from the BIMs and particularly IFC, the BO-IDM intended to become a model with less complex structure and integrated indoor navigation functionality. As a result, although the BO-IDM schema is similar to the IFC, some of the initial classes have been eliminated, as prescribed by the conceptual model requirements, ending with 18 classes (Figure 9). In order to serve its purpose, the model should include clear semantic information, contain the properties and temporal functional states of each building element (e.g. ‘open’, ‘closed’ for a door), go beyond the traditional 2d representations by presenting information about elements of the 3rd dimension, and spatially relate the building elements (e.g. an opening on a wall).

Deliverable D3.2n 08/2019 n UPM Page 32 of 96 BIMERR project n GA #820621

Figure 10. BO-IDM visualization of two different building transformed from IFC model, within GIS software [Isikdag et. al., 2013]

As indicated by the defined requirements, the model should be implemented with software which supports geodefined geometries. The ESRI platform was selected for this purpose: the ESRI Shapefile format was used for geometries and the ESRI Geodatabase format for GIS information. The implemented BO-IDM model [Isikdag et. al., 2013] has been populated from an IFC model. The model implementation showed that the information of BIMs was successfully transformed in the BO-IDM Oriented model as in Figure 10. Regarding interoperability, testing showed that when the representation was more complex (i.e. from polygons to surface patches) the transformation was less reliable or even inconsistent. However, the model was tested only with a single software (FME), so new tests with other software could reveal different results.

Although BO-IDM is not one of the most widely applied data models, it proposes an enhanced representation of BIM, which can be easily recognized by applications that perform geoinformation analysis and can also be mapped to other popular models, such as CityGML. The enhanced indoor navigation functionality of BO-IDM could be integrated in BIMERR for applications such as emergency-aware renovation design, utility maintenance and facility management. It is also a semantically-focused model, meaning that it includes functional characteristics of the building (such as type of room usage), which are crucial for renovation design.

3.1.5 BISDM

Table 3: Characteristics of BISDM

Data Model Building Interior Space Data Model (BISDM) Available Formats UML diagram –text Documentation BISDM 3.0 Version 3

Deliverable D3.2n 08/2019 n UPM Page 33 of 96 BIMERR project n GA #820621

Last Update 2011 Application Building/interior space management Software tools Indicatively: Autodesk Revit , ARCHICAD, ESRI ArcGIS

The Building Interior Space Data Model (BISDM) is an open data model, that was established in 2007 by ESRI and is based on Geographic Information System (GIS). It allows users to effectively share building/asset information and collaborate with other technologies commonly used for asset and facilities management. BISDM focus is exclusively on interior space planning and building management and its main purpose is for storing in-building information/data in appropriate format as to be compatible with and easy to exploit in GIS software. For example, it enables spatial features (e.g. walls, doors) to link to external features.

Figure 11. Relationships between BISDM, SDI and BIM data elements [extract from [Casazza, 2010]]

BISDM was created to satisfy the needs of known in-building GIS applications; nevertheless, all data modelling derived from its use can produce applications that can be completely integrated with existing outside GIS-applications.

The data required to populate a BISDM model can be extracted from an accurate BIM model, mapped directly from IFC data elements and the same data elements can be also used in CAD/BIM applications. The data models consist of 2 types namely the Split and Merged models. Merged models can only be utilized through GIS applications; Split models can be utilized through combinations of GIS and other systems such as BIM.

An illustration of the relationship between the data elements of a Spatial Data Infrastructure (SDI) used in GIS apps, BISDM and BIM can be seen in Figure 11. Exploiting these common data elements, offers interesting and exclusive possibilities for integrating the BIM/GIS applications.

Deliverable D3.2n 08/2019 n UPM Page 34 of 96 BIMERR project n GA #820621

BISDM provides template GIS feature classes and tables in a physical Unified Modeling Language (UML) diagram, that represents the building information. Each feature class has a field in their attribute table named“ID_field”that describes the identification of that particular feature. The relationship classes are connected through the different“ID_fields” in each object. The data type for the different“ID_fields is text. BISDM include several tables describing the objects in more detail. All the feature classes in this model have relationships with the associated information tables.

The tables support visualization and analysis even if tabular and spatial data are managed separately [Grisé & Wittner, 2008] . The BISDM Feature classes are divided into the groups presented below:

Ø BISDM3 Core - A feature dataset containing the Building Feature Classes

Figure 12. Proposed BISDM Assets class names16

Ø BISDM3 Assets - A Building’s Infrastructure and equipment dataset, built on the BISDM2 Core adding extra feature classes using the IFC developed for BIM standards. It provides essential Geographic feature classes that correspond to

16Extract from BISDM v3.0. Retrieved from: https://www.arcgis.com/home/item.html?id=964233a8633f4a5088bf21f728ee95fe (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 35 of 96 BIMERR project n GA #820621

IFCxml elements, leaving options for implementation for the integration of GIS features with additional tabular information for these assets17. As seen in Figure 12 the proposed BISDM Assets class names follow the structure of IFCs which is desirable for data exchange, supporting further the interoperability among the various software platforms. Ø BISDM3 Interior/Exterior Transportation Network - A UML diagram representing the basic structure for developing a building interior transportation network for routing and other network analysis tasks. The model can be used to represent different modes of transportation inside buildings such as hallways, stairs, escalators and elevators. BISDM also offers the ability to do route tracing and transportation analysis (e.g. identify the nearest facility, travel distance and time analysis as well as location/allocation [Grisé & Wittner, 2008]. Depending on the type of network analysis required, users can add or remove feature classes.

In general, BISDM aims to provide a foundation for additional data related to buildings/structures and can be easily extended for a variety of other purposes e.g.: architecture, construction, building-level energy, environmental management, security and emergency preparedness.

In the context of BIMERR, exploiting BISDM enables users to control BIM data of a building enriched with spatial information. For example, facility managers could overcome the challenges they face in querying, analysing and reporting information about specific elements of buildings, because it is not stored in a common database. BISDM can provide the foundation for a unified “all-buildings” data source, making the information available throughout an organization and among different stakeholders of the AEC industry involved in a particular project.

3.1.6 GBXML

The Green Building schema (gbXML) enables interoperability between building design and engineering analysis software by facilitating the transfer of building information via

17 IFC Schema Specifications Database. Retrieved from: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ (Date of Access 15/7/2019) Deliverable D3.2n 08/2019 n UPM Page 36 of 96 BIMERR project n GA #820621

an XML-based data schema. According to gbxml.org18 it is currently supported by over 40 engineering and analysis modelling tools. gbXML supports over 500 types of elements and attributes to describe a building. The documentation for the most recent schema is available at gbxml.org19. As an example, Figure 13 shows the gbXML Building element, its attributes and child elements. In the context of BIMERR, gbXML can be used as a data exchange/storage format for building information. The rich gbXML data model allows to store very detailed building data (geometry, constructions, heating, cooling, air flows, lightning, etc.). By using gbXML with its strong industry and software tool support (e.g. AutoCAD), BIMERR’s data exchange efficiency with external tools can be increased.

18 http://www.gbxml.org/About_GreenBuildingXML_gbXML 19 http://www.gbxml.org/schema_doc/6.01/GreenBuildingXML_Ver6.01.html Deliverable D3.2n 08/2019 n UPM Page 37 of 96 BIMERR project n GA #820621

Figure 13. gbXML-Building Element

Deliverable D3.2n 08/2019 n UPM Page 38 of 96 BIMERR project n GA #820621

3.2 RELEVANT ONTOLOGIES

This section reviews relevant ontologies related to the building domain, focusing on those standard ones such as SAREF, oneM2M, SSN, BOT, ifcOWL and GML3.

3.2.1 ETSI SAREF ontology and its extensions

The Smart Appliances REFerence ontology (SAREF) is a standard for smart appliances published by ETSI TC SmartM2M [ETSI, 2015] in 2015. SAREF is a reference ontology that provides an important contribution to enable semantic interoperability in the IoT. This standard subsequently evolved into a new version published in March 2017 [ETSI, 2017a] and currently includes also three Technical Specifications that extend the SAREF ontology to three different domains, namely energy (SAREF4ENER [ETSI, 2017b]), environment (SAREF4ENVI [ETSI, 2017c]), and buildings (SAREF4BLDG [ETSI, 2017d]).

The current and envisioned modules of the SAREF ontology can be seen in Figure 14. More precisely, the SAREF extensions being currently developed are related to the following domains: wearables, water, automotive and eHealth & Ageing well. Such figure also represents that a set of alignments have been defined between the SAREF ontology and the oneM2M base ontology [ETSI, 2016], providing an overall view of the SAREF family of ontologies and related ontologies.

SAREF

Industry & Manufacturing Building

Smart City Agriculture Environment Energy

eHealth & Wearables Water Automotive Ageing well

oneM2M Base Ontology

Figure 14. The Current and envisioned modules of the SAREF ontology W3C W3C W3C W3C SSN/SOSA OWL Time WGS_84 Org

Deliverable D3.2n 08/2019 n UPM Page 39 of 96 ISA Dublin OGC Ont. BIMERR projectCPSV n GA #820621 Core Geo SPARQL measurements

The SAREF ontology is intended to provide a core model for IoT that could be extended and adapted in order to cover specific domains. As depicted in Figure 15, the core SAREF ontology 20 focuses on the definition of smart applications for what main concept defined is saref:Device that can be divided into saref:Sensor and saref:Actuator. SAREF allows the representation of the function(s) that a device can have by means of the concept saref:Function.

A device could be designed to perform more than one function. In addition, a function can have one or more commands (saref:Command) that represent the directive that a device must support to perform a certain function. Such commands might act upon a state (saref:State). SAREF also allows the representation of services (saref:Service) that make the functions discoverable, registrable and remotely controllable by others. In this ontology, the task for which a device is designed from a user perspective (for example, the task of “bake” for an oven) can also be represented by means of the concept saref:Task. The observations made by a device are represented by the concept saref:Measurement which is also related to the saref:UnitOfMeasure in which the observation is measured and the saref:Property being measured. Finally, due to the traditional focus of SAREF ontology on the monitoring and optimization of energy or other resources, this ontology allows the representation of consumption (saref:Profile) of properties (e.g. energy) or commodities (e.g. water) saref:Commodity in a given period of time saref:Time and with an associated price saref:Price.

20 In the following, “saref” will be used as a prefix for the namespace “https://w3id.org/saref#” Deliverable D3.2n 08/2019 n UPM Page 40 of 96 BIMERR project n GA #820621

saref:consistsOf saref:Profile saref:isAbout saref:isAbout saref:Commodity

saref:hasTime saref:Time saref:has Profile saref:hasPrice saref:Price saref:isControlledByDevice saref:Property

saref:accomplishes saref:controlsProperty saref:Task sare:measuresProperty <> saref:isMeasured saref:relatesTo saref:isAccomplishedBy Measurement ByDevice saref:Device saref:isUsedFor saref:hasDescription:: rdfs:Literal saref:consistsOf saref:hasManufacturer:: rdfs:Literal saref:hasFunction saref:hasModel:: rdfs:Literal saref:Function saref:relates ToProperty saref:represents saref:isOfferedBy saref:isCom mandOf saref:Actuator saref:makes <> <> Measurement saref:hasCommand saref:Sensor saref:offers saref:Service

saref:Command saref:Measurement saref:hasDescription:: rdfs:Literal saref:timeStamp:: xsd:dateTime saref:hasValue:: xsd:float saref:hasState saref:State saref:actsUpon

saref:isMeasuredIn saref:UnitOfMeasure saref:isMeasuredIn

Legend: Class Class object property applicable to the attached classes Ontology: saref: https://w3id.org/saref# Attribute applicable to the attached class subclassOf

Figure 15. General overview of the SAREF ontology.

The SAREF family of ontologies includes an ontology for buildings devices, namely SAREF4BLDG, which is highly relevant for BIMERR due to the coverage of devices defined in the IFC standard and their properties. This ontology represents buildings, building spaces and building objects providing an extensive classification of building devices.

3.2.2 oneM2M base ontology

The oneM2M21 initiative aims at developing technical specifications addressing the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. In the context of oneM2M efforts, the oneM2M base ontology [ETSI, 2016; oneM2M, 2018] has been designed in order to provide a minimal number of concepts, relations and restrictions that are necessary for semantic discovery of entities in the oneM2M System. Ontologies are used in oneM2M to provide syntactic and semantic interoperability of oneM2M systems with external systems. Such

21 http://www.onem2m.org/ Deliverable D3.2n 08/2019 n UPM Page 41 of 96 BIMERR project n GA #820621

external systems should be described by domain specific ontologies, not considered in the context of the oneM2M ontology.

The oneM2M ontology22 provides main classes and properties to model device functions and service operations, among other things, as show in Figure 16. One of the main classes includes is “Thing” (oneM2M:Thing) that is an entity that can be identified in the oneM2M System and may have properties (oneM2M:ThingProperty).

A thing that is able to interact electronically is called a "Device" (oneM2M:Device). The devices are linked to their functions (oneM2M:Function) by means of the property (oneM2M:hasFunction). Such functions can have one or more commands (oneM2M:Command). Such commands are exposed by operations (oneM2M:Operation) which link to them by means of the property oneM2M:exposesCommand. In addition, the services (oneM2M:Service ) offered by the devices can also have operations which would as well expose commands.

22 In the following, “oneM2M” will be used as a prefix for the namespace “http://www.onem2m.org/ontology/Base_Ontology/base_ontology#” Deliverable D3.2n 08/2019 n UPM Page 42 of 96 BIMERR project n GA #820621

Figure 16. OneM2M Base Ontology graphical overview. (Figure extracted from [oneM2M, 2018])

Finally, oneM2M also allows the representation of different type of variables (oneM2M:Variable) used as input or output for commands, services and operations.

It is worth mentioning that a set of mappings between SAREF and oneM2M ontologies have been already defined and documented along with the SAREF v2 ontology [ETSI, 2017a].

3.2.3 W3C SSN ontology

The Semantic Sensor Network ontology (SSN) was developed in the context of the Semantic Sensor Network Incubator Group (SSN-XG). The final report of the original SSN, published on 28th June 2011, contained as well as the corresponding OWL ontology code. The scope of this ontology is to describe sensors, their capabilities and properties in a way that “allows the network, its sensors and the resulting data to be organized, installed and managed, queried, understood and controlled through high-level

Deliverable D3.2n 08/2019 n UPM Page 43 of 96 BIMERR project n GA #820621

specifications” [Compton et. al., 2012]. This first version of SSN provided 4 perspectives: sensor, observation/data, system and feature and property, that can be adopted to many type of domains and applications. However, this version of SSN does not provide any concepts for reactions and actuators description.

To address to the lack of actuators modelling of original SSN, the joint W3C and OGC Spatial Data on the Web Working Group released a new version of the SSN [Haller et. al., 2018] that differentiates between the SSN module23 and a module called SOSA24 (Sensor, Observation, Sampler and Actuator), among others.

The second version of SSN/SOSA extends the SSO pattern (Stimulus Sensor Observation Pattern) by including classes and properties for actuators and sampling. The three major components of SOSA are "sensors and observations", "samplings and samples" and "actuators and actuations". To describe sensing acts, SOSA25 provides the concept sosa:Sensor that make sosa:Observation about sosa:ObservableProperty as shown in Figure 17. The observable property is a property of a sosa:FeatureOfInterest. Secondly, to record the results of sensing acts, SOSA present sosa:Sampler that make sosa:Sampling of some sosa:FeatureOfInterest to produce sosa:Sample but also the sosa:Result concept could be used. Finally, to describe the ability of using actuators for some actions, SOSA includes sosa:Actuator that make some sosa:Actuation on some sosa:ActuationProperty. The actuation property is also a property of a sosa:FeatureOfInterest.

Due to the domain covered by SSN/SOSA and its wide adoption, this ontology is considered relevant in the context of BIMERR in order to model sensors and actuators in buildings maximizing semantic interoperability with existing projects and datasets annotated following this ontology.

23 http://www.w3.org/ns/ssn 24 http://www.w3.org/ns/sosa 25 In the following, “sosa” and “ssn” will be used as prefixes for the namespaces “http://www.w3.org/ns/sosa/” and “http://www.w3.org/ns/ssn/” respectively Deliverable D3.2n 08/2019 n UPM Page 44 of 96 BIMERR project n GA #820621

Figure 17. Overview of the core structure of the SSN ontology. (Figure extracted from [Haller et. al., 2018])

3.2.4 W3C BOT ontology

BOT [Rasmussen et. al., 2017a] ontology is a minimal OWL DL ontology for representing relationships between sub-elements of a building. The main aim to build the BOT ontology is to combine with multiple domain specific ontologies by following the common W3C principles of promising reuse. The BOT ontology is being developed by the W3C based LBDC (Linked Building Data Community) Group. This ontology presents a high-level presentation of the topology of building with spaces and stories including 3D mesh geometry of these components. Buildings, sites, stories and spaces are all non- physical objects describing a spatial zone [Rasmussen et. al., LDAC 2017b].

The scope of BOT is to specially present some specific relationships between the sub- elements of a building. A building usually contains of the building itself and several stories, rooms, and building components possibly related with each other. The object properties of the classes have specified domains and ranges so a reasoner can infer classes automatically.

The BOT ontology is designed to response various competency questions such as: (1) how to describe adjacencies between various zones (2) how to express a building site, (3) how to express interfaces between element/element, zone/zone, or zone/element. Some specific ontologies for products, geometry, and properties are being designed in domain working groups, and these are all being aligned with BOT. Deliverable D3.2n 08/2019 n UPM Page 45 of 96 BIMERR project n GA #820621

Primary concepts described in BOT are bot:Element bot:Zone, and bot:Interface, as shown in Figure 18. BOT Zones could be further categorized as bot:Site, bot:Space, bot:Storey and bot:Building. Zones could have adjacent zones, related by the object property bot:adjacentZone. Zones kept in a building are described by the property bot:containsZone, which could be presented by the properties bot:hasBuilding, bot:hasStorey, and bot:hasSpace.

Figure 18. Classes and relationships involved in Zones. Image taken from https://w3c-lbd- cg.github.io/lbd/bot/

3.2.5 ifcOWL

Industry Foundation Classes (IFC) are an open specification for Building Information Modeling (BIM) data26. ifcOWL is a OWL representation of the IFC schema27. Using ifcOWL, which represents the IFC data as directed labelled graph, allows to link building data to related data sets such as material data, GIS data, and sensor data. Data management and exchange benefit from these linked data sets. ifcOWL is relevant to BIMERR because it allows the specification of building life-cycle relevant data by open linked data standards. The complexity of the data model allows to exchange/store rich building-related data sets. It must be evaluated if this high

26 https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/ 27 https://technical.buildingsmart.org/standards/ifc/ifc-formats/ifcowl/ Deliverable D3.2n 08/2019 n UPM Page 46 of 96 BIMERR project n GA #820621

complexity benefits or hinders BIMERR at the development of an efficient data exchange format.

3.2.6 GML3

The Geography Markup Language (GML) is an XML grammar for expressing geographical features. It serves as a modelling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. It has been used as a data structure for storage and exchange of geographic features, but it has its limitation in characterising the semantics of objects. This led to the development of a variety of GML application schemas in order to define such information for specific applications. The applications related to the building domain are IndoorGML and CityGML. IndoorGML is used mostly for indoor navigation applications, while it contains only a minimum set of geometric and semantic modelling construction components. Contrarily, CityGML is considered to be the most comprehensive urban information model and is used to describe 3D objects with respect to their geometry, topology, semantics and appearance.

While it is true that CityGML's building model is widely used for many applications, it is not as complete as BIM, especially when detail is of the essence. Some of the requirements of the proposed design are the assessment of the building safety, the estimation of the cost of repair of the damaged components and the visualization of the location and mode of damage at the component level. In the context of modelling the buildings and flood, a new data model as a GML profile has been introduced to combine BIM and GIS at the data level. While GIS has been preferred for the flood modelling, BIM and LoD4 of CityGML have been selected for the modelling of building elements. Out of those two, BIM contains more precise building information and it has been considered the main data source. Data model's packages inherit their high-level features from the GML classes. In the Terrain package and Flood package GML's features has been used the most. The proposed method seems to be closely connected with BIMERR, as the methodology, used in this project, can also be used for other building types and the data model can be extended to all types of buildings and events, like a renovation process. Τhe requirements of the proposed method are also related to BIMERR, as the cost of repair and the visualization of damage at the component level are being also addressed on the renovation of buildings. Lastly, the usage of CityGML for the modelling of building elements and the high-level features of GML's classes, in the building package, disclose Deliverable D3.2n 08/2019 n UPM Page 47 of 96 BIMERR project n GA #820621

their usefulness on the building domain, and to assess the flood damage to building [Amirebrahimi, 2016].

3.3 RELEVANT STANDARDIZATION INITIATIVES

This section reviews main standardization bodies in the building domain as buildingSMART, ETSI, W3C, ISO and COBie.

3.3.1 buildingSMART Linked Data Working Group

The buildingSMART Linked Data Working Group28 (LDWG), created in 2015 during the Spring Summit of buildingSMART International, is devoted to build and maintain a recommended version of an ifcOWL ontology as an equivalent to the IFC EXPRESS schema. The ifcOWL ontology is to be used in linked data and semantic web applications that consume IFC data. The group meets at regular intervals, both virtual and live, to keep track of and discuss possible enhancements to the ifcOWL ontology. The LDWG is part of the Technical Room and closely interacts with the other working groups, such as the MSG and the bsDD-WG. The group is also in charge of aligning semantic web activities with ongoing efforts in buildingSMART, such as the bSDD and providing support in the usage of an ifcOWL ontology. With SAREF, SmartM2M is promoting oneM2M Base Ontology with extensions in many IoT domains.

3.3.2 ETSI SmartM2M

ETSI (European Telecommunications Standards Institute) is an independent European standardization organization within the telecommunications industry. Within ETSI, the SmartM2M Technical Committee focuses on the machine-to-machine communications developing standards to enable M2M services and applications in combination with IoT technologies. In this context, the TC addresses the connection of smart applications through the SAREF ontology. Finally, the TC also supports the role of ETSI in AIOTI (www.aioti.eu) WG03 (IoT Standardization) in collaboration with the H2020 IoT Large Scape Pilot and IoT Platforms.

28 https://technical.buildingsmart.org/community/linked-data-working-group/ Deliverable D3.2n 08/2019 n UPM Page 48 of 96 BIMERR project n GA #820621

3.3.3 W3C Linked Building Data Community Group

The W3C Linked Building Data Community Group 29 (LBDCG) aims to enable all stakeholders in the building life cycle to query and access necessary data for supporting their business use cases by using semantic web technologies. These semantic web technologies can be applied on buildings (geometry, products, topology and usage) and infrastructure data (roads, railroads, bridges). This group combined the building information modelling (BIM) and Web of Data technologies to describe several requirements and use cases for linked data based application across the buildings life cycle. Both governmental and industrial organizations who use data from BIM modelling applications and other data such as sensor data, material data, GIS data and geographical data to obtain their business process. Apart from the online meetings regularly planned to advance in the group developments, the group members use to meet physically during Linked Building Data related events, for example the Linked Data in Architecture and Construction workshop series.

3.3.4 buildingSMART buildingSMART, (previously known as International Alliance for Interoperability) is considered as one of the most important standardisation organizations (established in 1995) focusing on standardisation processes, workflows and procedures in the Building Information Modelling (BIM) area, covering many different domains, enabling more efficient digital information workflows.

‘’buildingSMART is the worldwide authority driving the transformation of the built asset economy through creation & adoption of open, international standards’’. buildingSMART has developed open international BIM standards [Chapman, 2013], covering a wide range of processes and information capabilities unique to the built Figure 19. buildingSMART 31 environment industry, which are briefly described as follows: Basic Standard

29 https://www.w3.org/community/lbd/ Deliverable D3.2n 08/2019 n UPM Page 49 of 96 BIMERR project n GA #820621

• Industry Foundation Classes (IFC) is buildingSMART’s first developed data model (currently IFCv.4), created for information/data exchange among different actors of the building sector who are not using the same vendor specific software. IFC represents the “operating system” responsible for transporting information/data between different software applications. As a file format, IFC follows the ISO STEP file structure (.ifc), a text file formatted using extensible markup language, XML (.ifcXML), or a compressed file (.ifcZIP) containing a .ifc or .ifcXML file. IFC provides strong support for semantics by offering true object-based modelling with class definitions and inheritance [Jorge & Keith, 2017]. • buildingSMART Data Dictionary (bsDD), formerly known as International Framework for Dictionaries (IFD), is an open object-oriented database, providing ontologies and attributes to IFC objects, such as doors, walls, and structural elements [Petrie, 2016]. It is used to identify objects in the built environment and their specific properties, irrespective of language by linking existing databases with construction information to a buildingSMART based Building Information Model (BIM), thus resulting in enhanced share and product information exchange between the different actors of the AEC industry and software developers. • Information Delivery Manual (IDM), provides the methodology for defining which information should be shared and documents business processes and data requirements. IDMs enable to capture and gradually integrate business processes, whilst at the same time provides thorough specifications of the information that a user (fulfilling a specific role) would need to provide at a particular point within a project. • BIM Collaboration Format (BCF), a software-independent communication protocol for sharing “comments” linked to building elements when design issues have been found [Mogollon, 2014]. It consists of an open standard XML schema that encodes messages, enabling workflow communication among the available BIM software tools. • Model View Definitions (MVD) a standard for translating processes into technical requirements. MVD defines a legal subset of the IFC Schema and provides implementation guidance for all IFC concepts (classes, attributes, relationships, property sets, quantity definitions, etc.) used within a specific subset [See et. Al., 2011]. Thus, it represents the software requirement specification for the implementation of an IFC interface to satisfy the exchange requirements of the AEC industry during a construction project’s lifecycle.

Deliverable D3.2n 08/2019 n UPM Page 50 of 96 BIMERR project n GA #820621

A list of BIMERR relevant buildingSMART standards is presented in Table 4 below and are described in section 3.1.

Table 4: List of BIMERR relevant buildingSMART standard

Standard Acronym Standard Name Scope Remarks IDM Information Delivery Processes ISO 29481-1 Manual ISO 29481-2 IFC 4.1 Industry Foundation Building ISO 16739:2013 Classes Version 4.1 BCF-XML BIM Collaboration Collaboration Format XML BCF-API BIM Collaboration Web Service Format REST API bSDD (IFD) buildingSmart Data Product data ISO 12006-3 Dictionary Classifications mvdXML Model View Definition Formal description of XML Model View Definition

3.3.5 ISO/Technical Committee 59/Subcommittee 13

Within the International Organization for Standardization, the Technical Committee (TC) 59 [ISO, 2018b] is devoted to the standardisation, in the field of buildings and civil engineering works, of: terminology, organization of information technology in building and civil engineering processes, geometric requirements for buildings, to building elements and components including modular coordination, general rules for joints, tolerances and fits, and performance requirements. The committee's standards also address vital and topical issues such as sustainability, accessibility and service life.

Particularly, the subcommittee (SC) 13 deals with the organisation and digitisation of information about buildings and civil engineering works, including BIM. Amongst the standards already published, or under development, by the ISO/TC 59/SC 13 the following are relevant to BIMERR:

• ISO 12006 (Parts 2 and 3), related to data meaning (dictionary and classification); • ISO 16739-1:2018, linked to the IFC data schema; • ISO 29481, which includes methodology and format (Part 1) and the interaction framework (Part 2) of IDM. • ISO 19650, about the organisation and digitisation of information in building and civil engineering works, including BIM. More precisely, Part 1 is related to

Deliverable D3.2n 08/2019 n UPM Page 51 of 96 BIMERR project n GA #820621

concepts and principles; Part 2 is linked to the delivery phase of the assets. Note also that Part 3 (operational phase) and Part 5 (security) are currently under development.

3.3.6 ISO TC211 (GML3)

ISO/TC 211 is a standard technical committee involved with the areas of digital geographic information and geomatics. The goal of the initiative is to establish a structured set of standards for information regarding objects or phenomena associated with a location relative to the Earth. Many standards related to ISO/TC 211 are being followed in the building domain. GML or ISO 19136 is the most widely used international standard to represent 2D and 3D geographic information and it is included in the list of standards by the ISO/TC 211 committee. It implements a subset of the types in the ISO 19107 standard and it is the basis of other standards, such as CityGML.

Beyond GML, there are other standards associated with ISO/ TC211. One of them is ISO 19107, which provides conceptual schemas for describing and manipulating spatial characteristics of geographic features. It has been utilized on the information model BO- IDM, in order to be compliant with the geometries of building elements and spaces. Due to that, the model can be recognized by geoinformation analysis and processing applications, easily mapped to CityGML, and used as an alternative of LOD 4 representation of CityGML in supporting indoor navigation [Isikdag, 2013]. Furthermore, ISO 19125 describes the common architecture for simple feature geometry and it can be used to represent the geometry in 2D. Specifically, in the INSPIRE building model, which consists of four different profiles, in the Core 2D profile, for the representation of geometry, the ISO 19125 has been used. It has not been used on the other profiles, due to the fact that it is restricted to 2D. The Core 2D profile features types for buildings and building parts in 2D geometry. In Figure 20 , the UML diagram of the Core 2D profile of INSPIRE Building model is illustrated [Gröger, 2014]. All of the aforementioned standards are relevant to BIMERR, as they can be used for the representation of building features.

Deliverable D3.2n 08/2019 n UPM Page 52 of 96 BIMERR project n GA #820621

Figure 20. UML diagram of the Core 2D profile of INSPIRE Building Model

3.3.7 NBIMS (COBie)

The NBIMS (National BIM Standards) Project Committee30 is part of the buildingSMART alliance, which is a council of the National Institute of Building Sciences. It was chartered in 2005, as the Facility Information Council, with the mission to establish and manage a series of open National standards, in order to improve the entire lifecycle of facilities and guide all aspects of Building Information Modeling.

30 https://www.nationalbimstandard.org/ Deliverable D3.2n 08/2019 n UPM Page 53 of 96 BIMERR project n GA #820621

The NBIMS Committee works towards incorporating internationally adopted standards, especially from efforts such as the International Standardisation Organisation (ISO), in order to achieve broader adoption by countries outside the US. An obstacle towards this goal is the North American specific nomenclature, however there is hope that this could be overwhelmed when mapping to other standards occur, thus achieving international interoperability.

Regarding the relevant data models of the NBIMS, various aspects of the whole facility lifecycle are covered and a number of standards has been developed, including: COBie (asset data exchange), SPV (design to spatial program validation), BEA (design to building energy analysis), QTO (design to quantity takeoff for cost estimating), BPie (building programming information exchange), SPARKie (electrical information exchange), HVACie (heating, ventilating and air condition information exchange), WSie (water systems information exchange) and more. Reference standards, such as OmniClass, developed by allied standards organisations are also included. The most recent publication of the alliance’s efforts was the NBIMS-US Version 3, in 2015.

NBIMS-US is designed for two audiences: on the one hand, designers, engineers, constructors, operators and owners of built environment, and on the other hand, the software developers and vendors who develop programs for data and information interoperability. Interoperability is a core concept in the BIMERR project. As part of the buildingSMART alliance and creator of the COBie and other information exchange specifications, the NBIMS-US Committee is a possible target for the standardisation activities of BIMERR.

Deliverable D3.2n 08/2019 n UPM Page 54 of 96 BIMERR project n GA #820621

4. ANALYSIS OF THE MATERIALS DOMAIN

This section provides a short review of existing European building materials, components related databases and ontologies, which may be utilised within the design of the materials and components database for BIMERR.

4.1 RELEVANT DATA MODELS

Several existing European database models are identified as relevant to the creation of the BIMERR materials and components database, namely: Baubook.info; Eurobau.com; Oekobaudat.de and Gabi.

4.1.1 Baubook.info database

The web platform baubook31 is a database of building material and their ecological and structural-physical aspects. Currently 3616 building products from 359 vendors are described in the database.

The baubook platform also contains a catalog with around 400 reference values which includes different ecological and structural-physical indicators. These values deliver the primary indicators and orientation values for energy and eco certificates. They are especially helpful for calculation of energy certificate in early planning phase where the concrete products are not decided yet. On the example of insulation material EPS-W 15, Figure 21 shows which reference values are provided by baubook. Upon request these values are provided as XML document.

31 www.baubook.info Deliverable D3.2n 08/2019 n UPM Page 55 of 96 BIMERR project n GA #820621

Figure 21. baubook.info – reference values (example)

4.1.2 Eurobau.com database

Based on the building material classification freeClass, Eurobau.com provides detailed technical information (product measurements, u-values, etc.) on more than 100.000 building products from hundreds of vendors. Data can be queried through a webservice available at http://webservices.eurobau.com/eurobau/ or from downloadable CSV files (after registration). Eurobau.com is highly active in the Austrian and Central European building material industry, has a strong support from this industry and provides therefore highly up-to-date building material data. Detailed cost data is available for the Austrian market, cost data for the Polish market can be derived from the Austrian figures.

Deliverable D3.2n 08/2019 n UPM Page 56 of 96 BIMERR project n GA #820621

4.1.3 Oekobaudat.de database

Oekobaudat.de provides around 1200 life cycle assessment datasets for building materials, construction, transport, energy and disposal processes. The database can be used to reconstruct the entire building life cycle and is maintained by the German Ministry of Interior, Building and Community.

The used data format is based on the International Reference Life Cycle Data System (ILCD) data format, compliant with EN 15804 provided as CSV files. Amongst others the following life cycle and impact assessment indicators are provided32: i) use of renewable primary energy (PERE), ii) use of renewable primary energy resources used as raw materials (PERM), iii) global warming potential (GWP), and iv) depletion potential of the stratospheric layer (ODP).

4.1.4 GaBi database

The GaBi construction material database33 contains regionalized Life Cycle Assessment (LCA) information of around 2600 construction materials. The materials include but are not limited to glue, concrete, plaster, paints, insulating material, wood, windows, lighting, plumbing, heating, and elevators. The data is available in XML and updated annually by a community of life cycle experts from over 20 countries.

4.2 RELEVANT ONTOLOGIES

One relevant ontology that has been identified for BIMERR materials and components database design is entitled as ‘Freeclass.eu’.

4.2.1 Freeclass.eu ontology

Freeclass.eu is an open-source construction material classification schema. The OWL ontology specification is available at http://www.freeclass.eu/freeclass_v1.owl. The

32 https://www.oekobaudat.de/fileadmin/downloads/Einreichung/2018-03-20_ILCD- EPD_Defin_CPEN2018.pdf 33 http://www.gabi-software.com/international/databases/gabi-databases/construction- materials/ Deliverable D3.2n 08/2019 n UPM Page 57 of 96 BIMERR project n GA #820621

freeclass.eu classes are linked to the Eurobau.com construction material product database. The current freeclass OWL file is from 2009 and therefore no longer compatible with the latest Eurobau.com data structure.

Freeclass has also taken part in a BIM initiative to integrate their materials classification schema for BIM. This is open source project that is freely available via: https://www.freebim.at/. For guidance on installation with existing BIM software vendors is also provided in video format34.

4.3 RELEVANT STANDARDIZATION INITIATIVES

This section describes the CWA 16762:2014 – CEN agreement due to is relations to the standardization initiatives in the materials domain.

4.3.1 S.R. CWA 16762:2014 - CEN Workshop Agreement

The CEN/WS SERES (“ICT Standards in Support of an eReporting Framework for the Engineering Materials Sector”) was approved in February 2012, started in March of the same year and lasted for 21 months, until November 2013. The final text of this CEN Workshop Agreement (CWA) was published in May 2014. It aimed at the electronic representation of engineering materials, in order to make the sharing of engineering materials data feasible. CEN/WS SERES was organized on three parts, that of Business Analysis, Standardization and Governance, and lastly Technical. In the first part, an extended review of using electronic data exchange in various industries was made, such as automotive. Moreover, the risks and benefits of the adoption of an electronic material data exchange, instead of a physical one, were presented, by undertaking use cases with industrial partners. In the second part, a review was done of the associated standards communities, regarding materials, materials data and Information and Communication Technology (ICT). Furthermore, a discussion of actions, related to the creation of a framework for using and extending the technologies used in the CES/WS SERES deliverables, was made. The third part contains a review of the related

34 https://www.freebim.at/videoschulung Deliverable D3.2n 08/2019 n UPM Page 58 of 96 BIMERR project n GA #820621

technologies and the description of the data models, schemas and ontologies that represent materials data.

In the context of developing robust ICT standards for engineering materials data, standards from materials science, computerized engineering and ICT have been blended. Specifically, from materials science the work done by ASTM Committee E49 has been used, from the computerized engineering world standards developed by ISO TC184/SC4 have been analyzed and extended and from the ICT community the principles of the ISO 15926 standard have been adopted. Regarding the modelling of engineering materials, a written specification has been authored to achieve a common understanding of the domain. The written specification provides a common framework to develop a description of the main categories of engineering materials and it is illustrated in Figure 22. The most significant concepts, describing an engineering material according to the CEN/WS SERES model, are material type, characterization, process and source. CEN/WS SERES as a CWA does not have the status of a European Standard, but it is a work towards the standardization of engineering materials. Thus it is related to BIMERR, as it provides a way to describe the main categories of materials, such as: metals, plastic, ceramics and composites, which are used for construction or insulation. [Bullough, 2014]

Figure 22. Information included in the written specification

Deliverable D3.2n 08/2019 n UPM Page 59 of 96 BIMERR project n GA #820621

Deliverable D3.2n 08/2019 n UPM Page 60 of 96 BIMERR project n GA #820621

5. ANALYSIS OF THE ENERGY CONSUMPTION DOMAIN

This section reviews, relevant data models, ontologies and standardization initiatives for the energy consumption domain.

5.1 RELEVANT DATA MODELS

Building energy data can be captured either directly by data models with specified syntaxes (IDD and epJSON for EnergyPlus , BDL for DOE-2, bps for ESP-r, etc.) or indirectly by widely used openBIM data models to achieve true interoperability (gbXML and IFC). For the later, a BIM to BEPE input data mapping process is required. Several of these data models overlap with the usage patterns and behaviors domain (see chapter 6), due to the consumption being a function of activities and behaviors happening in a building.

EnergyPlus has been selected as BEPE engine for the energy consumption estimation in BIMERR. Its data models (and syntax specifications) are Input Data Dictionary and epJSON. IDD relies on comma-separated text, where an entry defines an object of a class and specifies all the data needed to model it. A newer data schema, epJSON, has also been introduced based and is scheduled to fully replace IDD from EnergyPlus’ version 10.0. Being based on the well-known JSON, epJSON is much easier to work with, especially for conversion of data from other models into a unified representation.

State of the art practice automates the generation of BEPE input data files from BIM data sources from the standard openBIM schemas. gbXML and IFC are the most frequently used schemas here. gbXML has data definitions for the start and end of heating and cooling, heater/cooler types, the temperatures inside and outside, and power consumption data (max power), among others. These all can be used as inputs to calculating actual energy consumption of a building as well as (historically) recognize trends for that consumption. buildingSmart’s Inductry Foundation Classes (IFC) are a file format used to exchange data between CAD systems, cost prediction systems and other AEC-industry applications. The IFC schema however can only give information about the 2nd level space boundaries and it is not sufficient for HVAC modelling in BEP simulation engines.

Deliverable D3.2n 08/2019 n UPM Page 61 of 96 BIMERR project n GA #820621

An IFC-to-BEPE transformation can be performed either directly (adding further information by hand), or by utilizing intermediate data models to bridge the gap between BIM and BEPs data. One commonly used intermediate data model here is SimModel. Its XSD schema is a union of two data representations: one for building geometry, elements, materials, zones, spaces and HVAC systems (similar to IFC), and the second for the BEPS related information (similar to IDD).

Finally, the obXML model defines a “comfort envelope” of parameter values within which a building’s occupants feel the temperature, lighting, and other energy-intensive parameters as comfortable. Starting from these values and combining them with the obXML definitions of systems (windows, shades, thermostats, equipment, etc) it is possible to calculate and predict energy consumption and efficiency for the building as a whole, under different comfort envelopes.

5.2 RELEVANT ONTOLOGIES

The SAREF ontology (section 3.2.1) has been extended with several other ontologies, of which two are relevant for the energy efficiency domain:

• SAREF4EE 35 , the extension for EEBus and Energy@Home projects, includes definitions of various actuators, sensors, appliances, and control and measurement behaviors for appliances. It addresses use cases such as Remote Network Management, scheduling, remote control and remote start, communication of appliance status and info, and demand response. The ontology is relevant for BIMERR due to its potential to describe consumption behavior data. • SAREF4BLDG 36 , the SAREF extension for building devices, aims for a more efficient interaction and integration of actors, methods and tools during the different phases of the building life cycle. The ontology is very relevant to BIMERR because it has been developed with the Architecture, Engineering and Construction (AEC) and Facilities Management (FM) fields in mind. It supports mechanisms to facilitate the exchange and interoperability of data between

35 http://ontology.tno.nl/saref4ee/ 36 https://w3id.org/def/saref4bldg Deliverable D3.2n 08/2019 n UPM Page 62 of 96 BIMERR project n GA #820621

actors (architects, engineers, consultants, contractors, and product component manufacturers) along the different stages of the building life cycle (Planning and Design, Construction, Commissioning, Operation, Retrofitting/Refurbishment/Reconfiguration, and Demolition/Recycling). SAREF4BLDG is based on the Industry Foundation Classes (IFC) standard for building information (see Section 3.1.1.1).

OEMA37 is a set of eight interconnected ontologies from various domains, all centered on energy (e.g. energy performance, infrastructures, weather data, etc.). The set of OEMA ontologies also provides a common representation of concepts that belong to different energy domains. The eight OEMA ontologies are: Energy and Equipment, External factors, Geographical, Infrastructure, Person and Organisation, Smart Grid Stakeholders, and Units, joined together by the “Ontology Network” ontology. In addition to describing energy consumption behavior, this ontology describes the interactions between multiple stakeholders with a stake in the result of the BIMERR project.

5.3 RELEVANT STANDARDIZATION INITIATIVES

The Energy Performance Certificate (EPC) (known in various EU countries as Energieausweis, Diagnostic de performance énergétique, Certificazione energetica degli edifici, Energieprestatiecertificaat, etc.) results from European Union Directive 2002/91/EC relating to the energy performance of buildings. It provides a rating that summarises the energy efficiency of a building between A (Very efficient) and G (Inefficient). Several factors are taken into account, such as insulation, windows and glazing, types of energy, etc. The rating is done by software, which makes assumptions on the insulation properties of various building materials depending on age and construction type. Any renovation – including those with BIMERR tools – may result in changes to the insulation and energy efficiency; furthermore, the types of materials used for renovation may need to be updated or inserted in the software used for rating, thus making BIMERR activities a crucial factor in determining the energy performance of buildings.

37 https://innoweb.mondragon.edu/ontologies/oema/index-en.html

Deliverable D3.2n 08/2019 n UPM Page 63 of 96 BIMERR project n GA #820621

ISO50001:2018 aims to guide companies in integrating energy management into their processes. It provides a framework of requirements for organizations, among which requirements on creating an energy policy, setting targets of use, and measuring policy results from actual use of energy. As many other ISO quality management standards, ISO 50001 is based on continuous improvement, which implies both measurement, control, but also changes to the energy behavior of buildings. This puts ISO 50001 squarely in the BIMERR domain.

In addition to the above named standardisation initiatives, many countries have national-level laws requiring certain energy performance levels, or setting targets to reach within given timeframes. These also represent a key factor necessitating the BIMERR tools in renovation and construction.

Deliverable D3.2n 08/2019 n UPM Page 64 of 96 BIMERR project n GA #820621

6. ANALYSIS OF THE USAGE PATTERNS AND HABITS DOMAIN

This section reviews relevant data models, ontologies and standardization initiatives for the usage patterns and habits domain.

6.1 RELEVANT DATA MODELS

The potential of using BIM data to automate the Building Energy Performance Estimation (BEPE) model generation has received lately considerable attention. With the analysis of the usage patterns and habits domain, known as Occupant Behaviour (OB) modelling, being one of the key factors towards increasing the Building Energy Performance Estimation (BEPE) tools accuracy, investigation upon publicly available BIM and BEPE schemas’ expressiveness and their capability to capture the OB required information or definition of a new data model for OB data representation has been the topic of this section.

Considering that within BIMERR, Profiling Residents Usage of Building System (PRUBS) is in charge of generating such OB models, to be used as input to EnergyPlus, that has been selected to be the BEPE engine, a literature review has shown that data models depicted in Figure 23 could be adopted.

Figure 23. Data models of Occupant Behaviour modelling for BEPE purposes

OB models are represented using either the specific syntax of particular BEPE programs (IDD and epJSON in terms of EnergyPlus) or common semantic data models, in the form of XML (gbXML, obXML or simXML) or IFC (using Design Transfer View as the selected Model View Definition, since there is often a need to insert supplementary data to the

Deliverable D3.2n 08/2019 n UPM Page 65 of 96 BIMERR project n GA #820621

IFC). In this section, know-how OB information is captured at each data model of Figure 23 and their strengths/weaknesses of are briefly presented.

6.1.1 Simulation Program Oriented Data Models

The Input Data Dictionary (IDD) is the native data model of EnergyPlus, used to populate its Input Data File (IDF) consisting of all data required for a BEPE. IDD consists of a comma separated text by a semi column, where an entry defines an object of a class and specifies all the data needed to model it. From version 8.8 of EnergyPlus, a new data schema has been supported based on JSON format standard. It is called epJSON, scheduled to fully replace IDD from EnergyPlus’ version 10.0. It is worth mentioning that a recent study has shown remarkable performance improvements in terms of files size, files parsing and inputs processing due to the EnergyPlus JSON input refactoring [Adams, 2018] .

Figure 24. Example of EMS classes’ instances in epJSON, used to override values of the cooling setpoint at each timestep

Concerning the OB modelling, there are three main groups of epJSON (or IDD) classes, whose objects could be used to populate OB data: (1) Energy Management System (EMS) classes allow custom functions to overwrite the occupants’ presence and actions data (schedules) at each simulation timestep (for the sake of example, see Figure 24 (2)

Deliverable D3.2n 08/2019 n UPM Page 66 of 96 BIMERR project n GA #820621

Building Controls Virtual Test Bed (BCVTB) API classes enable the co-simulation of EnergyPlus with an external tool, where the OB modelling functions are simulated; and (3) Function Mock-up Units (FMUs) classes enable the aforementioned co-simulation in a more efficient manner.

While Simulation Program Oriented Data Models consist the most widely used BEPE data representations, they suffer from a strong limitation: lack of reusability among other simulation tools.

6.1.2 Open-source Common Data Models

The gbXML, briefly presented in Section 3.1.6, defines an XML-based standard representation of buildings and systems, and its rich content allows to capture almost all data required for a BEPE in a precise way. Nevertheless, it represents OB data by simplified and predefined schedules (timeseries) or simplified equations (Figure 25), while OB approximators can be complex functions of a set of features (e.g. indoor air temperature; relative humidity, solar radiation, etc.) that are calculated by the simulation engine and vary at each timestep.

Deliverable D3.2n 08/2019 n UPM Page 67 of 96 BIMERR project n GA #820621

Figure 25. gbXML´s XSD diagram of Equation class that could be used for simplified equation-based OB modelling

To address this drawback, in [Hong, 2015b], data, methods, and models have been developed and applied to understand and reduce the gap between simulated and measured building energy performance by representing occupant behaviour in a standardized ontology and XML schema (obXML). obXML builds upon the Drivers– Needs–Actions–Systems (DNAS) framework [Hong, 2015a] to represent energy-related occupant behaviour in buildings. Drivers represent the environmental and other context factors that stimulate occupants to fulfil a physical, physiological, or psychological need. Needs represent the physical and non-physical requirements of occupants that must be met to ensure satisfaction with their environment. Actions are the interactions with systems or activities that occupants can perform to achieve environmental comfort (see Figure 26). Systems refer to the equipment or mechanisms within the building that occupants may interact with to restore or maintain environmental comfort. Although obXML appears to be a promising schema that meets a wide range OB modelling requirements, within BIMERR, more sophisticated methods and models will be developed as part of PRUBS module; hence, possible extensions of this schema should be investigated.

Deliverable D3.2n 08/2019 n UPM Page 68 of 96 BIMERR project n GA #820621

Figure 26. XSD diagram of the main obXML´s topology for OB action´s modelling

Another XML-based data model is the SimModel XML (SimXML) [O’Donnell, 2012]. Its XSD schema is defined by the union of two different data representations. The first representation captures all the BIM related information, such as building geometry, building elements, materials, zones, spaces and HVAC systems. The structure of this representation follows the fundamental principles of the IFC schema. The second representation is used to capture all the BEPS related information in more precise way and its structure has strong similarities with the Input Data Dictionary (IDD) of EnergyPlus. SimXML acts as an intermediate data model to bridge the gap between BIM and BEPE data. In fact, although IFC is a rich in content data schema, it cannot capture all the BEPE data requirements. To encapsulate all the BEPE data requirements in a common file, the need for an intermediate data model is highlighted. However, since SimXML is the union of IFC and EnergyPlus data schemas, OB modelling data can be captured either following the EnergyPlus or the IFC (see Figure 27) specifications, and its strong dependence on a specific BEPE engine could constitute the dissuasive factor towards adopting it.

Deliverable D3.2n 08/2019 n UPM Page 69 of 96 BIMERR project n GA #820621

Figure 27. Express-G diagram of the IfcTimeSeries class for schedule-based OB modelling

In recent BIM-to-BEPE data transformation attempts, except from gbXML, IFC is frequently selected to achieve true interoperability. IFC appears to be a more suitable choice as its rich content enables interoperability among different software environments. Similar to gbXML, IFC schema represents OB data by simplified, predefined schedules (IfcTimeseries instances, as depicted in Figure 27). However, IFC

Deliverable D3.2n 08/2019 n UPM Page 70 of 96 BIMERR project n GA #820621

schema allows for user defined Psets, that could be used to support OB modelling based on complex functions. Currently, IFC file format has not been used to represent any OB models.

6.2 RELEVANT ONTOLOGIES

In the context of semantic data modelling, respective ontological representations in RDF format have been developed for some of the aforementioned data models. In the case of IFC schema, its corresponding data model, ifcOWL, has been described in Section 3.2.5 Ontological representations of gbXML and obXML do not exist. However, Apache Jena and Apache Xerces frameworks could be applied for a transformation from XML to OWL, and vice versa.

6.2.1 E+OWL

E+OWL is a Semantic Web Implementation of EnergyPlus IDD, a Java application with three main functions: (1) EnergyPlus IDD transformation to a schema that uses Web Ontology Language (OWL) format; EnergyPlus IDF transformation to instances that are represented in OWL format; and (3) the OWL format instances transformation back to EnergyPlus IDF file for simulation. Using the OWL format, data stored in EnergyPlus IDF can be queried and the relationships of the data items in the model can be visualized using Semantic Web tools.

6.2.2 SimModel OWL

For a better SimModel information integration with other building information, Pauwels et al. [Pauwels, 2014] developed the SimModel OWL to represent its information in RDF. For that purpose, a conversion service has been built that is able to parse the SimModel ontology in the form of XSD schemas and output a SimModel ontology in OWL. Details of the SimModel OWL is beyond the scope of this work, but we refer the interested reader to [Pauwels, 2014] for a thorough description.

6.3 RELEVANT STANDARDIZATION INITIATIVES

This section describes the standardization initiatives IEA-EBC for the definition and simulation of occupant behaviour in buildings (Annex 66 ) and for Occupant-Centric Building Design and Operation (Annex 79).

Deliverable D3.2n 08/2019 n UPM Page 71 of 96 BIMERR project n GA #820621

6.3.1 IEA – EBC Annex 66 – Definition and simulation of occupant Behavior in Buildings

The Annex 66 project [IEA–EBC Annex 66, 2013] was approved in June 2013, started in November of the same year and lasted until June 2018. It aimed at providing scientific description and clear understanding of the energy related occupant behaviour in buildings along with a set of research methodologies and simulation tools to bridge the gap between occupant behaviour and the built environment. Through Annex 66, a standard occupant behaviour definition platform was set up, aiming to establish a quantitative simulation methodology addressing the occupant behaviour in buildings and understand the influence of occupant behaviour on building energy use and indoor environment.

Five subtasks were defined in the project (A-E). In Subtask A, Occupant movement and presence model, a definition and simulation methodology to represent the occupants’ presence and movement was provided. The goal of Subtask B, Occupant action models in residential buildings, was to provide a standard description for occupant action behaviour simulation, systematic measurement approach, modelling and validation methodology in residential buildings. The scope of Subtask C, Occupant action models in commercial buildings, was to provide a standard description for occupant action behaviour simulation, systematic measurement approach, modelling and validation methodology in commercial building. The activities of Subtask D, Integration of occupant behaviour definition and models with current building energy modelling programs, focused on the promotion of third-party software development and creation of a framework in XML schema and a software module with occupant behaviour models. Finally, for Subtask E, Applications in building design and operations, a number of case studies to demonstrate applications of the new occupant behaviour definition and models were carried out. These case studies provided verification of the applicability of the developed definition and models by comparing the measured and the simulated results. Annex 66 worked towards the standardization in the simulation of occupant behaviour, for building design optimization, energy diagnosis and performance evaluation which is closely related with the scope of BIMERR.

6.3.2 IEA – EBC Annex 79 – Occupant-Centric Building Design and Operation

Annex 79 [IEA–EBC Annex 79, 2018] began in June 2018 and is a continuation of Annex 66. It aims to integrate and implement occupant’s presence and behaviour in the design Deliverable D3.2n 08/2019 n UPM Page 72 of 96 BIMERR project n GA #820621

process and building operation so that both the energy performance and the comfort conditions in the building can be improved. Annex 79 is separated in 4 Subtasks. In Subtask 1, Multi-aspect environmental exposure, building interfaces and human behaviour, different aspects are addressed such as the multi-aspect comfort and behaviour models, the relationship between the building interfaces and human behaviour, the conduction of field and laboratory studies on human comfort and behaviour, and the research on building interfaces. Subtask 2, Data-driven occupant modelling strategies and digital tools, focuses on developing tools and methodologies for data-driven Occupant Presence and Action (OPA) modelling. The activities of this subtask include developing new occupant data collection approaches, investigating new data-driven methods and developing a platform for sharing data-driven methods related to OPA. Subtask 3, Applying occupant behaviour models in performance-based design process, focuses on improving energy prediction and also, to better understand the occupants’ interaction with different architecture and control concepts. Its goal is to develop systematic methods to improve the existing occupant models and improve the overall building design in terms of comfort, usability and energy consumption. The new methods explored regarding the behavioural models can be eventually integrated to BIM. Finally, Subtask 4, Development and demonstration of occupant-centric building control, aims at developing and demonstrating occupant-centric building controls.

The activities of Annex 79 are very closely related to the occupant’s behaviour activities of BIMERR since it seeks to improve the modelling and simulation methods currently available in to ultimately integrated them with BIM. However, as Annex 79 took off in the summer of 2018, few outcomes are currently available.

Deliverable D3.2n 08/2019 n UPM Page 73 of 96 BIMERR project n GA #820621

7. ANALYSIS OF THE WEATHER DOMAIN

This section reviews relevant data models and ontologies for the weather domain.

7.1 RELEVANT DATA MODELS

Weather data can be retrieved by a variety of online services of different providers (e.g. AccuWeather38, Weather202039) that are already exposing their forecasts via suitable APIs or as a Service. Though most of these services require a subscription plan, free services also exist. One of the mostly used ones is OpenWeather40 which provides current, hourly and long term (e.g. 16 or 30 days) forecasts together with historical data. The World Meteorological Organization (WMO), also provides online forecasts in JSON format for each city. All these services use custom representation models that are suitable for consumption by an API. Most of the available services use XML and/or JSON to format the forecasts, however a common data model does not exist. The information however that is communicated tends to follow the same format. Figure 28 depicts a sample JSON response from OpenWeather.

Currently, WMO is working on representing weather metadata in XML with the focus being establishing metadata standards for WMO. This could lead to the establishment of a standard representation schema in the future.

38 https://www.accuweather.com/

39 https://weather2020.com/

40 https://openweathermap.org/

Deliverable D3.2n 08/2019 n UPM Page 74 of 96 BIMERR project n GA #820621

Figure 28. Sample response from OpenWeather (information clipped for visibility)

7.2 RELEVANT ONTOLOGIES

Various ontologies for weather have been proposed. The most relevant for the context of BIMERR is the SEAS (Smart Energy Aware Systems) WeatherOntology, which, as the name implies, is geared towards smart systems. One particularly useful characteristic of SEAS WeahterOntology is that, among the various concepts it encapsulates, it can represent the service from which the weather data are obtained, thus coupling the data

Deliverable D3.2n 08/2019 n UPM Page 75 of 96 BIMERR project n GA #820621

source to the data representation in a semantically sound way. Figure 29 depicts the class diagram of the most important entities of WeatherOntology

Figure 29. WeatherOntology Class Diagram (Classes are not fully expanded for clarity)

In the domain of Linked Data, various data sets for specific countries and regions have been published openly and can be used by third parties. On the global scale, The Global Weather Sensor Datasets is a noteworthy effort to collect hourly climatological data from the globe. It collects data in linked data format from over 20.000 weather station worldwide and it consists of over 120 billion triples.

Deliverable D3.2n 08/2019 n UPM Page 76 of 96 BIMERR project n GA #820621

8. ANALYSIS OF THE REALITY CAPTURE DOMAIN

This section reviews relevant data models, ontologies and standardization initiatives for the reality capture domain.

8.1 RELEVANT DATA MODELS

There are a number of formal and informal standards for storing 3D and colour data delivered by technologies such as laser scanning or produced by photogrammetry, although there is also a strong dependency on proprietary formats, complicating the interoperability between software solutions and, in consequence, between professionals.

In the following subsections, three levels of standards are detailed.

8.1.1 Basic data formats

The lack of well-established robust standards for the storage of 3D and colour data initially led to the use of simple and understandable formats amongst reality capture professionals. In these data formats, spatial coordinates, and potentially RGB information, are usually structured in character-separated lines, with one line per point, as shown in Figure 30. XYZ data, for each point are included in every row; additional information (e.g. RGB and laser intensity) can be also incorporated. The character used to separate each file is often a Tab or a comma.

Figure 30. Data structure for basic data formats

Deliverable D3.2n 08/2019 n UPM Page 77 of 96 BIMERR project n GA #820621

Even though there are no standards (i.e. written rules) regulating these formats, their simplicity and their codification using the American Standard Code for Information Exchange (ASCII) make them easily understandable and widely used. For these reasons, data formats such as TXT, XYZ and PTS (although the last one is a Leica proprietary format) are considered ‘open’, in the sense that they are human-readable. All these formats share a common attribute: all of them store unconnected data without any additional information (e.g. device location for each scan). Commonly, they can be referred to as ‘dumb formats’.

A more complex data format is PLY [Turk, 1994]. It is normally used to store mesh information, but it can also store point clouds, by simply recording the cloud points as ‘vertices’ and no mesh face. As illustrated in Figure 31, a PLY file includes a header followed by one or two element lists. The header contains information about the number of elements (i.e. vertices and faces) stored in the file. Vertex lists contain, per row, the 3D coordinates for each mesh vertex; in the case of storing point cloud information, each row records a cloud point Face lists include, in each row, the indices of the points defining each face; in the case of storing point cloud information, this list is kept empty. Both vertex and face information can be codified by means of ASCII or in binary format for more compact and rapid storage, loading and saving. However, like in above-mentioned formats, only geometric and colour-related data are stored.

Figure 31. Data structure for PLY data format

8.1.2 Enriched data formats

PTX: Reality capture is usually performed from multiple points of view, depending on the geometry of the environment or objects to be scanned. Therefore, several datasets will be delivered throughout this process, one per scanner location. All the obtained point clouds can be stored in a single file, together with relevant information related to the position of the device for each scan. The PTX format, created by Leica and generally

Deliverable D3.2n 08/2019 n UPM Page 78 of 96 BIMERR project n GA #820621

adopted by the community, enables this. Although PTX is a proprietary format, it is considered ‘open’ meaning that datasets can be stored following ASCII rules and are readable by humans.

The structure of a PTX file is illustrated in Figure 32. For each scan, a header and a list of vertices (containing 3D coordinates and colour) are included. Each header contains information related to the number of points in the cloud and the transformation matrices to be applied to register under a Universal Coordinate System (UCS) (if such multi-scan registration has been performed).

Figure 32. Structure of a PTX file

However, some authors [Bourke, 2015] indicate that there PTX files can – and maybe were originally intended to – be used to point clouds in the form of 2D grids as produced in regular laser scan processes. The advantage of such format is that it retains the neighbouring connectivity of points. But, this alternative use of the format highlights the lack of standardisation and the need for a true open standard format to exchange reality capture data.

E57: In 2006, the ASTM International created the ASTM Committee E57 on 3D Imaging Systems. This committee addresses issues related to 3D imaging systems and, during the last decade, they have been working on an open standard to exchange data obtained by 3D imaging systems: the E57 File Format for 3D Imaging Data Exchange [Huber, 2011].

Deliverable D3.2n 08/2019 n UPM Page 79 of 96 BIMERR project n GA #820621

Figure 33 shows (a) the structure of an E57 file and (b) the hierarchy of the data stored in the file. This tree-shaped diagram, which corresponds to the box named ‘XML section’ in (a), describes how the E57 elements are organised. As illustrated, 2D images are stored together with 3D data in the E57 standard. This means that the format can be used for: storing all data actually acquired by laser scanners (as opposed to just the output point cloud); but also to store data from photogrammetric systems.

Of all formats discussed in this section, E57 is the only one that is fully open and managed formally by through a (ASTM) committee. Furthermore, it is able to capture more information than PTX and makes effective use of binary data sections to optimise file sizes.

(a) (b) Figure 33. Structure of an E57 file. (a) File sections. (b) Hierarchical structure of the stored data

8.2 RELEVANT ONTOLOGIES

There has noticeably not been any serious work on developing some ontology for the Reality Capture domain. Some ontology certainly drove the E57 standard discussed below, but only in an implicit way. In the subsection below, we do report an IFC schema extension to record point clouds, but it can be noted this schema is narrower in scope that the range of information that what can be captured in the E57 standard.

8.2.1 Point cloud schema extension for the IFC model

3D semantic models in IFC contain comprehensive information about how a building has been planned and/or constructed. However, the IFC schema, until recently, didn’t

Deliverable D3.2n 08/2019 n UPM Page 80 of 96 BIMERR project n GA #820621

provide any means to store point clouds, linked to 3D models in BIM (i.e. IFC) structures, which is especially relevant for maintenance and operational activities.

The recent EU-funded FP7 project DURAARK proposed the enrichment of IFC models with point cloud data [Beetz, 2015]. As illustrated in Figure 34, two new entities are defined to extend the existing IFC ontology/schema, namely IfcPointCloud and IfcPointCloudElement.

Figure 34. EXPRESS-G diagram of the DURAARK schema extension [Beetz, 2015]

IfcPointCloud is a subtype of IfcGeometricRepresentationItem and can be attached to any IfcProduct. This entity allows not only the representation and storage of point cloud data in different formats, but also the addition of attributes such as colour and reflection index for every point in the IfcPointCloud (see Figure 35).

Deliverable D3.2n 08/2019 n UPM Page 81 of 96 BIMERR project n GA #820621

Figure 35. EXPRESS-G diagram of the DURAARK proposed schema extension for attribute vector elements [Beetz, 2015]

8.3 RELEVANT STANDARDIZATION INITIATIVES

This section presents the ASTM committee for the definition of 3D image standard.

8.3.1 ASTM E57

ASTM Committee E57 was created in 2006 to develop standards related to 3D imaging systems, which include laser scanners and optical range cameras [ASTM, 2016]. This committee, whose name was given to the open standard for reality capture previously mentioned (E57), is divided into several subcommittees that regulate the produced standards. Four of these boards are technical and focus on terminology, test methods, guidelines and data interoperability.

Amongst the key documents and standards proposed by the Committee E57, two of them are of particular interest to BIMERR, namely E2807-11 ‘Standard Specification for 3D Imaging Data Exchange’ [ASTM, 2011] and E2544-11a ‘Standard Terminology for Three-Dimensional (3D) Imaging Systems’ [ASTM, 2011b].

Deliverable D3.2n 08/2019 n UPM Page 82 of 96 BIMERR project n GA #820621

9. ANALYSIS OF THE GEOGRAPHICAL DOMAIN

This section reviews relevant data models, ontologies and standardization initiatives for the geographical domain.

9.1 RELEVANT DATA MODELS

Data models in the geographical domain refer mainly to the representation of the information regarding geolocation. Metadata that accompany the location (such as population data, points of interest etc), are generally included in semantically enriched models (typically in an ontology). In terms of information representation, the next subsections give a brief description of the vector data model and the raster model, the two most widely used schemas for representing geolocation.

9.1.1 Vector data model.

The vector data model represents objects are represented as geometrical entities with well defined boundaries. These entities can be a point a line or a polygon. Points are defined by a single x,y coordinate pair, lines are defined by an ordered list of points and polygons are defined by a list of lines that form a closed area. Volumes can also be included in the vector data model by similarly defining them as a list of polygons that form a closed volume. Each entity is also assigned an identifier that corresponds to the feature it represents. For example, a river may be modelled with a line, that will have the appropriate feature id so that corresponds to the river (Figure 36 depicts one such example).

Deliverable D3.2n 08/2019 n UPM Page 83 of 96 BIMERR project n GA #820621

Figure 36. Sample representation of a river in vector data model

There are various formats used for the Vector data model, with the most widely used being Shapefile (Esri), Geodatabase feature class (Esri), GML (OpenGIS Consortium), KML (Google) and GeoJSON. In general, data represented in the vector model, can also be encoded using the Well Known Text representation of Geometry (WKT) or the Well Known Binary representation of Geometry (WKB). WKT is a markup language for representing a map in text format, while WKB stores the same information in binary format. Both can be used to easily store the data in the database, with WKB providing the most efficient means in terms of storage requirements.

9.1.2 Raster data model

In the raster data model, the earth surface is quantized in a grid of square cells. Each cell is identified uniquely by the set of x,y coordinates which is relevant to the origin of the grid. According to which information is needed to be coded, each cell is assigned a numerical value. For example, if elevation information is needed, each cell has the value of the average height of the grid cell. In general, if multiple information needs to be stored (e.g. elevation together with temperature), the value of each cell can be an ordered list containing the information needed.

Deliverable D3.2n 08/2019 n UPM Page 84 of 96 BIMERR project n GA #820621

Figure 37 depicts an example of a river represented in raster format where the feature id of the river is encoded in the cell colour.

Figure 37. Sample representation of a river in raster data model

Deliverable D3.2n 08/2019 n UPM Page 85 of 96 BIMERR project n GA #820621

9.2 RELEVANT ONTOLOGIES

9.2.1 Geonames

The Geonames Ontology is widely used for representing locations. It allows the encoding both for location data, such as latitude, longitude and elevation using real- world coordinates and relevant metadata that accompany these locations. Sample metadata can refer to the population of the area and to various administrative information. Geonames makes use of the SKOS41 Ontology and the FOAF42 Vocabulary and by following the Linked Data Paradigm, its entries are aligned to other widely used linked data databases such as DBpedia. As sample class diagram of the most important classes of Geonames, together with the relevant links to entities of SKOS and FOAF is depicted in Figure 38.

Figure 38. Class diagram depicting the main Entities of Geonames and their relation to entities from SKOS and FOAF

Geonames versatility and the fact that data aligned to Geonames is automatically aligned to SKOS, FOAF and DBPedia, makes Geonames a prime candidate for usage within the BIMERR framework.

41 https://www.w3.org/2004/02/skos/ 42 http://xmlns.com/foaf/spec/ Deliverable D3.2n 08/2019 n UPM Page 86 of 96 BIMERR project n GA #820621

9.2.2 Geopolitical Ontology

Geopolitical Ontology was developed by the Food and Agriculture Organization of the (FAO). Its aim is to describe data regarding countries and territories. It is a multilingual ontology and apart from geolocation data, it provides historical data as well. Geopolitical Ontology is fully compliant with the Linked data principles and triples containing instances is already available in the Linked Open Data Cloud.

9.3 RELEVANT STANDARDIZATION INITIATIVES

Various standards have been implemented or are considered for encoding geographical data.

9.3.1 ISO 6709

ISO 6709 Standard representation of geographic point location by coordinates is the international standard for representation of latitude, longitude and altitude for geographic locations in point format. Each point is characterized by a minimum of two coordinates (latitude and longitude) with an extra optional parameter for height or depth and an extra parameter which optionally specifies the coordinate system.

ISO 6709 provides a universal and unambiguous way for representing locations; thus adopting the standard for BIMERR will be useful when location identification needs to be carried out by usage of coordinates.

9.3.2 ISO 3166

ISO 3166 is a standard for defining codes for the names of countries, territories and, in general, locations of interest. It consists of three parts: a) ISO 3166-1 which defines codes for the names of countries, dependent territories, and special areas of geographical interest, b) ISO 3166-2 which defines codes for the names of the principal subdivisions of all countries that are coded in ISO 3166-1, and c) ISO 3166-3, which defines codes for country names which have been deleted from ISO 3166-1.

ISO 3166 provides a unique schema for naming areas to various degrees of granularity and is therefore relevant either when precision to the level of coordinates is not needed

Deliverable D3.2n 08/2019 n UPM Page 87 of 96 BIMERR project n GA #820621

or in cases where the coordinates need to be accompanied by easy to read and identify information.

9.3.3 Geonames

Geonames is a geographical database the entries of which are represented by URIs. In this sense, Geonames entries are linked data. A Geonames ontology, to which all entries of the geonames database are aligned, also exists.

One of the main advantages of Geonames is that they can be linked with other linked data sources, most notably those of DBPedia. This is useful specifically for BIMERR since the produced triples can be easily semantically enriched with existing information, thus allowing the execution of more complex and meaningful queries.

Deliverable D3.2n 08/2019 n UPM Page 88 of 96 BIMERR project n GA #820621

10. CONCLUSIONS

The BIMERR Interoperability Framework (BIF) aims at enabling semantic interoperability between the ICT ecosystem to be provided by BIMERR for end-to-end support of building renovation for energy efficiency. This solution will be based on the definition of ontologies for which an initial survey on the available resources to be reused should be carried out. In this first survey reported in this document existing data models, ontologies and standardization initiatives related to the BIMERR project have been identified for the following domains: building (including structure and components), materials, energy consumption, usage patterns and habits and weather.

Table 5 shows an overview of the data models, ontologies and standardization initiatives for each of the above-mentioned domains. From this information the availability and gaps regarding resources to be reused during the project could be identified. For example, it can be observed that there is a good number of resources for the building domain, either regarding data models, ontologies and standardization initiatives as well for geographical and energy related ontologies. On the other hand, there might be a need for weather or reality capture ontologies. In addition, a gap for energy consumption relevant data models and standardization initiatives for the weather domain has been identified

Table 5: Domain Coverage existing data model, ontologies and standardization initiatives

Domain Data Model Ontology Standardization Initiative Building • IDBm • ETSI SAREF • buildingSMART Linked • IFC ontology Data Working Group • BDV • oneM2M base • ETSI SmartM2M • MVD ontology • W3C Linked Building • COBie • W3C SSN ontology Data Community • CityGML • W3C BOT ontology Group • BO-IDM • ifcOWL • buildingSMART • BISDM • GML3 o buildingSMART • GBXML Linked Data Working Group • ISO/TC 184/SC 4 (ISO 16739 -IFC) • ISO/Technical Committee 59/Subcommittee 13

Deliverable D3.2n 08/2019 n UPM Page 89 of 96 BIMERR project n GA #820621

• ISO 29481 - IDM • ASTM E57 • ISO TC211 • NBIMS

Materials • Baubook.info • Freeclass.eu • S.R. CWA 16762:2014 – database CEN • Eurobau.com database • oekobaudat.de database • GaBi database Energy EnergyPlus • SAREF ontology • ISO50001:2018 Consumption variants • SAREF4EE • SAREF4BLDG • OEMA Usage • EnergyPlus • E+OWL • IEA – EBC Annex 66 patterns and DataModels • SimModel OWL • IEA – EBC Annex 79 habits domain • XML Data Models • IFC dataModels Weather • AccuWeather • SEAS NA • Weather2020 WeatherOntology Reality • Basic data • Point cloud schema • ASTM E57 capture formats extension for the • Enriched data IFC model formats GIS • Vector data • Geonames • ISO 6709 model • Geopolitical • ISO 3166 • Raster data Ontology • Geonames model

The outcome of this deliverable will serve as input for the work to be done during T4.1 in which an analysis focused on the specific coverage of each domain will be carried out

Deliverable D3.2n 08/2019 n UPM Page 90 of 96 BIMERR project n GA #820621

and compared to BIMERR needs. The BIMERR architecture being defined in D3.5 and the analysis to be presented in D4.1 will drive the ontology requirements specification activity and its further development.

Deliverable D3.2n 08/2019 n UPM Page 91 of 96 BIMERR project n GA #820621

11. REFERENCES

[Adams ,2018] Adams, Mark B., and Joshua Ryan New. (2018) EnergyPlus Performance Improvements via JSON Input Refactoring. Oak Ridge National Lab (ORNL), Oak Ridge, TN (United States). [Amirebrahimi, 2016] Amirebrahimi, S., Rajabifard, A., Mendis, P. and Ngo, T. (2016). A BIM-GIS integration method in support of the assessment and 3D visualisation of flood damage to a building. Journal of Spatial Science, 317-350. [ASTM, 2016] ASTM International (2016). ASTM International Technical Committee E57 on 3D Imaging Systems https://www.astm.org/COMMIT/E57_Fact_Sheet_2016.pdf (Accessed 18/3/19) [ASTM, 2011] ASTM (2011). E2807-11, Standard Specification for 3D Imaging Data Exchange, Version 1.0, ASTM International, West Conshohocken, PA. [ASTM, 2011b] ASTM (2011). E2544-11a, Standard Terminology for Three-Dimensional (3D) Imaging Systems, ASTM International, West Conshohocken, PA. [Bazjanac, 1997] Bazjanac, V. and Crawley, D. B. (1997). The Implementation of Industry Foundation Classes in Simulation Tools for the Building Industry. Building Simulation Conference, Prague (CZ). [Beetz, 2015] Beetz, J., Krijnen, T. and Wessel, R. (2015). Point cloud schema extension for the IFC model. Deliverable 3.5. DURAARK FP7 Project. [BIM Collab] BIM Collab, https://www.bimcollab.com/en/BIM/OpenBIM/BCF [Bourke, 2015] Bourke, P. (2015). PTX Plain Text Data Format. http://paulbourke.net/dataformats/ptx/ (Accessed 13/03/2019) [buildingSMART, 2014] buildSMART (2014). What is openBIM? IFC Introduction. https://www.buildingsmart.org/about/what-is-openbim/ifc-introduction/ (Accessed 27/02/2019) [Bullough, 2014] Bullough, C., Faget, A., Virgili, A., Leal, D., Rumble, J., Loveday, M. and Austin, T. (2013). CEN CWA 16762:2014 ICT Standards in Support of an eReporting Framework for the Engineering Materials Sector. [Cassaza, 2010] Cassaza K., Building Interior Space Data Model: The Link from BIM to GIS & the Foundation for an Existing-Structure BIM, Journal of Building Information Modeling, 2010. [Chapman, 2005] Chapman, R.E. (2005). Inadequate Interoperability: A Closer Look at the Costs. 22nd International Symposium on Automation and Robotics in Construction, ISARC 2005, Ferrara (Italy). https://doi.org/10.22260/ISARC2005/0087 [Chapman, 2013]Chapman, I., (2013), The buildingSMART Data Dictionary’, [Online] Available at: http://www.thenbs.com/topics/bim/articles/bsdd.asp [8 Mar 2015]. [Cheng et al., 2016] Cheng, J., C.,P., Lu, Q. and Deng,Y. (2016) Analytical review and evaluation of civil information modeling, Automation in Construction, Vol. 67, July 2016, 31-47, ISSN 0926-5805, DOI: http://doi.org/10.1016/j.autcon.2016.02.006.

Deliverable D3.2n 08/2019 n UPM Page 92 of 96 BIMERR project n GA #820621

[Compton et. al., 2012] Compton, M., Barnaghi, P., Bermudez, L., García-Castro, R., Corcho, O., Cox, S., Graybeal, J., Hauswirth, M., Henson, C., Herzog, A., (2012). Others: The SSN ontology of the W3C semantic sensor network incubator group, Web semantics: science, services and agents on the World Wide Web 17, 25–32. [Delany, 2015] Delany, S. (2015). Classification. NBS, BIM Toolkit. https://toolkit.thenbs.com/articles/classification#classificationtables [Ebrahimipour and Yacout, 2015] Ebrahimipour, V., and Yacout, S. (2015) Ontology modeling in physical asset integrity management, Springer, London. 32-25, ISBN 3319153269 [El Mekawy, 2011] El Mekawy, M., Östman, A. and Shahzad, K. (2011). Towards Interoperating CityGML and IFC Building Models: A Unified Model Based Approach. Advances in 3D Geo-Information Sciences, 73-93. [ETSI, 2015] ETSI TS 103 264 - v1.1.1 (2015). SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping. [ETSI, 2016] ETSI TS 118 112 – v2.0.0 (2016), oneM2M; Base Ontology (oneM2M TS- 0012) version 2.0.0 Release 2. [ETSI, 2017a] ETSI TS 103 264 - v2.1.1 (2017). SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping. [ETSI, 2017b] ETSI TS 103 410-1 - v1.1.1 (2017). SmartM2M; Smart Appliances Extension to SAREF; Part1: Energy Domain. [ETSI, 2017c] ETSI TS 103 410-2 - v1.1.1 (2017). SmartM2M; Smart Appliances Extension to SAREF; Part2: Environment Domain. [ETSI, 2017d] ETSI TS 103 410-3 - v1.1.1 (2017). SmartM2M; Smart Appliances Extension to SAREF; Part3: Building Domain. [Gröger, 2014] Gröger, G. and Plümer, L. (2014). The Interoperable Building Model of the European Union. Geoinformation for Informed Decisions, 1-17. [Grisé & Wittner] Grisé, S. & WITTNER, E. 2008. Building Interior Space Data Model. 2008 ESRI User Conference: Technical Workshops held on 4-8 August 2008. Available at: http://www.scdhec.gov/gis/presentations/ESRI_Conference_08/tws/workshops/t w_919.pdf. Date of access: 7 Nov. 2010. [Haller et. al., 2018] Haller, A., Janowicz, K., Cox, S. J., Lefrançois, M., Taylor, K., Phuoc, D. Le., Lieberman, J., García-Castro, R., Atkinson, R., Stadler, C. (2018). The modular SSN ontology: A joint W3C and OGC standard specifying the semantics of sensors, observations, sampling, and actuation, Semantic Web(Preprint), 1– 24. [Hietanen, 2006] Hietanen J. (2006) IFC model view definition format, International Alliance for Interoperability. [Hong, 2015a] Hong T, D'Oca S, Turner WJ, Taylor-Lange SC. An ontology to represent energy-related occupant behavior in buildings. Part I: Introduction to the DNAs framework. Building and Environment. 2015 Oct 1;92:764-77.

Deliverable D3.2n 08/2019 n UPM Page 93 of 96 BIMERR project n GA #820621

[Hong, 2015b] Hong, Tianzhen, et al. "An ontology to represent energy-related occupant behavior in buildings. Part I: Introduction to the DNAs framework." Building and Environment 92 (2015): 764-777. [Huber, 2011] Huber, D. (2011). The ASTM E57 file format for 3D imaging data exchange, Proc. SPIE 7864, Three-Dimensional Imaging, Interaction, and Measurement, 78640A. https://doi.org/10.1117/12.876555 [IEA–EBC Annex 66, 2013] IEA–EBC Annex 66. (2013). Definition and simulation of occupant Behavior in Buildings (https://annex66.org/)(Accessed 10/07/2019) [IEA–EBC Annex 79, 2018] – IEA–EBC Annex 79. (2018). Occupant-Centric Building Design and Operation (http://annex79.iea-ebc.org/)(Accessed 10/07/2019) [Isikdag, 2006] Isikdag, U. (2006). Towards the implementation of building information models in geospatial context (Doctoral dissertation, Salford: University of Salford). [Isikdag, 2013] Isikdag, U., Zlatanova, S. and Underwood, J. (2013). A BIM-Oriented Model for Supporting Indoor Navigation Requirements. Computers, Environment and Urban Systems, 41:112-123. [ISO, 2018] International Organization for Standardization (2018). Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries -- Part 1: Data schema, ISO 16739-1:2018. [ISO, 2007] International Organization for Standardization (2007). Building construction -- Organization of information about construction works -- Part 2: Framework for classification, ISO 12006-2:2015. [ISO, 2007b] International Organization for Standardization (2007). Building construction -- Organization of information about construction works -- Part 3: Framework for object-oriented information, ISO 12006-3:2007. [ISO, 2016] International Organization for Standardization (2016). Building information models — Information delivery manual — Part 1: Methodology and format, ISO 29481-1:2016. [ISO, 2016b] International Organization for Standardization (2016). Building information models -- Information delivery manual -- Part 2: Interaction framework, ISO 29481-2:2012. [ISO, 2018b] ISO/TC59 (2018). Buildings and civil engineering works. https://committee.iso.org/home/tc59 (Accessed 02/04/2019) [Jorge and Keith, 2017] Jorge C. and Keith C. Cl (2017) Modeling Standards and File Formats for Indoor Mapping, Department of Geography, University of California [Kang and Choi, 2015] Kang, T., W. and Choi, H.,S. (2015) BIM perspective definition metadata for interworking facility management data, Advanced Engineering Informatics, Vol. 29(4), 958-970. [Löwner, 2013] Löwner, M.O., Joachim, B., Gröger, G. and Häfele, K.H. (2013). New Concepts for Structuring 3D City Models - an Extended Level of Detail Concept for CityGML Buildings. Computational Science and Its Applications-ICCSA 2013, 466-480.

Deliverable D3.2n 08/2019 n UPM Page 94 of 96 BIMERR project n GA #820621

[Matar et. al., 2017] Matar M., Osman H., Georgy M., Abou-Zeid A., El-Said M., A systems engineering approach for realizing sustainability in infrastructure projects, HBRC Journal, Volume 13(2), August 2017, 190-201. [Mogollon, 2014] Mogollon, N. (2014)BCF. BIM Collaboration Format Explained’, OpenBIMer [Online] Available at: http://openbimer.com/?p=286 [OCCS, 2017] OCCS Development Committee Secretariat (2017). OmniClass. A strategy for classifying the Built Environment. http://www.omniclass.org/ (Accessed 27/02/2019) [O'Donnell, 2012] O'Donnell, James. "SimModel: A domain data model for whole building energy simulation." (2012). [oneM2M, 2018] oneM2M Partners (2018), oneM2M; Base Ontology (oneM2M TS- 0012 version 3.7.1. [Pauwels, 2014] Pauwels, Pieter, Edward Corry, and James O'Donnell. "Representing SimModel in the web ontology language." Computing in Civil and Building Engineering (2014). 2014. 2271-2278. [Pătrăuceana et. al., 2015] Pătrăuceana V., Armeni I., Nahangi M., Yeung J., Brilakis I., Haas C., State of research in automatic as-built modelling”, Advanced Engineering Informatics, Volume 29(2), April 2015, 162-171.

[Petrie, 2016]Petrie, R. (2016). buildingSMART Data Dictionary Strategic Overview. Retrieved from buildingsmart. org/wp-content/uploads/2016/03/16-03-21- bSDDStrategic-Overview-Webinar.pps. [Rasmussen et. al., 2017a] Rasmussen M. H., Pauwels P., Hviid C. A. and Karlshøj J.,Proposing a Central AEC Ontology That Allows for Domain Specific Extensions, in: Joint Conference on Computing in Construction, Vol. 1, 2017, pp. 237–244. doi:10.24928/JC32017/0153.. [Rasmussen et. al., 2017b] Rasmussen M. H., Pauwels P., Lefrançois M., Schneider G., Hviid C. and Karlshøj J., Recent changes in the Building Topology Ontology, in: Proceedings of the 5th Linked Data in Architecture and Construction Workshop (LDAC 2017), 2017. doi:10.13140/RG.2.2.32365.28647. [Sabbagh, 2019] Sabbagh, M. BIM and COBie for Facility Management. Yapı Bilgi Modelleme, 1(1), 21-31. [See et. al., 2011] See, R., Karlshoej, J. and Davis, D. (2011) ‘An Integrated Process for Delivering IFC Based Data Exchange’, BuildingSMART, Publication (2011), 1-44. [Singer and Borrmann, 2015] Singer, D.; Borrmann, A. (2015) A Novel Knowledge- Based Engineering Approach for Infrastructure Design. Proceedings from: The Fourth International Conference on Soft Computing Technology in Civil, Structural and Environmental Engineering, Prague, Czech Republic, 2015 Accessible via: https://www.cms.bgu.tum.de/en/17-research-projects/46-open- infra-platform [Studer et. al., 1998] Studer, R., Benjamins, V., Fensel, D. Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering. 25 (1998) 161-197

Deliverable D3.2n 08/2019 n UPM Page 95 of 96 BIMERR project n GA #820621

[Turk, 1994] Turk, G. (1994). The PLY Polygon File Format, The Board of Trustees of The Leland Stanford Junior University. https://web.archive.org/web/20161204152348/http://www.dcs.ed.ac.uk/teachin g/cs4/www/graphics/Web/ply.html (Accessed 11/03/2019) [Wix, 2010] Wix, J. and Karlshoj, J. (2010). Information Delivery Manual. Guide to Components and Development Methods. buildingSMART International.

Deliverable D3.2n 08/2019 n UPM Page 96 of 96 BIMERR project n GA #820621