Ontology-Based Expert System for Automated Monitoring of Building Energy Systems | Journal of Computing in Civil Engineering | Vol 37, No 1

Existing SchemasDifferent 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.Ontology SystemFor 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: •building topological structure and metadata about its energy system,•general expert knowledge formalized as axioms and rules for energy-efficient building operation,•monitoring data from the BMS, and•software algorithms, i.e., the program that processes data, building information, and aforementioned knowledge.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.



Source link