Ontology-Based Expert System for Automated Monitoring of Building Energy Systems

Different ontologies have emerged in information science that represent a good background a software application can build upon. Following one of the primary purposes of semantic web which consists of sharing common vocabularies on the internet, Vandenbussche et al. (2017) gathered and extensively documented all actual and publicly available vocabularies from many different and heterogeneous domains. Most relevant domains for our case encompass industrial automation, Internet of Things (IoT), energy management, and building design as well as building automation and monitoring. Pritoni et al. (2021) have reviewed relevant metadata schemas for building energy applications.

Focusing on the building information modeling (BIM) domain, the industry foundation classes web ontology language (ifcOWL) schema has been released by buildingSmart as a web ontology language (OWL) representation of the Industry Foundation Classes (IFCs) (ISO 2018). The W3C Linked Building Data community group has brought and promotes complementary standard ontologies that shall further support interoperability in the Architecture, Engineering, Construction and Facility Management (AEC/FM) sector. This includes a central lightweight ontology called building topology ontology (BOT) for describing the spatial topology of buildings (Rasmussen et al. 2021).

In addition, and as nonexhaustive enumeration, ontologies like PRODUCT, PROPS, ontology for managing geometry (OMG), file ontology for geometry formats (FOG), and building product ontology (BPO) provide complementary concepts allowing to describe among others product data, geometric representations and further properties (W3C-LBD-CG 2022). Some of these ontologies are already aligned with W3C recommendations for adjacent domains, e.g., the geospatial ontologies (OGC and W3C 2017), smart applications reference ontology (SAREF) (ETSI 2022), ontology modeling for intelligent domotic environments (DogOnt) (Bonino and De Russis 2019), Brick (Balaji et al. 2018), the semantic sensor network (SSN) (W3C 2017), and the quantities, units, dimensions and data types (QUDT) ontologies. The latter were originally initiated by the Constellation Program at National Aeronautics and Space Administration (NASA) (FAIRsharing.org 2021). Those ontologies cover in a wider range the domains of automation, monitoring, and IoT. Further interesting vocabularies and ontologies for smart buildings are, among others, Project Haystack (Project Haystack 2022), Tubes (Pauen et al. 2020), RealEstateCore (Hammar et al. 2019), and the BACS ontology (Terkaj et al. 2017). Furthermore, some metadata schemas have specific scopes like, e.g., control ontology (CTRLont) (Schneider et al. 2017) for control systems, and for smart grids, the IEC common information model (CIM), smart grid architecture model (SGAM), or facility smart grid information model (FSGIM) (Shafiullah et al. 2017).

All these efforts make a wide set of vocabularies available to the scientific community. However, this multitude of ontologies partly overlaps in the scope of AEC/FM, which as a countereffect slows down the widespread adoption of such technology in the industry. For a particular application, one should reuse as far as possible existing ontologies that best cover the targeted application domain instead of creating new redundant vocabularies. Moreover, the choice should focus on schemas that are already standardized or applied by a wide consortium of industries. Following these rules we partly relied on existing schemas inside the ontology system described in next subsection, thus ensuring future interoperability with systems applying those same schemas.

For providing the expert system with the ability to interpret an existing building and configure by itself underlying monitoring functions, we rely on the use of Semantic Web technologies. The main purpose of introducing ontologies into that system is to enable a model-based monitoring of building energy systems, in contrast to purely data-driven approaches (Mehmood et al. 2019). One common critic to classical rule-based systems is that rules and the semantics of the analyzed problem are usually hard-coded into the used programming language. In our case, the following building blocks are maintained separately:

That way, the knowledge rules for efficient building operation are kept generic whereas the targeted building-specific monitoring functions (field tests) that use BMS data as input can be derived and executed automatically. Thus, there is a separation between the data model and the algorithm that may be implemented in different programming languages. This distinction between model and algorithm is in fact the backbone of ontology-based logical reasoning (Rattanasawad et al. 2018). In our case, logical reasoners act as solving algorithms to derive the specific monitoring functions of the recommendation system. Logical reasoners are programs that process the description logics inside an ontology in order to derive new logical statements about objects described by the ontology. By nature, a reasoner is generic, i.e., does not need to be adapted to a specific use case, and thus may be used to derive the desired information. This way, it is possible to interchange or update models respectively buildings in a flexible manner.

To implement this approach, a core information model is introduced inside the expert system that is composed of a set of ontologies that conceptualize specific technical domains (Fig. 1). Two main information domains are covered, the building HVAC and BACS domains. The first provides a representation of a building and its built-in energy system, and the second focuses on representing the monitoring system of the building. Among the different metadata schemas and standards, the IFCs introduced and maintained by BuildingSMART International (2020) cover many AEC disciplines including also to some extent the HVAC domain. The automation domain has been formally described into the semantic sensor network (SSN) and sensor, observation, sample, and actuator (SOSA) models (W3C 2017) introducing, among others, the superordinate concepts of ssn:System, sosa:Observation, sosa:Actuation, sosa:Sample, and sosa:FeatureOfInterest.

For representing HVAC systems, the Brick ontology (Fierro et al. 2020) emerged a few years ago. It comprehensively covers the ventilation domain and is in permanent further development. Further useful ontologies are BOT, which is a lightweight ontology for describing the spatial structure of buildings, and the QUDT ontologies. QUDT enables enriching measurement data from sensors with meaningful annotations by providing comprehensive vocabularies for units systems, physical dimensions, and quantities from among others physics or chemistry. All of these schemas rely on Semantic Web data standards like resource description framework (RDF) and OWL and are actively maintained by international standardization institutions or community groups.

Because each ontology covers a specific domain with its limitations, we developed further ontologies inside the core model that enable a full description of a building in its operation phase and at metadata level. The resulting overall ontology is illustrated in Fig. 1. Additional ontologies consist of the Energy System Information model (ESIM), and Metric, Sense, and Risk models. Their purpose is on the one hand to aggregate the different described domains into one fully exploitable model. On the other hand, they fill semantic gaps in the existing standards with additional concepts and knowledge that are necessary for configuring and executing the targeted energy monitoring and recommendation system that is fully described in the “Expert System” section.

Similarly to Brick, ESIM describes the built-in energy system, thus filling gaps of Brick for some HVAC system components like solar, geothermal, or heat pump systems. Moreover, it enlarges the building scope to the district and energy grid levels. Accordingly, we have proposed some schema extensions inside the Brick community because Brick aims at becoming a widely used reference, whereas ESIM is rather used as an internal model for the specific purpose of the presented application. The Metric model consists of a set of quantity kinds and key performance indicators (KPIs) that complement QUDT with specific metrics for HVAC engineering (e.g., mm:HeatingEnergyConsumption, mm:HeatingCoilValvePosition, mm:SupplyAirTemperature, mm:IndoorAirTemperature, and so on) in contrast to the more fundamental and higher-level quantities from QUDT (e.g., quantitykind:Irradiance, quantitykind:Energy, quantitykind:Temperature, and so on). The Risk model provides a catalog of possible faults and operation errors that can lead to energy wastes, together with corrective ECMs.

Finally, the Sense ontology represents the central knowledge model that aggregates the several concepts and in which logical axioms and rules are encoded for formalizing expert knowledge. Concepts aggregation is performed in two ways, i.e., by mapping entities from one ontology to the Sense ontology, or by importing a whole ontology when all or most of its concepts are needed. In both cases, a so-called alignment is made by whether subsumption or equivalence relations between heterogeneous classes. As a result, the Sense model can formally represent a whole energy system in its operation phase including its subsystems and components, i.e., features of interest for the expert system, together with among others its sensors system, the observed properties, their measurement units and their references to data points from an external BMS database. Moreover, it includes formalized knowledge in the form of logical axioms and rules, as described in next section. This contrasts with the external ontologies, which rather focus on system description (Brick, ifcOWL, and so on), whereas the purpose of the Sense ontology is system characterization and interpretation.

Despite the broad scope of disciplines they represent, the external ontologies depicted in Fig. 1 lack reasoning logics and especially expert knowledge that can be applied for specific use cases. For our purpose of automatic setup of a monitoring and recommendation system, this knowledge has been integrated into the Sense ontology. The Sense ontology is named by analogy to the word sensing and is meant to interpret a system by means of logical axioms and internal rules based on predicate logic. This ontology is used to emulate the cognitive reasoning of a HVAC or BACS expert who would set up a monitoring system on the basis of information about the building energy system. When processed by a reasoner, the Sense model is able to identify locations within a building, its topology, and built-in systems. Key inferred facts are, for example, the presence and types of heating/cooling systems, energy distribution components, shading system, the presence or not of a heat recovery system, the types of terminals (e.g., radiators or air outlets), and which of those are operable by users. For describing this knowledge, there exists a certain number of ontology modeling constructs and rule languages that are applied. Fig. 2 gives some examples of so-called class axioms that are used to classify individuals or objects inside the ontology system.

The first example allows some HVAC zones inside a building to be identified, which should then be considered by the expert system for analyzing the usage of heating energy. More specifically, it selects heating zones by checking if they host some distribution component like, e.g., radiators from a heating system. The second one is used for classifying data points from the BACS system relying on the topological and functional description of the energy system. Indeed, the expert system requires specific and semantically richer quantities from the Metric model. Thus, a data point of a valve position or command can be identified as a heating coil valve position by interpreting the function of its related object inside the fluid flow subsystem. The third example is a simple class axiom that selects all entities that should be analyzed for some fault detection if they are threatened by some energy risk.

Table 1 provides some examples of generic expert rules formulated in the Semantic Web Rule Language (SWRL), which are evaluated for a given building by a reasoner (Pellet). In this case, potential risks are identified in an air-handling unit (AHU) according to its built-in components (e.g., heating coil, cooling coil, fans, humidifier, and so on). As a result, specific fault detection rules, which are programmed into single monitoring functions inside the expert system, are associated to corresponding existing instances of AHUs. Accordingly, if an AHU carries a certain energy risk, the expert system will apply corresponding monitoring functions in order to identify related faults or issues from real operation data.

This subsection presents an example utilization of the ontology system for identifying relevant monitoring functions in an air-handling unit of a residential house in Germany. The asset consists of three floors with $510.13{\mathrm{m}}^2$ living space with an indoor pool (ground floor: $277.64{\mathrm{m}}^2$, attic: $221.63{\mathrm{m}}^2$, and basement: $10.86{\mathrm{m}}^2$ including technical building equipment). The HVAC system provides heating and cooling energy from a gas boiler and complementary renewable energy sources, i.e., a geothermal collector and a heat pump. Energy storage is maintained by water tanks (heating circuit and drinking water), concrete core heat storage, and an open water storage. The distribution consists of floor heating and a ventilation system with integrated heat pump, heating coils, and a heat-recovery exchanger. The following case example focuses on the air-handling unit, which is schematized in Fig. 3.

The energy system has been modeled using Brick and the internal ESIM schema. Because Brick lacks some necessary components like, e.g., heat pumps, evaporators, or floor heating, the gaps have been filled by ESIM concepts. Both ontologies are aligned with the Sense ontology, which itself includes further useful knowledge and concepts for metrics or quantities, risks, and monitoring functions. Fig. 4 shows an extract of the RDF graph and more specifically the triples involving the AHU object. Those triples define components of the AHU.

Fig. 5 displays the outcome of the reasoning process. In that case, only the new inferred facts or triples about the AHU are shown on the portion of the graph. Main new facts include potential issues leading to energy waste (prefixed by risk:), relevant monitoring functions, i.e., FDD rules that should be used to detect such risks (prefixed by sense:) in real time, as well as all measurement points useful for executing the monitoring functions and for performing data analytics (prefixed by nsc: in the figure).

The previous sections introduced the ontology, which represents only one part of the expert system. This linked data system only provides necessary knowledge for processing building metadata and for configuring algorithms or tests for operational state interpretation and ECM recommendation. The whole expert system consists of three main components (Fig. 6):

The building and monitoring metadata contained in the fact base consist of information from the OWL ontology, which is imported from RDF/XML syntax into Python at run time using the RDFlib library. It provides the description of the building structure together with its technical systems (heating system, cooling system, and so on) as well as the types of sensors and meters installed, the quantities they measure, their units, and so on. In the case example from previous section, this information was described inside the Brick and ESIM instance models. In contrast to metadata, actual measurement data are not stored into the ontology but are regularly cached into Pandas data frames from a database prior to each inference run. On the basis of the fact base and with the help of the knowledge base, the inference module can then characterize the building as it is built and assess its operating conditions.

The derivation of ECMs is executed sequentially in three steps or inferencing levels as illustrated in Fig. 6. The first level consists of metadata processing, which aims to characterize the existing building systems, i.e., determine the structure of the particular building energy system, find the potential issues that might occur, and generate tests to check if the issues actually occur at a given point in time. For that purpose, the ontology system and logical reasoning as presented in previous sections are involved. It is executed once to set up the system or periodically when metadata, i.e., building information, changes over time (retrofitting of HVAC system, addition of sensors, and so on).

This system characterization step is run in Python using the Owlready2 library. For each room, HVAC subsystem, or component, it delivers a list of potential energy risks and ECMs that should be checked for validity in the second inference level. Additionally, it provides for each building element of interest a list of monitoring functions or data checking rules (tests) together with the required measurement points that should be queried from the existing data acquisition system. As an example, if a room hosts radiators, it will be classified as a heating zone and considered for checking potential overheating. If a sensor exists for measuring the temperature in this room, the sensor ID and information about the location of interest will be passed to the next levels of inference, which will provide the end user with the advice to reduce indoor temperature if overheating really occurs.

The second and third inference levels consist of data processing or analytics. At this stage, monitoring functions selected in the previous inference level are executed in parallel. The inference module executes these inference levels continuously and in real time. The monitoring functions consist in our case of data preprocessing functions and rules (or tests), which are defined as IF-THEN statements including boolean operators (OR, AND, and NOT) together with information about the actual data point IDs to be checked. These rules (tests) are used for interpreting the operational conditions of the building technical systems (weather conditions, systems on/off status, indoor conditions, and so on). They are based on command and measurement time series that are cached into the fact base. The cached time series range from the most recent value to a few hours in the past, which keeps the computational effort low. If a fault or ECM is validated at a certain time, a warning or recommendation is triggered on the third level of inference by the expert system. In contrast to the first level, the second- and third-level rules were implemented directly as boolean expressions into the Python programming language. One reason for the distinct inference levels is that ontology-based reasoning is more adapted for semantic processing of metadata and less for time-series analysis, while a programming language like Python provides a fast and efficient way of processing large time-series data and for expressing procedural rules.

A fundamental prerequisite for the proposed workflow is the availability of data and metadata. Because data are extensively supplied in modern BMS systems, metadata are still difficult to gather for populating the ontology system. In that context, three types of metadata sources can be involved, which result in three alternatives for the workflow:

A first prototype was developed as a recommendation system for building users of 12 buildings across Europe following Workflow 1. In that context, a common database schema was defined to store and continuously update all sensors and meters data. The metadata required to populate the ontology were defined into that database schema and implemented in the Structured Query Language (SQL). A simplified version of this schema is illustrated in Fig. 7 in the form of an entity-relationship diagram (ERD). The resulting relational model applies a modeling construct used in BIM that consists of nesting building elements into a spatial hierarchy (BuildingSMART International 2020). The building information contained in these metadata is reused in the fact base mentioned in previous section together with the measurement time series from sensors and meters. Thanks to this information, the recommendation system has the ability to unambiguously locate each measurement within or outside a building, and to characterize the building and available data points.

Currently, Workflow 2 is being implemented in two further pilot buildings including the one from the “Case Example” subsection. It relies on the Brick paradigm promoted and under active development by the Brick community (Fierro et al. 2020). Because much more metadata can be extracted from BIM models like the ones produced in CAD design tools, an integration into a BIM Workflow 3 represents the next extension of the prototype. The instantiation of metadata inside the ontology system from BIM data is not put in focus in that article, but it is a work in progress that relies on existing data conversion methods from the Linked Building Data field (Bonduel et al. 2018).

For synchronizing data from the existing monitoring system of each building with the fact base, a universal communication interface was chosen. It consists of an Open Platform Communications Unified Architecture (OPC UA) interface, which shall increase, as one of the established automation standards, interoperability possibilities with BACS systems of future buildings (OPC Foundation 2020). The incoming data are continuously synchronized through the OPC interface with the fact base of the recommendation system. The recommendation system itself runs as a cloud service remotely on a virtual machine that is hosted at our premises.

Even if the workflow can run automatically thanks to the expert system, there is still some initial manual effort necessary for preparing the data infrastructure and entering metadata into the database for Workflow 1. Additionally, when data were not accessible or missing in the existing BACS system, new monitoring devices were installed, favoring low-cost and wireless sensors. For the 12 buildings (around 2000 measurement time series), this implied several labor days for providing data into the database, and a few more days for setting metadata. Workflows 2 and 3 will considerably reduce effort for metadata setting, and interoperability with BACS systems of modern buildings will avoid equipment installation work.

The results from the recommendation system are sent as JavaScript Object Notation (JSON) payloads to a RESTful server, which is accessible for a client end-user application. This latter provides users with recommendations and alerts through a web and mobile front end. The communication between client and server occurs through a specifically designed representational state transfer (REST) application programming interface (API). The REST architectural style provides a data exchange architecture enabling so-called create, read, update, delete (CRUD) operations, relying on HTTP protocol for exchanging data resources. Corresponding endpoints are shown on Fig. 8.

The server is continuously fed by new recommendations from the recommendation system and it is periodically queried by the client application in order to provide the end users with new messages. Each recommendation object contains following main information:

Fig. 8 provides a screenshot of a front-end application that shows the recommendation view. In the example, current recommendations for an open-space floor of an office building in Spain are listed. The related ECMs are based on available heating and cooling zones identified in the database system as well as on the available data points for checking potentially wasted energy in terms of heating, cooling, lighting, or appliances use. In the 12 buildings previously mentioned, a comparative study was performed in which 120 building users were using the recommendation system from October 2020 until May 2021. The system proposed in real time the following types of ECM:

The experiment evaluation reported an overall energy saving of 12.2% (Calleja-Rodríguez et al. 2021). It should be noted that during this study, other software components were developed, e.g., for data visualization and for gamification in order to increase people’s engagement in using the recommendation system.