Rule-Based Model for Smart Building Supervision and Management

Abstract

Smart buildings are aimed at monitoring and controlling building facilities through a Building Management System (BMS). While current BMSs are based on processing logs of devices deployed in the building, this paper enables supervision and control of building by the use of semantic technologies. A common information base, as a core data model, is defined, which describes and defines formally the main physical and conceptual building elements (namely: assets, spaces, data points, incidents and key performance indicators), their characteristics and interrelationships, as well as the constraints that apply to them. For instantiation purposes, we relied on a logical framework based on the existential rules, which allows to describe any domain as a set of facts, a set of rules and a set of constraints. We have implemented a fragment of our logical model as a proof of concept, where two real-world scenarios are implemented as demonstrators of the FUSE-IT project. The former is about access control to a data center, and the latter is about temperature anomaly correlated with the heater functioning in a given zone of a building. The aim of these experiments is to illustrate the functional capabilities of our approach for smart control in building management.

Full text

Rule-Based Model for Smart Building Supervision
and Management
Nouredine Tamani∗, Shohreh Ahvar†, Gabriel Santos‡, Bernard Istasse§,
Isabel Praça‡, Paul-Emmanuel Brun¶, Yacine Ghamri∗, and Noël Crespi†
∗University of La Rochelle, La Rochelle, France; †Telecom SudParis, Evry, France ‡GECAD, ISEP/IPP, Porto, Portugal
§EISIS/Arc Informatique, Nantes/Paris, France, ¶Airbus Defence & Space, Paris, France
∗{nouredine.tamani, yacine.ghamri}@univ-lr.fr; †{shohreh.ahvar, noel.crespi}@telecom-sudparis.eu,
‡{gajls, icp}@isep.ipp.pt §bernard.istasse@neuf.fr, ¶paul-emmanuel.brun@airbus.com
Abstract—Smart buildings are aimed at monitoring and con-
trolling building facilities through a Building Management Sys-
tem (BMS). While current BMSs are based on processing of
logs of the devices deployed in the building, this paper enables
supervision and control of building by the use of semantic
technologies. To this aim, A common information base as a core
data model is defined, which describes and defines formally the
main physical and conceptual building elements (namely: assets,
spaces, data points, incidents and key performance indicators),
their characteristics and interrelationships, as well as the con-
straints that apply to them. For instantiation purposes, we relied
on a logical framework based on the existential rules, which
allows to describe any domain as a set of facts, a set of rules
and a set of constraints. We have implemented a fragment of
our logical model as a proof of concept, where two real-world
scenarios are implemented as demonstrators of the FUSE-IT
project. The former is about access control to a datacenter, and
the former is about temperature anomaly correlated with the
heater functioning in a given zone of a building. The aim of
these experiments is to illustrate the functional capabilities of
our approach for smart control in building management.
Index Terms—BMS, Ontology, Internet of Things (IoT),
Knowledge bases, Existential rules, SSN, SAREF, FUSE-IT
I. INTRODUCTION
Designing smart and sustainable cities is one of the major
challenges of our era where smart buildings is a key to
achieve a high quality of life in both residential and industrial
sites. Building Management System (BMS) is a cornerstone
component in any smart building. It concentrates the infor-
mation and the decisions to be made to ensure a good and
secure functioning of their cyber and physical elements. Within
this context, the FUSE-IT project (www.itea2-fuse-it.com) is
aimed at addressing the need of sustainable, reliable, user-
friendly, efficient, safe and secure BMS for Smart Critical
Sites where the use of such systems are more crucial because
of security and safety issues. Industrial sites (especially when
they are close to urban areas), hospitals and public buildings
(city halls, schools, universities, airports, stadiums, etc.) are
examples of critical sites.
To become smart, such buildings are equipped with a
full set of systems which covers the following four activity
domains: (i) Energy supply and efficiency (e.g., micro-grids,
energy monitoring, back-up, storage); (ii) Facility and building
automation (e.g., heating, ventilation and air conditioning,
lighting); (iii) Information and communication (e.g., local
area networks, indoor wireless, network operation); and (iv)
Security and safety (e.g., fire detection, anti-intrusion video-
surveillance, network access control). Therefore, an over-
whelming amount of data is collected through a large number
of sensors and connected objects, which are deployed at
different places in those buildings. The gathered data need
to be integrated and processed efficiently to ensure the good
functioning of each domain system, along with evaluating the
cross domain key performance indicators (KPI) [1].
Facing the large number of sensors and their heterogeneity,
traditional data models, storage and processing methods (e.g.,
relational databases and related technologies) are not suitable,
in terms of efficiency, to deal with such complex data. More-
over, the process of decision making needs to go beyond the
classical query/retrieval schema to handle more sophisticated
ways to analyse events, such as deductive and inductive
reasoning, and efficient data interlinking to extract significant
information for all four domains. To do so, it is important to
shift the data model to a new and a more adapted model based
on logics such as description logics and their related well-
known data structure called ontologies, which, in addition,
allows interoperability between heterogenous systems.
Therefore, we show in this paper how the ontology can be
used as a tool for developing the FUSE-IT Smart BMS, which
describes a unified view of concepts and data involved in the
above mentioned domains. The core data model developed in
FUSE-IT project covers the main five aspects of a building
such that sensors and appliances are seen as assets, which are
located in spaces that could be organized in zones; each asset
collects data as data points of divers types used to monitor
the considered building for the key performance indicators
and incidents discovery and management.
These five concepts are the main common elements of
different ontologies already developed in each domain of
BMS such as Semantic Sensor Network (SSN) [2], Smart
Appliances REFerence (SAREF) [3], Smart Energy Aware
Systems (SEAS) [4] ontologies, to name a few. The aim of
FUSE-IT model is to provide a generic and an overall view of
smart buildings, solve the problem of multi-sourced data het-

erogeneity, and covering necessary concepts and relationships
to implement diverse control and monitoring functions within
a smart BMS. Such a model can be seen as a first attempt to
build a unified data model for smart buildings to cover their
main aspects, which are actually not or only partially covered
in existing BMS ontological data models [2]-[5].
For instantiation purposes, we relied on the logical frame-
work, introduced in [6], [7], based on existential rules to
translate our core data model into a set of facts, a set of
rules and a set constraints or negative rules. The choice of
the aforementioned logical framework is motivated by its
large expressivity, which can model diverse building types
and management rules. We have implemented the fragment
of our logical framework corresponding to the SWRL rules
[8], as a proof of concept in two real-world use-cases in the
context of FUSE-IT project final review. The first scenario was
implemented at AIRBUS site in France to control the number
of authorized people to be inside a data center at the same time
by using logical rules and reasoning inference. The second
use-case has been implemented at Hospital Sao Jao in Porto
(Portugal) for the final demonstration of the project. This use-
case was about controlling the variation of temperature inside a
patient room and raising an anomaly when the ontology detects
that the temperature is still low even when the heater is on for
more than half an hour. It is noteworthy that the evaluation
of such an approach is still not trivial since, to the best of
our knowledge, there is no well-known semantic method that
we can use as a baseline for a comparison study. Our proof
of concept showed the potential of using logical rules to deal
with building supervision and management.
Section II sums up some related work. Section III describes
the main elements of the FUSE-IT BMS core data model.
Section IV details the knowledge base framework based on
facts, rules and negatives constraints. The architecture based
on our FUSE-IT core data model and logical rule implementa-
tion are presented in section V. Section VI is dedicated to the
implementation of two real world use-cases: building access
control, and temperature supervision correlated with the heater
functioning. Section VII concludes the paper.
II. RELATED WORK
Many projects are actually elaborating semantic models
for facilitating building management. We can mention both
Haystack [9] and Brick [10] projects, in which strong metadata
models have been developed to help implement realistic cases
of building description with a focus on building equipments.
However, the developed ontologies are more taxonomies than
complete ontologies, since they seem lacking the potential of
actionable entities with a weak development of relationships
among concepts.
Considering actionable entities, the base ontology from
OneM2M [11], SAREF, along with the sensing capabilities
with DogOnt [12] and SSN are important ontologies in the
context of IoT. The initiative is being extended to include
building reference components with the alignment with In-
dustry Foundation Class 4 (IFC4) [13] on the one hand, and
energy control and demand response capabilities, with support
of EEBus and Energy@Home projects [14], [15], on the other
hand. The recent project SEAS is also elaborating modular
ontologies for Smart Buildings and related needs covering
different aspects of Smart Grids, which enables interaction
between consumption and production energy systems to op-
timize global energy usage. Although the project is actually
completed and the SEAS ontology was aligned with SEAS, it
still needs to be aligned with ifcowl [16] which is planned
as a future development. It is also worth mentioning the
“Facility Smart Grid Information Model" (FSGIM) model
[5] for facilities and assets description, which is a Uniform
Model Language (UML) model that could be translated into
an ontology format.
It is worth noting the model developed in [17] and its
extension in [18], which is dedicated to semantic building
systems for advanced data analytics for energy efficiency.
The authors defined the concepts of zones, sensors, KPI and
Incidents, and made use of rules to detect anomalies in the
building, as a combination of conditions and conclusions,
expressed as concepts in their ontology. This approach requires
to implement a specific function to check the premisses of
each rule and ensure its application while it is triggered. We
borrow the concepts of KPI and Incidents in our model but
we define the rules differently to separate the modeling level
from the functional level in our system, since the rules, in our
case, are expressed as SWRL logical rules [8], which avoids
redundancy and allows to infer any suspicious event happens
in the system.
The inconvenient of the above mentioned models lies in
the fact that they cover only a subset of the key domains
of smart BMS (Energy, Security, Facility, and ICT). They
are not sufficient to consider the case of Critical Sites that
FUSE-IT is dealing with. Neither ICT nor security are well
covered in the related work. Therefore, the FUSE-IT project
aims at building a reference model based on gathering several
ontologies among the ones described above with additional
models or concepts. The aim of our model is describing
metadata to have access to data and make them actionable in
an interoperable context of interconnected systems protected
by secured services.
III. FUSE-IT ONTOLOGICAL DATA MODEL
The FUSE-IT ontology provides a holistic view of smart
buildings by combining the four above mentioned activity
domains, as a four-layer system [19]:
1) Smart sensors, effectors and actuators,
2) Smart energy and information networks,
3) Smart Building Management System (SBMS), and
4) Smart Security Management System (SSMS).
As described in the introduction, the assets (i.e., devices) are
deployed inside spaces, which can be organized in zones; each
asset collects data used to measure KPI and detect incidents
to be processed. Therefore, the FUSE-IT data model is built
around 5 main concepts, namely, assets (device or appliance),
spaces, data points, incidents and KPI. Figure 1 illustrates the

Fig. 1. FUSE-IT core data model.
main classes and the relationships among them describing the
data model for FUSE-IT BMS.
FUSE-IT model is meant to be compatible with the main
ontologies developed for smart BMS field. This backward
compatibility may encourage the adoption of the FUSE-IT
model by the industry. As a result, when developing the
FUSE-IT ontology, it is a major requirement to reuse, as
much as possible, publicly available ontologies of the partially
covered domains. Accordingly, our core model can be seen as
a simplified version of the main components defined in SEAS,
SAREF, IFC and SSN ontologies. Indeed, in these models, the
concepts of devices, spaces and zones (referred as Building
zones) are defined to express the assets and their corresponding
locations. However, in SEAS and SAREF, a zone is a part or
a section of a building, campus, town, etc (actually SEAS
reuses the same definition of space as SAREF), which means
that it refers to a physical location. But in our case, a zone is
a logical space defined within a physical space. For instance,
a restricted access area in a public administration.
Besides, as mentioned in [4], if SEAS is aligned to SAREF
ontology, seasDevice is more generic than sarefDevice, which
may also be aligned with SSN ssnDevice.
Data points are modeled differently in our case in order to
be more generic than in SEAS, where a data point is a content
related to a sensor with the kind of data (data type) it collects.
For instance, a temperature sensor is related to temperature
values with Content and Temperature classes. In our case, a
data point defines any content of a given data type collected
by an asset at a given timestamp. This simplifies the model
and allows to reduce the complexity of its implementation.
Moreover, our approach for data modeling is similar to one
defined in ONEM2M. However, OneM2M base ontology
does not specify explicitly a DataPoint, since it combines
Service, Device, Variable as superclasses of InputDataPoint
and OutputDataPoint concepts. In SAREF, the closest concept
related to data is Measurement, which has a timestamp, a
value and a unit of measure, among other properties. But it
is limited to values of type float. In addition, the concept of
DataPoint can be seen as an implementation of Observation
and ObservationValue concepts defined in SSN ontology.
Incidents in our model can be seen as a kind of
FeatureOfInterest as it is defined in SEAS as a thing, a person,
or an event. However, in our case an incident is a event
occurred in the system which can belong to the four domains
of FUSE-IT. Moreover, in SAREF, the only concept defined is
event function, which is limited to notify a given device that
a certain value has reached a threshold.
KPI concept cannot be mapped with any class in SEAS
and in SAREF, where there is no explicit definition of KPI.
However, a KPI can be seen as a combination of features of
interest as things, related to the data they collect. We make
use of the concept as it is defined in IBM knowledge center
[20], where KPIs are quantifiable measurements to assess the
increasing and decreasing of an acitivity performance, which
is critical to the success of a business. The definition of KPI
in our model simplifies the expression of such information, as
well as their processing to assess the system.
We remind the reader that our aim is not to develop a
new ontology for building management systems, but to show
how semantic technologies can be used to implement some
management functions, such as anomaly detection, as part of
the issues we dealt with in FUSE-IT project.
IV. KNOWLEDGE BASE SPECIFICATION
We detail in this section our formal model for knowledge
base implementation, in terms of vocabulary and syntax oper-
ators used to build a knowledge base as facts and rules.
We consider the positive existential syntactic fragment of
first-order logic, denoted by FOL(∧,∃)[7], [6], whose for-
mulas are built with connectors: implication (→), conjunction
(∧), and the usual quantifiers (∃,∀).
Definition 1 (Vocabulary): Let V=(C,P,V) be a vocab-
ulary composed of 3disjoint sets where Cis a finite set of
constants, Pis a finite set of predicates and Vis an infinite
set of variables, such that:
•a term tover Vis a constant (t∈ C) or a variable (t∈ V)
referring to a unique value (unique name assumption),
•an atomic formula (or atom) over Vis of the form
p(t1, ..., tn)where pis an n-ary predicate (n∈N), and
t1, .. ., tnare terms,
•a ground atom is an atom with no variables,
•a variable in a formula is free if it is not in the scope of
any quantifier,
•a formula is said closed if it has no free variables,
•a conjunct is a finite conjunction of atoms,
•a ground conjunct is a conjunct of ground atoms,

•given an atom or a set of atoms A,var s(A),consts(A)
and ter ms(A)denote its set of variables, constants and
terms, respectively.
In logic programming and deductive databases, a basic
knowledge is called a fact and can be expressed by a ground
atom. But, as we need to account for incomplete knowledge,
such as “The HVAC system is ON but do not know which
HVAC it is”, then a fact may contain existentially quantified
variables and not only constants [6].
Definition 2 (Fact): A fact on a vocabulary Vis the
existential closure of a conjunct over V.
Therefore, fact F=“Some HVAC systems are ON” is
represented as: F=∃x1(HV AC(x1) ∧ has St ate(x1,ON))
A set of ground facts stored form a database that can
be queried. The query evaluation process makes use of
substitution and homomorphism between facts.
Definition 3 (Substitution and homomorphism): Given a set
of variables Vand a set of terms T,a substitution σis a
mapping from Vto T.Given a fact F,S(F)denotes the
fact obtained from Fby replacing each occurrence of x∈
V ∩ var s(F)by σ(x). A homomorphism πfrom a fact F1
to a fact F2is a substitution σof vars(F1)by (a subset of)
ter ms(F2)such that S(F1) ⊆ F2.
Rules are logical formulas that are used to infer new facts
from other facts. Rules may contain variables and should
account for unknown individuals to capture the case where
some information are incomplete. Therefore, we consider in
our logical framework existential rules.
Definition 4 (Existential rules): An existential rule (or
simply a rule) is a first-order formula of the form:
r=∀X((∀YH[X,Y]) → (∃ZC[Z,Y]))
where vars(H)=X∪Yand var s(C)=Z∪Ywhere Hand C
are conjuncts called the hypothesis (or the body of the rule)
and conclusion (or the head of the rule) of rrespectively.
We denote by r=(H,C)a contracted form of rule r.Given
a rule r,Hand Cshould not be empty.
Example 1: The following existential rule expresses that for
each HVAC system there is a status attached to it.
∀x,HVAC(x) → ∃yStatus(y) ∧ hasStatus(x,y)
Negative constraints are a special case of existential rules
that allow to represent knowledge that dictates how things are
not ought to be or should not take place in a given domain.
Definition 5 (Negative constraints): A negative constraint
(or constraint) Nis a first-order formula of the form:
N=∀X(H[X] →⊥)
where H[X]is a conjunct called hypothesis of Nand Xis a
sequence of variables appearing in the hypothesis.
Example 2: Negative rule N:∀x(HVAC(x) ∧
has St atus(x,0O N 0) ∧ hasStatus(x,0OF F 0)→⊥means
that it is impossible for a HVAC system to be ON and OFF
at the same time.
Now, we can define our knowledge base as a collection of
facts, rules, and negative constraints, it is denoted by K=
(F ,R,N ).
To be able to perform deduction, rules have to be used
with the facts to produce new facts. In logic, this is a simple
application of Modus Ponens inference rule. In our case,
the application of rule Rion fact Fjis the substitution of
variables that makes the body Rilooks like Fj. Thus, it is a
homomorphism that maps body(Ri)to Fj.
Definition 6 (Rule application [6]): A rule R=H→Cis
applicable to a fact Fif there is a homomorphism σfrom
Hto F. The application of Rto Fby πproduces a fact
α(F,R, π)=F∪πsa f e(C), where πs a f e is the safe substitution
that replaces existential variables with new variables (to avoid
variable propagation in the new facts). α(F,R, π)is said to be
an immediate derivation from F.
Example 3: Let us consider the following rule and fact.
R1=∀x asset(x) → ∃yzone(y) ∧ a sset InZ one(x,y)
F1={asset (temperatur eS ensor1)}
R1is applicable to F1because there is a homo-
morphism from {as set (x)} to F1that substitutes xby
temper at ureSensor1. The immediate derivation from F1is
fact: F2={zone(u) ∧ asset I nZ one(temper at ur eSensor1,u)},
where uis a fresh variable.
The process of rule application creates new facts making
other rules applicable. The process of such successive appli-
cations of rules on the set of facts is called R-derivation [6].
Definition 7 (Closure): Given a fact F∈ F and a set of rules
R, the closure of Fwith respect to R, denoted by C lR(F), is
defined as the smallest set (with respect to ⊆) which contains
Fand is closed under R-derivation.
Definition 8 (Consistency vs inconsistency): Given a knowl-
edge base K=(F ,R,N ), a set F⊆ F is R-inconsistent if and
only if there exists a constraint N∈ N such that ClR(F) |=HN
(also writing ClR(F) |=⊥), where |=is the first-order semantic
entailment (given two facts fand f0; we have f|=f0iff
there is a homomorphism from f0to f). Otherwise, Fis said
R-consistent.
V. FUSE-IT ON TOLOGY-BAS ED SM ART BUILDING
MANAGER ARCHITECTURE
In this section, we describe the software developed based
on our FUSE-IT core data model as a proof of concept.
In Subsection V-A, we detail the architecture based on a
Representational State Transfer (REST1) API for data collec-
tion and management. In Subsection V-B, we describe our
instantiation of our knowledge base to express the context of
our applications. In Subsection V-C, we detail our application
based on the developed FUSE-IT core data model.
A. REST API Based Architecture for FUSE-IT Applications
To be able to exploit the data collected by the different
assets deployed within a building area, we have developed a
central server named PC-VUE which is a REST API server. It
1https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest.
World Wide Web Consortium. 11 February 2004. Section 3.1.3.

Internet
Local
Network
Data
Incident
Data
Data
Data
Incident
PcVue
Server
REST API
Knowledge
based
Fig. 2. FUSE-IT REST API Data Server.
allows any authorized application to exploit the data through
a REST API, implementing the well-known HTTP functions:
get, post, put, and delete, in order to provide read, write, update
and erase data functions in the data server as web services.
Figure Fig. 2 illustrates the main components of the smart
building management system, developed within FUSE-IT
project. The central element in the system is the PcVue server.
It hosts the FUSE-IT data management service, which collects
the data from the assets deployed in a given building through
a local network (it could also be a private connection through
a public network). The data are then stored, in compliance
with the data model we described in Section III, as DataPoint
instances, then made available to applications for exploitation,
through a lightweight loosely connected web services based on
HTTP REST API. Hence, the PcVue server publishes different
web services for data sharing with authorized applications.
The latter can fetch all data needed by invoking GET services
implemented by PcVue. Once an application raises an alert, it
can send it the PcVue through a POST service as an instance
of an incident. The latter is then made available for processing
for other applications to solve the identified issue.
B. FUSE-IT Core Data Model and Rule Implementation
The obtained core data model is instantiated and populated
with the already defined instances in the database through
connections to the REST API server. The retrieved data are
used by the reasoner to infer any anomaly in the building.
An anomaly is defined by a logical rule which can be either
expressed by a human agent (an expert in security and building
management, for instance) or learned by the system through
a habit-based algorithm such as the one we introduce in
[21]. Logical rules in our model implement the rationale that
guides the management of the building. Rules can be split
into two categories, namely (i) normal behavior rules, and
(ii) abnormal behavior rules. Each rule expresses precondi-
tions to fulfill along with the action to perform in the case
where preconditions are met. The rules are existential rules
implemented within our logical framework K=(F,R,N), as
detailed in Section IV. The execution of a rule modifies the
status of the system by updating one or several parameters,
activating/deactivating devices, etc. The reasoning, in our case,
is based on the following three kinds of logical rules:
•Data definition rules: these rules are about facilitating
data definition in the system. For instance, if a space s1
contains zone z1, and asset a1is declared in zone z1, then
the reasoning system can add implicitly the information
that asset a1belongs to space s1. The corresponding rule
can be expressed as rule R2as follows:
R2:∀x,y,z asset(x) ∧ assetInZ one(x,y) ∧
zone InSpace(y,z) → asset I nS pace(x,z)
•Building management rules: these rules express the
management rules defined by the building manager. The
management can encompass appliance management, se-
curity, presence, etc. It could be about lightening, heating,
air conditioning rules, presence and occupancy rules, etc.
For instance, if space s1is not occupied than turn off the
lights, which can be expressed as R3as follows:
R3:∀x,yspace(x) ∧ light(y) ∧ lightInSpace(y,x) ∧
occu pation(x,NULL) → changeStatu s(y,”OF F ”)
Building management rules include also security rules
such as “if a given open space is empty, then the access
door must be locked", which can be expressed as negative
rule N1as follows:
N1:∀x space(x) ∧ has Lock Stat us(x,”OP E N”) ∧
occu pation(x,NULL)→⊥
•Habit-based rules: this kind considers the rules express-
ing knowledge about the habit of occupants of a space or
the usage of a given appliance. For instance, if a badge ID
is used at an unexpected time stamp (defined according
to the owner habit) then an alert is raised; or an appliance
requests from the smart grid much more energy than
usual, the system raises an alert. These rules are extracted
from habit learning algorithm, which has been designed
to learn continuously the habit of a set of devices and
assets, which are put under the watch of the Anomaly
Detection component [21]. The habit is built from the
data point values published by the assets/devices on the
REST server. The habit is then expressed as rules, which
are added to the ontology to better analyze the alert.
The implementation of the rules in our proof of concept is
limited to the SWRL rules since they form a subset of the
existential rules that we base our logical framework.
Proposition 1: Let K=(F,R,N) be a knowledge base as
defined in Section IV, and Sis the set of all SWRL rules.
Then: ∀r∈ S ⇒ r∈ R
Proof 1 (scketch): The proof of Proposition 1 is based on
the fact SWRL rule as of the form:
∀X1, ..., Xn:P1(X1) ∧ ... ∧Pn(Xn) → C(Y),
where X1, ..., Xnare vectors of variables and/or constants, Pi,
with i∈ {1, ..., n}are npredicates forming the body of the
rule, and Cis the conclusion of the rule involving vector
Y=vars(C) ∪ consts(C), such that var s(C) ⊆ Ðn
i=1vars(Pi)
and consts(C)=Ðn
i=1consts(Pi) ∪ Z, where Zare new
constants which are not involved in any predicates Pi. It means
that the conclusion the rule does not create any new variable.

Assets
Asset
Description
Ontology
Instances
Main
functions
Fig. 3. FUSE-IT Ontology-Based Anomaly Detection Main Interface.
Therefore, the above rule is a special case of existential rule
which can be expressed as follows:
∀X(H(X) → C(Z,X))
where X=Ðn
i=1Xi,Zare a vector of constants, His a
conjunct of atoms P1(X1)∧... ∧Pn(Xn), and C is the conclusion
of the rule.
C. Anomaly detection application user interface
A user interface has been designed and implemented in
order to manage the ontology, the assets put under control and
to handle the incidents. Fig. 3 illustrates the main interface of
our rule-based anomaly detection system. The main functions
are as follows:
•Compute Incidents: it confronts the data available in the
ontology with the logical rules and checks their validity.
Each rule infringement generates an alert, which then
translated into an incident value that is saved locally.
•Manage Incidents: This function shows the user interface
corresponding to incidents management.
•Reload Ontology: this button allows to reload the data
from a local location. It permits to the user to modify the
facts locally by updating the data. To take into account the
performed changes, this function reloads the new version
of the knowledge base.
•Download Data: this function fetches the new version of
the data on the server and updates the local ontology
accordingly.
List of ongoing
Incidents
Incident Description
Functions
Defined for an
Incident
Incident Filtering
Functions
Fig. 4. FUSE-IT Ontology-Based Anomaly Detection Incident Management
Interface.
•Update Datapoint: this function allows updating a single
designated data point by retrieving its current value from
the data server.
Figure 4 is the interface developed for incident management.
Two groups of functions have been defined. The former is
applied on the list of ongoing incidents for filtering purposes
and the latter is about functions defined for a given incident.
For the list of incidents, it is possible to filter them in order to
display only a given category. There are three defined types,
namely, Sent Incidents, Local Incidents, and Waiting Incidents.
An incident is created by default as a waiting incident, since
the system needs from the user to define the status of the
incident (either to keep local or to send to the server); if the
user specifies that the incident is local, then its type is updated
to “local" (“local NACK", which means that the incident is not
processed yet). If the user prefers to send the incident to the
server, then incident type becomes “sent”, and the incident is
shared with other teams in the building management and then
is supposed to be processed by a better equipped one.
A forth button to display all incidents is also implemented.
For a given incident, the user can update locally its status if
the incident is declared as “local", or remotely if the incident
has been sent to the server. Finally, the user can archive an
incident if its status is “ACK" (which means processed and
closed). The incident is then removed from the ontology and
it is stored on an external storage unit.

Fig. 5. Alert inferred for temperature variation anomaly.
VI. USE CASES IMPLEMETATION
The objective of the experiments, we carried out, is to show
the added-value of using the semantic layer of our data model
to describe a building and logical rules to manage its normal
activity and detect abnormal situations.
Hence, we show some functions of our ontology-based
anomaly detection through the following two real-world use-
cases implemented within the final demonstrator of the FUSE-
IT project involving actual sensors and real data collected,
stored and managed within the REST server:
•physical access control to a data center, detailed in
Subsection VI-A ,
•abnormal temperature variation correlated to the HVAC
functioning, detailed in VI-B.
A. Physical access control to a data center
The first use-case is about physical access control to a room
hosting a data center of a company. To have access to the room,
a badge is necessary and the door is equipped with a turnstile,
which allows only one person to pass at the same time. The
manager has fixed the maximum number of people who can
be inside the room to 3. The badge is also needed to get out
of the room. Therefore, the badge signals are used to count
the number of people who are inside the room. In the case of
this number exceeds the threshold fixed by the manager, an
alert is raised.
The logical rule corresponding to the anomaly can be
expressed as a negative constraint as follows:
!
The alert
generated as a JSON
Object, ready to be sent
to the server, if
should be
Fig. 6. Number of occupants alert generated as a JSON Object.
∀x,y,z,t,uAsset(x) ∧ locatedAt(x,y) ∧
hasT hr es hol d(y,t) ∧ Curr entOccupancy(y,u)
∧greaterEqual (u,t)⇒⊥
The corresponding SWRL rule has been defined and imple-
mented on the data available on the REST server as follows:
R1:Asset(?x),locatedAt(?x,?s),
has Occu pantT hr es hol d(?s,?t1),collects(?x,?d1),
hasCurrentDat aPointV alue(?d1,?dv1),
hasV alue(?dv1,?t2),gr eater T han(?t2,?t1)
⇒raisedAlert (?x,”OCCUP ANCY ”)
Rule R1means that any location in the building which
contains any given asset which reports the number of people
who are actually inside, and for which a threshold is defined
for the number of occupants at the same time, and the
actual number of occupants exceeds the threshold, an alert is
generated. We have simulated the ⊥result by a new predicate
defined in the knowledge base so as any alert is attached to
the sensors which collected the data that triggered the negative
rule (constraint).
The system has been tested and an alert is generated when
the number of occupant at the same time of the data-center
exceeds the limited allowed value. The alert can be either kept
local for a local processing or sent as incident to the server to
be processed remotely. Fig. 6 shows the generated alert as a
JSON object to be sent to the server, if should be.
B. Abnormal temperature variation correlated to HVAC
This second scenario is aimed at showing a more complex
logical rule dealing with a combination of information about

both temperature sensor in a given room and the HVAC
system. Let us consider temperature inconsistency, such as
“after activating the heater for more than half an hour, the
temperature variation is still low". The corresponding rule can
be expressed in our logical framework as follows:
∀x,y,z,t1,t2,u1,u2Asset(x) ∧
assetCat egor y(x,”Temperatur e”)∧
Appl iance(y) ∧ assetC ategr oy(y,”heat”) ∧
is InZ one(x,z) ∧ is InZ one(y,z)∧
hasCurrentT emperature(x,t1) ∧
has Pr eviousT em per ature(x,t2)∧
has St atus(y,”ON”) ∧ timest amp(t1,u1) ∧
timest am p(t2,u2)∧
has AtL eastHal f HourV ariation(u2,u1) ∧
has At L eastFiveDegreesV ar iation(t2,t1)⇒⊥
Within the ontology, the rule becomes as follows in SWRL:
R2:Asset(?a),assetC at egor y(?a,”tem per ature”),
Appl iance(?p),assetCat egor y(?p,”heating”),
has St atus(?p,1),isI nZone(?a,?z),isI nZone(?p,?z),
collects(?a,?t),hasCur rent Dat aPointValue(?t,?vnow),
has LinuxTimestamp(?vnow,?linnow),
has DataPointValue(?t,?vold),
has LinuxTimestamp(?vol d,?linol d),
subtract(?res,?linnow,?linol d),
gr eater T han(?r es,1800),hasV al ue(?vnow,?valnow),
hasV alue(?vol d,?valold),
subtract(?di f ,?val now,?val ol d),l essT ha n(?di f ,5) →
raisedAlert (?a,”Temper at ure_Variation”)
It is worth noticing that in rule R2, the value 1800 is the
number of seconds corresponding to 30 mn, and the anomaly
is identified by the intersection if the identifiers of the involved
asset and appliance. The temperature variation is supposed to
be greater than 5Celsius degrees. Fig. 5 displays the inferred
alert by the ontology based on the data retrieved from the Rest
API server. We notice that the alert is formatted as a JSON
object to be sent to the sever for its processing by the security
stuff. It is also added as an instance of IncidentV al ue in the
ontology along with all its characteristics.
VII. CONCLUSION
This paper positioned the definition and exploitation of
FUSE-IT ontology as an unified core data model for the
FUSE-IT smart BMS developed for the next generation of
BMS for critical sites. FUSE-IT core data model gathers
well-identified concepts and relationships from well-defined
ontologies dealing with four key domains (Energy, Security,
Facility, and ICT), which are not (or only partially) covered
in existing building management models. We have defined
a logical framework composed of facts, rules and negative
constraints to be able to model a large wide of buildings
as well as rules that can be expressed upon. Finally, the
proposed BMS ontological model has been instantiated in
two real world use-cases such that the first one is about
controlling physical access to a datacenter, and the second
one is abnormal temperature variation in a given room, where
a temperature sensor and a HVAC controller are actually
installed and provide data, which are correlated to infer an
abnormal situation.
As future work, from modeling viewpoint, it is possible to
extend the developed core data model to become an ontology
model for BMS management. From application viewpoint,
more sophisticated reasoning-based functions, based on the
existential rules, such as diagnostic, healing, and recovery.
These functions can be implemented beyond the anomaly
detection by integrating cross-analysis of the data to provide
a global solution for smart building management.
REFERENCES
[1] H. Pouyllau, B. Istasse, S. Ahvar, N. Crespi, I. Praça, S. Garcia-
Rodriguez, and E. Mengusoglu, “Fuse-it: Enhancing critical site super-
vision with cross-domain key performance indicators,” in 2016 Global
Information Infrastructure and Networking Symposium (GIIS), Oct
2016, pp. 1–6.
[2] L. Lefort, C. Henson, K. Taylor, P. Barnaghi, M. Compton, O. Corcho,
R. Garcia-Castro, J. Graybeal, A. Herzog, K. Janowicz, H. Neuhaus,
A. Nikolov, and K. Page, “Semantic sensor network xg final report,”
World Wide Web Consortium (W3C), Tech. Rep., 2011.
[3] “Saref ontolog,” http://ontology.tno.nl/saref.
[4] M. Lefrançois, J. Kalaoja, T. Ghariani, and A. Zimmermann, “SEAS
Knowledge Model,” ITEA2 12004 Smart Energy Aware Systems, De-
liverable 2.2, 2016.
[5] “Fsgim:ashrae spc 201,” http://spc201.ashraepcs.org.
[6] J.-F. Baget, M. Leclère, M.-L. Mugnier, and E. Salvat, “On rules
with existential variables: Walking the decidability line,” Artificial
Intelligence, vol. 175, no. 9, pp. 1620 – 1654, 2011. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S0004370211000397
[7] M. Chein and M.-L. Mugnier, Graph-based Knowledge Representation:
Computational Foundations of Conceptual Graphs, 1st ed. Springer
Publishing Company, Incorporated, 2008.
[8] (2004, May) SWRL: A semantic web rule language
combining OWL and RuleML. W3C. Last access on Dez
2008 at: http://www.w3.org/Submission/SWRL/. [Online]. Available:
http://www.w3.org/Submission/SWRL/
[9] “Haystack project,” http://project-haystack.org.
[10] “Brick project,” http://brickschema.org.
[11] M. B. Alaya, S. Medjiah, T. Monteil, and K. Drira, “Toward seman-
tic interoperability in onem2m architecture,” IEEE Communications
Magazine, vol. 53, no. 12, pp. 35–41, Dec 2015.
[12] D. Bonino and F. Corno, “Dogont - ontology modeling for intelli-
gent domotic environments,” in The Semantic Web - ISWC 2008,
A. Sheth, S. Staab, M. Dean, M. Paolucci, D. Maynard, T. Finin, and
K. Thirunarayan, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg,
2008, pp. 790–803.
[13] “Buildingsmart,” http://buildingsmart.org/ifc.
[14] “Energy-home,” http://www.energy-home.it/SitePages/Home.aspx.
[15] “Eebus,” https://www.eebus.org/en/about-us/.
[16] P. Pauwels and W. Terkaj, “Express to owl for construction in-
dustry: towards a recommendable and usable ifcowl ontology,”
AUTOMATION IN CONSTRUCTION, vol. 63, pp. 100–133, 2016.
[17] D. Schachinger and W. Kastner, “Semantics for smart control of building
automation,” in 2016 IEEE 25th International Symposium on Industrial
Electronics (ISIE), June 2016, pp. 1073–1078.
[18] F. Petrushevski, S. Gaida, B. Beigelböck, G. Zucker, C. Schiefer,
D. Schachinger, W. Kastner, and M. Šipeti´
c, “Semantic building systems
modeling for advanced data analytics for energy efficiency,” 08 2017.
[19] S. Ahvar, G. Santos, N. Tamani, B. Istasse, I. Praça, P. E. Brun,
Y. Ghamri, and N. Crespi, “Ontology-based model for trusted critical
site supervision in fuse-it,” in 2017 20th Conference on Innovations in
Clouds, Internet and Networks (ICIN), March 2017, pp. 313–315.
[20] J. Ploennigs, A. Schumann, and F. Lecue, “Adapting semantic sensor
networks for smart building diagnosis,” in Proceedings of the 13th
International Semantic Web Conference - Part II, ser. ISWC ’14. New
York, NY, USA: Springer-Verlag New York, Inc., 2014, pp. 308–323.
[21] N. Tamani and Y. Ghamri-Doudane, “Towards a user privacy preserva-
tion system for iot environments: a habit-based approach,” in 2016 IEEE
International Conference on Fuzzy Systems (FUZZ-IEEE), July 2016,
pp. 2425–2432.