Linked data and semantic web technologies are gaining impact and importance in the Architecture, Engineering, Construction and Facility Management (AEC/FM) industry. Whereas we have seen a strong technological shift with the emergence of Building Information Modeling (BIM) tools, this second technological shift to the exchange and management of building data over the web might be even stronger than the first one. In order to make this a success, the AEC/FM industry will need strong and appropriate ontologies, as they will allow industry practitioners to structure their data in a commonly agreed format and exchange the data. Herein, we look at the ontologies that are emerging in the area of Building Automation and Control Systems (BACS). We propose a BACS ontology in strong alignment with existing ontologies and evaluate how it can be used for capturing automation and control systems of a building by modeling a use case.
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 [
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.
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.
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.
Several works focused on the energy management of facilities [12], such as airports [30].
An approach for domotics intelligent devices (DogOnt) was proposed by [
A well established ontology for the formal specification of sensor data is the W3C
Semantic Sensor Network (SSN) ontology [
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 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 EXPRESS 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 [
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.
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
composed into other intervals via the property osph:isDecomposedByHistory. A history interval can be characterized by a start and end time as xsd:dateTime via the properties osph:hasIntervalStartTime and osph:hasIntervalEndTime, respectively. A history interval can be related to individuals of osph:StateFrequency via the property osph:hasStateFrequencies. osph:StateFrequency describes the stay of an object in a specific state during a history interval.
osph:UnitOfMeasurement is a class defining a generic unit of measurement. The relations between these classes are shown in Figure 3, whereas the relations with classes defined in other modules are described in Sect. 3.2.
The bacs module defines specializations of classes to directly support the instantiation of the use case (Sect. 4). Classes bacs:LightSensor and bacs:TemperatureSensor represent light and temperature sensors, respectively. The class bacs:SpaceProperty and its subclasses bacs:SpaceIlluminanceProperty and bacs:SpaceTemperatureProperty model specific properties of a space (e.g. a room). The class bacs:SpaceObs and its subclasses bacs:SpaceIlluminanceObs and bacs:SpaceTemperatureObs are designed to represent observations made in a space. 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.
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.
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 autososa,osph fsm,osph fsm,osph sosa,osph bot,osph bot,sosa sosa,bacs bacs,bot, osph osph:ObjectDefinition, sosa:FeatureOfInterest osph:ObjectDefinition, fsm:StateMachine, osph:ObjectHistory; osph:hasStateMachine, osph:hasHistory osph:StateFrequency, fsm:State; osph:hasRelatedState osph:ObjectHistory, sosa:Observation; osph:hasHistoryObservations expression, fsm:Condition, fsm,osph expression:Expression;
osph:hasConditionExpression expression, expression:Variable, ssn,osph ssn:Property; osph:representsProperty osph:ObjectDefinition, bot:Building, bot:Space, bot:Element, bot:Storey bot:Element, sosa:Sensor 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
The Abox ontology module named bacs test3 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. 1 :room a owl:NamedIndividual , bot:Space ; 2 bot:containsElement :lightsensor , :sunblind , :tempsensor ; 3 ssn:hasProperty :room_illuminance_prop , :room_temperature_prop ; 4 bot:adjacentElement :window ; osph:hasHistory :room_history . 5 :tempsensor a owl:NamedIndividual , bacs:TemperatureSensor ; 6 sosa:observes :room_temperature_prop . 7 :sunblind a owl:NamedIndividual , bot:Element ; 8 osph:hasHistory :sb_history ; osph:hasStateMachine :sb_StateMachine . 9 :room_temperature_prop a owl:NamedIndividual , bacs:SpaceTemperatureProperty ; 10 osph:hasPropertyUnit :temperature_unit . 11 :room_illuminance_prop a owl:NamedIndividual , bacs:SpaceIlluminanceProperty ; 12 osph:hasPropertyUnit :illuminance_unit .
Fragment 1: Excerpt of space and elements instantiation 1 :sb_StateMachine a owl:NamedIndividual , fsm:StateMachine ; 2 fsm:contains :sb_InitialState, :sb_dayShadeDeployed, :sb_nightShadeDeployed, 3 :sb_noShade, :sb_trDayNight, :sb_trDayNo, :sb_trInitNo, :sb_trNightNo, 4 :sb_trNoDay, :sb_trNoNight, :sb_trDayNight_guard, :sb_trDayNo_guard, 5 :sb_trNightNo_guard, :sb_trNoDay_guard, :sb_trNoNight_guard. 6 :sb_dayShadeDeployed a owl:NamedIndividual , fsm:Simple . 7 :sb_nightShadeDeployed a owl:NamedIndividual , fsm:Simple . 8 :sb_trDayNight a owl:NamedIndividual , fsm:Transition ; 9 fsm:Source :sb_dayShadeDeployed ; fsm:Target :sb_nightShadeDeployed ; 10 fsm:TransitionGuard :sb_trDayNight_guard . 11 :sb_trDayNight_guard a owl:NamedIndividual , fsm:Guard ; 12 fsm:GuardCondition :sb_trDayNight_condition . 13 :sb_trDayNight_condition a owl:NamedIndividual , fsm:Condition ; 14 osph:hasConditionExpression :sb_trDayNight_expr . 15 :sb_trDayNight_expr a owl:NamedIndividual , expression:BinaryExpression ; 16 expression:hasLhsOperand :room_illuminance_var ; 17 expression:hasOperator expression:LESSTHAN ; 18 expression:hasRhsOperand :illumA . 19 :illumA a owl:NamedIndividual , ifcmr:IfcIlluminanceMeasure ; 20 express:hasDouble "5.0"^^xsd:double .
Fragment 2: Excerpt of sunblind state machine instantiation 1 :room_history a owl:NamedIndividual , bacs:SpaceHistory ; 2 osph:isDecomposedByHistory :room_history_int1 , :room_history_int2 ; 3 osph:hasIntervalStartTime "2017-03-09T08:00:00"^^xsd:dateTime . 4 :room_history_int1 a owl:NamedIndividual , bacs:SpaceHistory ; 5 osph:hasHistoryObservations :room_illum1 , :room_temp1 ; 6 osph:hasIntervalStartTime "2017-03-09T08:00:00"^^xsd:dateTime . 7 :room_illum1 a owl:NamedIndividual , bacs:SpaceIlluminanceObs ; 8 sosa:hasResult :illum1 ; sosa:madeBySensor :lightsensor ; 9 sosa:observedProperty :room_illuminance_prop . 10 :illum1 a owl:NamedIndividual , ifcmr:IfcIlluminanceMeasure ; 11 express:hasDouble "90.0"^^xsd:double . 12 :sb_history a owl:NamedIndividual , osph:ObjectHistory ; 13 osph:hasStateFrequencies :statefreq1 ; 14 osph:hasIntervalStartTime "2017-03-09T09:30:00"^^xsd:dateTime . 15 :statefreq1 a owl:NamedIndividual , osph:StateFrequency ; 16 osph:hasRelatedState :noShade ; osph:hasStayRatio "1.0"^^xsd:double .
Fragment 3: Excerpt of room and sunblind history instantiation
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. 1 SELECT distinct ?building ?storey ?room ?elem ?statemach 2 WHERE { 3 ?building rdf:type/rdfs:subClassOf* bot:Building. 4 ?building bot:hasStorey ?storey. ?storey bot:hasSpace ?room . 5 ?room bot:adjacentElement|bot:containsElement ?elem . 6 OPTIONAL{ ?elem osph:hasStateMachine ?statemach .} 7 }
Fragment 4: SPARQL query to get the elements in the building 1 SELECT distinct ?statemach ?fsmelem ?class ?source ?target ?guard ?condition 2 WHERE { 3 ?statemach rdf:type/rdfs:subClassOf* fsm:StateMachine . 4 ?statemach fsm:contains/fsm:hasStateMachineElement* ?fsmelem . 5 ?fsmelem rdf:type ?class . FILTER ( ?class != owl:NamedIndividual ) . 6 OPTIONAL{ 7 ?class rdfs:subClassOf* fsm:Transition . 8 ?fsmelem fsm:Source ?source . ?fsmelem fsm:Target ?target . 9 OPTIONAL{ 10 ?fsmelem fsm:TransitionGuard ?guard . ?guard fsm:GuardCondition ?condition .} 11 }}
Fragment 5: SPARQL query to get the components of a state machine
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).
This work has been partially funded by the Italian research project “Efficientamento dei processi di produzione e gestione integrata di utenze energivore con fonti rinnovabili e sistemi di accumulo mediante periferiche ICT in un contesto Smart District” within the “Piano Triennale 2015-17 della Ricerca di Sistema Elettrico Nazionale”.