# Interoperable digital building twins through communicating materials and semantic BIM

Ana Roxin, Wahabou Abdou, William Derigent

► To cite this version:

Ana Roxin, Wahabou Abdou, William Derigent. Interoperable digital building twins through communicating materials and semantic BIM. SN Computer Science, 2022, 3 (1), pp.23. 10.1007/s42979-021-00860-w. hal-03549008

HAL Id: hal-03549008

https://hal.science/hal-03549008

Submitted on 4 Mar 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Interoperable Digital Building Twins Through Communicating Materials and Semantic BIM

Ana Roxin<fnref n="1" /> Ⓒ Wahabou Abdou<fnref n="1" /> · William Derigent<fnref n="2" />

Received: 7 December 2020 / Accepted: 6 September 2021 / Published online: 28 October 2021
© The Author(s) 2021

## Abstract

This paper presents contributions of the ANR McBIM (Communicating Material for BIM) project regarding Digital Building Twins, specifically how Semantic Web technologies allow providing explainable decision-support. Following an introduction stating our understanding of a Digital Building Twin (DBT), namely a lively representation of a buildings' status and environment, we identify five main research domains following the study of main research issues related to DBT. We then present the state-of-the-art and existing standards for digitizing the construction process, Semantic Web technologies, and wireless sensor networks. We further position the main contributions made so far in the ANR McBIM project's context according to this analysis, e.g., sensor placement in the communicating material and explainable decision-support.

**Keywords** Digital building twin (DBT) · Building information modeling (BIM) · IFC · Semantic web · Linked data · Semantic interoperability · Wireless sensor networks · Concrete · Sensors

## Introduction

The construction industry is involved in many domains: residential, industrial, civil structures, infrastructures such as roads, rail, waterways, etc. Since the end of the twentieth century, the European construction industry has been facing a double challenge.

* Maintaining a high level of employment compared to other industries which automate and exercise redundancies while increasing productivity.

* Aligning with an increasing level of requirements related to the environmental and societal issues such as protection of vegetal and animal species, water management, health, and safety for the workers on site.

Consequently, construction projects are complex environments where multiple stakeholders must cooperate and interact to create more and more intelligent structures. A "smart" construction needs to manage more significant amounts of data. This data must be monitored, registered, and structured to develop the services such as digital archives, data analysis, and interpretation for prediction. The complexity of information required for today's decisions for the construction industry requires digital techniques. Consequently, there are considerable investments in digitization at the national, regional, and global levels, along with a need for collaboration and interoperability between systems. Digital techniques do not ensure this happens seamlessly. The observed environment is traditionally modeled using GIS (geographic information systems), while the built environment is modeled using BIM (building information modeling). The traditional difference in granularity between these two perspectives (GIS and BIM) is more and more vanishing. Use cases and perspectives converge and largely overlap. The models from the two domains are tightly bound to each other. Every built construction has a location in the existing environment,

This article is part of the topical collection “Advances on Signal Image Technology and Internet based Systems” guest edited by Albert Dipanda, Luigi Gallo and Kokou Yetongnon.

<figure><img src="image_2.png" /></figure>

Ana Roxin
ana-maria.roxin@ubfc.fr

Wahabou Abdou
wahabou.abdou@u-bourgogne.fr

William Derigent
william.derigent@univ-lorraine.fr

<footnote n="1">¹ LIB EA7534, University Bourgogne Franche-Comté, Dijon, France</footnote>

<footnote n="2">² CRAN CNRS UMR 7039, University of Lorraine, Nancy, France</footnote>
the Earth (if we do not consider outer space), and GIS incorporates all built environments. Each of these two domains spends huge investments in capturing information from the other domain—today, mainly resulting in double-spending. The removal of the barriers to sharing information across disciplines will save significant investments and result in higher quality information.

In line with this, the construction industry has already embedded in its processes the management of vast amounts of digital data for investigating and describing existing conditions, monitoring traffic, toll systems, or operation. Many sensors are already widely used in Europe to report in real-time the information related to mobility. State-of-the-art technology offers multiple data sources, sensors, and analytic engines to automate and improve the process. However, instead of each individual monitoring their small area of responsibility, sensors should have the capability to communicate with each other and, in real-time, draw the picture of the whole building as it exists at a specific moment in time. This is the understanding we have of the Digital Building Twin (DBT) concept.

Following this definition (DBT as lively representations of buildings' status and environment), this article presents the contributions made in this field and in the context of the McBIM project, started in 2017 and funded by the French National Agency of Research (ANR). The article comprises three main sections: “Research Issues for Digital Building Twins” summarises research issues regarding DBTs to identify the main related research domains. For each of these domains, “Standards and State-of-the-Art Approaches for Digital Building Twins” provides the state-of-the-art, namely existing standards for digitizing the construction process, latest advances in Semantic Web technologies, and wireless sensor networks. Section “Pushing Forward the State-of-the-Art: The ANR MCBIM Approach” presents the contributions envisioned by the ANR McBIM project, namely explainable decision-support based on real-time sensor data integrated into a digital building representation.

## Research Issues for Digital Building Twins

Now in the twenty-first century, the construction domain faces an increasing number of challenges. Among those we may cite.

* The growing competition to win control over construction data and information among the stakeholders present, including asset managers and operators.

* The general tendency to develop and implement digital environments for monitoring the "connected humans" present in each territory e.g., "smart cities".

* The necessity to provide innovative structures and services to dramatically decrease the carbon impact in the construction and operation phases.

Following our definition of the DBT, and considering the above challenges, we divide the research issues into the following categories. Each category pertains to a different domain, and the related state-of-the-art is provided in the specific sub-sections of “Standards and State-of-the-Art Approaches for Digital Building Twins” mentioned below.

The first domain is building information modelling (BIM). The recent advances in this field, emphasizing effective information management, have dramatically improved delivery and performance efficiencies by catalysing increasingly innovative ways of working in construction. Implementing BIM open standards allows better strategic decisions and improved predictability through better risk management. Section “Digitizing the Construction Process: Standards for Digital Building Twins” provides an overview of existing BIM open standards.

While digital tools and technologies handle complex information exchanges in the construction domain, digitalization does not automatically ensure interoperability. Existing software implementations of open BIM standards highlight the growing need for collaboration and interoperability among those systems. Today, in the context of a construction project, only syntactic interoperability can be reached, which constrains every actor to use the same software. Still, issues arise whenever an actor uses a different software or tool to query or produce information, whatever form such information may take (models, spreadsheets, drawings, certificates, programs, etc.). Indeed, construction projects are complex systems that require an intensive collaborative effort from all stakeholders involved, along with a complete understanding of the cause and effect of all inputs. Without these, it is impossible to identify deviations from the plan early on, let alone implement corrective actions and prevent adverse outcomes. Efficiency, safety, and accuracy in construction projects require a common understanding of the information exchanged. Thus, the second domain is semantic interoperability and the challenges related to its implementation among actors, tools, and technologies as involved in a construction project. Indeed, a design DBT differs from a construction DBT, which differs from a Facility Management DBT. Still, all the underlying digital models must be synchronized persistently, and interoperable information exchange must be ensured among stakeholders. Section “Achieving Semantic Interoperability—Definition and Problem Statement” further explains what is understood by semantic interoperability and how it can be implemented.

The third domain pertains to Semantic Web technologies. Indeed, another issue for DBTs is to capture all the knowledge related to the construction processes themselves and
allow this knowledge to be handled by machines in (semi-) automatic ways. While today ICT systems allow storing BIM data and associating it with context elements (thus obtaining BIM information), they fail in providing the flexibility and the reasoning needed for lean decision-support. This is mainly because most of this knowledge is implicit and pertaining to human experts. Ontologies (as formal and explicit specifications of shared domain conceptualizations) allow integrating data and information from infinite data sources and information models and reasoning on such structures (making explicit knowledge from implicit knowledge). The flexibility, expressiveness, and the ability to explain all the deductions made have allowed ontology-based approaches (using Semantic Web technologies and Linked Data principles) to be identified as the only type of approach to address interoperability issues mentioned above [1] comprehensively. Section “Semantic Web Technologies for BIM and IoT” provides a review of such existing approaches as implemented and sometimes pushed at the level of standardization organizations.

After capturing underlying knowledge, the next step is to integrate building monitoring and analysis data, as provided by sensors deployed in the building. The fourth domain is wireless sensor networks (WSN). Our vision of a DBT goes beyond WSN, pushing the idea of materials that can communicate with their environment, sense it, and measure their internal physical states. It exploits the evolution of the Internet of things, leading to an increasing "sensorization" of physical spaces. In our vision, a DBT must be able to reason about its status and surrounding environment. Integrating sensor data with BIM models allows digitally representing physical and functional characteristics of physical spaces and, thus, provides relevant information about the building. Reusing the concept of "communicating material" (coined by CRAN in 2010 [2], our vision is entirely in line with the above idea of "smart cities", as DBTs must be aware of their environment and their status. Section "Data Dissemination and Energy Efficiency in WSN" summarizes state-of-the-art approaches existing in WSNs for ensuring data dissemination and energy efficiency.

Thus, to ensure semantic interoperability, sensor data are integrated into the DBT through ontologies. Analysis of such data as support of decision-making processes is implemented on top of such ontologies using logical rules and constraints. Explainable decision support is the fifth domain addressed by the McBIM project. Section “Specifying Expert Knowledge” presents how Semantic Web technologies ensure expert knowledge and how semantic rules can help implement explainable decision-support functionalities.

With the above issues in mind, this article presents how the French National Research Agency-funded ANR McBIM project helps push forward the state-of-the-art to provide an implementation for our vision of the DBT. Before submitting

our contributions, the sections below further explain the existing approaches related to the issues listed above and provide a review of current standards applicable in the related domains.

## Standards and State-of-the-Art Approaches for Digital Building Twins

Before describing the research orientations took in the context of the ANR McBIM project, this section will resume primary existing standards and approaches about the issues tackled by the project, namely: (1) digitizing the construction process, (2) achieving semantic interoperability, (3) semantic web technologies and their applications for BIM and IoT, (4) WSN: algorithms for data dissemination and approaches for energy efficiency and (5) specifying expert knowledge using semantic rules.

## Digitizing the Construction Process: Standards for Digital Building Twins

Digitizing the construction process has been addressed through different standards, at different levels e.g., internationally with the ISO, European-wide in the context of CEN, and national-wide in national chapters such as the French AFNOR and the German DIN. Most of the existing standards are difficult to implement today. This is either because they do not have a computer-defined implementation process (e.g., the ISO 19650 standard family), or because they lack interoperability with other existing standards (as an example, at the level of the ISO TC59/SC13 a 14th Joint Working Group has been created for tackling interoperability issues among BIM and GIS systems). This section presents these standards.

First and foremost, ISO 19650-1 (published in December 2019) provides the base definition for BIM: "Use of a shared digital representation of a built asset to facilitate design, construction and operation processes to form a reliable basis for decision-making" [3]. Much more than a 3D model, BIM is considered a process for sharing information along design, realization, and operation phases. ISO 19650-2 [4] provides a clear view of the process of information delivering in a digital building twin context: the client specifies (a) the Asset Information Model (AIM) or the "as-built" or "as maintained" asset, and (b) the Project Information Model (PIM) or the system for delivering the information. These specifications are related to the whole building life cycle, covering its design, construction, and operation phases. Following a system engineering approach, one could define the AIM as "the system to be delivered" and the PIM as "the system for delivering". The idea of providing a "reliable" mechanism for "decision-making" is crucial. It's also one
<figure><img src="image_3.png" /><figcaption>Fig. 1 The building bricks of BIM: IDM, MVD and IFC [3]</figcaption></figure>

of the main reasons Semantic Web technologies have been widely recognized as enablers for such a mechanism.

In the context of the ANR McBIM project, we consider BIM as a system that allows the generation, storage, and exchange of information about building elements and sensors. Such a BIM-based system goes beyond a simple viewer of three-dimensional building models. Following the assumption that a BIM system must enable "reliable" decision-making, the ANR McBIM system includes semantic knowledge alongside building models. State-of-the-art approaches in semantics for BIM are presented in the next section ("Semantic Web Technologies for BIM and IoT"). The ANR McBIM approach is discussed in section "Implement Explainable Decision-Support".

In this section, we present the standards forming the building bricks of BIM. They are illustrated in Fig. 1 [3]:

ISO 29481:2016 or "Information Delivery Manual" [5] is the standard for describing actors and processes involved in a contracted exchange. Following IDM, Exchange Requirements (ER) are specified, in the "building planning" phase, in natural language by domain experts (or BIM users) and software developers (or BIM providers). An ER defines what kind of information must be included in the exchange. IDM Process Maps (PM) are specified using Business Process Model and Notation (BPMN) and usually include stakeholders, project stages, and activities.

In the next building lifecycle phase, namely design, the above informal IDM is adapted as Model-View Definitions (MVD), which represent a subset of the complete IFC Schema and are serialized in XML (mvdXML) [5]. Each ER defined in an IDM is translated into specific concepts and relations from the IFC Schema (see the paragraph below). The goal of MVDs is to enable compliance and conformity-checking of IFC files according to constraints defined in IDMs.

ISO 16739:2013 "Industrial Foundation Classes" [6] is the open BIM standard for representing buildings' conceptual models. Following ISO 10303-21:2012 or STEP (Standard for the Exchange of Product data) [7], IFC's main serialization is EXPRESS. The *.ifc format is open, public, and non-proprietary, promoted by the international standardization organization bSI (buildingSMART International). The current version of IFC is IFC4.2, but IFC5 should be made official by 2022.

The IFC Schema is divided into four main layers listed below [8].

1. The Core Layer comprises the most general entity definitions, each entity having a "globally unique identifier" along with optional "owner and history information"

2. The Interoperability Layer defines entities specific to different disciplines, in terms of general products, processes, or resources, and provides the concepts and relations for exchanging and sharing construction information among different domains (inter-domain)

3. The Domain Layer further specializes the element definitions from the Interoperability Layer and enables the exchange of construction information in the context of the same domain (intra-domain)

4. The Resource Layer includes the description of costs, actors, quantities, constraints, approvals, etc. All concepts from the Resource Layer do not have a "globally unique identifier" thus they must be related to a concept from the core, the domain, or the interoperability layer.

According to the IFC Schema, building elements generalize elements present in a building and are modeled using the IfcElement concept. Doors, beams, or walls represent typical examples of building elements. An instance of IfcElement is assigned to a building's spatial structure (e.g. a
<table><caption>**Table 1** IFC Pset_ConcreteElementGeneral [8]</caption><thead><tr><td>Property</td><td>Description</td></tr></thead><tbody><tr><td>ConstructionMethod</td><td>Designator for whether the concrete element is constructed on site or prefabricated. Allowed values are: 'In-Situ' vs 'Precast'</td></tr><tr><td>StructuralClass</td><td>The structural class defined for the concrete structure (e.g. 'I')</td></tr><tr><td>StrengthClass</td><td>Classification of the concrete strength in accordance with the concrete design code which is applied in the project</td></tr><tr><td>ExposureClass</td><td>Classification of exposure to environmental conditions, usually specified in accordance with the concrete design code which is applied in the project</td></tr><tr><td>ReinforcementVolumeRatio</td><td>The required ratio of the effective mass of the reinforcement to the effective volume of the concrete of a reinforced concrete structural element</td></tr><tr><td>ReinforcementAreaRatio</td><td>The required ratio of the effective mass of the reinforcement to the effective volume of the concrete of a reinforced concrete structural element</td></tr><tr><td>DimensionalAccuracyClass</td><td>Classification designation of the dimensional accuracy requirement according to local standards</td></tr><tr><td>ConstructionToleranceClass</td><td>Classification designation of the on-site construction tolerances according to local standards</td></tr><tr><td>ConcreteCover</td><td>The protective concrete cover at the reinforcing bars according to local building regulations</td></tr><tr><td>ConcreteCoverAtMainBars</td><td>The protective concrete cover at the main reinforcing bars according to local building regulations</td></tr><tr><td>ConcreteCoverAtLinks</td><td>The protective concrete cover at the reinforcement links according to local building regulations</td></tr><tr><td>ReinforcementStrengthClass</td><td>Classification of the reinforcement strength in accordance with the concrete design code which is applied in the project. The reinforcing strength class often combines strength and ductility</td></tr></tbody></table>

<figure><img src="image_4.png" /><figcaption>**Fig. 2** Associating sensor types to IfcSensor instances using IFC4</figcaption></figure>

building storey) using IfcRelContainedInSpatialStructure. The property IfcRelDefinesByType allows setting an element type to an IfcElement. IfcBuildingElement is the subclass of IfcElement representing tangible building elements, some of which can be made of concrete (which is the focus of the ANR McBIM project). Among those elements ( subclasses of the IfcBuildingElement class), in the context of the ANR McBIM project, we will focus on IfcBeam and IfcWall elements.

Additional to classes, the IFC specification defines property sets ensembles of property taxonomies. Users can add missing properties from the Psets specified in the standard [8], indicating they are not present in the standard by removing the "Pset_" prefix from those property names. Each of the classes above (IfcBeam and IfcWall) implements the three Psets for concrete or precast concrete elements, namely Pset_ConcreteElementGeneral, Pset_PrecastConcreteElementFabrication and Pset_PrecastConcreteElementGeneral. As the ANR McBIM project will not consider precast elements, we list in Table 1. The properties in Pset_ConcreteElementGeneral, which are implemented in the context of the project.

sIfcSensor is a newly added concept in IFC4 and represents a device that measures a physical quantity and converts

it into a signal that an observer can read or by an instrument. Using IfcSensorType with a value from IfcSensorTypeEnum (listed below in t), several types of building sensors can be specified into building data. Figure 2 illustrates the concepts and relations that need to be instantiated to assign a sensor type to an instance of IfcSensor (Table 2).

## Achieving Semantic Interoperability: Definition and Problem Statement

Before discussing this, one must first define what interoperability is. ISO (International Standards Organization) provides several for "interoperability" depending on the domain of knowledge or application considered. Following the definition provided by ISO/TC 46/SC 4 Technical interoperability in ISO 21127:2014 [9], "technical interoperability" implies that either "two systems can exchange information" or that "multiple systems can be accessed with a single method". From a computer science point of view, several levels of interoperability are considered [10].

* Level 1 interoperability or physical interoperability is defined as the "computation, use, transfer and exchange of data" [11]
<table><caption>**Table 2** Sensor types defined in IFC4.1 [8]</caption><thead><tr><td>Constant</td><td>Description</td></tr></thead><tbody><tr><td>COSENSOR</td><td>A device that senses or detects carbon monoxide</td></tr><tr><td>CO2SENSOR</td><td>A device that senses or detects carbon dioxide</td></tr><tr><td>CONDUCTANCESENSOR</td><td>A device that senses or detects electrical conductance</td></tr><tr><td>CONTACTSENSOR</td><td>A device that senses or detects contact, such as for detecting if a door is closed</td></tr><tr><td>FIRESENSOR</td><td>A device that senses or detects fire</td></tr><tr><td>FLOWSENSOR</td><td>A device that senses or detects flow in a fluid</td></tr><tr><td>FROSTSENSOR</td><td>A device that senses or detects frost on a window</td></tr><tr><td>GASSENSOR</td><td>A device that senses or detects gas concentration (other than CO2)</td></tr><tr><td>HEATSENSOR</td><td>A device that senses or detects heat</td></tr><tr><td>HUMIDITYSENSOR</td><td>A device that senses or detects humidity</td></tr><tr><td>IDENTIFIERSENSOR</td><td>A device that reads a tag, such as for gaining access to a door or elevator</td></tr><tr><td>IONCONCENTRATIONSENSOR</td><td>A device that senses or detects ion concentration, such as for water hardness</td></tr><tr><td>LEVELSENSOR</td><td>A device that senses or detects fill level, such as for a tank</td></tr><tr><td>LIGHTSENSOR</td><td>A device that senses or detects light</td></tr><tr><td>MOISTURESENSOR</td><td>A device that senses or detects moisture</td></tr><tr><td>MOVEMENTSENSOR</td><td>A device that senses or detects movement</td></tr><tr><td>PHSENSOR</td><td>A device that senses or detects acidity</td></tr><tr><td>PRESSURESENSOR</td><td>A device that senses or detects pressure</td></tr><tr><td>RADIATIONSENSOR</td><td>A device that senses or detects radiation power</td></tr><tr><td>RADIOACTIVITYSENSOR</td><td>A device that senses or detects atomic decay</td></tr><tr><td>SMOKESENSOR</td><td>A device that senses or detects smoke</td></tr><tr><td>SOUNDSENSOR</td><td>A device that senses or detects sound</td></tr><tr><td>TEMPERATURESENSOR</td><td>A device that senses or detects temperature</td></tr><tr><td>WINDSENSOR</td><td>A device that senses or detects airflow speed and direction</td></tr><tr><td>USERDEFINED</td><td>User-defined type</td></tr><tr><td>NOTDEFINED</td><td>Undefined type</td></tr></tbody></table>

* Level 2 or syntactic interoperability concerns the "ability of two or more systems or services to exchange structured information" [12]

* Level 3 semantic interoperability comes on top of the two previous levels and, when implemented, enables "the meaning of the data model within the context of a subject area [to be] understood by the participating systems" [13]

These interoperability levels are interconnected, e.g. implementing Level L's interoperability requires implementing interoperability of the level (L-1). Thus, reaching semantic interoperability cannot be done without having implemented physical and syntactic interoperability. Physical interoperability is solved using hardware standards (e.g. Ethernet) and standard network protocols (e.g. TCP/IP or HTTP). Syntactic interoperability has also been resolved through the specification and implementation of syntax standards such as XML, HTML, WSDL, or SOAP.

When it comes to semantic interoperability, several flavors exist, each resulting in different actions that can be performed on the underlying knowledge. To best apprehend

these concepts, we will start from existing ISO definitions for "semantic interoperability" [10].

* ISO 13606-1:2018 [14] defines it as the "ability for data shared by systems to be understood at the level of fully defined domain concepts". This definition points to the first level of semantic interoperability, which is "understanding of data". Such understanding is usually characterized as minimum semantic interoperability. It is enabled by approaches based on Resource Description Framework (RDF). In this case, only the minimum knowledge is modeled: the concept of a "building" is related to the concept "sensor" through the relation "contains".

* ISO 16678:2014 [12] considers such interoperability as "the ability of two or more systems or services to automatically interpret and use information that has been exchanged accurately". This definition places the need for information interpretation, information being defined as contextualized data. This is called extended semantic interoperability and requires minimum semantic interoperability (thus RDF). This is called extended semantic
interoperability and requires minimum semantic interoperability (thus RDF). The RDF Schema language allows defining a common interpretation of the elements contained in the message exchanged. Following our previous example, with RDF Schema, the "building" concept is identified by an URI (Unified Resource Identifier), allowing a computer agent to dereference the concept and access an RDFS-defined ontology specifying additional knowledge about a "building". *Extended semantic interoperability* allows obtaining additional knowledge about the concepts handled, but it does not allow to constrain such knowledge. Following our example, with this level of interoperability it is impossible to specify that if a "sensor" is in a "building", the same "sensor" cannot be contained in a "different building".

* The definition from ISO/IEC 19941:2017 [13] point to *full semantic interoperability* and requires higher-order ontology description languages from the OWL family such as OWL-DL, OWL 2 RL, etc. This level of interoperability allows bounding knowledge: allowed interpretations represent the lower bound, while constraints preventing specific inferences form the upper bound. In the context of our "building" containing "sensors", an incoherence would be notified if the same "sensor" instance is in two different "building" instances.

Regarding the digitalization of construction, engineering, and architecture (AEC), the French expert commission PTNB identified Linked Data and Semantic Web technologies as the only approach that fully addresses interoperability issues in these domains [1]. Thus, the next section briefly presents knowledge modeling with Semantic Web standards and the main existing ontologies pertaining for digital building twins.

## Semantic Web Technologies for BIM and IoT

In the last decade, Semantic Web and Linked Data technologies have received increasingly more attention to facilitating knowledge modeling in the AEC/FM sector. Since then, the topic of using semantics for delivering actionable knowledge has continuously gained attention from both researchers and industrials. This section's scope is not to provide a state-of-the-art regarding Semantic Web, but to list and describe main conceptual differences associated to knowledge modeling with Semantic Web languages such as RDFS or OWL.

Indeed, modeling with Semantic Web languages is different than object-oriented modeling. For example, in the EXPRESS language (used for serializing IFC), all the concepts are related to one single key or primary (meta-) concept. In EXPRESS, a property is always declared in the context of an entity. With Semantic Web languages, classes and properties are defined independently. The belonging of

an instance to a class is determined by the set of necessary and sufficient conditions that the individual must observe. In the context of Semantic Web, a class is defined as an ensemble of properties its individuals must all implement, with specific values. Another difference in semantic modeling is the Open World Assumption (OWA), which states that it is not because some knowledge is missing or was not specified that it must be assumed as false. In EXPRESS, what is not specified is by default assumed false—it is called a Closed World Assumption (CWA). In Semantic Web, the assumption that applies is the No Unique Name Assumption (UNA). Indeed, Semantic Web handles resources identified by means of URIs (Unique Resource Identifiers). It is only if two URIs are identical, that the resources they identify are considered identical. In the context of BIM (namely in IFC files), resources are identified by means of so-called GUIDs (Globally Unique Identifiers) that usually contain UUID data. The main issue with this approach is that these GUIDs are not unique from one IFC file to the other. This is mainly justified by the freedom of implementation provided by the IFC standard for software companies. Identification using URIs as implemented in the context of the Semantic Web allows waiving the issues related to UUIDs.

Several ontologies exist and allow modeling and annotating data in digital building twins, namely building, sensor, urban and geographic data. They are listed and briefly described in the table below (see Table 3). More details about these ontologies, the Linked Data principles [15] they respect, along with an evaluation of their modeling quality can be found by the reader in [16].

## Data Dissemination and Energy Efficiency in WSN

Several research initiatives underlined the benefits of integrating Internet of things technologies such as RFID, WSN into construction products and an extensive review of research works or industrial initiatives in the construction domain using RFID technologies. These approaches show that RFID technologies have been tested and can bring significant economic leverages in all the phases of the precast concrete lifecycle, e.g. in precast quality management [17] or for construction supply chain [18], by bringing product information to stakeholders. Additionally, WSNs are also seldom used when active monitoring of the structure is needed as in manufacturing (for early-age concrete inspection as in [19]) or for structure health monitoring [20]. Industrial initiatives are also numerous, but RFID tags are used most of the time [16]. For example, we may cite Lafarge, who integrated RFID tags directly into the concrete of the D2 tower<fnref n="1" /> for traceability applications.

<footnote n="1">¹ https://skyscrapercenter.com/building/d2-tower/9831.</footnote>
<table><caption>**Table 3** Existing ontologies pertaining for digital building twins</caption><thead><tr><th>Ontology name and URI</th><th>Description</th><th>Relation to standardization organization</th></tr></thead><tbody><tr><td>BOT (Building Topology Ontology) [56]<br>https://w3c-lbd-cg.github.io/bot/bot.ttl</td><td>BOT is one of the outputs from the W3C Community Group (CG) Linked Building Data (LBD). Currently published as an unofficial draft, BOT is a lightweight ontology containing only 7 classes (Building, Element, Interface, Site, Space, Storey and Zone), one datatype property (hasSimple3DModel) and 14 object properties (adjacentElement,adjacentZone, containsElement, containsZone, interfaceOf, intersectingElement, intersectsZone, has3DModel, hasBuilding, haselement,hasSubElement, hasSpace, hasStorey and hasZeroPoint). The Bot ontology eases the handling and the querying of building models in terms of zones as areas with spatial 3D volumes</td><td>Contribution of the W3C CG LBD</td></tr><tr><td>BRICK Schema [57]<br>https://brickschema.org/schema/1.1/Brick.ttl</td><td>Now at its version 1.1, the BRICK ontology comprises 831 classes, 23 object properties but no datatype properties. It is linked to concepts and properties in the ontologies such as QUDT, SKOS, SOSA or vcard. The "things" present in buildings are modelled using the Entity class, which has 3 sub-classes representing physical entities (with a physical location), virtual entities (software-based) and logical entities (defined by rules). Object properties (or relationships in the BRICK vocabulary) are based on 3 main types e.g. composition, topology and telemetry<br>The ontology provided adapts the above mentioned BRICK philosophy using the OWL and RDF Schema languages. Still, it has not yet been described or illustrated in support of reasoning functionalities<br>BRICK is related to Project Haystackª which is also an metadata vocabulary using tags for annotating building system and smart device data</td><td>ASHRAE (American Society of Heating, Refrigerating and air-conditioning engineers)</td></tr><tr><td>CityGML Building Module [58]</td><td>An AbstractBuilding is defined as a sub-class of a site, itself sub-class of a CityObject. Several properties are defined for the AbstractBuilding class such as its function, usage and roof type (all being typed as a CodeType in GML), along with properties such as its measured height, storeys (and storey heights) above and below ground, its year of construction and demolition. Additional properties specific to noise calculation scenarios are also present, for example the level of building reflection (in dB) or building's number of inhabitants. One can add sub-classes to the AbstractBuilding class by prefixing them with "featureType"</td><td>OGC (open geospatial consortium)</td></tr></tbody></table>
<table><caption>**Table 3 (continued)**</caption><thead><tr><th>Ontology name and URI</th><th>Description</th><th>Relation to standardization organization</th></tr></thead><tbody><tr><td>COBie [59]<br>COBieOWL [35]</td><td>First issued in 2007 by a laboratory of the U.S. Army Corps of Engineers, COBie uses a spreadsheet-based format. Without addressing geometric data, COBie eases the collaboration among stakeholders while specifying information about a building during different lifecycle phases (design, construction, operations, maintenance and asset management). The COBie format is largely implemented today in commercial software</td><td>bSI, US National Institute of Building Science, BSI (British Standards Institute) 1192-4:2014</td></tr><tr><td>DogONT [67]<br>https://iot-ontologies.github.io/dogont/</td><td>Standing for "Ontology Modelling for Intelligent Domotic Environments", the DogONT ontology was conceived to tackle the issue of domotic systems' interoperability. It defines 167 cases for different devices, states and functionalities, each pertaining to 5 levels: Building Thing (all existing resources, controllable or not), Building Environment (the location of the resources), State (the stable configurations for controllable resources), Functionnality (what a resource can do) and Domotic Network Component (network functionalities of networked resources)</td><td>No</td></tr><tr><td>FIEMSER [60]</td><td>This ontology was developed by TNO, between January 2014 and March 2015, during the EU FP7 project of the same name FIEMSER (Friendly Intelligent Energy Management Systems in Residential Buildings). It contains 103 classes, pertaining to 8 different "views" which allow describing a building's spatial structure. A Building consists of several BuildingSpace (class representing a physical space in a building), each BuildingSpace being part of a BuildingPartition. Functional spaces are represented as BuildingZone, each BuildingZone comprising several BuildingSpaces. Devices present in such building spaces are also modelled either as HomeEquipment (in relation to building energy e.g. Generator, Load, Mechanism or Storage) or ControlledDevice (typically a sensor or an actuator)</td><td>Related to SAREF, which is now an ETSI standard</td></tr><tr><td>GeoSPARQL<br>https://github.com/opengeospatial/ogc-geosparql</td><td>Defined by the OGC, GeoSPARQL comprises a vocabulary for representing geospatial data with RDF and an extension of the SPARQL query language for handling spatial relationships. GeoSPARQL allows qualitative spatial reasoning and quantitative spatial calculus. Following a modular approach, GeoSPARQL Core comprises extension for topology vocabulary, geometry, query rewrite and RDF Schema entailments. 2 versions are available: v1.0 and v1.1</td><td>OGC</td></tr></tbody></table>
<table><caption>**Table 3 (continued)**</caption><thead><tr><th>Ontology name and URI</th><th>Description</th><th>Relation to standardization organization</th></tr></thead><tbody><tr><td>GML [68]<br/>a) ISO 19136:2015 https://def.isotc211.org/ontologies/iso19136/<br/>b) RDF definition of GML 3.2.1 geometries http://schemas.opengis.net/gml/3.2.1/gml_32_geometrysdiff.pdf</td><td>Geography Markup Language is a standard specified as an XML grammar by the OGC. GML follows GML Schema and allows modelling and exchanging spatial data. Its 3.2 version has been adapted as an ISO standard (ISO 19136:2007), following the collaboration between OGC and ISO TC 211. The latest version of the ISO standard (ISO 19136:2015) extends the previous specification and refernces the SKOS vocabulary while providing a Turtle serialization. The UML behind ISO 19136:2015 has been translated into an ontology by the ISO/TC 211/AG 06 GOM (Group for Ontology Maintenance). Version 3.2.1 of GML has been adapted into an ontology of geometries by OGC<br/><br/>Using an EXPRESS to OWL converter, the whole IFC EXPRESS specification has been translated into OWL for each of the standard versions published e.g. IFC2×3, IFC4ADD1, IFC4ADD2<br/><br/>ISO 19150 https://def.isotc211.org/ontologies/iso19150/ ISO 19150:2012 defines rules for developing OWL ontologies and thus reaching semantic interoperability for geographic information. It is mainly a mapping of UML constructs into OWL e.g. a description of how to convert into OWL the General Feature Model (GFM) defined in ISO 19109<br/><br/>ISO 19150:4:2019 further defines as an OWL ontology the concept of service, through classe such as GeoWebServiceDescription, GeoWebServiceIdentification, and object properties (e.g. date, language) and datatype properties (e.g. description, version). The ontology is generated from an UML model, being thus too complex and too expressive, while not respecting OWL modelling principles. As an example, the above mentionned object property e.g. "date" should've been modelled as datatype property and should've had a literal domain such as xsd:xsd:date</td><td>OGC / ISO 19136:2015<br/><br/>buildingSmart International<br/><br/>ISO TC 211</td></tr></tbody></table>
<table><caption>**Table 3 (continued)**</caption><thead><tr><th>Ontology name and URI</th><th>Description</th><th>Relation to standardization organization</th></tr></thead><tbody><tr><td>ISO 21597-2020 Parts 1&2</td><td>ISO 21597 ICDD (Information Container for Data Drop)<br>standard addresses information deliveries for construction industry. In this specific context, an information delivery is usually an ensamble of sketches, models, spreadsheets and other multimedia files (videos, photos, etc.). ISO 21597 comes in two parts: Part 1 provides the Container and the Linkset ontologies, while Part 2 specifies the Extended Linkset ontology. With the elements from Part 1, one is able to specify an archive (as a file with the *.icdd extension) containing both the ressources needed in the information delivery long with a description of these resources and how they inter-related with each other (using concepts defined in the Linkset ontology). Part 2 further pseficates the concepts from the Linkset ontology in order to define annotations for human users. The capacities in terms of reasoning for both Part 1 and Part 2 are very limited. Indeed, while Part 1 ontologies do support inference, their high expressivity and complexity provides their scalability; Part 2 only defines sub-classes of classes defined in the Linkset ontology with some annotations and definitions, thus no reasoning is possible (and this is mentioned in the standard)</td><td>ISO TC59/SC13</td></tr><tr><td>OWL-Time<br>https://www.w3.org/TR/owl-time/</td><td>Candidate to a W3C Recommendation since the 26th of March 2020, the Time ontology follows a collaboration between W3C and OGC through the Spatial Data on the Web Working Group. This ontology allows describing temporal entities, such as time intervals, along with their topological relations between time instances and time intervals</td><td>W3C Spatial Data on the Web Working Group</td></tr><tr><td>SAREF [52]<br>https://saref.etsi.org/saref4bldg/v1.1.2/</td><td>Initially developed in the same EU FP7 as the FIEMSER ontology, SAREF is now an ETSI standard [51]. Following a modular structure, SAREF comprises 110 classes and 42 properties, linked with concepts and properties from other existing ontologies and vocabularies such as SSN, Time, WGS84, units of measure ontology (OM) and several other ontologies from the FIEMSER project (e.g. Echonet, EnOcean, SEP2, UPnP). Starting from the Device concept, SAREF further specifies the Tasks it accomplishes, and the Commodities it is used for. A Device has a Function and a State, and offers a Service, while making a Measurement</td><td>ETSI TS 103 264: " SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping"</td></tr></tbody></table>
<table><caption>**Table 3 (continued)**</caption><thead><tr><th>Ontology name and URI</th><th>Description</th><th>Relation to standardization organization</th></tr></thead><tbody><tr><td>SAREF4BLDG [53]<br>https://saref.etsi.org/saref4bldg/v1.1.2/</td><td>Specified as the third part of the SAREF standard, this represents the extension of SAREF for the building domain. The starting point of this extension is the SpatialThing class as defined in the WGS84 ontology. This concept is further divided by SAREF4BLDG into a Building, a BuildingSpace and a PhysicalObject (that can either be a BuildingObject or a saref:Device). SAREF4BLDG specifies all device types considered by the IFC4.1 standard as 62 classes, each belonging to one of the levels considered namely a BuildingDevice (DistributionDevice or a ShadingDevice), a TransportElement or a VibrationIsolator. Links have been defined to the ifcOWL ontology for IFC4.1 by means of rdfs:seeAlso</td><td>ETSI TS 103 410-3: "SmartM2M: Smart Appliances Extension to SAREF; Part 3: Building Domain"</td></tr><tr><td>SEAS [62]<br>https://ci.mines-stetienne.fr/seas/seas-1.1.ttl</td><td>The SEAS ontologies have been developed in the context of the ITEA2 project of the same name. SEAS comprises 4 horizontal modules, the core module linking them all together. The module FeatureOfInterestOntology reuses concepts from SOSA/SSN ontologies and further specifies patterns for describing features of interest (e.g. a fridge) along with their properties (e.g. consumption). The EvaluationOntology module addresses qualifications of property evaluations, also by defining ontology patterns. The ProcedureExecution-Ontology addresses ProcedureExecutors (e.g. sensors, web services) and the methods implemented as Procedure (e.g. sensing, processing). Finally the SystemOntology module defines patterns to characterize systems and their interactions (e.g. subSystemOf, connectedTo)</td><td>ETSI – Extension to SAREF were designed and proposed as an ETSI Technical Specification based on the patterns from SEAS [62, 69]</td></tr><tr><td>SSN (Semantic Sensor Networks) http://www.w3.org/ns/ssn/<br>SOSA (Sensor, Observation, Sample and Actuator) http://www.w3.org/ns/sosa/[63]</td><td>SSN allows describing sensors and their observations. Concepts such as time and location are reused from other existing ontologies (OWL-Time and WGS84). This ontology is a modular version of the initial SSN developed by the Semantic Sensor Networks W3C Incubator Group, and is aligned with the upper level ontology Docle-UltraLite (DUL).<br>SOSA is the central block of SSN, defining concepts such as Sensor, Actuation, Observation, FeatureOfInterest, ObservableProperty, Procedure or Result. These concepts are further linked to SSN concepts e.g. sosasSensor rdfs:subClassOf ssn:System</td><td>Follows the work of the W3C Spatial Data on the Web Working Group, and is a W3C Recommendation since 19 October 2017</td></tr></tbody></table>
<table><caption>**Table 3 (continued)**</caption><thead><tr><th>Ontology name and URI</th><th>Description</th><th>Relation to standardization organization</th></tr></thead><tbody><tr><td>Web of Things (WoT) Thing Description [64]<br>https://github.com/w3c/wot-thing-description/tree/master/ontology</td><td>Starting from the central class of Thing, the vocabulary defines how it can be used (through 3 types of Interaction-Affordances e.g. Properties, Actions and Events), what machine-understandable data it can exchange (specified as URI schemes or content types based on MIME types) and what links to other Things it has (expressed as Web links e.g. href, type, rel or anchor). Through the JSON-LD serialization [65] links can be made to ontology concepts identified by URIs on a Web scale</td><td>W3C Recommendation since 9 April 2020</td></tr></tbody></table>

Data dissemination in a wireless sensor network (WSN) relies on cooperation amongst nodes. Given that each sensor node has a limited transmission range, some intermediate nodes could act as relays to enable extensive network coverage. A WSN is considered a set of nodes equipped with wireless communication interfaces that work together. Concerning energy in WSN, a lot of research works have been proposed in the last two decades. Following the top-down survey for energy efficiency in WSNs [21], Fig. 3 introduces various ways to address this issue.

If all categories can be explored to improve energy efficiency, in ANR McBIM we focus on data dissemination across the network. Some protocols are based on RPL (Routing Protocol for Low-Power and Lossy Networks) [21]. In [22] the authors proposed an RPL-based routing protocol (named PriNergy) that meets the quality-of-service requirements, avoids network congestion, and seeks for energy-efficiency. Tita et al. [23] proposed a protocol that uses two-hop information to improve the performance of WSNs in terms of energy and quality-of-service. They introduced two metrics: (1) the potential relay information (PRI), which considers the residual energy, the distance, the delay, and the quality of the links to neighbour nodes, and (2) the neighbourhood state index (NSI) algorithm, which helps reducing delay and load traffic. Some protocols use optimization techniques to improve clustering in WSNs. The authors of [24] used the MOA (Mayfly Optimization Algorithm) [25] to efficiently select the cluster heads (CH). This approach considers energy, position, and distance when choosing a CH. To optimize the network's overall energy, a rotation of the CH role over time is considered. Other techniques were explored in works like energy harvesting [17] or data reduction [26].

Routing is an essential task in WSN communications. Routing protocols allow finding paths to transport data from a source to a destination (e.g., the sink). A path is made up of the list of intermediate nodes. According to [27], WSN routing protocols are classified according to the network structure or the protocol operations (see Fig. 4). Various communication technologies like IEEE 802.15.4 (ZigBee), IEEE 802.11 (Wi-Fi), IEEE 802.15.1 (Blue-tooth Low Energy), and so on can be used to transmit data through the network to an internet gateway. In the ANR McBIM project, low frequencies (from 900 MHz band to 2.5 GHz) were preferred for propagation in concrete. Successful communication tests were, by example, realized using LORA, BLE or ZigBee.

In flat routing protocols, all nodes play the same roles. These protocols are used, for example, in flooding or data-centric dissemination cases. In some cases, each node's role may depend on several criteria (position, remaining energy, etc.). This class is known in some other cases as hierarchical routing protocols.

<footnote>ahttps://project-haystack.org/download.</footnote>
<figure><img src="image_5.png" /><figcaption>Fig. 3 Approaches addressing energy efficiency in WSNs (adapted from [21])</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Table 4 Comparison of WSN routing protocols [66]</figcaption></figure>

<table><thead><tr><td>Protocol name</td><td>Energy efficiency</td><td>Maintenance cost</td><td>Resilience to link failure</td><td>Scalability</td></tr></thead><tbody><tr><td>LEACH</td><td>-</td><td>+</td><td>+</td><td>-</td></tr><tr><td>PEGASIS</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>CCM</td><td>+</td><td>-</td><td>-</td><td>-</td></tr><tr><td>CRBCC</td><td>+</td><td>+</td><td>+</td><td>-</td></tr><tr><td>BCBRP</td><td>-</td><td>-</td><td>++</td><td>-</td></tr></tbody></table>

LEACH (Low Energy Adaptive Clustering Hierarchy) [28] is one of the most popular WSN clustering protocols. Clusters are computed in a distributed way. A probability p is calculated for selecting cluster heads (CH), each node selecting the CH with whom it can communicate with the minimum energy. Any node can endorse the CH role over time to best distribute the traffic load and energy consumption. PEGASIS (Power-Efficient Gathering in Sensor Information Systems) [29] proposes an improvement of LEACH. It forms a chain amongst nodes and favors communications between closest neighbors. The Chain-Cluster-based Mixed routing protocol (CCM) [30] relies on LEACH and PEGASIS benefits, especially latency and energy consumption. CCM forms routing chains and selects a head (amongst chain heads), sending aggregated data to the sink. Chain-Routing-Based on Coordinates-oriented-Cluster (CRBCC) [31] is another cluster-based routing protocol. Nodes are grouped depending on their geographical coordinates. The clusters are formed based

on the Y coordinate, and the algorithm forms a chain within each cluster and elects a leader for each chain. Balanced Chain-Based Routing Protocol (BCBRP) [32] is another data dissemination protocol that aims to extend the lifespan of the sensor nodes. It relies on three steps: (1) split the network into several subnetworks with equal size, then (2) select a bridge node within each subnetwork, and
<figure><img src="image_7.png" /><figcaption>**Fig. 5** Illustration of semantic annotation in the interpretation of IFC data [54]</figcaption></figure>

finally (3) build a chain that interconnects the subnetworks via the bridges. Table 4 summarizes the advantages of the common WSN routing protocols.

Usually, sensor nodes are battery-powered. The batteries could be hard to recharge or replace (because WSN could be deployed in hostile environments). Therefore, energy efficiency is a critical issue in this kind of network.

Nodes consume energy to send or receive messages and for carrier listening. Reducing the transmission power can lead to less energy consumption when sending messages. However, this method reduces the transmission range, increases the number of hops, and lengthens the paths. Energy could also be saved by arranging nodes to not remain active during the hole monitoring time. The sensor nodes will alternate the active and inactive (sleep) modes. The alternating of active/inactive modes is referred to as the duty cycling approach.

Duty cycling is an effective energy conservation mechanism in WSN. The lower the duty cycle, the longer a node is idle and saves energy. This lengthens the network lifetime. The duty cycle can be applied to all subsystems of a sensor node, including the radio communication subsystem. When they are actives, nodes can send or receive messages or simply listen to the radio channel. Inactive listening (idle) can represent a significant consumption of energy over time. Two common phenomena favour duty cycling. First, it exploits the redundancy in wireless sensor deployment [3]. The system can thus adaptively select only a minimal subset of nodes that will remain temporarily active to maintain connectivity. Second, it exploits the fact that in most applications, occurrences of events are rare. Most of the time, the nodes are listening to the channel. In other words, the selected subset of nodes must not be active all the time. Moreover, these protocols auto organizing the network are led by nodes considering their own or a local view of the network. These decentralized decision-making protocols are interesting locally but could be sub-optimal for the whole network.

## Specifying Expert Knowledge

Integrating expert knowledge in data processing allows delivering a better understanding, thus handling such data. For addressing this, Semantic Web standards allow defining metadata (descriptions of the data) and constraints, thus supporting reasoning processes on top of the gathered data. Such approaches are beyond state-of-the-art today, as they have been proven efficient through implementation [3]. To support this claim, two references can be cited: (1) the IfcWoD (Web of Data) adaptation of ifcOWL, which allows almost 90% reduction of query execution times [33] and (2) the federation approach exploiting the FOWLA architecture [34] allowing to interoperate the COBieOWL [35] and ifcOWL ontologies (as provided by buildingSMART [1]). Using the ifcOWL ontology corresponding to the IFC version of the building data exchanged, one can annotate such data and ease its interpretation both by humans and machines (as illustrated in Fig. 5).

When applying Linked Data principles [15] to define semantic links among those ontologies and vocabularies, it is possible to create a so-called knowledge continuum (through explicit semantic links specified among their concepts and relations). Such combined knowledge becomes a conceptualization of the application domain considered. Semantic Web languages allow an adequate expressivity level for such conceptualizations, while maintaining the overall system's efficiency. On top of such conceptualizations, a set of semantic rules can be defined, corresponding to the expert "know-how". Contrary to machine learning approaches, semantic rules are based on description logs and enable tracking and constraining how the expert system rules. Such methods are called programmed or constrained reasoning. They must be implemented in AI-based systems where the deductions must be explainable to the human user (see Fig. 6).

Not only can one implement constrained reasoning on top of such modeled knowledge but semantic rules also allow
<figure><img src="image_8.png" /><figcaption>Fig. 6 Defining rules and interpreting them [55]</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 7 Using semantic rules to define the concept of a building envelope</figcaption></figure>

defining concepts missing in the considered ontologies. For example, the IFC specification does not hold a building envelope concept, meaning all elements of a building that have an isExternal property defined in the related IFC data. The rules illustrated below (Fig. 7) demonstrate how one can use semantic rules to describe this missing concept [36].

Furthermore, such rules allow specifying building abstractions corresponding to existing Levels of Detail (LOD) or some specific expert needs. Authors in [37] have defined and implemented an approach based on semantic rules that can extract the exact sub-portion of an IFC file following an ensemble of provided elements e.g., either GUIDs, or relation or concept names.

Lead by LIB (Laboratory of Computer Science of Bungundy), WP4 from the ANR McBIM project will compose and specify constraints and rules about expert knowledge in structural health monitoring in construction and exploitation phases. Based on this, WP4 will provide methods

to implement semantic compliance checks at these two building lifecycle phases, thus allowing to specify human knowledge and experience in a computer-processable way. Sections “Implement a Standard-Compliant Solution” and “Implement Explainable Decision-Support” further detail developments done in the context of this WP.

## Pushing Forward the State-of-the-Art: The ANR McBIM Approach

With a consortium of academics and industrials, ANR McBIM focuses on the construction industry's need for new standards and methods for material tracking and recycling. In this project's context, we consider ontological approaches for constraint checking, following consistent information taxonomies and protocols and processes for information exchange, conforming to the concepts and principles defined
<figure><img src="image_10.png" /><figcaption>**Fig. 8** The overall vision of the ANR McBIM project</figcaption></figure>

in the ISO 19650 standard family [3, 4, 38–40]. More specifically, the ANR McBIM project aims to design a "communicating concrete", meaning embed concrete building elements with sensors and integrate the sensed data into the BIM platform, thus delivering an interoperable digital building twin (see Fig. 8).

The project exploits the benefits of "communicating concrete", namely:

a. its data storing capacity allows them to convey information related to design, manufacturing, and logistics, valuable during these lifecycle phases or BOL (Beginning Of Life), but also during EOL (End Of Life), meaning building demolition and recycling;

b. its sensing and processing capacities, practical during MOL (Middle Of Life), representing operation and maintenance lifecycle phases.

Two building lifecycle phases are considered for implementing and testing the considered approach, namely construction and exploitation phases (for structural health monitoring).

Still, before reaching this vision, several additional challenges must be tackled for integrating real-time sensor data with BIM models. Indeed, open BIM standards do not provide capabilities to process real-time data, as do those supplied by sensors in smart environments. Some of the specific challenges are (a) extracting knowledge out of BIM, using the Industry Foundation Class (IFC) standard [6], (b) ensure real-time processing and reasoning over sensor data. Many approaches have been proposed to solve these challenges by integrating BIM with real-time data. However, most of them lack practical validation or are highly dependent on domain specifications. Attempts are related to the development of applications concerning specific application domains, namely (1) energy management, (2) building automation, (3) fire control, (4) health and safety, (5) safety risk, and (6) augmented reality (AR), and therefore they

cannot be considered as standard solutions, adaptable to a large class of application domains. These facts reveal a lack of a standard solution for combining BIM with real-time data that streamlines the creation of sophisticated solutions to leverage sensor data with complex characteristics of the built environment.

For addressing these challenges, ANR McBIM provides means to relate the physical world (e.g. the building element made of concrete) to the digital world (e.g. the data associated with this particular building element). For collecting the data, in the project's context, we use a WSN embedded into the concrete and composed of two types of nodes: the sensing nodes (SN) and the communicating nodes (CN). These are illustrated in the figure below (see Fig. 9). Sensing nodes are in charge of capturing the building element's physical values (e.g. temperature, moisture) and relaying them to the communicating nodes. SNs are powered via RF harvesting techniques. The communicating nodes have more capabilities and are battery-powered. They can communicate with each other and with the digital world (e.g. as a gateway). This architecture allows obtaining the values used for implementing explainable decision-support, as described in section “Implement Explainable Decision-Support”.

In the context of the ANR McBIM project, we seek to conceive and implement a solution for integrating BIM with sensor data. The following objectives are therefore pursued: (1) consider an updated building model, (2) integrate data from multiple sensors, (3) resolve queries that combine sensor with building data, (4) produce answers for those queries in real-time in terms of the sensor data processed, and (5) over a clean, easy-to-use, and simple interface to the user. As mentioned in the introduction, this is a different concept from BIM, notably from the goals pursued. Indeed, while BIM only renders the elements in an IFC file, a digital building twin must integrate real-time data, mainly obtained from sensors integrated into the building. Moreover, as it is an ongoing project, not all the objectives above have been reached. The article at hand focuses on the use of ontologies
<figure><img src="image_11.png" /><figcaption>**Fig. 9** Communication among sensor nodes in the WSN considered for ANR McBIM [17]</figcaption></figure>

for seamlessly integrating data gathered from sensors into building data. Sections below examine in more detail points (2) to (4) from the objectives listed. Sections “Designing Robust Wireless Communications” to “Reorganizing the Sensors” further discuss details regarding sensor communication, placing, and reorganization. Section “Implement a Standard-Compliant Solution” details the structure of the McBIM ontology and its relationship with existing standards applying in the context of BIM. Finally, “Implement Explainable Decision-Support” illustrates how the standard ifcOWL ontology can be used for implementing monitoring of specific building elements.

self-protection (also known as self-chop). These objectives have been recently extended [41]. To ensure self-chop properties, autonomous systems must be able to interact with their environment thanks to sensor and effector modules. In addition, they must have a knowledge base that can be made up of a simple configuration rules or enriched by artificial intelligence algorithms. The interaction with the environment must be continuous. It makes it possible to adapt to changing contexts. The overall working process of such a system is described by a closed control loop [41] (illustrated by Fig. 10).

## Designing Robust Wireless Communications

When sensor nodes are deployed in hostile or difficult-to-access environments, they should be designed to operate autonomously. In the framework of the McBIM project, human interventions to manage the sensor nodes after they have been poured into concrete will be very difficult. The autonomic computing paradigm allows self-management.

Self-management systems with limited human interventions allow to cope with complex management systems and reduces the overall maintenance costs. Systems become a collection of interconnected autonomous entities. The autonomic computing paradigm is inspired by the autonomic nervous system. The main objectives for autonomic systems are self-configuration, self-healing, self-optimization, and

<figure><img src="image_12.png" /><figcaption>**Fig. 10** Illustration of the interactions between an autonomous element and the knowledge base</figcaption></figure>
<figure><img src="image_13.png" /><figcaption>**Fig. 12** Target coverage while ensuring network connectivity</figcaption></figure>

<figure><img src="image_14.png" /></figure>

## Sensor Placing in the Communicating Material

The sensor nodes will be poured into the concrete to monitor specific areas of a wall. These areas are called targets. Sensor nodes should be as a priority around the targets. Redundancy can help to extend WNS lifetime (using duty cycling) and make up a fault-tolerant system. Figure 11 illustrates sensor deployment around the targets to form a connected network. Figure 12 shows how sensor placement can be modified to provide interconnection and act as relay nodes. The sensor placement around specific areas is like the target monitoring problem [42].

The efficient deployment of sensor nodes can be defined as a multi-objective optimization problem. Given a number of sensor nodes, the goal will consist of maximizing the redundancy around the targets while guaranteeing the network's connectivity (all the nodes must be able to communicate with each other directly or through relay nodes). The problem can also be defined as determining the minimum number of sensor nodes to cover all the targets and then place a few sensors to ensure connectivity. Our early

works have provided promising results regarding target coverage based on evolutionary algorithm [43] and stochastic physics-based optimization algorithm [44]. In the context of ANR McBIM, we seek to adapt these approaches, considering the concrete environment's specificities.

## Reorganizing the Sensors

Again, as sensors are embedded into concrete, their lifetime varies depending on the internal routing of sensor data in the material. Thus, the issue is to adapt the routing strategy of the communicating material to maximize the global network lifetime. About this issue, the McBIM project vision is to use the DBT to represent the network inside the material (and not only the material itself). This WSN DBT will then be used to estimate/simulate each node's residual node lifetime of the network. This view corresponds to the "Analyse" function of an autonomic manager. Based on the system's node energy levels, centralized network organization methods will then be used on global data, leading to
<figure><img src="image_15.png" /><figcaption>Fig. 13 ANR McBIM approach for optimized routing structures [44]</figcaption></figure>

optimized routing structures. This approach is presented below in Fig. 13.

The left side of Fig. 13 shows the communicating concrete with sensor nodes inserted. These nodes send data stored and analyzed in the concrete digital twin, in which a virtual node represents each node. The middle of the figure depicts the concrete digital twin (here a beam), in which the virtual nodes are represented as colored spheres. As for the real nodes, the virtual nodes are gathered in a network (links between virtual nodes being represented in Fig. 13 as white lines). The data sent by the real communicating concrete feeds the different energy models contained in each node [26]. Using these models, the concrete digital twin reports an estimation of nodes' remaining energy levels, which are used to evaluate the remaining network lifetime. Figure 13 depicts a "concrete agent" that monitors the real concrete through the digital representation built on its right side. When appropriate, the agent launches a reorganization process to explore new routing strategies. If a better routing is found (i.e., a design maximizing the concrete lifetime), the design is kept, and reorganization orders are then sent to the WSN.

## Implement a Standard-Compliant Solution

As mentioned in “Digitizing the Construction Process: Standards for Digital Building Twin” and “Achieving Semantic Interoperability: Definition and Problem Statement”, implementing the functionalities needed for explainable decision-support while maintaining semantic interoperability requires defining standard-compliant ontologies (knowledge bases). Thus, the logic behind ANR McBIM is enabled by the ANR McBIM ontology, which uses concepts as defined in existing standards. Following ISO 19650-1:2018 [3], a Common Data Environment enables "the development of a federated information model". The project will provide a federated knowledge model for

handling all knowledge related to the considered built asset, considered construction works, and life cycle, along with stakeholders' roles and requirements. Thus, ANR McBIM uses an ontology that federates concepts defined in existing standards and specified in separated modules. These modules are federated through semantic rules (defined in SWRL) following the FOWLA approach presented in [34]. This will be addressed in the context of the project's WP4, which will determine the federation of existing schemas and models by defining outgoing semantic links to concepts and properties already present in other vocabularies (as listed in Table 3). Reusing the FOWLA approach [34] enables a flexible solution while ensuring its efficiency regarding query execution times. Indeed, FOWLA considers interoperable sub-schemas among the assessed modules, thus maintaining the federation even if one module evolves (e.g. new concept added). Moreover, the approach depicted in [45] allows improved SPARQL query execution times by only selecting pertaining SWRL rules [46].

Several modules (or schemas) will be considered for the ANR McBIM ontology.

* The "standards module" will use concepts from ISO 19650-1:2018 [3] and ISO 29481 Parts 1 [5] and 3 [47] along with the relations among them represented in Fig. 14.

* The "concrete module" will explicitly define all characteristics (e.g. those from buildingSMART Data Dictionary,<fnref n="2" /> but also national working groups such as media-Construct Masonry) and refer to existing classifications for concrete (e.g. OmniClass 2013). Principles defined in ISO 12006-2 [48] for information classification and those from ISO 12006-3 [49] about attribute metadata definition will be respected.

<footnote n="2">² http://bsdd.buildingsmart.org/.</footnote>
<figure><img src="image_16.png" /><figcaption>Fig. 14 Standard concepts from ISO 19650-1, ISO 29481-1 and ISO 29481-3 considered by the ANR McBIM ontology</figcaption></figure>

* The "actor module" will list all actors involved in ANR McBIM processes regarding the actor terminology defined in ISO 19650-2 [4]. According to ISO 29481-1:2016 [5], an actor is a "person, organization, or organizational unit (such as a department, team, etc.) involved in a construction process". According to the different processes specified in ANR McBIM, the following actors are considered: the client, the delivery team, and the task team. Following ISO 19650-2 [4], each of these will either be an appointed party, or an appointing party, according to the process and lifecycle phase considered.

* The "sensor module" will contain all necessary knowledge about the sensors deployed into concrete. Alignments are provided to the main standard ontologies listed in "Semantic Web Technologies for BIM and IoT", while also defining equivalency links to pertaining classes in ifcOWL ontology for IFC4.1.

Following the study of Part 1 of the ISO 19650 standard [3], ANR McBIM aims at implementing the information delivery cycle defined by the standard. Namely, the following steps have been considered.

1. Specify information requirements through organizational information requirements (OIR), asset information requirements (AIR), project information requirements (PIR), exchange information requirements (EIR)

2. Define planning for information delivery

3. Implement automatic compliance checking for information approval, through the definition of (1) collaborative information management processes as defined in ISO 19650-2 [4], (2) information review process (e.g. spatial coordination, information compliance) as defined in ISO 19650-2 [4], (3) security-related best practices according to ISO 19650-5 [40].

For doing so, we based our definitions on BPMN specifications of the processes considered in the project context. For each building element considered (e.g. IfcBeam or Ifc-Wall), we envisaged the following lifecycle phases: design, production, delivery (handover), operations, management, and demolition. We identified ISO 19650-1 concepts [3] and ISO 19650-2 actors [4] as involved. The above steps can thus be implemented as semantic rules (or constraints) on top of the McBIM ontology, ensuring the (semi-) automatic checking of the considered processes. The aim is to verify the compliance with the requirements about a lifecycle phase, for example, check the compliance with the client requirements during the delivery phase.

## Implement Explainable Decision-Support

Explainable decision support is one of the main innovations in the context of this project. The idea is to ease the querying of the overall knowledge specified in the different federated ontology modules.
<table><caption>**Table 5** Triples extracted from the OWL file representing the beam from Fig. 15 and listing the knowledge about the instance IfcSensorType_60210</caption><thead><tr><th>Line</th><th>Subject</th><th>Predicate</th><th>Object</th></tr></thead><tbody><tr><td>1</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:globalId_IfcRoot</td><td>inst:IfcGloballyUniqueId_207</td></tr><tr><td>2</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:hasPropertySets_IfcTypeObject</td><td>inst:IfcPropertySet_602111</td></tr><tr><td>3</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:hasPropertySets_IfcTypeObject</td><td>inst:IfcPropertySet_60207</td></tr><tr><td>4</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:hasPropertySets_IfcTypeObject</td><td>inst:IfcPropertySet_60220</td></tr><tr><td>5</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:name_IfcRoot</td><td>inst:IfcLabel_208</td></tr><tr><td>6</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:predefinedType_IfcSensorType</td><td>ifcOWL:TEMPERATURESENSOR</td></tr><tr><td>7</td><td>inst:IfcSensorType_60210</td><td>rdf:type</td><td>ifcOWL:IfcSensorType</td></tr><tr><td>8</td><td>inst:IfcSensorType_60210</td><td>ifcOWL:relatingType_IfcRelDefinedByType</td><td>inst:IfcRelDefinedByType_60209</td></tr></tbody></table>

<figure><img src="image_17.png" /><figcaption>**Fig. 15** IfcBeam equipped with three instances of IfcSensor</figcaption></figure>

Based on the modules listed in the previous section, the ANR McBIM ontology implements Linked Data principles to align upper-level concepts of the ontology with existing standard ontologies e.g. ifcOWL4ADD1 [50], SSN/SOSA [51], SAREF [52], SAREF4BLDG [53], SEAS [62], etc.

Of course, similar decision-support could be implemented by using only ifcOWL, but given the high expressivity of this ontology, queries expressed on top of it have been proven time-consuming [33]. To further exemplify the complexity of writing queries for ifcOWL, the following example shows the SPARQL query for obtaining the data values from IfcSensor instances. Let us consider the next IfcBeam element, comprising three instances of IfcSensor (corresponding to the beam illustrated in Fig. 13).

For a clearer idea of the structure's complexity for ifcOWL, the table below (see Table 5) lists all triples about one IfcSensor instance, namely the one identified as IfcSensorType_60210 in Fig. 15. Line 1 references the IFC GUID instance (but not the GUID's value) and line 6 defines this as a temperature sensor. Still, the table below (Table 5) only represents the basic knowledge about this sensor.

The SPARQL listing below (Table 6) allows querying the minimum data values recorded by all three sensors from Fig. 15. Results are displayed in Table 7.

<table><caption>**Table 6** SPARQL query for minimum data values recorded by the sensors from Fig. 15</caption><thead><tr><th>Line</th><th>Subject</th></tr></thead><tbody><tr><td>1</td><td>PREFIX ifcowl: &lt;http://www.buildingsmart-tech.org/ ifcOWL/IFC2X3_TC1#&gt;</td></tr><tr><td>2</td><td>PREFIX express: &lt;https://w3id.org/express#&gt;</td></tr><tr><td>3</td><td>PREFIX list: &lt;https://w3id.org/list#&gt;</td></tr><tr><td>4</td><td>SELECT ?sensor (min(?value) as ?minValue)</td></tr><tr><td>5</td><td>WHERE</td></tr><tr><td>6</td><td>{</td></tr><tr><td>7</td><td>?PropertyV ifcowl:nominalValue_IfcPropertySingleValue ?V</td></tr><tr><td>8</td><td>?V express:hasDouble ?value</td></tr><tr><td>9</td><td>?PropertyV ifcowl:name_IfcProperty ?id</td></tr><tr><td>10</td><td>?id express:hasString "TemperatureSensorSetPoint"</td></tr><tr><td>11</td><td>{</td></tr><tr><td>12</td><td>WHERE</td></tr><tr><td>13</td><td>{</td></tr><tr><td>14</td><td>SELECT ?PropertyV ?sensor ?Property</td></tr><tr><td>15</td><td>WHERE</td></tr><tr><td>16</td><td>{</td></tr><tr><td>17</td><td>?sensor rdf:type ifcowl:IfcSensorType</td></tr><tr><td>18</td><td>?sensor ifcowl:hasPropertySets_IfcTypeObject ?Property</td></tr><tr><td>19</td><td>?Property ifcowl:hasProperties_IfcPropertySet ?PropertyV</td></tr><tr><td>20</td><td>}</td></tr><tr><td>21</td><td>}</td></tr><tr><td>22</td><td>}</td></tr><tr><td>23</td><td>GROUP BY ?sensor</td></tr></tbody></table>

<table><caption>**Table 7** Results provided to the query in Table 6.</caption><thead><tr><th>Sensor</th><th>minValue</th></tr></thead><tbody><tr><td>inst:IfcSensorType_60235</td><td>22.0</td></tr><tr><td>inst:IfcSensorType_60236</td><td>22.2</td></tr><tr><td>inst:IfcSensorType_60210</td><td>21.9</td></tr></tbody></table>
Given the SPARQL query's length and complexity listed in Table 6, the ANR McBIM ontology's goal is to allow formulating simpler queries. Using a more straightforward ontology structure, the ANR McBIM knowledge base only needs to be populated with instance data from IFC files (e.g. through ETL-based processes). The queries and the reasoning rules are to be implemented on top of the ANR McBIM knowledge, using concepts and relations from that ontology solely. Using the semantic links defined to other ontologies (such as ifcOWL) knowledge can be inferred in terms of IFC elements.

The ANR McBIM project will seek to implement advanced knowledge analysis based on semantic rules, thus enabling reactive and proactive explainable decision-making. *Reactive decision-making* algorithms will produce notifications and alarms to the platform's end-users considering specified thresholds for parameters of interest. *Proactive decision-making* (predictive modeling) will help better interpret real-time construction progress/structural health monitoring results and provide recommendations on preventing accidents, shortcomings, and deviations or how to foresee discrepancies at the considered construction stages. Both reactive and proactive decision-making algorithms will be integrated into the digital platform to enhance end-users' visibility on the construction site's progress.

## Conclusion

With this paper, we presented the main research issues existing in the digital building twin field as imposed by the growing need to digitize construction processes. Approaches for sensing a building start becoming state-of-the-art. Still, regarding real-time surveillance and decision-making in construction processes encompassing building lifecycle phases other than facility management, several standards exist at the ISO level. In contrast, no standard implementation has been defined. This article further presented the contributions envisaged in the ANR McBIM project's context and how they can push forward existing state-of-the-art approaches. The concept of "communicating concrete" and its applications in optimizing the sensor network lifetime have tangible benefits for building structural health monitoring and building demolition and concrete recycling. The contributions regarding reactive and proactive decision-making are also trail-blazing and enable the level of confidence users to need for "a reliable basis for decision-making" (as defined by ISO 19650-1:2018 [3]).

Further actions to be considered in this project address the development and the alignment of the McBIM ontology with all the ontologies listed in this article's section "Seman-tic Web Technologies for BIM and IoT". Once the McBIM ontology and its related modules are specified, they will have

to be further implemented in the overall system environ-ment developed by the French SME 360SmartConnect.<fnref n="3" /> Expert semantic rules will have to be established on top of this ontology to implement the processes, and compliance-checking approach envisioned. The overall strategy will be tested in a real environment, and results presented to pertain-ing standardization organizations.

**Acknowledgements** The ANR McBIM project described in this article has received funding from the French National Agency of Research (ANR) under Grant agreement no ANR-17-CE10-0014-03.

**Funding** This study was funded by the French National Agency of Research (ANR) under Grant Agreement no ANR-17-CE10-0014-03.

## Declarations

**Conflict of Interest** The authors declare that they have no conflict of interest.

**Open Access** This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.

## References

1. Grand F, Ridgway Ph, Soubra S et al. Stratégie française pour les actions de pré-normalisation et normalisation BIM appliquées au bâtiment. Feuille de route normalisation, Plan Transition Numé-rique dans le Bâtiment. 2018.

2. Kubler S, Derigent W, Thomas A, Rondeau E. Embedding data on "communicating materials" from context-sensitive infor-mation analysis". J Intell Manufact Springer Verlag Germany. 2014;25(5):1053-64. https://doi.org/10.1007/s10845-013-0745-y.

3. ISO19650-1:2019. Information management using building infor-mation modelling—Part 1: Concepts and principles. ISO/TC59/SC13 Organization and digitization of information about build-ings and civil engineering works, including building information modelling (BIM). 2019.

4. ISO19650-2:2019. Information management using building infor-mation modelling. Part 2: Delivery phase of assets. ISO/TC59/SC13 Organization and digitization of information about build-ings and civil engineering works, including building information modelling (BIM). 2019.

5. ISO29481-1:2016. Building information models—Information delivery manual—Part 1: Methodology and format. ISO/TC59/SC13 Organization and digitization of information about build-ings and civil engineering works, including building information modelling (BIM). 2016.

<footnote n="3">³ https://www.360sc.io/.</footnote>
6. ISO16739-1:2018. Industry foundation classes (ifc) for data shar-
ing in the construction and facility management industries part 1:
Data schema. ISO/TC59/SC13 Organization and digitization of
information about buildings and civil engineering works, includ-
ing building information modelling (BIM). 2018.

7. ISO10303-21:2016. Industrial automation systems and integration product data representation and exchange—Part 21: Implementation methods: Clear text encoding of the exchange structure. ISO/TC 184/SC 4 Industrial data. 2016.

8. Industrial Foundation Classes (IFC) 4.1 Official documentation and standard definition. [Online]. https://standards.buildingsm art.org/IFC/RELEASE/IFC4_1/FINAL/HTML/.

9. ISO21127:2014. Information and documentation a reference ontology for the interchange of cultural heritage information. ISO/TC 46/SC 4 Technical interoperability. 2014.

10. Roxin A, Hbeich E. Semantic interoperability between BIM and GIS—review of existing standards and depiction of a novel approach. 36th CIB W78—Information Technology for Construction, Newcastle, United Kingdom. 2019.

11. ISO/IEC20944-1:2013. Information technology metadata registries interoperability and bindings (mdr-ib) part 1: Framework, common vocabulary, and common provisions for conformance. ISO/IEC JTC 1/SC 32 Data management and interchange. 2013.

12. ISO16678:2014. Guidelines for interoperable object identifica-
tion and related authentication systems to deter counterfeiting
and illicit trade. ISO/TC 292 Security and resilience, 2014.

13. ISO/IEC19941:2017. Information technology cloud computing interoperability and portability. ISO/IEC JTC 1/SC 38 Cloud Computing and Distributed Platforms, 2017.

14. ISO13606-1:2019. Health informatics electronic health record communication part 1: Reference model. ISO/TC 215 Health informatics, 2019.

15. Berners-Lee T. "Linked Data", 2006. http://www.w3.org/Desig nIssues/LinkedData.html.

16. Li N, Becerik-Gerber B. Life-cycle approach for implementing RFID technology in construction: learning from academic and industry use cases. J Construct Eng Manag. 2011;137:1089-98. https://doi.org/10.1061/(ASCE)CO.1943-7862.0000376.

17. Loubet G, Takacs A, Gardner E, De Luca A, Udrea F, Dragomirescu D. LoRaWAN battery-free wireless sensors network designed for structural health monitoring in the construction domain. Sensors (Switzerland). 2019;19(7):1510. https://doi.org/10.3390/s19071510 (Published 28 March 2019).

18. Ikonen J, Knutas A, Hämäläinen H, Ihonen M, Porras J, Kallonen T. Use of embedded RFID tags in concrete element supply chains. J Inf Technol Construct. 2013;18:119-47.

19. Barroca N, Borges LM, Velez FJ, Monteiro F, Górski M, Castro-Gomes J. Wireless sensor networks for temperature and humidity monitoring within concrete structures. Construct Build Mater. 2013;40:1156-66. https://doi.org/10.1016/j.conbuildmat. 2012.11.087.

20. Jiang S, Georgakopoulos SV. Optimum wireless powering of sensors embedded in concrete. IEEE Trans Antennas Propagat. 2012;60(2 PART 2):1106-13. https://doi.org/10.1109/TAP. 2011.2173147.

21. Rault T, Bouabdallah A, Challal Y. Energy efficiency in wireless sensor networks: a top-down survey. Comput Netw. 2014;67:104-22. https://doi.org/10.1016/j.comnet.2014.03.027 (ISSN 1389-1286).

22. Safara F, Souri A, Baker T, Al Ridhawi I, Aloquily M. PriNergy: a priority-based energy-efficient routing method for IoT systems". J Supercomput. 2020;76:8609-26.

23. Tita ED, Nwadiugwu W-P, Lee JM, Kim D-S. Real-time opti-
mizations in energy profiles and end-to-end delay in WSN using
two-hop information. Comput Commun. 2021 (In press).

24. Jasmine Lizy P, Chenthalir Indra N. Metaheuristic energy effi-
cient protocol for heterogeneous WSN. Materials Today Proc.
2021 (In press).

25. Zervoudakis K, Tsafarakis S. A mayfly optimization algorithm.
Comput Ind Eng. 2020;145.

26. Wan H, David M, Derigent W. Energy-efficient chain-based data gathering applied to communicating concrete. Int J Distrib Sens Netw. 2020;16(8):1–25. https://doi.org/10.1177/1550147720 939028.

27. Singh P, Singh S. A review: power efficient gathering in sensor information system (PEGASIS) protocol for WSN. Int Res J Eng Technol IRJET. 2015;02(03):1010-3.

28. Heinzelman WR, Chandrakasan A, Balakrishnan H. Energy-effi-
cient communication protocol for wireless microsensor networks.
In: Proceedings of the 33rd annual Hawaii international confer-
ence on system sciences, vol. 2; 2000. https://doi.org/10.1109/
HICSS.2000.926982.

29. Lindsey S, Raghavendra CS. Pegasis: power-efficient gathering in sensor information systems. Proc IEEE Aerosp Conf. 2002;3:3.

30. Tang F, You I, Guo S, Guo M, Ma Y. A chain-cluster based rout-
ing algorithm for wireless sensor networks. J Intell Manufact.
2012;23(4):1305-13. https://doi.org/10.1007/s10845-010-0413-4.

31. Gengsheng Z, Zhengbing H. Chain routing based on coordi-
nates-oriented clustering strategy in WSNs. In: International
Symposium on Computer Network and Multimedia Technology
(CNMT), pp 1-4. 2009.

32. Ahn KS, Kim DG, Sim BS, Youn HY, Song O. Balanced chain-based routing protocol (bcbrp) for energy efficient wireless sensor networks. In: 2011 IEEE Ninth International Symposium on Parallel and Distributed Processing with Applications Workshops, pp 227-231. 2011.

33. Mendes de Farias T, Roxin A, Nicolle C. IfcWoD, semantically adapting IFC model relations into OWL properties. In: Proceedings of the 32nd CIB W78 conference on information technology in construction, Eindhoven, Netherlands. 2015.

34. Farias TMF, Roxin A, Nicolle C. FOWLA, a federated architec-
ture for ontologies. In: Bassiliades N, Gottlob G, Sadri F, Pas-
chke A, Roman D, editors. Rule technologies: foundations, tools,
and applications. RuleML 2015. Lecture notes in computer sci-
ence, vol. 9202. Cham: Springer; 2015. https://doi.org/10.1007/
978-3-319-21542-6_7.

35. Mendes de Farias T, Roxin A, Nicolle C. COBieOWL, an OWL ontology based on COBie standard. In: Proceedings of on the move to meaningful internet systems: OTM 2015 conferences, confederated international conferences: CoopIS, ODBASE, and C&TC 2015. Rhodes, Greece. 2015.

36. Mendes de Farias T, Roxin A, Nicolle C. A semantic web approach for building view definitions. buildingSMART International Standards Summit, 12 Apr 2016, Rotterdam, Netherlands. https://www.slideshare.net/anaroxin/a-semantic-web-approach-for-defining-building-views.

37. Mendes De Farias T, Roxin A, Nicolle C. A rule-based methodol-
ogy to extract building model views. Autom Construct Elsevier.
2018;92:214-29. https://doi.org/10.1016/j.autcon.2018.03.035.

38. ISO19650-3:2020. Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) information management using building information modelling. Part 3 : Operational phase of the assets. 2020.

39. ISO19650-4. Information management using building informa-
tion modelling—Part 4: Information exchange. ISO/TC 59/SC 13
Organization and digitization of information about buildings and
civil engineering works, including building information modelling
(BIM). Under development.

40. ISO19650-5:2020. Information management using building infor-
mation modelling—Part 5: Specification for the security-minded
building information modelling, digital built environments and
smart asset management. ISO/TC 59/SC 13 Organization and
digitization of information about buildings and civil engineering
works, including building information modelling (BIM). 2020.

41. Lalande P, McCann J, Diaconescu A. Autonomic computing—principles, design and implementation. Undergraduate topics in computer science. London: Springer; 2013. https://doi.org/10.1007/978-1-4471-5007-7

42. Mini S, Udgata SK, Sabat SL. Sensor deployment and scheduling for target coverage problem in wireless sensor networks. IEEE Sens J. 2014;14(3):636-44.

43. Ndam Njoya A, Abdou W, Dipanda A, Tonye E. Optimization of sensor deployment using multi-objective evolutionary algorithms. J Reliable Intel Environ. 2016;2(4):209220.

44. Ndam Njoya A, Thron C, Barry J, Abdou W, Tonye E, Konje NSL, Dipanda A. Efficient scalable sensor node placement algorithm for fixed target coverage applications of wireless sensor networks. IET Wireless Sensor Syst. 2017;7(2):44-54.

45. Kannengiesser U, Roxin A. 2016. An agile process modelling approach for BIM projects. In: eWork and eBusiness in architecture, engineering and construction: ECPPM 2016. CRC Press, pp 99-107 (ISBN 9781138032804).

46. Mendes de Farias T, Roxin A, Nicolle C. SWRL rule-selection methodology for ontology interoperability. Data Knowl Eng Elsevier. 2015. https://doi.org/10.1016/j.datak.2015.09.001.

47. ISO29481-3. Building information models information delivery manual—Part 3: Data schema and classification. ISO/TC 59/SC 13 Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM). Under development.

48. ISO12006-2:2015. Building construction organization of information about construction works—Part 2: Framework for classification. ISO/TC 59/SC 13 Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM). 2015.

49. ISO12006-3:2007. Building construction organization of information about construction works—Part 3: Framework for object-oriented information. ISO/TC 59/SC 13, Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM). 2007.

50. buildingSmart International, IFC Specifications Database. [Online]. https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/.

51. Lefrançois M. Planned ETSI SAREF extensions based on the W3C&OGC SOSA/SSN-compatible SEAS ontology paaerns. Workshop on semantic interoperability and standardization in the IoT, SIS-IoT, Sep 2017, Amsterdam, Netherlands. 2017.

52. ETSI, ETSI TS 103 264 V2.1.1 (2017-03): SmartM2M; smart appliances; reference ontology and oneM2M mapping. 2017. http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v020101p.pdf.

53. ETSI TS 103 410-3 V1.1.2 (2020-05): SmartM2M; Extension to SAREF; Part 3: Building Domain. https://www.etsi.org/deliver/etsi_ts/103400_103499/10341003/01.01.02_60/ts_10341003v010102p.pdf.

54. Roxin A. Linked (meta)Data—principles and applications for BIM". buildingSMART international standards summit plenary session, Espace Grande Arche, La Défense, Paris, France. 2018. https://www2.slideshare.net/anaroxin/les-donnes-lies-pour-le-bim.

55. Roxin A. Bringing meaning to BIM data—why and how?. Bouygues Construction workshop "BIM In Motion", 23 October 2019, Bouygues Challenger Site, Paris, France. https://www2.slideshare.net/anaroxin/bringin-meaning-to-bim-data.

56. Holten Rasmussen M, Lefrançois M, Schneider GF, Pauwels P. BOT: the building topology ontology of the W3C linked building data group. Semantic Web J IOS Press. 2020. http://www.seman tic-web-journal.net/system/files/swj2279.pdf.

57. Balaji B, Bhattacharya A, Fierro G, Gao J, Gluck J, Hong D, Johansen A, Koh J, Ploennigs J, Agarwal Y, Bergés M, Culler D, Gupta RK, Kjærgaard MB, Srivastava M, Whitehouse K. Brick: metadata schema for portable smart building applications. Appl Energy. 2018;226:1273-92. https://doi.org/10.1016/j.apenergy. 2018.02.091.

58. Open Geospatial Consortium. OGC City Geography Markup Language (CityGML) Encoding Standard 2.0.0. Technical report, April 2012. https://portal.opengeospatial.org/files/? artifact_id= 47842.

59. East B. Construction-operations building information exchange (COBie). 2014. http://www.wbdg.org/resources/cobie.php.

60. Roes J, den Hartog F, Daniele L, Verhoosel J. The FIEMSER ontology. https://sites.google.com/site/smartappliancesproject/ ontologies/fiemser-ontology?authuser=0.

61. Pauwels P, Terkaj W. EXPRESS to OWL for construction industry: towards a recommendable and usable ifcOWL ontology. Autom Construct. 2016;63:100-33. https://doi.org/10.1016/j. autcon.2015.12.003.

62. ETSI SmartM2M. SmartM2M; Guidelines for consolidating SAREF with new reference ontology patterns, based on the experience from the ITEA SEAS project. ETSI Technical Report TR 103 549 V1.1.1 (2019-07). https://www.etsi.org/deliver/etsi_tr/ 103500_103599/103549/01.01.01_60/tr_103549v010101p.pdf. 2019.

63. Haller A, Janowiczn K, Cox S, Le Phuoc D, Taylor K, Lefrançois M. "Semantic sensor network ontology" W3C. 19 October 2017. W3C Recommendation. https://www.w3.org/TR/2017/REC- vocab-ssn-20171019/. 2017.

64. Kovatsch M, Matsukura R, Lagally M, Kawaguchi T, Toumura K, Kajimoto K. Web of Things (WoT) Architecture. W3C Recommendation. 9 April 2020. https://www.w3.org/TR/2020/REC-wot- architecture-20200409/. 2020.

65. Kellogg G, Champin P-A, Longley D. "JSON-LD 1.1". W3C. 16 March 2020. W3C Candidate Recommendation. https://www.w3. org/TR/2020/CR-json-ld11-20200316/. 2020.

66. Derigent W, David M, Wan H, Dragomirescu D, Takacs A, Loubet G, Roxin A, Melet R, Montegut L. Materials communicating with BIM: aims and first results of the McBIM project. In: Proceedings of structural health monitoring. 2019.

67. Bonino D, Corno F. DogOnt—ontology modeling for intelligent domotic environments. In: Sheth A, et al., editors. The semantic web—ISWC 2008. Lecture notes in computer science, vol. 5318. Berlin: Springer; 2008. https://doi.org/10.1007/978-3-540-88564-1_51.

68. ISO 19136-1:2020. Geographic information—Geography Markup Language (GML)—Part 1: Fundamentals. ISO/TC 211 Geographic information/Geomatics. 2020.

69. ETSI SmartM2M. SmartM2M; SAREF consolidation with new reference ontology patterns, based on the experience from the SEAS project. ETSI Technical Specification TS 103 548 V1.1.1 (2019-07). https://www.etsi.org/deliver/etsi_ts/103500_103599/ 103548/01.01.01_60/ts_103548v010101p.pdf.

**Publisher's Note** Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.