The building is the most energy-consuming sector, amounting to 42% of final energy consumption in France in 2021 [1]. Therefore, acting on the management of energy consumption is key to saving energy building sector. In this context, we investigate the possible optimization approaches of the Internet of Things (IoT) control system of smart buildings. We identified three factors that have a significant impact on energy consumption in IoT control systems: (1) weather, (2) human activity, and (3) physical phenomena that occur in smart buildings. For instance, thermal transfers occur between different zones of the building, such as from the office to the hallway. Physical phenomena occurring in a complex and heterogeneous connected Cyber-Physical System (CPS), e.g. smart building, are poorly taken into account in current IoT applications. These physical phenomena are often represented by Building Performance Simulations (BPS) which uses mathematical models to simulate the dynamics of the CPS based on observations of connected objects.
Integrating this class of models to IoT systems reinforces a well identified issue facing the IoT field: heterogeneity. Indeed, complex CPS such as smart buildings are composed of several interacting heterogeneous subsystems. This heterogeneity makes the IoT system prone to the challenge of interoperability [2]. The exchange of the data between the cyber and physical components and its understanding have been identified as major challenge in the literature [3]. Extensive researches are led in the IoT field, by different academic and industrial entities, focusing on semantic interoperability issue. They leverage semantic web technologies (such as ontologies) to tackle the high fragmentation of IoT systems. For example, the World Wide Web Consortium (W3C) 1 introduces the Web of Things (WoT) [4,5] as a standard architecture/model for semantic interoperability.
For the building performance simulation, Functional Mock-up Interface (FMI) [6,7] stands out as the leading interoperability standard in the simulation industry. It addresses diversity of modeling tools, and therefore of modeling formats and languages, studied in several research [8,9,10] by facilitating the exchange of dynamic simulation models among various tools in a standardized format. It also allows the same model to be executed independently of the modeling tool. Nevertheless, addressing the interoperability between simulation models and other applications, such as IoT applications, remains a pending challenge [11,12].
To overcome this challenge, BPSs and IoT systems need to interoperate as part of a smart building management system. This requires effective data exchange between these heterogeneous systems. Reaching a consensus on shared data model (ontologies) enables to ensure semantic interoperability among different components of the smart building management system. Additionally, leveraging linked data principles enhances the interoperability further, as it enables the creation of a web of interconnected and interrelated data, fostering a more holistic and integrated approach to smart building management.
In this paper, we presents the Web of Simulations Ontology (WoSO) as a core vocabulary providing a high-level description of BPS, modeling two different facets. For the IoT aspect, the simulation is viewed as a component of the extended IoT system, relying on the SAREF ontology standard for its representation. For the BPS aspect, it relies on the Functional Mock-up Interface Specification to identify and describe information related to the core functionality of a simulation.
Organization The rest of this paper is organized as follows. Section 2 presents concrete and practical scenarios. Section 3 introduces the ontology objectives and requirements. Section 4 presents some of the relevant research works that propose ontologies in both IoT and BPS domains. Section 5 describes the main steps of the ontology development process and the overview of the ontology. In Section 6 "case study" we implement the WoSO ontology to the scenario A depicted in the second section. Finally, in Section 7, we conclude with synthesis of the work already done and future work.
We present a concrete and practical context in which interoperability between BPS and IoT systems is required to optimize energy management. By extension, requires the definition of WoSO. Through these examples, we describe the tasks that need to be supported by WoSO and serve as a basis for defining its requirements and evaluation tests.
Scenario A: Office heating control Mr. John works in Office 123 that has a heating control system consisting of a thermostat and a heater. Mr. John is typically in his office from 8 a.m. to 6 p.m. on working days, but some days he is out of the office. His calendar is shared on the Web. The temperature setpoint is 15°C during the night, and 19°C when Mr. John is in his office. The temperature setpoint should be reached before Mr. John arrives, but not too early before so as to save energy. To do so, the heating control system determines when Mr. John will arrive based on his calendar, and how long it would take for the office to reach the temperature setpoint based on a thermal simulation of the office. Scenario B: Energy performance monitoring Ms. Smith lives in a house powered by photovoltaic panels and equipped with an IoT control system that provides real-time information about the house's energy production and consumption. She wants to increase the temperature of the house by 3°C without consuming more energy than it produces so as not consume the energy reserves. To do so, the IoT control system determines how much energy the house will consume if the temperature is raised, and how much energy the photovoltaic panels will produce according to the weather forecast, based on the energy performance simulation.
The main contribution of the paper consists of an ontology, called Web of Simulations Ontology (WoSO). It provides a common vocabulary and structured representation of building performance simulations, enabling a shared and standardized understanding of the forecasts and predictions made based on BPS and its relationships with the data of the IoT system. This promotes more effective aggregation and integration of the BPS data in the decision making process of the IoT system.
The design and development choices that have been made in the development of the WoSO ontology are driven by the following requirements:
In this section we identify reference ontologies in the IoT domain and select the one we align our ontology with. We, also, explore existing BPS ontologies to evaluate their relevance and coverage according to our requirements and positions our research to fill gaps in current knowledge representation in BPS field.
With the ongoing expansion of components within the IoT landscape, there is a continual emergence of new solutions aimed at addressing their heterogeneity and allow interoperability across platforms, ecosystems, and devices. As a result, a multitude of ontologies have been developed to meet the requirements according to context-specific needs of IoT Applications [13,14,15].
Great works and efforts have been made in past years to comprehensively encompass the IoT domain in a standardized way. For example, 58 ontologies with IoT tag are referenced on the Linked Open Vocabulary (LOV).
The selected ontologies for our study are: Sensor, Observation, Sensing, Actuation / Semantic Sensor Network (SOSA/SSN [16]) and The Smart Applications REFerence (SAREF [17,18]).
SSN/SOSA, porposed by the joint W3C and Open Geospatial Consortium (OGC) 2 , is specifically crafted for modeling and representing sensor and actuator networks, observations, actions and related entities, providing standardized depiction of sensors, actuators, elements such as samples and their relationships within networks. it finds application in scenarios where accurate and standardized representation of sensor network is crucial [19].
SAREF, proposed by European Telecommunications Standards Institute (ETSI) 3 , on the other hand, is designed for the semantic modeling and representation of smart appliances and devices within the IoT landscape, providing a standardized way to describe the devices, the appliances and their services, functions, and interactions. The primary focus of SAREF is on smart devices commonly found in scenarios where the representation of smart appliances is essential for seamless integration and communication within the IoT application.
While they share common goals of providing semantic representations for IoT concepts and both being considered as references from standards bodies, each of them models different aspects of the Internet of Things (IoT) and sensor-related domains. The specialized application of SAREF in domains like home automation and smart buildings, where semantic clarity regarding smart appliances is paramount, makes SAREF more tailored to the energy management applications targeted in our research.
The complexity of building systems and the need for interdisciplinary collaboration have led to the adoption of ontologies as a means to enhance knowledge representation and interoperability within the BPS domain.
Pritoni et al [20] present a survey of ontologies for building design, energy modeling, occupants and behavior and building energy applications across the building life cycle. Regarding energy modeling, it presents ontologies that describes Building Information Modeling (BIM), for instance: Industry Foundation Classes (IFC), Green Building XML (gbXML), ifcOWL, and IoT ontologies as described in the previous section 4.1. However, it does not mention ontologies that represent the Building performance simulation itself.
Indeed, The data exchange for the extended building-simulation domain and even for the entire Architecture, Engineering, Construction, Owner, Operator (AECOO) industry is widely covered topic in the literature [21,22] In [23], the authors propose an ontology-based automatic framework which can integrate data from different sources and generate Building Energy Management (BEM) models with thermal zoning automatically. In their approach, they consider four key information domains for BEM, weather, building, internal heat gain and HVAC system to integrate data from various information sources in a single Data model: Building Energy Management model (BEM). Accordingly, four ontology components are designed and constitute the whole ontology model of BEM: Brick schema, Building Topology Ontology (BOT), weather ontology model and building energy models. A similar effort was conducted by Bjorskov et al. [24], they propose a framework for automated and adaptable energy model development to provide the simulation models required by building DTs. The framework builds upon the Smart Applications REFerence (SAREF) ontology to ensure interoperability.
The purpose of both frameworks [23,24] is to provide a single data model that represent all the data resources needed for simulation to be execution, but don't include the representation of simulation data in the data model. However, it is necessary for the simulation to be represented in the data model so that it can be used as a resource by the other components of the system, as advocated in our approach.
The Physics-based Simulation Ontology (PSO) [25] models physical phenomena based on the perspective of classical mechanics involving partial differential equations and the information artefacts that are about the physical phenomena. This representation focuses on physics problems that govern the physical phenomena modeled in the simulation models and don't include their relationships with other domains.
The FMUont ontology [26] is the closest to what we want to achieve. It focuses on the interoperability between the simulations, it is developed in order to derive connections between FMUs. the structure of FMUont is designed to relate variables of single FMU to pre-defined objects to other domains, established ontologies that are linked to ensure compatibility with other fields. However, this ontology considers only FMU format for simulation models and it doesn't define some concepts for instance: model and simulation.
Our approach seeks to provide domain-agnostic solution and focuses on two vertical domains: IoT and BPS, which are common in the Smart Building domain. Therefore, we introduce WoSO: an ontology that represents the semantic description of the BPS domain and the relationship between BPS and IoT domains.
We applied the ACIMOV methodology [27], which is an agile ontology development methodology that adopts DevOps principles and provides tools (e.g. GitLab template) to improve accessibility and organization of the ontology development process.
The rest of this section is organised as follow:
Competency questions In this section, we defines a list of competency questions that illustrate the technical requirements. Accordingly, the scope and the limits of the ontology are defined.
The conceptualisation is the process of enumerating the terms and entities within the scope. then these terms, entities and relationships are illustrated in a diagram.
Evaluation In this section, the correctness and the completeness of the ontology is assessed according to the ability of the model to answer the CQs.
WoSO is published at the following URL: https://purl.org/woso#
Based on the scenarios depicted in the Motivating Scenarios section and the requirements listed in the section 3, we raised a total of 10 competency questions, including 5 BPS-oriented competency questions, and 5 IoT-oriented ones. They are available in the supplementary material of this article, an some of them are listed below. To ensure the alignment to the latest version V3.2.1 of SAREF [17], we adapt the SAREF reference ontology patterns [28] to building performance simulations. SAREF focuses on the concept of device, which is defined as a tangible object designed to accomplish a particular task in IoT system. Therefore, a saref:Device offers a service (the saref:Service saref:isOfferedBy min 1 saref:Device). Moreover, a saref:Device can measure a property, such as saref:Temperature and saref:Energy.
Even though a simulation model is not a tangible object, it is still a component of the IoT system that produces and consumes data. A BPS accomplish the task of simulating, and offers a function. It can also act upon some features or properties, such as forecasting and predicting values for these properties. Moreover, a simulation may consist of other simulations (co-simulations). A simulation model can be executed by a device.
Accordingly, we formulate the following competency questions:
The WoSO ontology is a OWL 2 DL ontology that consists of 5 classes, 6 object properties, and 15 data properties. WoSO has two main classes highlighted in bold in Figure 1:
woso:SimulationModel This class refers to a mathematical model for the calculation of the system state variables based on equations describing a physical or abstract system, it has data properties to describe the metadata listed in FMI specification. For exemple: woso:hasName, woso:hasVersion, woso:generationTool, woso:generationDateAndTime and so one.
woso:Simulation A simulation is the execution of the woso:SimulationModel under certain condition, it also has data properties: woso:hasName, woso:hasExecutionStartTime, woso:hasExecutionEndTime. Object property woso:isExecutionOf links a woso:Simulation to the woso:SimulationModel it is an execution of.
The inputs, outputs, and parameters of a simulation model are described in natural languages using datatype properties woso:hasInputDescription, woso:hasOutputDescription, and woso:hasParameterDescription. SAREF object properties saref:hasInput and hasOutput are also applicable, if the description of inputs and outputs requires more structure.
A simulation is linked to its actual inputs, outputs, and parameters, using object properties saref:hasInput, saref:hasOutput, and woso:hasParameter. WoSO defines the class woso:SimulationVariable that may be used to type objects of these properties.
A woso:PredictingFunction is a function (saref:Function) that allows to transmit data from or to a woso:Simulation such as its inputs and outputs.It is linked to the woso:Simulation with the object property saref:hasFunction. A woso:PredictionService is a type of service (saref:Service) that exposes the woso:PredictingFunction on a network. A Service is offered by (saref:isOfferedBy) a woso:Simulation.
The high level terminology of the ontology is shown in the diagram depicted in Figure 1.
To ensure the overall quality and effectiveness of the WoSO ontology, we evaluate the ontology to assess its correctness and completeness. The correctness evaluations focus on logical consistency and semantic integrity, the completeness evaluations assess the coverage of all the needed concepts and relations.
To do so, we verify that the competency questions defined at the beginning of the development of WoSO are covered by the classes and properties and the queries responses are the ones expected. We first translate the CQs listed in the section 5.1 into SPARQL queries, then execute them over the ontology. The following list shows the CQs and the corresponding SPARQL queries.
CQ1 What is the model executed by a simulation?
In this section, we implement the ontology WoSO according to the first scenario depicted in the section 2. We created a fictive knowledge graph, with instances of the elements described in the scenario. Then, we execute the SPARQL queries over the knowledge graph to verify that the answers match the expected ones. Listing 1 instantiates the ontology to represent the first scenario of Section 2.
<Office123> a saref:FeatureOfInterest ; rdfs:label "Office 123"@en .
<Thermostat> a saref:Device ; rdfs:label "Thermostat"@en .
<CurrentTemperature> a woso:SimulationVariable ; rdfs:label "Current Temperature"@en .
<DayTimeTemperatureSetPoint> a woso:SimulationVariable ; rdfs:label "Day time Temperature Set Point"@en .
<NightTimeTemperatureSetPoint> a woso:SimulationVariable ; rdfs:label "Night Time Temperature Set Point"@en .
<HeaterState> a woso:SimulationVariable ; rdfs:label "Heater State"@en .
<SimulationStep> a woso:SimulationVariable ; rdfs:label "Simulation Step"@en .
<HeaterStatePrediction> a saref:Function ; rdfs:label "Heater State Prediction"@en .
<HeatingControlPrediction> a woso:PredictionService ; rdfs:label "Heating Control Prediction"@en .
<ThermalModel> a woso:SimulationModel ; rdfs:label "Thermal Model"@en ; woso:models <Office123> . <ThermalSimulation> a woso:Simulation ; rdfs:label "Thermal Simulation"@en ; woso:isExecutionOf <ThermalModel> ; saref:hasInput <CurrentTemperature> , <DayTimeTemperatureSetPoint> , <NightTimeTemperatureSetPoint> ; saref:hasOutput <HeaterState> ; woso:hasParameter <SimulationStep> ; saref:offers <PredictionService> ; saref:hasFunction <HeaterStatePrediction> ; saref:madeBy <Thermostat> .
Listing 1: Instantiation of WoSO according to the scenario A "Office heating control".
In this paper, we introduced the Web of Simulation Ontology (WoSO) as a foundational framework for integrating Building Performance Simulations (BPS) into Internet of Things (IoT) systems, with the aim of optimizing energy management in smart buildings. WoSO provides a high-level description of BPS and IoT systems, relying on ontology reference of the IoT domain: SAREF and a widely used standard in the BPS domain: the FMI standard. It addresses the interoperability challenge at the semantic level, enabling effective data exchange and interaction between these two domains.
The ontology development process follow ACIMOV ontology engineering methodology and involves ontology engineers and domain experts. The formal model is constructed from the conceptual model using OWL and Turtle, we also generate a documentation.
We have several perspectives for this work. First, we update the competency questions continuously to maintain the ontology and extend it. Then, we assess the execution time and the results of the queries that require reasoning capabilities. In parallel, we are working on the implementation of WoSO for the use case of building energy management efficiency. The building is a tertiary building located on EDF R&D site, and is equipped with an IoT control system and a building thermal model. We have access to the data space where the IoT data is stored and to the library of BPS: BuildSysPro. The aim is to assess its effectiveness and its performance in data exchange between IoT and BPS.
Current ontology development relies primarily on FMI standard and SAREF ontology and focuses only on Physics-based Simulations. A potential improvement is to explore other standards and solutions of model exchange (other than FMI), in order to broaden the ontology application scope. For instance include human activity simulation.