Towards an integrated approach of building-data management through the convergence of Building Information Modelling and Internet of Things

This contribution presents a possible use of the Building Information Model (BIM) for the implementation of Building Management Systems (BMS) and proposes tools and methods for each critical step of the process. The resulting designed process enables each building stakeholder to work at an earlier stage on the digital model located on a dedicated server. This paper proposes a novel and integrated approach to building-data management and analyses the main obstacles and limitations that may currently affect the practical implementation.


Introduction
There is a consensus that there is a need to substantially improve the sustainability of building construction. This requires in particular a better collaboration between stakeholders [1]. Despite advances in technology, they often use traditional ways to communicate and work together. Currently, construction engineering is characterized by a transition to BIM technology [2]. Located on a cloud server and used by each stakeholder, BIM models allow optimising communication. Therefore, it increases efficiency during the construction process in terms of information exchange, identification of errors and repeating tasks prevention. The monitoring of building performance through the data generated by a sensors/actuators network is also essential. Access to this information has been made easy and ubiquitous thanks to Internet of Things (IoT) devices and protocols [3]. Communication (of all stakeholders via the BIM model) and information management (via sensors/actuators network -IoT) are among the key areas of management operation at every stage of a construction project [4].
While BIM and IoT deployment in the construction sector is growing exponentially, there is a gap in integrating these two technologies in a systematic way through open standards and systems [5]. This paper proposes a multi-step process to merge the two digital technologies in order to optimize the execution of a construction project. This process targets the use of a BIM model in conjunction with the building BMS (1) to improve facility management and (2) to automatically generate elements of the User Interface (UI). In addition to these technical aspects, attention is paid to the obstacles and limitations that may arise. This allows taking a step back and looking at the feasibility of such a system by highlighting the critical steps.

Methodology
In order to demonstrate that it is possible in practice and relevant to use BIM models dynamically to configure and develop the BMS faster and at an earlier stage, an ideal process is simulated. Key steps of the process and needed interfaces are identified and suitable practical solutions are pursued. Some of these solutions are then tested in practice on representative and realistic environments.
After having defined a suitable nomenclature for the data (sensors and actuators) that could be used throughout the process, an optimal process that could be applied to a real case (the experimental building used for this project) is developed. Each step of this process is defined, and tests of critical properties of software components are carried out to determine the feasibility of such a system. Based on the tests described in §4.2 and §5.2 and semi-structured interviews carried out with targeted stakeholders, a non-exhaustive list of possible improvements is compiled.  Figure 1 illustrates the standard phases of a BIM process that can be adopted to structure the temporal sequencing of the building life cycle, starting from the programming phase and ending with the renovation phase [6]. In this section, an integrated building-data management process is described. If this process is applied to the BIM model development and well-implemented, it will facilitate communication between stakeholders and prevent information loss as well as multiple processing of the same information.

Integrated building-data management based on BIM process
During the "conceptual design" phase of the project, architects define volumes, stories, rooms and space use. At this stage, it is already possible to visualize the core elements of the project and to define a first nomenclature based on the space composition of the project (e.g. site/building/storey/space/…).
In the "detailed design" phase, the HVAC, electrical, building control and monitoring systems are specified in collaboration with the architect/client. Building automation, HVAC and electricity specialists then define the appropriate solutions and choose the required devices. All the necessary information related to the chosen technologies and devices is then entered into the BIM model based on the Industry Foundation Classes (IFC) data schemas [7]. This allows to identify potential issues related to space conflicts in the model or electrical wiring problems. It also allows to include all necessary information about communication and programming. At this stage, it would be possible to extract from the BIM all the information needed to develop the BMS, as well as the user interfaces. The geometrical data (3D model) can for instance be dynamically loaded in a visualisation or a virtual reality platform. This means that any modification of the 3D model is automatically transcribed in the application. It is also possible to extract lists of sensors or actuators with their designation, location and individual address by parsing the IFC model. At this point, a specific nomenclature dedicated to building management and user interaction can be generated and the building programmers (automation expert, IT specialist) can begin to work on a virtual model.
During the "documentation phase", the technical data needed for the subsequent phases of the process (e.g. component information, datasheets, instructions, etc.) are put together in the BIM documentation model. All changes made in the "fabrication phase" have to be documented and the BIM model updated.
After the "fabrication" and the "construction 4D/5D and logistics" [8] phases, the project is considered as complete. Any modifications (e.g. addition or displacement of a sensor, renaming of a room) must be reported in the BIM model. The information technology (IT) and building automation specialist then program the building based on the nomenclature defined in the model, the monitoring system requirements and the desired building control logic. The connections are made between the BIM model, the data generated by the building and its users, the BMS and the UI (see §5).
During the "operation and maintenance" phase, the facility manager has access to the BIM model and all the available information about every device installed in the building. This facilitates their maintenance, replacement or re-programming. Any modification of a device has to be reported in the BIM model. The adoption of such process and architecture (see §5) facilitates the optimization of building operations, for example the energy performance optimization through additional rules and algorithms.

Sensors and actuators nomenclature
4.1. Nomenclature structure The data to be transmitted and stored in the database, namely measurements, parameters and commands, are a key element of the system. Therefore, the building's sensors and actuators must be uniquely identifiable. A consistent nomenclature of these elements is essential as it will be used throughout the whole system.
The sensors and actuators nomenclature' process is based on the functioning principle of Message Queuing Telemetry Transport (MQTT) topics [9]. MQTT is a publish-subscribed-based messaging protocol particularly well suited for use in a BMS. Its structure therefore influences the proposed nomenclature 4.2. Application to a practical case study The building called "NeighborHub" (NH) [10] illustrated in Figure 2 is used to perform the experiment. The NeighborHub is divided into three areas: the core (building's core), the skin (the building's envelope) and the outside (building's exterior). These areas are part of the sensors/actuators' nomenclature.
The nomenclature process is as follows: first, the BIM model is exported in a IFC file format [7]. This file is parsed, and the topics are automatically extracted, including the data related to localization (e.g. NH/Core/Living_space) and sensors/actuator's names (e.g. temperature). It is possible to reconstitute each topic for every sensor/actuator as shown in example in Figure 2. If a change occurs in the BIM model, the IFC file will be automatically parsed again to generate an updated list of MQTT topics. This list will also be used later in a conversion table (see §5.2 and Figure 3) to link the topic name to an identifier (ID). This ID has a specific format depending of the specific building automation protocols that is used by each device.

Architecture general description
The architecture described in Figure 3 represents what has been set up on the NeighborHub to perform tests. The left side of the diagram shows how the building stakeholders (e.g. architects, engineers, electricians, etc.) can have access to the shared BIM model stored on cloud servers. The BMS of the NeighborHub is in charge of recovering all the data from the various sensors/actuators' networks. The database [11] is used to store all the data (measurements, parameters and commands) from the sensors/actuators' network who communicates with the BMS. The user interface (Unity3D application) allows to visualize the building and its live/historical data as well as to interact with it. Figure 3 describes the practical implementation of the process. The first step is to create a conversion table that will be used during the process. One part of the table represents the topics corresponding to the sensors/actuators (1), which are automatically generated as described in §4.2. The other part of this conversion table is filled with the multiprotocol's sensors/actuators' ID from the BMS (3). The communication within the BMS is made in MQTT. This table is used to check that the sensor/actuator topic is present in the database in order to collect data from the BMS. If this is not the case, the missing object linked to the sensor or actuator is created via a Node.js script [12] (2). Data from IoT devices (sensors and actuators) pass through the BMS (4) and are automatically pushed into the database (5) by the same Node.js script using the REST API of the database. In case of an unresponsive query to the main database, a local storage system is used to hold these data and to release them once the database becomes available.

Practical implementation
The BIM model can also be loaded into the Unity3D user interface in order to dynamically update the information (6). The advantage is that the application changes according to the model. Tests are carried out with the Pixyz [13] plugin and their validation is performed on the Unity3D user interface representing the NeighborHub. This application can also access the near real-time data of the BMS and modify the status of the actuators in case of a change made by the user via MQTT (7). Finally, it is possible to visualize the historical/processed data from the database (8).  Figure 3. Process defined with the different steps.

Discussion
A possible improvement of the prototype of the process architecture presented in Figure 3 would consist of integrating the conversion table in the BIM model. The information (topics from the BIM model itself and ID of the BMS's sensors/actuators) could dynamically and automatically fill this table. Also, in the current implementation, each element (user interface, BMS, database) has access to the complete table. An improvement here would be to give access only to the information needed to improve security. It would also be interesting to unify communication protocols using only MQTT to homogenize communication within the architecture.
The experiments described above and interviews with professionals allowed to identify some current limitations and obstacles. The first one is related to the availability of BIM models for devices in the objects databases. Another potential problem is that the information available in the BIM model of devices is not sufficient to apply the proposed process and architecture. Moreover, one can observe some differences in the way the IFC standard is used by software providers, making it more difficult to extract the needed information.
The relatively recent emergence of IoT protocols and the existence of a high number of standards is a second potential obstacle to the interoperability and unified communication. The IoT acceptance in the construction sector is not fully achieved yet, this is mainly due to the maintenance, reliability and security issues. More generally, there is a lack of education and knowledge about these technologies among engineers and architects.

Conclusion
The convergence between BIM and IoT technologies allow to consider an integrated approach of building-data management. This would further enhance the potential benefits of using BIM for the stakeholders, by saving time, and by enhancing the efficiency and the involvement of stakeholders at an earlier stage of the process. This paper demonstrates a typical system architecture to achieve this integration and analyses some key steps of the process. The full implementation of such a system remains relatively tedious today due to the lack of maturity of certain tools. There is also a need for