This paper proposes a software architecture for creating and managing unambiguous descriptions of a Smart Building, allowing its Digital Twin to be deployed. These descriptions include static semantic structural description and dynamic time-series sensors data. Moreover, it is designed to be able to include data from various simulation tools, represented in the same way as sensors data. Thus, relying on these descriptions allow easy implementations of both monitoring and interaction tools that can the be interfaced with the Smart Building. Before the recent emergence of Smart Buildings, there was very few advantages in applying this concept to the eld of construction and building management. Non-connected buildings don't produce real-time data, and can't be monitored nor operated from computer systems. But now that more and more buildings include IoT devices that allow them to expose data and services, the bene ts of creating a Digital Twin to interact with the building, without interrogating the object itself, only by querying its Digital Twin, appears obvious. It then becomes crucial to be able to expose both a static description of the building's components (including IoT devices structural and functional description) and dynamic data that represent the evolution of the building's states over time.
Buildings have many diverse components such as building blocks, electricity
network, water pipes. . . The need to optimize a building's function, from the
minimization of energy consumption while maintaining comfort, to preventive or
predictive maintenance, led to considering the entire lifecycle management of the
building. When considering a non-connected building, the lifecycle management
can only rely on data that are maintained by human actions, which o ers very
few opportunities of innovating solutions. But buildings now become more and
more equipped with IoT devices, leading to the appearance of buildings meant
to be fully automatized known as Smart Building. Subsequently, the industry
now shows a growing interest in deploying Digital Twins of Smart Buildings. The
Digital Twin of a physical system is a notion that rst appeared in the early
2000s [
Several de nitions has been proposed for a Digital Twin, not speci cally
applied to Smart Buildings. The rst one comes from Grieves and Vickers who
proposed the following de nition [
Much work has been done on the static representation of a building. In 1987,
a Building Information Modeling (BIM) has been proposed to facilitate
collaborative work in both construction and evolution building's phases. Nowadays
many industrial BIM software exist like ArchiCAD, Tekla or Revit [
In the literature, we now nd more and more research work that focus on
BIM ontologies. Indeed it is known that ontologies facilitate the interoperability
between many applications. For instance, Berstein and Young in [
In this paper, we show how BIM and IoT ontologies (and even additional ontologies, like BOT) can be created and aligned, then used to automatically create and update data ow from sensors and actuators to databases, providing a full Digital Twin software architecture to manage both static and dynamic description of a Smart Building. This software architecture is able to alleviate the issue with BIM silo data and provide a global view of a Smart Building. Such data are core components of the Digital Twin of the Smart Building, and can then expose and integrate data both from real IoT devices and tools such as digital simulation tools to BMS (Building Management System) or intelligent control systems.
This paper is organized as follows. In Section 2, we present the reference architecture we propose. In Section 3, its proof of concept is presented. Finally, Section 4 concludes the paper. 2
In order to build a Smart Building Digital Twin, we propose a reference architecture as depicted in Figure 1. This reference architecture aims to be independent from tools and serves as a re ection tool to discuss the global approach and to identify the di erent phases required for reaching our goal. These phases are formally described below. In our proof of concept, we will describe how these phases have been implemented.
(1) Building the TripleStore for RDF data The rst phase consists of building a TripleStore that doesn't rely on industrial tools but is based on various domain ontologies such as: (a) ifcOWL for the infrastructure, (b) SSN (Semantic Sensor Network) and SOSA (Sensor, Observation, Sample, and Actuator) for IoT description. Additional standard ontologies like BOT (Building Ontology Topology) for the topological representation of the building can be used to facilitate the querying when topological data is required (such as re simulation).
Existing BIM industrial software do not use domain ontology, they rather use either their own proprietary format, or the industrial data exchange format IFC that we presented previously. In order to follow the recent evolution towards Smart Buildings, the industry prefers to de ne new releases that are not easily integrated in the products and that bring a lot of inconsistencies and errors. In particular the last IFC release does not support IoT in a proper way, it mainly focuses on the physical object and does not take into account its behaviour.
As said before, Smart Buildings are complex and costly to build, they require the expertise of many professionals who have been trained to use speci c industrial software. Thus these software cannot be replaced easily and it may take years before the industry replaces its IFC standard by RDF. This is why some adaptors (translators) need to be de ned to ll the gap between the industry and domain ontologies.
(2) Data Enrichment and Consistency
In [
When many di erent experts participate to the creation of a Smart Building Digital Twin through the means of domain ontologies, many problems can occur, such as information that is incomplete, redundant, in contradiction or imperfect. For example, each IoT object de ned in SSN should be associated (linked) to its physical object in the ifcOWL ontology, and vice versa. Moreover, one can export IFC data and topology data (BOT) from existing industrial software, such as Revit, but this will introduce some redundancy since IFC already contains some topological information. However for SSN and SOSA data to be instantiated, it requires IoT experts to de ne sensors and actuators in a proper way.
Once the Digital Twin is created and represented with many RDF triples, it will continue to be updated. The update of the building's description, which usually takes place in industrial software, should be made by means of the SPARQL language, on the Digital Twin. For instance, when the work of many experts is integrated in a BIM industrial software a list of inconsistencies can be produced and given back to the experts, it's then up to them to correct them. In some cases, industrial software already allow this, for instance physical collision detection when merging several BIM les. Thus we believe that smart building complex integrity constraints should be de ned as rules on the TripleStore for RDF data. This is still an open research problem as we do not know how di cult it will be to express them on ontologies.
Moreover a Digital Twin does not only re ect one state of a Smart Building,
it should also cover the whole life cycle of the Smart Building. If supporting
complex integrity constraints allows incremental updates, it does not provide
versioning capability. To our knowledge, there does not really exist research
tools nor industrial software that support Smart Building versioning. However
it is crucial as the French law imposes a decennial building contract that needs
to be kept in order to prove some wrongdoing. Simulation tools need to produce
di erent hypothetical states (versions) of a Digital Twin in order to decide which
material should be better to use. Rasmussen in [
Finally for the architecture to be complete, the TripleStore for RDF data should support concurrent access and transactions. Some TripleStores like AllegroGraph (a proprietary TripleStore) or JenaTDB have ever their transaction management system. Others, like Blazegraph do not support them.
(3) Data Flow Program Generation Up to now, only one part of the Smart Building Digital Twin has been created. In order to be complete, all the information produced by sensors which re ect the state of a Smart Building over time should be integrated. Thanks to the SSN and SOSA ontologies, the infrastructure of sensors network is fully described. Thus they can be queried in SPARQL to retrieve the needed information. For instance, a rst query retrieves the device name and protocol. The second uses the protocol name to determine what protocol-speci c information to retrieve. In the case of Modbus, it is the register o set corresponding to the device.
Thus, following the step presented above, it is possible to automatically generate both the schema of the sensor database by using the device name and the data ow program that is going to collect the sensors data and store them in the appropriate tables. In order to do so, one needs to choose a database for storing a huge amount of time series data coming from hundred of sensors. Once the database is chosen, one needs to de ne the physical schema and in particular the data distribution. Finally, many work ows should be de ned. For each system of sensors there is a speci c work ow associated, which is a graph. An arc between two nodes represents the data owing between the two tasks. Those tasks include connecting to the device at regular intervals, retrieving data from the device, processing it (for example converting from a format to another), associating it with the current timestamp, and inserting it into the right table in the database.
(4) System at run time Once the Data Flow Programs are deployed, data are collected in the sensors database mainly as time-series. As said earlier, tables names are linked to concepts in the IoT ontology. Thus in order to get data from a speci c sensor, the ontology must be queried rst to nd the sensor's name, then the sensor database must be queried to retrieve the data from this sensor. These links between the two databases need to be maintained in a consistent way, as sensors can be removed or added in the Smart Building over time.
(5) Applications Smart Buildings applications are developed to manage, to follow the evolution or to have a real-time view of the building. In order to enable an adequate performance of these applications, an easy access to data issued from sensors and about the building's infrastructure is required. Once built, the Digital Twin contains all the data required by advanced applications. 3
The implementation we present here is a part of the Digital Twin of the real
Smart Building. This building belongs to CESI [
(1) Building the TripleStore for RDF data
The CESI Smart Building BIM, containing the whole description of the building
and including furniture, has been designed using the Autodesk Revit software
[
Once the IFC le is obtained, it is translated into RDF in order to instantiate
the ifcOWL2X3 ontology (available in [
Concerning IoT, two separate parts are identi ed: the structural one (such as thermostat housing and his location on the wall), which is already contained in the IFC le and the functional one which is not and which corresponds to protocols, data access such as URLs, logical ID, register o sets, links between sensors and actuators. . . To add functional information into our prototype, we used the information in technical documents, such as the name of the device, its type and location, the protocol and the protocol-speci c information. . . Those les allow to de ne new classes and instantiate them. Thus the IoT is fully represented into several ontologies: SOSA/SSN for the functional part and ifcOWL for its structural representation. As said earlier, we used naming conventions to link the domain ontologies, which allow us to use SPARQL queries to associate the functional part to its corresponding physical objects. In our case, the naming convention is composed of : Room name + type of the reference object + number of this object + an optional IoT object (for instance TeslaWindow3Sensor).
Let's consider the example of the windows system for a speci c room which is called Tesla. Sensors are placed into each window but a unique system is collecting windows state using the Modbus protocol. The Modbus class is de ned as a subclass of sosa:Procedure, with speci c characteristics of this protocol. Then a WindowsTeslaSystem instance of ssn:System is created, with an instance of Modbus procedure as depicted in gure 2. We then add to all the windows in the room the sosa:Sensor class, and attached them to the global system. Instances can have multiple classes, such as windows that are both ifcowl:Window, sosa:Sensor and sosa:Actuator (as we can see in the gure 2) which allow us to link the structural and functional part. As depicted in gure 2, we built a JSON le with SPARQL queries about the Modbus protocol characteristics. This JSON le is then injected into the NodeRed server that manages data ows. This part is more detailed later. Note that in this current prototype we do not yet support complex integrity constraints, nor versioning, as these are really dependant upon the BlazeGraph TripleStore functionalities that we are using.
(2) Generating the Data Flow Program One major contribution of our work is to automatize as much as possible the sensors data acquisition. Indeed, a Smart Building is complex and can contain hundred heterogeneous sensors and actuators, making the work of the manager of the building cumbersome and repetitive if some changes occur such as adding or removing sensors from the building. The idea we defend here consists in using the description of the IoT objects found in our TripleStore to generate the schema of the sensor database, as well as to write the di erent data ow programs for acquiring all sensors time series data to be stored in the database.
In our prototype we decided to use the NoSQL CASSANDRA database that can deal with large amount of data and also for its horizontal scalability. Any time series database can be used, it must be adapted to the data and possible treatments of the use case. Data issued from a same controller is gathered in the same table. For instance, the various sensors data of the weather station managed by one controller are all stored in one table. In the same manner, all lights sensors of a single room are in another table. The partitioning is made with a \year-month" key. For our scenario, if the 90 sensors sense every minute it will produce approximately more than 47 millions tuples per year. This data is only stored in the CASSANDRA database and not in the triple store to alleviate the TripleStore for RDF data (ref Figure 1).
Once the database schema is created, by querying the TripleStore for RDF data and an IoT middleware, we are able to collect the real data and store them in the database. In our prototype we use Node-RED. Node-RED is a programming tool that allows the creation of work ows for connecting together hardware devices, APIs and online services. Its advantages include many IoT protocol connectors already implemented and usable, a readable ow description le format based on JSON and a WebServices API that allows modi cations of the deployed work ows.
Let's illustrate a little bit more how this works by considering the example of a work ow that detects a window opening. The connection to the window uses the IoT protocol name used by the window sensor, and some protocol-speci c data needed for the connection to this speci c window (such as the sensor ID, or a device register o set) obtained by querying the TripleStore for RDF data in SPARQL (Figure 3). In this example, the ModbusTCP/IP protocol is identi ed. The Modbus protocol needs the IP and port address of the server, and a the register number speci c to the window (since in the system that is installed, all window states are retrieved in a unique frame), thus another query is issued to retrieve the needed data as shown in the query (Figure 4). Note that this second query is speci c to the ModbusTCP/IP protocol, in the case of another protocol it would be di erent. The second node is responsible for recurrent device interrogation. The third node retrieves the current time and date for inserting in the database. The three following nodes are used for data processing. The last one generates a CQL query, used for inserting data into the CASSANDRA database. In this query, the table in which the data is inserted is determined using the window name that is obtained by querying our TripleStore.
(3) Simulations A Smart Building Digital Twin aims to analyze and predict the building's behaviour during its life cycle with some multi-domain simulations. Many applications, such as predictive maintenance for example, needs the structural description of the building, that contains the list of each object subject to maintenance, but also need to know the use time of each of these objects, in order to predict their failure probability over time. Another example is the Intelligent Control System, that in order to manage simultaneously and consistently thermal and light comfort, must have access to the list of all windows and lamps, but also to the current temperature and natural light. In case of low light, the system can determine whether it's better to open blinds or to turn on the lights. In our prototype, we focused on the environmental part which is a valid application of a multi-domain simulation: structural description, dynamic time-series sensors and meteorological data are necessary. Many other simulation applications can be added to have a full representation, they will all have the same principle and need the same data.
For predicting the evolution of temperature of the buildings rooms we used OpenModelica software and a simulator changing actuators state (like radiator heating or not) as shown in gure 5. OpenModelica tool automatically builds a multi-domain digital simulation model, using the structural description of a building (including its geometry and the building material), and the historical thermal and meteorological data (acquired from the building's sensors). We built a Modelica model by querying ifcOWL instances to obtain structural characteristics of a room (as walls location, thickness, material used, ...). We detected some incompatibilities (spaces not closed, ...) in our rst model then we built a list of the constraints that must be respected to have a coherent BIM representation accepted by OpenModelica software.
To start a simulation, several input are needed: meteorological data which are historical or predictive data not included in our prototype but more issued from di erent sources in one part. In a second part, a subdomain of the ifcowl which are relevant for simulation (rooms, walls, windows, . . . ), and IoT data. More information are necessary for simulation, such as operating mode of the heat pump or heating trip temperature which are not include in the dataset because they are not de ned in SOSA/SSN ontology. They could be added in extensions of those ontologies for example. Finally, during simulation not all sensors are analyzed, that is why some data are replaced by real ones which are stored into the CASSANDRA database (explained in section 3). Then the simulation pilot starts the simulation. Depending on the temperature evolution of the room, actuators states change due to thermostat rule by the dedicated simulator. This change is also modi ed in the state of actuator in the input of OpenModelica as shown in gure 5. Resulting data are stored into new tables in the Cassandra Database. Those tables store some parameters of the simulation con guration (such as representation and input datasets). 4
In this paper, we have presented a reference architecture for creating and managing a Digital Twin that provides a global view of a Smart Building (i.e. structural/static and temporal/dynamic data). Thus it will facilitate the development of various applications that were not possible before due to the numerous silo data. By o ering a TripleStore with its multi-domain ontologies promoted by the W3C, and its associated sensor database both built in good intelligence and consistency, it is now possible to tackle more advanced functionalities and applications.
We proved with our prototype based on a real Smart Building that it is a very promising way to follow. It enables us to develop a multi-domain digital simulation tool that is going to be used to train and educate future engineers in the domain of Smart Building. Although for our approach to be complete and fully e ective, some perspective issues such as complex integrity constraints and versioning, should be addressed by the research community. We also hope that the industry will bene t from this work and will make some e orts in that direction. 5
We would like to thank Yann Richou and Houssine Idoudi for their work in this project. This work is part of the LaVI&Co project (Laboratoires Virtuels pour l'Industrie et la Construction { Virtual laboratories for industry and construction), 40% funded by the Ile-de-France FEDER Regional Operational Program Strengthening of new digital uses and content in the elds of e-education and ehealth. Its aim is to validate and develop two Digital Twin models for educational use, one in the construction eld and based on the Smart Building mentioned above, and one in the industry eld, based on an autonomous metal additive manufacturing unit.