Semantic BMS: Ontology for Analysis of Building Operation Efficiency

Each organization needs to ensure various aspects of its operation that are not directly involved in reaching its primary goal (e.g. providing service to a customer or sell its products). Such tasks are the core part of the Facility Management discipline. In recent years, environmental aspects of facility operation gain attention in the eyes of facility managers, both because of the legislative requirements and a close relation to sustainability and low operation costs.

We can distinguish several systems and/or data sources that can be utilized to support and simplify tasks of facility management staff.

Computer Aided Facility Management (CAFM) systems facilitate tasks such as assignment of employees to rooms, a log of maintenance plans, requests, and tasks, or energy consumption data. A Building Information Model (BIM) contains spatial information about building constructions, parts, and technologies installed in them. Modern (“intelligent”) buildings are equipped with a variety of sensors and controllable devices (e.g. HVAC, security systems). The devices are integrated into the Building Automation System (BAS), also referred as Building Management System (BMS). The devices incorporated in BAS can be remotely controlled, monitored, and queried. Individual information objects (such as current temperature in particular room measured by a sensor) accessible in the BAS network are referred to as “data points” further in the paper.

A crucial part of sustainable and effective facility operation is benchmarking. Benchmarking methods in facility management are covered in EN 15221-7 standard, including environmental awareness. Requirements placed on benchmarking Key Performance Indicators (KPIs) are summarized in [1]. Among others, the authors mention flexibility, the quantitative nature of the KPIs and simplicity of use. BMS data satisfy the first three requirements, the simplicity of use is a downside of current BAS solutions.

The BAS contains a large amount of a precise, up-to-date, and detailed data that are valuable for a building operation analysis and cannot be obtained any other way. However, data points of the BAS are described by their location in the network topology, not by the role that algorithms, sensors, and actuators fulfill in the building operation. Using BACnet protocol as an example, data point representing temperature sensor is identified by the network address of the device that reads the value, data type of the input (Analog input) and ID of the input within the device. Besides this identification of data point, BACnet provides only several free-form string attributes such as Name or Description, which are intended to be easily readable by human operators.

The absence of structured semantic information prevents efficient querying of the data points for analytical purposes, as it is not possible to select and filter the data based on criteria such as a type of a source device, location of a measurement or measured quantity kind. If the data from data points are required (e.g. electricity consumption for last month for each of the buildings on the site which will be later compared), the operators of the system must manually gather the data point addresses by inspecting the building plans or user interface of the BAS.

The above-mentioned problem clearly emerges when operating large BAS system. Masaryk University utilizes BAS network consisting of approximately 1500 devices communicating using BACnet automation protocol with hundreds of thousands of data points available. The network covers 35 buildings with the overall area of 120 000 m² at the site of University Campus Bohunice in Brno, Czech Republic and several more over the whole Brno city. Previous attempts of data coming from the BMS of the university have been published in [2] and [3]. The requirements of effective operation of large-scale installations of automation technologies are discussed in [4].

This paper presents Semantic BMS ontology that aims to provide a semantic description of the building automation systems. Such description can be easily queriedfor building operation data needed for benchmarking, providing decision support in tasks such as improving facility efficiency, sustainability and increasing organizations’ environmental awareness.

The semantic description of sensor networks is a subject of ongoing research, as it combines two significant trends in computer and information science – Semantic Web (Open Linked Data) and Internet of Things. Furthermore, the trend towards “Smart Cities” stimulates research on the integration of automation systems and building automation data analysis.

The Open Geospatial Consortium (OGC) provides Sensor Web Enablement (SWE) suite of standards, ensuring syntactic model of sensor networks (SensorML) as well as interfaces and protocols for data exchange. OGC’s Observation&Measurements (O&M) provides a limited semantic description of sensor networks. The SWE however does not covera domain specific semantics.

Probably the most notable ontological description of sensor networks is Semantic Sensor Network Ontology (SSN) developed and maintained by W3C Consortium [5], which adopts the scheme of Observations&Measurements Model.

In architecture, engineering and construction industry, integration of different Building Information Model solutions is facilitated by Industry Foundation Classes standard in current version IFC 4 (ISO 16739:2013). The object-based data model together with the provided file formats ensure data exchange between BIM systems and can be viewed as a source of semantic information that can be used for analysis of building performance, as shown in [6]. However, the IFC does not aim to model complex semantic information concerning data points available in the building automation systems. In [7] and [8], direct mapping of data points to IFC entities is used for building operation analysis. As noted by the authors of [8], the IFC itself does not provide built-in capabilities for describing features of interest and properties observed by sensors.

Standardized building automation protocols such as BACnet (ISO 16484-5), LonWorks (ISO 14908-1), KNX (ISO 14543), or ZigBee generally cover the operation of building automation devices, providing specifications for physical communication layer, data link and networking layer and application layer on the highest level. Automation protocols focus on communication interfaces and do not provide tools for the complex and structured description of the semantics of the data points.

The MOST project presented in [9] provides a framework for building operation analysis. The MOST uses a relational database for storing basic semantic information about operation data.

In [10], the SSN is extended by a model of physical processes occurring in the building (e.g. adjacent room exchanging energy) to provide tool for building operation diagnosis and anomaly detection.

The Open Linked Data approach for building automation data streams is facilitated by EDWH Ontology proposed in [11]. The aim of the EDWH ontology is to provide a bridge between the SSN ontology and the W3C RDF Data Cube vocabulary, as the data are meant to be analyzed by OLAP data cube techniques.

In [12,13,14] the authors use a SSN-based ontology for energy management based on sensor data using OLAP and Complex Event Processing. The semantically described BAS data help to establish situation awareness at the strategy level and allow multi-level evaluation of energy consumption (from organization level to the level of individual appliances).

In general, existing ontologies either aims to describe different aspects of BAS than data analysis, use proprietary/ad-hoc structures for storing semantic data, ignore integration with BIM systems or do not provide a domain-specific mapping of BAS systems to the SSN ontology.

The goal of presented research is to provide a BAS-protocol-independent model of intelligent building systems. The Building automation system can be viewed as a sensor and actuator network for the purposes of data analysis. A semantic description of sensor networks is a subject of extensive research, resulting in frameworks and tools such as SensorML language, Observations & Measurements (O&M) model or Semantic Sensor Network ontology (SSN). However, for the use in the domain of building automation, certain differences have to be taken into account.

The Semantic BMS Ontology (SBMS) proposed in this paper is thus an extension of the SSN ontology, addressing domain-specific requirements of building automation data analysis. The SBMS remains “fully backward compatible” with the SSN ontology (meaning no modification were made in the SSN itself, it was only extended) and at the same time provide greater semantic description strength for the target domain that “pure” SSN.

The proposed ontology aims to represent information (data) available for operation analysis. It does not aim to describe physical topology of the BAS network or physical properties of the sensors and actuators such as operating range. Standardized building automation protocols themselves also provide limited metadata description of the system as well as other services such as a data store. Similarly, the BIM and CAFM provides additional sources of semantic information. As a result, the semantic description of the BMS is not required to contain some information that would be a duplicate (copy) of data available in the BAS, BIM or CAFM systems. The aim of the presented research is to enrich the BAS/BMS with semantic links to entities present in other systems (BIM, CAFM) and add a new layer of semantic metadata that are not available elsewhere.

The SBMS ontology enriches the SSN by adding the concept of a datapoint, which is distinct from a sensing device. While a sensing device is a source of data presented by a datapoint, a datapoint conceptualizes a measured value available in an automation system. It describes a representation of measured data in building automation software.

Figure 1 presents standard components of the SSN ontology together with their specializations defined in the SBMS ontology. The center point of the SSN is the ssn:Observation concept. The observation connects all actors and objects that take part in the process of obtaining measurement data, and thus provide all available semantic information via its properties. The specialized sbms:Observation as well as properties defined in the SBMS limits domains and ranges to those concepts that are usable in the domain of building automation. The changes affect the definition of the feature of interest, observed property, sensing methods and sensing devices.

Overview of the SBMS ontology

Full size image

Key concepts for accurate semantic annotation of sensor/actuator data are “Observed property” (OP) and “Feature of Interest” (FoI). The concepts were defined in O&M framework and adapted by the SSN ontology. The FoI represents an object of measurement. The OP represents specific information that we observe. In the domain of building automation, we can demonstrate the concepts on examples such as energy consumption (OP) of a specific building (FoI) or speed (OP) of a specific fan (FoI). The SBMS ontology further specializes the concepts for use in the domain of building automation.

The ssn:Feature of Interest is restricted by the subclass sbms:Scope to be site, building, floor, room, or device further described in the BIM database. This restriction reflects a nature of a data available in BAS. Since BAS ensure operation of the building, every piece of information available in the system can be related to specific part of a facility or to a piece of installed equipment. Class and property definitions are restricted so as validFoI can be either a device (e.g. valve, pump, engine, or PLC) or a location (site, building, floor, or room).

A similar restriction is applied to the ssn:Sensing Device by the subclass sbms:Source. Every piece of information available in the BAS must be measured by some device connected to the BAS network. Such devices are naturally present in the BIM database. As a result, each individual of sbms:Source has to be a device described in the BIM database, represented by sbim:Device class.

The SBMS ontology contains a simplified model of selected elements from the BIM systems. Such concepts reside in dedicated namespace sbim. Namely, it contains concepts describing locations and parts of the facilities (sbim:Site, sbim:Building, sbim:Floor, sbim:Room), and devices (sbim:Device and its descendants) that provide sensor data or that are observed by the building automation system. Classes representing specific types of building equipment are adapted from the IFC 4 specification.

3.1 Semantic Description of BMS Addresses

The SBMS ontology adds a representation of an address that publishes observed data in the BAS. Identification of a sensing device is not sufficient in case we need to obtain the data from the BAS system. The sensing device is identified by ID in the BIM. The BIM ID, however, cannot be used for accessing data in the BAS, since certain sensors are represented in the BIM as independent devices, but they are primitive and do not directly communicate within the BAS. An example of such device is a temperature sensor, which is a simple thermistor in a casing, connected to a PLC. The sensor is represented in the BIM as a separate entity, but the data is accessible via the PLC.

Thesbms:Addressclass defines several subclasses, most important are sbsms:Input and sbms:Output, representing sensor reading and actuator command.

The presented ontology is designed to model the data sources available in the BAS and provide additional semantic information regarding relationsof respective data points to a physical environment of the building. The newly added semantic information can be used by developers of new analytical applications for the domain of building operation analysis. Such applications will provide decision support for improving building performance and efficiency.

Typical environment-related tasks for such applications are related to energy consumption and workplace temperature conditions.

In case of energy consumption, the ontology can be easily used for selecting data points containing electric consumption. The combination of appropriate parameters defines desired data points: Source device type – Energy meter, “Input” data point type and Property domain “Electricity”). The Scope attribute in the result set then describes facilities that are responsible for a consumption measured by a given data point.

Another use case of the ontology related to environmental responsibility searches for rooms that are cooled or heated ineffectively. The ontology allows for easy selection of room temperature data. Data selection is very similar to the previous use case, finding data originating from temperature sensors measuring air temperature with Scope type of “Room”. The data then can be gathered and outliers – rooms with unreasonably high temperatures in winter on low temperatures during warm periods – can be identified and inefficient behavior can be addressed and removed.

The novelty of the ontology allows selecting data according to mentioned criteria. Current building automation systems do not provide querying mechanism and do not annotate the data by desired attributes, such as Scope or Property domain.

In order to facilitate the development of analytical applications to maximal extent, the Semantic BMS framework is being developed (see Fig. 2). The framework is divided into two main parts – Data providers and Semantic providers. Data providers are used for accessing measurement data. The Semantic providers present data available in the SBMS ontology. The rest of this section will be focused on the Semantic provider.

Semantic BMS framework overview

Full size image

As an ontology repository, Apache Jena TDB is used. The repository can be queried directly (using SPARQL) or via the Semantic API.

SPARQL Query that collects all the available data about a data point has following structure (in this case, the datapoint has BMS ID “1600.AV4”:

The segments of SPARQL query are ensure retrieval of different data point semantic descriptors. Lines 1–2 ensure selection of the desired data point. Line 3 retrieves a type of the data point (e.g. input or output). Line 5 gets the Observation individual that connects the data point to other semantic metadata. Lines from 6 to 13 retrieve information related to the source of the data – BIM id and type of source device. Similarly, lines 14–21 gather data about scope of the data point. Lines from 22 to 24 are related to the Observed property parameter. Lines 25–32 are intended to retrieve information regarding sensing type and possibly time window if applicable for given sensing. Often repeated FILTER statement deals with type hierarchy in ontology language. The query selects only leaf, most specialized subclass of given individual.

Results of such query are then returned in various serialization formats, such as SPARQL JSON.

Due to the complexity of SPARQL queries and generic SPARQL-JSON responses, semantic API was developed as a RESTful service providing semantic data using JSON format. The API uses Jersey framework ensuring RESTful capabilities and Apache Jena API for communication with the ontology repository.

As an example of API goals and capabilities, the “data points” endpoint will be discussed. The endpoint allows a consumer to query the ontology repository for data point semantic description based on given semantic criteria.

Example of JSON response payload:

The API provides following information about the data point with BMS ID “1600.AV4”:

• Datapoint type – Specifies a role of the datapoint in the BAS.

• Physical quality and property domain – Specifies physical quality represented by the data point (e.g. temperature, humidity, energy, or output power).

• Scope (Feature of Interest) – A scope specifies object the data point value is related to. Possible scopes are the location (e.g. building when measuring energy consumption) or device (e.g. fan in the case of data point representing fan speed).

• Data source – Specifies the device that provides the BAS with the data.

• Source device type – Describes the type of the source device (e.g. Flow meter).

• Sensing method and time window – The simplest case is direct sensing (e.g. room temperature). Other (indirect) sensing methods employ computation or aggregation over some period (e.g. energy consumption total for the last month).

Presented examples of the Semantic API capabilities aim to show how the data stored in Semantic BMS ontology can be queried using convenient and easy to implement methods, thus significantly simplifying development of various analytical and decision support application for the field of building operation analysis.

The presented ontology aims to provide additional semantics to datapoints available in building automation systems. The ontology is designed to be automation protocol independent and describes available data in a way that can be utilized during decision support tasks needed for building performance analysis, evaluation, and improvement, which are crucial tasks to achieve energy efficient and environment-friendly operation of facilities.

Using additional semantic layer, the process of obtaining and inspecting key performance indicator data is significantly simplified. Ontology design was based on long term experience with the operation of University Campus of Masaryk University as site equipped with hundredths of automation devices.

At the moment, the ontology is populated with sample data representing several typical components of building automation systems. Further steps contain the development of proof-of-the-concept Data provider for the BACnet protocol. The ontology will be populated with information describing an actual building. Next, methods described in the “EN 15221-7 Facility Management - Part 7: Guidelines for Performance Benchmarking” standard will be used for evaluation of the ontology and API usability. Assessment of query retrieval performance is also planned in this step, leading to possible optimization of ontology model or query composition.