Introduction

One of the major challenges in the engineering of complex cyber-physical systems is the interoperability between software applications that are used to engineer and manage these systems. Buildings constitute one of these systems and their engineering requires the interaction of a multitude of stakeholders over several stages of the life cycle [8]. Vast amounts of data are generated during this process. These data are typically stored across various formats and information silos being both in machine-readable formats (e.g. XML, STEP), or analog formats (e.g. drawings printed on paper). These data may include the design specification of the actual layout of a building, product data on the commissioned technical equipment, weather data [27] and sensor data obtained through the installation and operation of a Building Automation System (BAS) [23].

The ontology-based modeling approach and its related use of semantic web technologies seem to be a promising path towards addressing the prevalent heterogeneity of data in the Architecture, Engineering, Construction and Facility Management (AEC/FM) industry [5,30,15]. This is mostly undertaken by providing a common semantically well defined layer enabling seamless information exchange and linkage across domains. However, a plethora of ontologies is defined to provide conceptualizations of this domain (see Sect. 2). These ontologies can be used to represent data about buildings in a structured manner and help facilitating the information exchange between different stakeholders.

However, the existence of a multitude of ontologies that partly overlap in the scope of AEC/FM inhibits the wide-spread adoption of the technology throughout the industry. Several ontologies without standardization or consensus can only partially support the AEC/FM industry. Under the umbrella of the World Wide Web Consortium (W3C), the Linked Building Data Community Group (LBD) was initiated in 2016 to address this problem. This group aims at becoming a Working Group and thus effectively develop standard ontologies for the AEC/FM sector. When becoming a Working Group, the following mission will prevail, as listed in the editor draft of the charter [10]:

• to determine how building information can best be integrated with other data on the Web; • to determine how machines and people can discover that different facts in different datasets relate to the same building, especially when building is expressed in different ways and levels of granularity; • to identify and assess existing methods and tools and then create a set of best practices for their use; • where desirable, to complete the standardization of informal technologies already in widespread use.

The community group aims at achieving this mission through a number of deliverables. This includes a central ontology (not an upper ontology) that allows to express the building topology of any building (Site -Building -Storey -Space -Element): the Building Topology Ontology (BOT) [20]. In addition, a PRODUCT ontology, a GEOM ontology, and a PSET ontology are being defined, allowing to represent product data, geometric representations, and properties, respectively. The set of four ontologies form the core of the work that is aligned with W3C recommendations for adjacent domains, e.g. the geospatial ontologies [25], SAREF [6], DogOnt [1], and the Semantic Sensor Network (SSN [4]). The group also aligns with the W3C Data on the Web Best Practices [9] for the adoption of Semantic Web Technologies (SWT) in the domain of building data.

One subgroup of the LBD Community Group focuses on the formal modeling of Building Automation and Control Systems (BACS). This partially reflects the need to integrate tools supporting the monitoring and automation of buildings being in the need of smart systems to automatically control technical equipment and improve building operation in terms of energy efficiency and indoor comfort.

As a first result of this work we present in this paper a modular ontology where we integrate information from Building Information Modelling (BIM) and BAS: notably building elements, sensors and actuators, devices of BAS and control logic. The work mainly reuses and aligns existing domain ontologies to comprise domain information in one common knowledge base for the control and automation of buildings.

In Sect. 2, we provide an overview on existing domain ontologies regarding smart appliances and BAS. Then in Sect. 3, we present the BACS Ontology. In Sect. 4, we apply the BACS ontology to model an application scenario of state-based room control in a fictional BAS. Finally, we draw the conclusions in Sect. 5.

Related Works

In this section we review existing ontology modeling approaches with a special focus on smart appliances and building automation systems. A comprehensive review on the usage of Semantic Web Technologies in the building domain is presented in [15], also including a discussion on ontologies in the BAS domain.

General Systems and Building Information Modelling (BIM)

The Industry Foundation Classes (IFC) standard2 comprises a well accepted, open model for the information exchange when applying BIM in the AEC/FM-industry. The data model has already been converted to the Web Ontology Language (OWL) as the ifcOWL ontology [14]. Another set of ontologies including building information is available in the knowledge model for Smart Energy Aware Systems (SEAS) [13]. This includes ontology modules related to building automation and control, such as modules DeviceOntology, OptimizationOntology, and FailableSystemOntology.

An approach to align existing ontologies in the AEC domain is represented by the Building Topology Ontology (BOT) [20] that is part of the work conducted by the LBD Community Group. This ontology can be aligned with several of the mentioned ontologies, using some of the ontology alignment approaches proposed in [20]. In this scope, a BACS ontology is needed as well to model how appliances and devices can be used to automate and control the building and its components.

BACS and Energy-Related

Several works focused on the energy management of facilities [12], such as airports [30]. An approach for domotics intelligent devices (DogOnt) was proposed by [1]. The integration of buildings with grid and energy market information is tackled in the ThinkHome ontology [21]. An approach to integrate device descriptions on BAS devices, functional specification with adjacent domains of BIM was developed in the BASont ontology [16]. An approach to formalize semantic tags by means of ontology is described in the Haystack Tagging Ontology (HTO) [3]. Among the various ontologies related to BACS and smart appliances, the Smart Appliances REFerence (SAREF) ontology [6] unifies common accepted conceptualisations into one reference ontology; SAREF4BLDG [17] is its extension for the building domain.

Sensor Data and Control Logic

A well established ontology for the formal specification of sensor data is the W3C Semantic Sensor Network (SSN) ontology [4]. The SSN ontology has been recently updated [11] by including also the more general module SOSA (Sensor, Observation, Sample, and Actuator) making it possible to model key concepts also for the BACS domain, including sensor, actuator, observations, observable properties and results. The SSN ontology is included in the proposed BACS ontology (see Sect. 3). Within the reported approaches it may be observed that typically taxonomies are used to describe the actual control behaviour of a certain control logic in a BACS. A modelling effort to specify UML state machines, a well known modeling approach for state-based control logic, as an OWL ontology was presented by Dolog [7].

Summary

The reported ontologies form a comprehensive board of ontologies that can be reused to cover the BACS domain by spanning the description of building elements and equipment, sensors and actuators, BAS, and control logic. The ontology reuse, even if often applied in a limited fashion, represents a key best practice that was followed in this work.

The Building Automation and Control System Ontology

The proposed BACS ontology aims at supporting the modeling of the following information requirements:

• control behavior in a BAS (both discrete and continuous), including the sensecomprehend-actuate pattern in closed-loop control logic and the comprehendactuate pattern in open-loop control logic [24]; • physical devices of Building Automation Systems (BAS) and their location in the building as well as affiliation to technical equipment; • smart appliances;

• logical topology in a BAS.

The architecture of the BACS ontology exploits the ontology reuse and modularity principles [26]. The modular architecture consists of the following Terminological (Tbox) modules, as shown in Figure 1: • statistics, defining basic concepts about probability distributions and descriptive statistics • fsm, the ontology for Finite State Machine • sosa, the Sensor, Observation, Sample, and Actuator (SOSA) Ontology • ssn, the Semantic Sensor Network Ontology • expression, a novel ontology formalizing algebraic and logical expressions • osph, a novel ontology modeling object states and performance history • list, ontology defining the set of entities used to describe the OWL list pattern • express, ontology that maps the key concepts of EXPRESS language to OWL • ifcmr, fragment of the ifcOWL ontology (version IFC4) generated from the EX-PRESS sub-schema IfcMeasureResource • bot, the Building Topology Ontology • bacs, a novel domain ontology for building automation and control All these modules are available on the web (see Table1). Such composition of modules was selected by carefully reviewing candidate ontologies (see Sect. 2) against the following criteria: (1) minimum overlap with each other, (2) possibly W3C standards (e.g. ssn) and (3) meeting the defined information requirements.

The ontology modules fsm, sosa, ssn, and bot were already mentioned in Sect. 2. The group of modules list, express, and ifcmr supports the definition of quantity values. This ontology is a fragment of the ifcOWL ontology [28] generated from the IFC sub-schema IfcMeasureResource according to the method presented in [28]. These modules could be replaced by other similar ontologies, such as the Ontology of Units of Measure (OM) [22] or the QUDT ontology [19].

The statistics module is a minimal ontology defining the basic classes and properties needed to model data related to descriptive statistics and probability distributions. As an alternative, the larger and more complex STATO ontology [2] could be adopted.

The three novel modules proposed in this work (i.e. expression, osph, bacs) are described in Sect. 3.1, whereas the overall integration and alignment is presented in Sect. 3.2. The prefixes of the namespaces are defined in Table 1.

Novel Ontology Modules

The expression ontology aims at formalizing algebraic and logical expressions. A generic expression can be decomposed into atomic, unary, and binary expressions. An atomic expression can be a constant or a variable. This ontology was developed to provide a simple formal definition of expressions that can be used also as conditions to be met before a transition is triggered (see Sect. 3.2). The classes and properties of the expression ontology are sketched in Figure 2.

The osph ontology is the evolution and generalization of an early proposal that was based on the ifcOWL ontology [29]. This ontology plays a key role because it models Object States and Performance History (OSPH), while integrating the fsm, statistics, ssn, and expression modules. The following classes are defined in the osph ontology:

• osph:ObjectDefinition is an abstract class whose definition resembles that of IfcObjectDefinition in the IFC standard. • osph:ObjectHistory defines a history interval in the lifecycle of a generic object that is assigned via the object property osph:isHistoryOf. An interval can be de- In the future, all these classes will be re-assessed to check if they can be replaced by definitions imported from other dedicated domain ontologies.

Integration

The integration of the various ontology modules represents one of the main contributions in the proposed ontology architecture. Indeed, the novel modules osph and bacs mainly play the role of ontology mediator creating links between different domains, as it can be noticed in the diagram of Figure 1. The alignments between the various ontology modules are reported in Table 2 by specifying which module is the mediator (i.e. where the alignment is defined), which are the aligned modules, which are the involved classes and properties, and finally providing a description. A generic object (osph:ObjectDefinition) can be characterized by a state machine (fsm:StateMachine) and also by one or more histories (osph:ObjectHistory) that are able to capture the evolution of the object in terms of observations and state. An expression (expression:Expression) can be composed by constant values (ifcmr:IfcValue) and variables (expression:Variable) that are related to measurable properties (ssn:Property). The result of an observation (sosa:Observation) can be a descriptive statistics (statistics:DescriptiveStatistics) or a quantity value (ifcmr:IfcValue). The relevant alignments are also graphically represented in Figure 4.

Application Scenario

Description

The applicability of the proposed BACS ontology was tested against an application scenario that includes the instantiation of building elements, sensors and actuators, automation systems, and control logics. The scenario is motivated by the deployment of auto- matic control in the room of a building. The focus is on control logic because it can significantly impact on the energy consumption and comfort conditions.

In the scenario, a room is equipped with a window, a controllable sunblind, a room air temperature sensor and an outdoor illuminance sensor. A finite state machine is designed to control the sunblind depending on the room air temperature and outdoor illuminance, as presented in [18]. The sunblind can be in one of the following states: noShade, nightShadeDeployed, dayShadeDeployed (Figure 5). The following observations have been made in the system:

• room temperature: 20 • C at 2017-03-09T08:00:00; 24 • C at 2017-03-09T10:00:00 • room illuminance: 90 lx at 2017-03-09T08:00:00; 200 lx at 2017-03-09T10:00:00 • sunblind state: noShade at 2017-03-09T09:30:00

Instantiation

The Abox ontology module named bacs test 3 imports the bacs module and instantiates the application scenario in terms of OWL individuals defined in its namespace. For sake of simplicity, the following fragments in turtle format present only a subset of definitions included in bacs test.

Fragment 1 presents the definition of room, temperature sensor and sunblind. The room is associated with two properties: room temperature and room illuminance. Other definitions include building, building storey, window, and illuminance sensor.

Fragment 2 shows a part of the definition of the finite state machine modeling the control logic of the sunblind. As an example, the details of the transition from state dayShadeDeployed to nightShadeDeployed are reported. This transition can be triggered only if the guard condition is met, i.e. if the room illuminance is less then 5.0 lx. Fragment 3 provides an example of how the history of the room can be characterized by observations of its properties thanks to the sensors. In addition, the history of the sunblind considers the evolution of the sunblind state.

Finally, a couple of SPARQL queries are presented to show how the contents of the ontology can be extracted to support business processes, while referring to the prefixes defined in Table 1.

The query in Fragment 4 gets the elements in the building and the associated state machine (if existing). The query in Fragment 5 explores the finite state machine of any element in a room and returns the state machine components (e.g. states, transitions, guards) and further details about transitions.

Conclusions

This paper presented a modular ontology to model the domain of building control and automation, demonstrating its applicability in a test case. Reusing ontologies through integration and alignment is promising to tackle the building control and automation domain, but best practices and guidelines from ontology engineering will be further investigated. The proposed test case focuses on the building automation domain, but, as automation is relevant in many industries (process industry, manufacturing industry, etc.), the reuse of the ontology in other domains will be studied. Future works will address also:

• testing more complex cases requiring the interaction between smart objects; • preparation of a library of general purpose SPARQL queries and update to support the use of the BACS ontology (e.g. extraction of object history, extraction of expressions, triggering and execution of a control action); • integration with other ontologies specializing elements, sensors and actuators, and defining concepts related to geometry (e.g. placement, representation of objects).