ArticlePDF Available

Abstract and Figures

Despite the popularity of the subject, one surprising aspect of building automation (BA) is the scarcity of author- itative literature references regarding the topic. This situation hampers communication between developers and contributes to the well-known problem of heterogeneity where there is difficulty in integrating solutions from different manufacturers with each other. This article systematizes fundamental concepts and requirements of BA systems, defining each aspect based upon established literature standards. Using these aspects as guidelines, the main BA technology specifications avail- able are then reviewed with respect to their coverage of features. We then proceed by showing that none of the analyzed specifications are able to totally cover the expected standard functionality span of BA. Finally, we conclude that none of the existing approaches are able to fully overcome the problem of heterogeneity by satisfactorily addressing all the aspects of BA endorsed by the standards.
Content may be subject to copyright.
Building automation systems: Concepts and technology review
Pedro Domingues
, Paulo Carreira
, Renato Vieira
INESC-ID and Instituto Superior Técnico, Universidade de Lisboa, Portugal
Automation Systems Group, Vienna University of Technology, Austria
abstractarticle info
Article history:
Received 12 December 2014
Received in revised form 31 October 2015
Accepted 1 November 2015
Available online 11 November 2015
Building automation
Building automation technologies
Building automation standards
Information models
Despite the popularity of the subject, one surprising aspect of building automation (BA) is the scarcity of author-
itative literature references regarding the topic. Thissituation hampers communication between developers and
contributes to the well-known problem of heterogeneity where there is difculty in integrating solutions from
different manufacturers with each other.
This articlesystematizes fundamental concepts and requirements of BA systems,dening each aspect basedupon
established literature standards. Using these aspects as guidelines, the main BA technology specications avail-
able are then reviewed with respect to their coverage of features. We then proceed by showing that none of
the analyzed specications are able to totally cover the expected standard functionality span of BA. Finally,
we conclude that none of the existing approaches are able to fully overcome the problem of heterogeneity by
satisfactorily addressing all the aspects of BA endorsed by the standards.
© 2016 Published by Elsevier B.V.
1. Introduction............................................................... 2
2. Buildingautomationconcepts....................................................... 2
2.1. Levelarchitecture......................................................... 2
2.2. Communicationnetworks ..................................................... 2
2.3. Actuators,sensorsandcontrollers.................................................. 3
2.4. Devicemodel........................................................... 3
2.4.1. Datapoints ........................................................ 3
2.4.2. Commands........................................................ 4
2.5. Functionality ........................................................... 4
2.5.1. Groupingandzoning ................................................... 4
2.5.2. Eventsandalarms .................................................... 5
2.5.3. Historicaldataaccess ................................................... 5
2.5.4. Schedules ........................................................ 5
2.5.5. Scenarios......................................................... 6
3. Buildingautomationtechnologies..................................................... 6
3.1. KNX ............................................................... 6
3.2. LonWorks ............................................................ 6
3.3. ZigBee .............................................................. 7
3.4. BACnet.............................................................. 7
3.5. Othertechnologies ........................................................ 7
4. Managementserviceframeworks ..................................................... 8
4.1. BACnetwebservices........................................................ 8
4.2. OPC ............................................................... 9
4.3. oBIX............................................................... 9
5. Discussion ............................................................... 9
6. Conclusions............................................................... 11
Acknowledgments .............................................................. 11
References.................................................................. 11
Computer Standards & Interfaces 45 (2016) 112
Corresponding author at: Av. Prof Cavaco Silva Campus IST Taguspark 2780-990 Porto Salvo Portugal.
0920-5489/© 2016 Published by Elsevier B.V.
Contents lists available at ScienceDirect
Computer Standards & Interfaces
journal homepage:
1. Introduction
A building automation system (BAS) consists of a system installed in
buildings that controls and monitors building services responsible for
heating, cooling, ventilation, air conditioning, lighting, shading, life safe-
ty, alarm security systems, and many more. A BAS aims at automating
tasks in technologically-enabled environments, coordinating a number
of electrical and mechanical devices interconnected in a distributed
manner by means of underlying control networks. These systems may
be deployed in industrial infrastructures such as factories, in enterprise
buildings and malls, or even in the domestic domain.
Building automation has been receiving greater attention due to its
potential for reducing energy consumption and facilitating building
operation, monitoring and maintenance, while improving occupants' sat-
isfaction. These systems achieve such potential by employing a wide
range of sensors (e.g., for sensing temperature, CO
concentration, zone
airow, daylight levels, occupancy levels), which provide information
that enables decision-making regarding how the building equipment
will be controlled, aiming at reducing expenses while maintaining occu-
pant comfort [1].
The engineering practice of BA has primarily emerged from manu-
facturer documentation, and was followed by technology standards
such as BACnet [2],KNX[3], LonWorks [4],Modbus[5], ZigBee [6,7] or
EnOcean [8,9], which are not in agreement with regards to concepts
and terminology. One example of literature disagreement concerns
the application of LonWorks and KNX at the management level of a
BAS [10, p. 23,11]. Similarly, the denition of the concept of datapoint
is also inconsistent across literature (compare [12, p. 54] with [13]).
Moreover, with the evolution of BAS and technology in general, some
related literature references became outdated, no longer offering coher-
ent denitions in this topic. One example is the large number of litera-
ture references describing Supervisory Control and Data Acquisition
(SCADA) systems that are unable to provide a sufciently generic de-
scription of the SCADA systems' most common architectures [1420].
Some of these references are outdated, thus their accuracy with respect
to the current SCADA systems is questionable [13, Section 3.61 Note 7]
[21]. Indeed, BA is a multidisplinary eld where denition inconsistency
and disagreement are recurringissues and for which almost no author-
itative text exists.
The lack of commonly agreed eld-knowledge and the existence of
functionality gaps leads solution developers to repeatedly redene
basic concepts, creating their solutions bottom up instead of relying
on the existing body of knowledge. Despite the fact that this problem
has been identied and acknowledged in previous surveys and even
considered by some authors as the potential barrier for BA technologies
around the turn of the millennium[2224], an inclination to create cus-
tom solutions persists, which greatly explains theheterogeneous nature
of BA. Most solutions (i) are not able to inter-operate with other ven-
dors' solutions without additional overheads, locking costumers to spe-
cic product linesa major issue if such lines get discontinued,
(ii) have closed specications, (iii) are too complex to be used by non-
specialized personnel, whether they are end-users or system devel-
opers, (iv) only perform satisfactorily in the exact conditions they
were tailored for, not performing so well if the working environment
changes, thus lacking exibility, and (v) do not cover all the desired
functionalities expected in a BAS.
Over the years several interoperability solutions that target the
problems of heterogeneity have emerged from BA technology standards
with variable degreesof success. Despite a fewscattered literature refer-
ences, a principled discussion on how interoperability solutions cover
the main features of BA has never been carried out.
This article starts by introducing and unifying the basic concepts of
building automation systems with the goal of contributing with up-to-
date denitions in this eld. In addition, a set of features that, according
to documented standards, should be implemented in building automa-
tion systems, is detailed and the extent to which most common BA
technology specications cover the expected functionalities of a BAS is
evaluated. Finally, the main solutions for interoperability are analyzed
with a special focus on the Service Frameworks that have been created
within the BA eld.
By analyzing information models of standard BA technologies we
conclude that none is able to fully cover the breath of functionality
expected from BAS, and that distinct technologies are required in
order to create a fully functional system. However, the interoperability
of these technologies is hampered by the fact that, as we observe, a
number of concepts cannot be mapped between them. As a direct con-
sequence of this circunstance, manufacturers have been led to create
their own proprietary extensions thereby exacerbating the problem of
2. Building automation concepts
As discussed earlier, current literature references leave readers
with several unclear denitions and terminology that, in the long run,
promotes heterogeneity among BA technologies.
This section draws on established literature references to systema-
tize fundamental concepts of BAS prescribed by the ISO 16484-3 [25]
and EN 15232 [26] standards and characterizes the scope of functional-
ity expected from the typical BAS that will late be used to evaluate the
coverage of each technology standard.
2.1. Level architecture
A BAS is a distributed system oriented to the computerized control
and management of building services, also referred to as building auto-
mation andcontrol system (BACS)[10]. The architecture of this distrib-
uted system can be organized into three layers [27]: (i) The lowest layer
is known as the Field Layer where the interaction with eld devices
(sensors, actuators) happens, (ii) the middle layer is the Automation
Layer, where measurements are processed, control loops are executed
and alarms are activated, (iii) the top layer is the Management Layer,
where activities like system data presentation, forwarding, trending,
logging, and archival take place [13, p.52].
Modern BAS tend to separate the automation logic from the user in-
terface through service-oriented abstractions, providing exible access
to the BAS from several different platforms and locations [28,19,20].
2.2. Communication networks
The backbone of the eld level is the eldbus, a digital data bus that
allows communication between devices at the eld level such as con-
trollers, sensors, and actuators [10, p. 23, Chapter 2] [29,30].Aeldbus
aims at improving communication quality in comparison to previous
analog communication buses, and at reducing installation costs by cut-
ting down on the required wiring, since devices connected through
eldbus only communicate digitally. Devices connected to a eldbus
network are expected to have some computational power, and may
even replace several analog devices simultaneously, further contribut-
While eldbuses are used at the eld level, it is common to aggregate
data via a common (IP-based) backbone at the management level. The
overall installation consisting of eldbus segments and the backbone
is frequently referred to as control network. A plethora of different
control network technologies currently exist on the market with speci-
cations that vary according to requirements of their application [10].
Besides many vendor specic solutions, the main standards used
today are BACnet [2],KNX[3], LonWorks [4], Modbus [5],aswellas
wireless buses such as with ZigBee [6,7] and EnOcean being notably to
mention wireless representatives [8,9].
2P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
2.3. Actuators, sensors and controllers
The setup of a BAS comprises actuators,sensors and hardware mod-
ules. Actuators react to signals closing circuits or varying the intensity
of electric loads, which are physical devices such as a window blind or
a ceiling lamp. Sensors are devices that convert a physical reality into
a signal that can be measured. Although, some devices tinbothgroups
due to their sensing and actuating capabilities, for simplicity they may
be perceived as two different virtual devices: one device capable of
sensing and another one capable of actuating. In turn, actuators are
often confused with electrical loads or with the physical device they
drive, for example, what is commonly understood as a blind actuator
is indeed a motor actuator (attached to a blind). Finally, actuators and
sensors are attached to I/O ports of hardware modules that produce
electric signals according to digital output commands and create read-
ings from input signals.
The interaction between devices must be orchestrated through
some type of control logic. Such logic lies in components known as
controllers. In building control systems, a controller usually consists of
an application-specic hardware with embedded software that contin-
ually controls physical actuators (such as lights, blinds, among others)
depending on the feedback given by monitored inputs (such as light
or occupation sensors) or by receiving commands from the system
[13, Section 3.55].
From an application point of view, controllers expose different types
of logic objects that can be read or written. Depending on the sophisti-
cation of the controller, it may be capable of running more than one
control program simultaneously, reading and writing I/O ports or com-
municating with other controllers over the eldbus network.
Control function logic may have different complexity levels, ranging
from simple binary conditions developed using ladder logic or function
blocks [32,33], to mathematical expressions or even more sophisticated
algorithms such as Fuzzy Reasoning [34]. Depending on the sophistica-
tion of the control functions controllers can be distinguished as
Programmable Logic Controllers (PLC) or Direct Digital Controllers (DDC).
PLCs typically implant simpler and more rigid functions that require
little or no conguration, while DDCs are more exible and typically
implement functions that require extensive conguration such as
scheduling or scenario management.
Control functions can also be implemented in non-embedded soft-
ware running in a server, thus centralizing the control functions of the
BAS in the management layer, where the control logic can make use of
aggregated data from different eldbus segments. The advantage of a
software controller is that it may undertake more complex decisions
or explore additional information gathered from the system.
2.4. Device model
Automation hardware is highly heterogeneous and should be
abstracted in a way that enables software applications to be as indepen-
dent as possible from the specicities of the hardware.
With respect to a BAS, devices have two interfaces, an electrical inter-
face, that denes how to connect the device to the rest of the system,
and an application interface that enables other devices and software
applications to interact with the device through exposed datapoints.
Adevice driver is a component that controls devices connected to a
system, while simultaneously providing a layer of abstraction that sim-
plies their operation. Each device driver corresponds to a particular
type of device, meaning that a system having to support hundreds of
different devices must install hundreds of device drivers. The consider-
able diversity of devices available poses a challenge to the creation of a
generic device driver that ts every device of the same type, i.e., devices
that have compatible interfaces. The interface of onedevice is said to be
compatible with another if some of the properties of one interface exist
in the other and share the same data type. For example, a common de-
vice driver controlling every lamp dev ice where all lamps have the s ame
properties and properties to act upon, such as turning the ballasts on or
off. We can further distinguish between hardware device drivers and
software device drivers.
Hardware device drivers consist of hardware modules with I/O ports
and a micro-controller. The I/O ports are connected to physical devices,
which usually possess no intelligence and are directly operated using
electric signals, such as a lamp, a thermistor or the fan of an air condi-
tioner. The micro-controller is responsible for driving those devices
and exposing an interface that can be used to address each I/O port for
reading and writing purposes. This hardware module can be connected
to a computer, a network or to another hardware module [35, p. 523].
From a software point of view, reading from a sensor is equated with
reading from a variable that represents a hardware input port and com-
manding an actuator is equated with writing a value on a variable
representing an output port.
Software device drivers consist of application programming inter-
faces used to enable other applications to interact with devices. These
device drivers are used to (i) convert electric signals into values stored
in variables or objects that can be read by software applications, and
(ii) in contrast, they also convert values into electric signals that drive
actuator devices.
Overall, physical devices are mapped into I/O ports Overall, physical
devices are mapped into ware devicedrivers, providing a higher level of
abstraction, or to a software device driver that will act as an hardware
abstraction layer, serving other software applications with the capabili-
ty of operating those devices, without being concerned with low-level
hardware-related details, such as device communication protocols.
Fig. 1 illustrates this situation, where physical devices are connected
to I/O ports of a hardware module (acting as a hardware device driver)
capable of providingan interface that abstracts these connections. Such
an interface is then used to connect the hardware module (and thus
connecting the physical devices) to a network. On the other hand, soft-
ware applications require an abstraction layer, provided by software de-
vice drivers, to operate those devices. The network device driver will
implement the network's protocol stack, abstracting upper layers from
communication specicities and exposing the hardware module's pres-
ence in the network. This is followed by the hardware module's device
driver that will operate the module directly, providing a simpler inter-
face to the upper layer, exposing the module's ports and mechanisms
simplifying the tasks of reading and writing for those ports. Each port
will have an associated device driver that will expose the device con-
nected to that port and the corresponding operation mechanisms. Final-
ly, high-level abstractions of these devices are created by dening
objects that represent those devices and can be manipulated by soft-
ware applications.
2.4.1. Datapoints
Datapoints, endpoints, tags or points have different denitions
across the literature [12, p.54,13, Section 3.61]. However, they all
describeentities as an addressable point of interaction between the con-
trol system and its domain objects [11]. Datapoints can be physical or
virtual. A physical datapoint is directly related to a device connected to
the system, such as a device's I/O ports (where each port can be mapped
to a datapoint) [6, p.10].Incontrast,avirtual datapoint acts as a way of
addressing virtual objects such as services provided by devices, for
example, a temperature sensor exposing a datapoint that when read,
returns the average temperature measured in the last hour, or a
datapoint addressing a conguration parameter of a given device, in a
way that writing to that datapoint affects the associated conguration
parameter [36,37, Section 2.7.2]. Virtual datapoints can also be used to
address stub devices for testing purposes.
Every datapoint has metadata associated with it, which describe a
set of rules for the interaction with that datapoint, where we can typi-
cally nd the access type, the data-type, installed location, inuence
zone and a value update rate for reading and writing operations.
3P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
Datapoints offer one of three types of access: read, write, or both.
Readable datapoints are read-only and usually relate to sensor devices.
Writable datapoints are write-only and relate to actuator
deviceswriting to datapoints equates with updating the system's
state. Datapoints that offer both access types may be used to write up-
dates into a device, such as turning it on, and to read the device's internal
state from it, for example, to probe the device on/off status.
Datapoints that provide a read-access type should ensure a regular
value update rate so that every client application knows how often it
should poll that datapoint for value updates in a given period of time,
which is known as smallest sampling interval. On the other hand,
datapoints that support writing operations may provide a maximum
rate at which writings can be performed. For instance if a lamp device
and its associated writable datapoint are changed too frequently, hard-
ware damage may occur. In addition, datapoints may expose only their
new value when a signicant change of value (CoV) occurred.
In addition, datapoints have a data-type associated to them, which
tells client applications how the information is structured when they
read from a datapoint and how it must be structured when writing to
that datapoint. Moreover, data-types can have semantic information
associated with them, usually represented by a unit, which in turn de-
scribes what that structured information represents for a given domain
context. For instance, a datapoint's value can represent a binary quanti-
ty, which is unitless, or a temperature in Celsius, a percentage, an ap-
plied force in Newton, among others.
In some systems, datapoints having the same data-type can be
linked together in a process known as binding. This means that when
a datapoint is updated, linked datapoints are notied and may perform
an action, such as obtaining thesame value. A practical example of bind-
ing is a switch device that has its datapointrepresenting the switch
statusbound to a lamp device's datapoint. When the switch is pressed
the lamp device turns on or off accordingly (Fig. 2).
Non-virtual datapoints always belong to devices which are installed
in a physical location of a building. Knowing the installed location of a
datapoint is important, especially if that datapoint belongs to a sensor de-
vice. Conversely, datapoints also have a zone of inuence, i.e., the space
affected by their actuations, which may not be the same as the installed
location. For example, a heating, ventilating, and air conditioning system
(HVAC) usually occupies one room in the building and affects several
other rooms, while a lamp device affects the same room as it is installed
2.4.2. Commands
Operations that can be executed on devices are called commands.
When successful, commands cause devices to change their internal
state or to actuate in their environment of inuence. For example, set-
ting the intensity of a lamp is the result of executing the command
dim to level.
Commands have parameters specifying what operation should be
conducted, and attributes specifying how it should be carried out. The
command that dims a lamp to a given level requires specifying the
target value for the intensity parameter or ramp-up time. Commands
can be sent to devices individually or in group if all devices of a group
can accept that command.
2.5. Functionality
In this section, we present the basic functionality that, based on sev-
eral literature references and standards, it is essential in modern BAS
[25].Table 1 groups the functionalities described in two international
standards of reference in the following categories: Grouping and
Zoning, Event Notication, Alarm Notication, Historical Data Access,
Scheduling, and Scenarios.
2.5.1. Grouping and zoning
A device group is a logical identication of a set of devices. There are
two fundamental types of groups: device collections and command
Fig. 1. Illustration of a Building Automation Hardware and software stack. Physical devices are connected to an I/O module, responsible for exposing them as addressable entities (on the
left). Thecorresponding software representation ofthe hardware stack, where the I/O module is operated by a softwaredevice driver, exposing each portand each device connected to it
(on the right).
Fig. 2. Representation of two datapoints bou nd together, where the switch device's
datapoint noties the lamp device's datapoint of status updates.
4P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
groups. Device collections consist of a set of devices used to organize or
structure large installations. For example, all devices in hallwayscould
perhaps consist of all luminaries and occupancy sensors of hallways.
Command groups are collections of devices with compatible interfaces
that are intended for simplifying commanding multiple devices at
once. Interfaces are said to be compatible if they recognize the same
commands or expose the same type of datapoints. Consider two inter-
faces, one for controlling a lamp and other for a HVAC system. If they
both accept the commands on and off, they are said to have a degree
of compatibility with each other, where the oncommand will light
the lamp and turn the HVAC on, and the offcommand will switch
both devices off.
Device groups can be dened by hardware or by software. A hard-
ware device group is a group created by the use of a hardware device
module that abstracts several devices into just one device. For example,
an air conditioner capable of measuringtemperature and ventilatingthe
air can be an abstraction of two independent devices, one being a
thermistor and the other a fan. Software device groups have a major ad-
vantage over hardware device groups in that they can be dynamically
arranged in order to add or remove members without requiring any ef-
fort modifying the system's structure, whereas hardware device groups
would require hardware modications or network restructuring.
Groups of devices gather devices that are supposed to be commanded
together with a given purpose. The group will thus behave as a virtual de-
vice whose properties can be assigned; assigning a property of a group
will propagate that assignment to each device belonging to that group.
Agroupcanbeall lamps in corridorsthat are to be commanded togeth-
er in some situation. These groups are closely related with the concept of
Building automation is intrinsically related to the idea of controlling
spaces, since most actuations are conned to specic spaces. We can say
that spaces are divided into several sub-spaces, known as zones. A zone
can be a oor, a room (or just part of it) or an area within another zone.
Zones may berelated according to containment and adjacency, providing
information about the building(for example, to identify and distinguish
halls from rooms in a building). Furthermore, a zone is characterized by
metadatasuch as the zone name, space usage prole and location with-
in the parent zone as well as its boundary polygon that denes the
zone's shape and borders.
Arranging spaces into zones helps commissioning the BAS and eases
the task of the user in understanding, navigating and recognizing the
controlled area in a user interface software. Zone information is also
useful for querying spatial aspects of devices, such as where the devices
are installed and their inuenced environment.
2.5.2. Events and alarms
An event consists of any occurrence that modies a system's state
(a door that opens or a lamp that turns off). The user of the BAS may
choose to be notied of certain events, usually conditions that have
been veried, such as a room's temperature that has changed two de-
grees Celsius since the last measurement, a specic door that has just
opened, or a new person who has entered a room [13].
Alarms, on the other hand, are exceptional events generated by the
system's operating conditions. Typically, alarms correspond to excep-
tional conditions originating in a specicdevice or a group of devices.
Alarm events capture a malfunction of some device, lack of a resource
essential for the execution of a process or a condition of the overall
system's state that has to be pointed out. The information pertaining
to an alarm indicates the apparent source of the problem and may
also indicate when the originating alarming condition ceases. Alarms
have severity conditions associated to the degreeof disruption of the re-
lated object's normal operation. In contrast with regular events, alarms
also have an acknowledgment process: either they require manual ac-
knowledgment or may be transient, meaning that they are cleared
whenever the condition that initiated them is no longer veried [13].
2.5.3. Historical data access
Logs are essential to understand the activities of complex systems,
particularly in the case of applications with little user interaction in
BAS. Data logging is theprocess of recording commands sent to devices,
devices' state transitions and events (such as alarms), in order to under-
stand system activity and for diagnostic purposes. Logs may contain in-
formation about events, processes, alarms and user interactions [25].
Log records can be split in two categories: temporary and permanent.
Temporary records are relevant in a short period of time after their oc-
currence, and after that period they can be removed. Permanent records
must be kept for the entire life-cycle of the system. It is important to
note that the preservation of permanent records is very demanding in
terms of storage. For that reason, it is important to intelligently select
what information should be stored permanently, the sampling rate
and possibly the usage of data compression techniques.
Data analysis is a useful functionality built atop of data logging sys-
tems, enabling the extraction of relevant information such as energy
consumption and performance forecasts [38].
2.5.4. Schedules
The BAS is often required to execute certain tasks according to given
schedules. This is achieved by providing a scheduling service in order to
associate task executioncommands sent to deviceswith some mo-
ment in time. Schedules are uniquely identied by the combination of
their date, time and the tasks being performed. They can be dened ac-
cording to ne-grained units of time such as days, hours, minutes or
even seconds. As time passes, scheduled commands are executed.
Scheduled events can be one-time events or repeatable events.
For convenience, the system should support the creation of several
schedules; for example, two schedules used to manage the building's
illumination in the winter and summer. Schedules are embedded in
hardware controllers, but in larger facilities they are often congured
in the main server that runs the BAS software [10].
Table 1
BAS functionalities addressed in ISO 16484-3 [25] and EN 15232 [26].
This aspect is men-
tioned throughout the document EN 15232.
Functionality ISO 16484-3 EN 15232
Grouping/zoning Individual zone control is
listed as a required
functionality. (Section
The concept of zones is used to
dene room or zone specic
control activities and setpoint
preferences. (p. 27, 32, 46)
Event handling and
notication are described as
an operator function provided
by the HMI. (Section,
Refers to the notication of
changes in the system's status
changes for several purposes
such as controlling indoor
Alarm notication is described
as an operator function
provided by the HMI.
Alarm notication are
essential to detect malfunction
Historical data
This standard presents data
archiving and the means for
retrieving that data as
management functionalities of
a BAS. (Section
States that data collection and
logging are features offered by
building management
systems. (p. 10)
Scheduling Provides a section describing
time scheduling features.
Species the use of schedules
to control some attributes
such as the air ow in a room
(Section 7.5.1)
Scenarios There is no direct reference to
the scenarioterminology,
although, energy
management services are seen
as a requirement that
according to EN 15232
benets from this concept.
The standard denes several
system operating modes that
are used to adapt the
operation of the building to
occupants' needs. Each
operation mode can be
modeled as a scenario.
5P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
2.5.5. Scenarios
A scenario describes the desired status of a device or a group of de-
vices associated to some context (such as the time of day or occupancy
rate), relative to one or several zones.
Scenarios can be static or dynamic. A static scenario does not change
the state of devices once it is set, meaning that it does not prescribe ac-
tuation whenever environment conditions change. A static studying
scenariocan be dened as having the lights on over the table. The
TV scenario, in turn, would switch off all luminaries so that the occu-
pant could watch TV comfortably, and provide a dimmed ambient light
near the corridor. Thus, activating a scenario amounts to setting the de-
vices to the respective pre-set parameters dened in the scenario.
In contrast, a dynamic scenario describes how the system reacts ac-
cording to changes in the environment. A dynamic studying scenario
species that lamps have to be turned on if there is not enough light.
Implementing dynamic scenarios may become complex when they
vary according to occupants' preferences. This is especially true when
considering the preferences of more than one occupant in a zone or
taking into account multiple factors simultaneously such as energy con-
sumption peak times, noise, temperature or humidity.
Another important aspect of scenarios is the time dimension. Device
parameters can be set in sequence having certain delays, i.e., when a
scenario is activated the effect on the devices' status may not be imme-
diate. Consider a morningscenario which species two actions: (i) in
the 30 minutes before the rst person is expected to enter the building,
the heating system, which was previously turned off to save energy,
should turn on in order to heat the building according to a given set-
point. (ii) Then, 30 minutes later, the building's main entry door gets
unlocked so that people can enter while, hopefully, the building's tem-
perature will be at the desired set-point.
3. Building automation technologies
This section maps out the essential functionalities of a BAS to state-
of-the-art BA standard technologies available in the market. This analy-
sis is based on an extensive analysis of the information models of each
technology specications, studying how each information model of
deals with the functionalities identied in the previous section. Infor-
mation models represent, characterize and relate concepts of a given
domain by abiding to a common domain model where applications
can share information, from which low-level details regarding physical
and network specicities such as device architectures and protocol data
are abstracted.
We analyze how the information models address fundamental BAS
concepts such as grouping, notifying, scheduling, and commanding,
among others. Although many standards enable implementing these
functionalities through, e.g., model extensions, software plug-ins,
extra hardware modules, we will only consider functionalities natively
provided by the specications of standards, which formally dene
how such functionalities should be implemented. Otherwise manufac-
turers are left with the responsibility of carrying out these functionali-
ties, and having freewill for promoting closed proprietary solutions,
thus hampering interoperability with other solutions, resulting in situa-
tions of costumer lock-in.
3.1. KNX
KNX is a technology that emerged from the European Installation
Bus (EIB), European Home Systems (EHS), and Batibus that resulted in
the establishment, of the Konnex Association, in 1999. Later, in 2004,
the KNX protocol was standardized as norm EN 50090 and, in 2006,
KNX was recognized as the international ISO/IEC 14543-3 standard.
KNX distributes control across devices through functional blocks.A
functional block consists of a group of datapoints and a behavioral
specication about the device, for example, a binary push buttonfunc-
tional block representing the functionality of an on/off switch. Each
functional block can be associated with one device. Although a device
must implement at least one functional block, it may have multiple
ones. The KNX specication already denes standard functional blocks
and datapoint types.
A datapoint represents a functional block's inputs and outputs, and
application parameters such as an internal variable storing the minimum
light intensity that a lamp controller can provide. These datapoints have
an address and data-types associated to them [39] and typically, devices
communicate by writing to other devices' datapoints via group commu-
nication. Datapoints can be bound to other datapoints (thus joining a
group), in order to notify other devices of updates in the system. When
a datapoint value changes, the new value is propagated to all datapoints
bound to it.
The KNX specication denes three distinct ways of binding
datapoints: free binding,structured binding and tagged binding with in-
creasing levels of semantics. In free binding datapoints having the
same type can be linked freely. Structured binding follows a certain
pattern dened by the information model for linking datapoints based
on devices' functional blocks. For example, a push-button must have
its output datapoints linked to the input datapoints of the device it
will control. Finally, tagged binding proposes that part of the datapoint's
address should contain some information in order to highlight some as-
pects like the group the datapoint belongs to. This can be used to select
datapoints of a given zone, where parts of those datapoints' addresses
represent their location, thus tagged binding can be used to group
datapoints or devices [40]. Scene control is also supported, having
three distinct approaches: (i) Setting the scene conditions via a commis-
sioning tool, (ii) Setting the scene conditions of the connected actuators
and storing this scene as a scene number in the connected actuators,
and (iii) by using a datapoint type called scene number [41].
A key feature of the KNX message protocol is its observer-pattern-
based mechanism of information exchange. Multiple observing bus de-
vices are notied via a single multicast message of changes to data on a
single source. This allows the easy creation of m-to-nrelations, since the
source is not a xed device. Hence normal bus trafc is not transacted
via point-to-point messages, but through so-called group communica-
tion. Therefore, special group addresses are foreseen, which enable a re-
ceiving device to decide if it is a member of such a group, and a received
message can either be ignored or processed.
KNX devices are commissioned by the Engineering Tool Software
that provides the user with a higher level of abstraction with re-
spect to the system's conguration complexity. KNX has some limita-
tions: its specication does not natively refer to historical data access
features, event and alarm notication, task scheduling and scenario
management features, giving each vendor free will to implement such
functionalities at higher layers without following a base guideline.
3.2. LonWorks
LonWorks, or Local Operating Network (LON), is a eldbus protocol
developed by Echelon Corporation as a generic open control network.
Its objective is to support a wide range of distributed applications in var-
ious domains such as buildings, production lines, or transportation. In
1999, the underlying control network protocol entitled LonTalk has
been standardized as the ANSI/EIA-709 and ANSI/CEA-709 standard. It
is also available as the European standard EN14908 and as international
standard ISO/EIC-14908.
In LonWorks a network device is called a node. Nodes have a unique
address and may implement multiple functional proles. Functional
proles describe the application layer interface of a device in detail,
i.e., its expected functionality, which includes its behavioral congura-
tions and network variables. Network variables are datapoints exposed
by a device to other devices in the network used to exchange
KNX Software Tools ETS5:
6P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
information. Every network variable has an associated data-type that
denes units, scaling and structure of the data it contains. Network
variables can be bound (if they share the same data type). Network var-
iables usually follow well-dened rules dened in LonWorks Standard
Network Variables Types (SNVT) specication [42], guaranteeing inter-
operability between LonWorks devices. For example, LonWorks spec-
ies variable types responsible for carrying alarm notications.
An example of functional proles is a device acting like a switch,
implementing the Switch functional prole [43] that exposes an output
network variable used to turn on or off other devices, for example, a
lamp device. Then, that lamp device implements a Lamp Actuator func-
tional prole [44], exposing an input network variable used to receive
input values controlling the lamp's status. By binding these variables,
the switch device will be able to command the lamp device.
Functional proles can also be a drawback since there is no way that
the specication can foresee every need. Therefore it turns out that
many manufacturers implement their own proprietary extensions, thus
hampering interoperability. An example of a lack of functionality is the
absence of network variables tailored for historical data access. However,
similarly to other eldbus standards, LonWorks can have programmable
devices which may support such features not covered in the specication,
unfortunately, at the cost of interoperability loss [45, p. 55, 56].
LonWorks supports the creation of logical virtual networks within
the physical network structure's domains and subnets which can be
used to implement zoning. Domains are used to separate large, inde-
pendent groups of devices in a network, for example, separating lighting
systems from HVAC systems. Subnets are physical or logical groups of
devices within a domain. For example, a subnet can be a group of all de-
vices of a room. Domains and subnets provide LonWorks with the capa-
bilities of zoning. Inside subnets nodes can be addressed individually or
by broadcasting. Another way to associate devices in a way that is inde-
pendent of domain-subnet-node addressing is by creating a group.
Groups are a collection of devices, where each member can communi-
cate with others using the group's identication. Groups can also be
used for broadcasting messages.
3.3. ZigBee
ZigBee is a standard based on IEEE 802.15.4 specifying the network
and the application layer. ZigBee enables devices to communicate wire-
lessly, reducing wiring costs and the aesthetic impact of the system's in-
stallation, providing a simple, low-rate, low-power and cost effective
protocol for RF applications.
ZigBee's information model is mainly dened across three layers
that manage device objects, endpoints and bindings between those
endpoints, known as the Application Support Sublayer, ZigBee Device
Object and Application Framework layers [6].
The Application Support Sublayer is responsible for binding end-
points, message forwarding between bound devices, and the manage-
ment of groups. Device groups are supported by group addressing
where writing to a given address may result in writing to several devices.
The ZigBee Device Object layer is responsible for overall device man-
agement, and is specically responsible for dening (i) the operating
mode of the devicetelling if a device coordinates network communica-
tions or acts as an end device, (ii) device discovery and determination
of which application services the device provides (each application ser-
vice corresponds to an endpoint of a device), and (iii) for handling bind-
ing requests from other devices or coordinators.
Finally, the Application Framework is home to a device's applica-
tions. An application object tells what services the device can offerfor
example, an application object can be a light bulb, a light switch, a LED,
or an I/O line. Each ZigBee device can have up to 240 applications, thus
240 endpoints are reserved for this purpose in each device. To
communicate with other devices applications make use of specicpro-
tocol data units called clusters that consist of predened message struc-
tures consisting of commands and attributes, resembling an object in
object-oriented programming context [46, p. 238239], that both com-
municating devices are aware of, thus providing interoperability. For
example, an on/off cluster denes how to turn something on or off.
This cluster is generic enough for working with light switches, pumps,
garage door openers and any other device that can be switched on or
off. ZigBee's cluster library provides clusters for managing device
groups, scenarios, and alarm notications [47].
3.4. BACnet
building automation and control networking protocol (BACnet) was
developed by a project committee established by the American Society
of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). Its
main objective was to provide a solution for BAS of all sizes and types.
In 1995, BACnet was published as ANSI/ASHRAE 135 standard and
later became a CEN and ISO standard within the ISO 16484 series [2].
Overall, BACnet denes an information model that organizes the sys-
tem devices using a standard collection of objects [27]. These objects
represent application services along their inputs and outputs, such as
devices, calendars and schedules, commands, and control loops. In
BACnet a device is represented by a device object which denes device
properties like device model name, device vendor, device status and
the list of other BACnet objects associated to the device. For example,
a device with two analog inputs will have two instances of analog
input objects associated [10, p. 243]. BACnet's model also accommo-
dates proprietary object types for manufacturers to register functional-
ities not covered by standard objects, risking the interoperability
between devices [54, p. 10].
BACnet supports grouping through a specicgroup object that
consists of a list of objects belonging to a desired group and a list of
the selected properties of each of those objects. Groups can be used to
create logical groups such as zones.
The BACnet's calendar object consists of a list of relevant dates (for
example, public holidays or special events). On the other hand, schedule
objects associate functions to specic dates, time or date intervals.
Schedules can be periodic, if they are repeated every week or they can
be a one-time event [55].
BACnet commands are used to write to several attributes of a group
of objects simultaneously when invoked. These objects can be devices,
calendars, inputs, outputs. BACnet commands can be represented as ob-
jects containing a list of actions that can be executed,where each action
consists of a list of attributes of other objects to be changed along with
their new values. For example, a command object can dene a set of
attributes to modify when a certain room is unoccupied and another
differentset of attributes when it is occupied, hence dening two possi-
ble scenarios for that room, one called occupiedand the other called
Also, it provides an object for logging and historical data access. The
Trend Log Object acts as a monitor on the object values, storing each
change in memory for further analysis. Developers can choose how
much data they can hold in memory, by specifying how many values
they want to keep.
Another interesting BACnet feature is the notication class object
used for distributing event notications. These objects may require the
recipient's acknowledgment and a list of recipients. The subscription
of a recipient is maintained by a list of recipient device objects, associat-
ed with the notication object.
BACnet provides neither concept of inheritance noraggregation. Any
model extensions must be made based on the creation of new standard
objects. This lack of advanced modeling mechanisms makes data repre-
sentation, such as sub-typing, difcult. [11].
3.5. Other technologies
Other frequently used technologies in BAS are EnOcean [8],Insteon
[56],Modbus [57] and Z-Wave [58]. EnOcean and Z-Wave dene low-
7P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
power wireless communication protocols and their inherent electrical
aspects, and are usually employed in home and industry automation.
Similarly, Insteon provides support for, but is not restricted to, wireless
communication and is generally used for home automation. On the
other hand, Modbus species an application layer messaging protocol
for automation device communication (mainly focused on controler-
to-controler message exchange), which can be implemented using sev-
eral types of buses and networks (e.g., Modbus RTU, or Modbus TCP).
However, these technology standards dene mostly message trans-
port protocols and do not specify interesting information models in the
context of interoperability. Indeed the decisions regarding how device
specic commands and top-level concepts (like scenarios or alarms,
are carried out) are left open to the hardware manufacturers.
4. Management service frameworks
Service-Oriented Architectures (SOA) or Service Frameworks de-
scribe architectural principles and patterns aiming at reducing depen-
dencies between systems to ensure interoperability, sustainability and
autonomy, through the abstraction of service [59].
Services are an abstraction of functionality available as a remote
procedure call and serviceprovider applications provide servicesto con-
sumer applications. One key aspect of most SOAs is that service pro-
viders and consumers are loosely coupled. Service providers publish to
a service broker server descriptions about their services, specifying
each service's capabilities and invocation requirements. This service
broker server manages a list of available service descriptions published
by service providers, which can be requested by consumers. This action
is usually known as service discovery. Serviceconsumers must adapt to a
specic interface in order to establish communication with service
types of technology, such as devices from a range of vendors or devices
communicating using a diversity of protocols. Ultimately, a SOA acts as a
communication gateway between system devices and client applications.
Services can be reused by other applications that share the same in-
terface guidelines as the service provider. Consider a BAS based on a
SOA, where a service framework is responsible for encapsulating the
logic of building automation and simultaneously for offering its services
to enable any external application to interact with the system. These ex-
ternal applications may be graphical user interfaces for the automation
system, thus enabling the development of multiple interfaces such as
one interface for a desktop computer and another for smart phones.
Moreover, this form ofinterconnectionopens BAS to the world ofthe In-
ternet of Things (IoT)with one of its manifestations being, for example,
smart grids [60]. Here, information and communication technologies
are an added guarantee of the grid's stabilit by coordinating demand
variability with intermittent power production that arises from an in-
creasing adoption of renewables.
Service Management Frameworks for BAS ease the task of maintain-
ing the system, because changes in the automation software's internal
logic will not affect any of its interfaces, and interfaces can be created
or modied without affecting the automation software. Fig. 3 illustrates
the typical topology found in management service frameworks, which
abstract multipurpose client applications from the underlying automa-
tion technologies.
In the following sections, we study the most commonly used service
frameworks to tackle heterogeneity that have emerged from automa-
tion standards and have gathered ample support in the BA industry.
4.1. BACnet web services
The BACnet specication also covers a high-level SOA protocol,
concerning a client-server communication protocol oriented to the
needs of building automation systems, known as BACnet/WS. This pro-
tocol provides a WS interface that can be used to communicate with
multiple eldbus networks [61,49].
BACnet/WS services are used for reading and writing data into the
servers which can be directly connected to a eldbus network. These
servers are organized by an information model consisting of hierarchi-
cally arranged nodes, where nodes are used to map BAS domains.
Nodes can only have one parent node, but can have an innite number
of children nodes. Nodes are described by their attributes, like node
type, display name, value, and units, and these attributes can have
nested attributes. Some node attributes are optional while others are
always required (like the value attribute, for example). BACnet/WS pro-
vides two types of nodes: Standard nodes and reference nodes. Stan-
dard nodes contribute to the server's hierarchic model by naming part
of the path to each leaf node (where leaf nodes are nodes with no chil-
dren), i.e., the path to a leaf node is the composition of all standard
nodes belonging to that leaf's path. Reference nodes are, as their name
suggests, links to other nodes. These nodes are used to allow other
nodes to appear in different places in the same hierarchic model. Each
BACnet/WS server instance can only have one hierarchic model, mean-
ing that every concept must be a child of the root node [49,62].
BACnet/WS denes different types of service, where the most
frequently used are: the options services,theread services and the write
services. The options services are used to modify the server's behavior.
For example, changing the precision of retrieved values, or the server's
default localization (important for localized attributes like multilingual
names and the server's time-zone). Read services provide several
ways of reading values from nodes' attributes, which can go from read-
ing particular attributes, to reading an array of attributes with just one
Fig. 3. Typical topology of a Management Service Framework abstracting multipurpose client applications from the underlying building automation technologies.
8P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
request. In contrast, writing services provide a way of writing values
into those attributes, individually or in group.
4.2. OPC
Object Linking and Embedding for Process Control (OPC) is an indus-
try standard for dening a standardized mechanism to access automa-
tion hardware such as sensors, actuators and controllers, as well as
associated services such as data logging and event notication subscrip-
tions [53]. OPC is based on the idea that each vendor provides OPC-
compatible drivers for their network devices. These drivers abstract
OPC systems from dealing with the intrinsic specications used by
each vendor's devices. In this way every device can communicate
through OPC's uniform data representation [27].
At its core, OPC conceptual model rests on two generic concepts:
nodes and references. Every OPC object is a node, and every node may
have references to other nodes [63,53, p. 22]. Each node has unique
identication and a class type telling the purpose of the node. Nodes
may represent objects, types, variables or even methods. Each node
has a display name which is a human-readable localized text describing
the object.
References capture relationsbetweennodes and are associated with
aReference Type object that denes their semantics. The most common
types of these references are inheritance and composition. References
between two nodes can be asymmetric (implying different roles for
each node, such as an inheritance reference) or symmetric (implying
similar roles for both sides). Reference types may also have references
between them, thus supporting sub-typing through the use of sub-
type reference types [53 Fig. 2.5].
In sum, OPC denes a meta-model consisting of 8 standard classes of
nodes, where the most relevant are: objects,variables and methods [50,
p. 82]. Objects are a kindof node used to structure the system's domain,
known as address space. They do not contain any information other
than the attributes inherited from nodes. Object values and behaviors
are exposed using variables and affected by invoking methods. More-
over, methods and variables are connected to an object by theuse of ref-
erences. There are two types of objects: simple and complex. Simple
objects are used to dene semantics, usually in order to organize other
nodes; they have neither variables nor methods. Complex objects ex-
pose some structure of nodes beneath them, composed by variables
and methods, which are present on each instance of these objects.
Every object node is related to a node called object type,dening the
object's type [50, p. 83].
Objects can also be marked as event sources which trigger events
given certain conditions. Clients can subscribe to these events so they
get notications every time they occur through the subscription services.
Comparable to objects, variables can also be simple and complex. Sim-
ple variable types only dene the semantics of a given property, whereas
complex variables expose some structureofmorevariablesbeneathit.All
variables have an associated data-type and a value attributed to it. The
data-type indicates the type of value held by avariable. OPC specication
denes approximately forty standard data types [64, p. 60], and new ones
can be added. Variables can be marked as historizable, meaning that the
variables' values will be recorded into a log registry with a pre-dened
sampling rate. Clients can subscribe to variables' value changes, so that
they receive noticationsaboutavariable'sprogress.
Although OPC is exible enough to model different domains other
than building automation [65], it is also complex, therefore its specica-
tion may be hard to understand, extend and support. Due to this com-
plexity, there is a lack of updated free-software and development
tools [11]. Moreover, many tools are unable to implement the entire
OPC UA denes an extensive list of service sets [64], where the more
relevant are the discovery services, node management services, view
manipulation services, querying and attribute services, method services,
and monitored items and subscription services.
4.3. oBIX
oBIX is a platform independent model designed to promote device
interoperability through web-services [12]. oBIX implements a SOA
with three services used to read and write data, and to perform proce-
dure calls (invoking operations, in oBIX terminology). The reading
service is supported by every object in oBIX, writing is only supported
by writable objects, and invoke is only supported by oBIX operations.
The inputs and outputs of each service's request are specictothetarget
object or operation.
The oBIX information model consists of typed objects, described by
attributes. These objects are identied by their name and a Unied
Resource Locator (URL) used to describe the object. oBIX models can
be extended through object composition and inheritance.
The oBIX specication describes a mapping into XML, where each
object corresponds to exactly one XML element and attributes are rep-
resented as that element's XML attribute. The oBIX specication also de-
nes default objects, which correspond to the XML's primitive element
types such as string, real and Boolean. Some primitive elements have
additional attributes such as minimum and maximum values, units
and precision. There is no provision for devices, zones, groups or con-
trollers in oBIX's specication, as these concepts must be manually de-
ned. oBIX denes history records, events, and alarms services.
The history record service consists of an interface that when imple-
mented by any oBIX object, turns this object into a historical (traceable)
object whose attributes will be stored. This interface exposes properties
such as the maximum number of history recordsto maintain for an ob-
ject, and the timestamps of the rst and last records, among others. To
manage events, oBIX provides a watch object, that implements a cache
for storing events where clients can register several object attributes
whose changes are to be tracked by the watch object every time they
happen. Alarms are objects capable of generating events when some
conditions are met. These conditions usually consist of some object's at-
tribute whose value just went out of its dened bounds (for example, an
object with an attribute called temperaturewhose bounds are 0 and
70, in which its current value is less than 0 or greater than 70). Alarms
have to be associated to watch objects in order to keep track of recent
alarms and send them to the client each time it polls the server. oBIX
species services to query, watch, and acknowledge alarms.
5. Discussion
The previous sections analyze the main BA technology standards
aiming at understanding the extent to which their information models
cover BAS concepts and functionality. Tables 2, and 3 summarize the
analysis made concerning these technologies organized in terms of
functionality coverage of the ofcial standards specications.
It becomes clear that no single BA solution specication provides all
the functionality prescribed in the international reference standards ISO
16484-3 [25] and EN 15232 [26]although BACnet comes close to full
coverage of functionality. A direct consequence of this fact is that, to
get all the desired functionality in a complex infrastructure, more than
one technology is required and the integration of distinct technologies
can easily become a very complex undertaking [27,39].
BAS technologies have several concepts in common (such as
Datapoints, Groups and Zones), however they are dened and imple-
mented differently. For example, depending on the technology, Zones
can be represented through address-groups or objects listing all the
devices in a given physical area. Despite the complexity, integrating dis-
tinct technologies is possible to certain extent. For this reason, several
solutions based on gateways have been developed and deployed.
OPC servers,
9P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
A noteworthy remark is that BA technologies such as LonWorks,
BACnet, ZigBee and KNX have been designed to see their functionality
extended by the use of specic additions, suchas adding task scheduling
and alarm notication capabilities through programmable devices (see
for example, [45, p. 55,56]).Inpractice,however,manufacturers'de-
vices can only interoperate if they implement their extensions having
the same guidelines into account, which is not always possible due to
the limitations of the current standards for covering the needs of a
BAS. Therefore, it is often the case that these devices use custom-made
proprietary extensions that severely impair interoperability since they
are not partof the standard specication. One example is theimplemen-
tation of the proprietary TAC's network variables over the LonTalk pro-
tocol [66], which consists of a proprietary custom extension to the
original LonWorks specication.
The BA community has then pursued a solution for the problem of
interoperability at a higher level of abstraction. Service Management
Frameworks have thus emerged as integration solutions. As it can be
grasped from Table 3, they do not provide a common domain represen-
tation containing all the required concepts. OPC, BACnet/WS and oBIX
were designed to target interoperability between systems by dening
a common domain model and a service abstraction layer, but they still
miss somebasic functionality. As a result some concepts are not be map-
pable and thus cannot be interoperated.
Nowadays, interoperability is being put forward as the main chal-
lenge not only for BA but also for IoT technologies [67,2224].Much
like in BAS, two levels of interoperability are distinguished in IoT appli-
cations: technical and semantic interoperability [68].Technical interop-
erability concerns with the translation of messages from one protocol
to another, which is usually performed by the so called network gate-
ways. In contrast, semantic interoperability relates to how top-level con-
cepts from different technologies are interchanged, understood and
processed. The upsurge of interest in the IoT has created a profusion of
new device manufacturers which, develop their proprietary solutions
resulting in increased heterogeneityin the sense that each IoT device
Table 2
Mappingof how the analyzed technologiessupport the standardapplication concepts. Eachrow describes how a given technology implements each of theapplicational concepts (accord-
ing to its ofcial specication).
Technologies Functionality
Grouping/zoning Event notication Alarm notication Historical data access Scheduling Scenarios
BACnet Group communication
objects [10, p. 245]
Notication object
type [10, p. 248,249]
Event object type and
services for alarm notication
[10, p. 243,244,254]
Provides trend log object
as a standard object [2]
Calendar and
a Schedule
object types
p. 241,250]
Command objects may be used
to emulate the scenario concept
KNX Group communication type
[40, Section 4.2, 4.5]
Datapoint updates
are usually
throughout the
network [3]
N.A. N.A. N.A. Can be implemented by
different Datapoint Types
related to Scenes (e.g.
DPT_SceneControl) [41,
Section 4.19]
LonWorks Domains and subnets
enable the creation of
groups and zones [48,
Chapter 3]
Provides SNVTs to
handle events [42]
Provides SNVTs to model
alarms [42]
N.A. Provides an
events [42]
Provides SNVTs to manage
scenarios [42]
ZigBee Network group addresses
and clusters are used to
manage groups [47,
Chapter 3.6] [6]
Reports events using
a specic command
[6, Section 3.4.9]
The Alarms cluster can be
used for sending and
congure alarm notications
[47, Chapter 3.11]
N.A. N.A. Scenes cluster enables setting
up and recalling scenarios [47,
Chapter 3.7]
BACnet/WS Devices can be logically
grouped using the model's
hierarchy [49]
Provides services to
subscribe to event
notications [49]
Provides services to subscribe
to alarm notications [49]
Historical data can be
requested using the
method [49,
Section N.12.9]
N.A. N.A.
OPC UA Although OPC does not
dene the concept of
grouping, objects may be
used to aggregate other
objects [50, p. 75]
Monitored Items
offer ways to
subscribe to event
notications [51,
Section 5.12]
Denes an Information Model
for Conditions and Alarms
with acknowledgment
capabilities [52, Chapter 4]
OPC tracks changes in
variable attribute's
values and in the
system's address space
[53, Section 2.11]
N.A. N.A.
oBIX oBIX objects may aggregate
and reference other objects
[12, Chapter 8]
Watch objects
enable a client to
subscribe to objects'
state updates [12,
Chapter 11]
Supports the denition of
alarms with
acknowledgment. Alarms
have to be associated to
watch objects [12,
Chapter 14]
Traceable objects have
attributes which are
stored by the history
record service [12,
Chapter 13]
N.A. N.A.
Table 3
Comparison of the coverage of functional aspects by the studied technologies. Legend: low or no support medium or partial support high or full support.
Functionality Building automation technologies Service frameworks
BACnet KNX LonWorks ZigBee BACnet/WS OPC UA oBIX
Grouping/zoning ●● ◐◐
Event notication ●● ●●
Alarm notication ●○ ●●
Historical data access ●○ ● ●
Scheduling ●○ ○ ○
Scenarios ◐● ○ ○
10 P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
communicates using its own proprietary protocol
. Overcoming
heterogeneity seems to be a moving target.
6. Conclusions
This article systematizes fundamental aspects of BAS, contributing to
a common understanding of fundamental building automation con-
cepts aligned with the well known standards ISO 16484-3 and EN
15232. Using these standards as guidelines this work highlights the
scope of the functionality that should be expected from the typical BAS.
Another contribution of this work is the assessment of the industry's
standard building automation technologies in terms of functional re-
quirements employing a uniform terminology. Moreover, the study
also provides a detailed mapping of features between existing technol-
ogies, according to their ofcial specications, and identies their func-
tionality gaps. It becomes clear that no single technology is able to cover
all the functionality expected from a BAS, thus requiring posterior, cus-
tom made, feature developmentsa state of affairs that, presumably, is
among the main causes of heterogeneity in building automation.
Despite the fact that the BA heterogeneity problem is amply recog-
nized in the literature, its extent has never been characterized against
the standards currently in effect. The impact of comparing solutions
with respect to functionalities according to literature standards is thus
far reaching. On the one hand, this study sets the stage for a better un-
derstanding of the features and limitations of BA technologies. On the
other hand, our systematization of exposed functionality also equips in-
tegrators, developers and manufacturers with vendor-independent
knowledge of requirements for BAS technology, easing the task of un-
derstanding and integrating different solutions.
Overall, no solution exists that is capable of providing the fullbreath
of BA functionality. In the meanwhile, a profusion of ad-hoc solutions
and technology standards that compete to be the lingua franca keep
arising in the IoT.
The work of INESC-ID authors was supported by national funds
through FCT (Fundação para a Ciência e Tecnologia), with references
UID/CEC/50021/2013 and EXCL/EEI-ESS/0257/2012 (DataStorm).Ac-
cess to automation technologies was facilitated by IST in the scope of the
SMARTCAMPUS EU project. The work of TU Vienna was partially carried
out in the context of research regarding IEA-EBC Annex 58 (supported
by Austrian Research Promotion Agency under the project number
P- 843156).
[1] M. Brambley, D. Hansen, P. Haves, D. Holmberg, S. McDonald, K. Roth, et al., Ad-
vanced sensors and controls for building applications: market assessment and po-
tential R&D pathways, PNNL-15149, Technical report, Prepared for the U.S.
Department of Energy by Pacic Northwest National Laboratory2005.
[2] ISO 16484-5, Building automation and control systems (BACS) Part 5: Data com-
munication protocols, 2014.
[3] ISO/IEC 14543-3-1, Information Technology Home Electronic Systems (HES)
Architecture Part 3-1: Communication layers Application layer for network
based control of HES Class 1, 2006.
[4] ISO/IEC 14908-1, Information Technology Control Network Protocol Part 1,
[5] MODBUS, Application Protocol Specication V1.1b32012.
[6] ZigBee Alliance, Inc., ZigBee Specication, 2008.
[7] IEEE 802.15.4, Standard for Local and Metropolitan Area Networks, 2011.
[8] EnOcean GmbH, EnOcean Serial Protocol 3 (ESP3), 2014.
[9] ISO/IEC 145433-10, Information Technology Home Electronic Systems (HES)
Part 310: Wireless Short-Packet (WSP), 2012.
[10] H. Merz, T. Hansemann, C. Hübner, J. Backer, V. Moser, L. Greefe, Building Automa-
tion: Communication systems with EIB/KNX, LON and BACnet (Signalsand Commu-
nication Technology), Springer, 2009.
[11] W. Granzer, W. Kastner, Information modeling in heterogeneous building automa-
tion systems, Proceedings of the 9th IEEE International Workshop on Factory Com-
munication Systems, 2012.
[12] T. Considine, B. Frank, OBIX Version 1.1 Committee Specication Draft 01, Public
Review Draft 01, Technical report, OASIS Open Building Information Exchange
[13] ISO 16484-2, Building automation and control systems (BACS) Part 2: Hardware,
[14] G. Clarke, D. Reynders,Practical modern SCADA protocols: DNP3, 60870.5and relat-
ed systems. Newnes, 2004.
[15] F. Wu, K. Moslehi, A. Bose, Power system control centers: Past, present, and future,
J Proc IEEE 93 (2005) 18901908.
[16] S. Mackay, J. Park, E. Wright, Practical Data Communications for Instrumentation
and Controls, Else vier, 2003.
[17] I. Fovino, A. Carcano, M. Masera, A secure and survivable architecture forSCADA sys-
tems, Proceedings of the 2nd International Conference on Dependability, 2009.
[18] K.A. Stouffer, J.A. Falco, K.A. Scarfone, SP 800-82. Guide to IndustrialControl Systems
(ICS) Security: Supervisory Control and Data Acquisition (SCADA) systems, Distrib-
uted Control Systems (DCS), and other control system congurations such as Pro-
grammable Logic Controllers (PLC), Te chnical report, National Institute of
Standards & Technology, 2011.
[19] G. Zecevic, Web based interface to SCADA system, Proceedings of the International
Conference on Power System Technology1998.
[20] J. Lahti, A. Shamsuzzoha, T. Kankaanpaa,Web-based technologies in power plant au-
tomation and SCADA systems: a review and evaluation, Proceedings of the IEEE In-
ternational Conference on Control System, Computing and Engineering, 2011.
[21] G. Björkman, T. Sommestad, H. Hadeli, K. Zhu, M. Chenine, SCADA system architec-
tures, Technical report, European Community: 7th Framework Programme, 2010.
[22] J.P. Thomesse, Fieldbuses and interoperability, Control Eng Pract Vol. 7 (1) (1999)
[23] E. Finch, Is IP everywhere the way ahead for building automation? Facilities Vol. 19
(11/12) (2001) 396403.
[24] Armin Veichtlbauer, Thomas Pfeiffenberger, U.S., Generic control architecture for
heterogeneous buildingautomation applications,SENSORCOMM 2012:The Sixth In-
ternational Conference on Sensor Technologies and Applications 2012, pp. 148153.
[25] ISO 16484-3, Building automation and control systems (BACS) Part 3: Functions,
[26] BSI: EN 15232, Energy performance of buildings Impact of Building Automation
Control and Building Management, Technical report, RHE/16, 2012.
[27] A. Fernbach, W. Granzer, W. Kastner, Interoperability at the management level of
building automation systems: a case study for BACnet and OPC UA, Proceedings of
the IEEE 16th Conference on Emerging Technologies Factory Automation (ETFA), 2011.
[28] P. Pallinger, L. Kovács, Ili: A framework for implementing smart spaces, ERCIM
[29] J.P. Thomesse, Fieldbus technology in industrial automation, J Proc IEEE 93 (2005)
[30] D. Dietrich, T. Sauter, Evolution potentials for eldbus systems, IEEE International
Workshop on Factory Communication Systems, 2000.
[31] M. Hawke,Introductionto eldbus,Technical report, MooreIndustries-International
Inc., 2006
[32] IEC 611313, Programmable controllers Part 3, 2013.
[33] IEC 614991, Function blocks Part 1: Architecture, 2012.
[34] J. Sousa, R. Babuška, H. Verbruggen, Fuzzy predictive control applied to an air-
conditioning systems, Control Eng Pract 5 (1997) 13951406.
[35] D.P. Bovet, M. Cesati, Understanding the Linux Kernel, O'Reilly, 2006.
[36] E. Warriach, E. Kaldeli, J. Bresser, A. Lazovik, M. Aiello, Heterogeneous device discov-
ery framework for the smart homes, Proceedings of the IEEE GCC Conference and
Exhibition, 2011.
[37] Echelon Corporation, LONMARK Application Layer Interoperability Guidelines, 2001.
[38] S. Ramos, J.M.M. Duarte, J. Soares, Z. Vale, F.J. Duarte, Typical load proles in the
smart grid conte xt; a clustering methods comparison, Proceedings of the IEEE
Power and Energy Society General Meeting, 2012.
[39] M. Neugschwandtner, G. Neugschwandtner, W. Kastner, Web Services in Building
Automation: Mapping KNX to oBIX, Proceedings of the 5th IEEE International Con-
ference on Industrial Informatics, 2007.
[40] Konnex Association, KNX System Specications, 2009.
[41] KNX Association: KNX Advanced Course: Interworking. (Home and Building Man-
agement Systems).
[42] Echelon Corporation, LONMARK SNVT Master List, 2002.
[43] Echelon Corporation, Functional Prole: Switch, 1997.
[44] Echelon Corporation, Functional Prole: Lamp Actuator, 1997.
[45] Echelon Corporation, Introduction to the LONWORKS System, 1999.
[46] R. Faludi, Building Wireless Sensor Networks with ZigBee, XBee, Arduino, and Pro-
cessing, O'Reilly Media, 2011.
[47] ZigBee Alliance, ZigBee Cluster Library Specication, 2008.
[48] Echelon Corporation, LonTalk Protocol Specication, 1999.
[49] ASHRAE American Society of Heating, Refrigerating and Air-Conditioning Engi-
neers, BACnet A Data Communication Protocol for Building Automation and Control
Networks (Standard 135-2004 ANSI Approved), 2004.
[50] OPC Foundation, OPC UA Part 3 Address Space Model 1.01 Specication, 2009.
[51] OPC Foundation, OPC UA Part 4 Services 12.01 Specications, 2009.
[52] OPC Foundation, OPC UA Part 9 Alarms and Conditions 1.00, 2010.
[53] W. Mahnke, S.H. Leitner, M. Damm, OPC Unied Architecture, Springer, 2009.
Internet of Things Protocols & Standards:
IoT in Protocol War:
11P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
[54] David M. Schwenk, Stephen J. Briggs, D.M.U., J.Bush, Development of anopen build-
ing automation system specication based on ANSI/ashrae 135-2004 (BACnet com-
munications protocol), Technical report, US Army Corps of Engineers, 2007.
[55] Chipkin Automation Systems, BACnet: The Schedule Object, http://www.chipkin.
com/bacnet-the-schedule-object/2007 [Online; accessed 14-July-2014].
[56] INSTEON, Insteon Whitepaper: The Details, V2.0, 2013.
[57] MODBUS IDA, Modbus Application Protocol Specication, V1.1b, 2006.
[58] Zensys A/S, Z-Wave Protocol Overview, V2.0, 2006.
[59] F. Jammes, H. Smit, Service-oriented paradigms in industrial automation, J IEEE
Trans Ind Inf 1 (2005) 6270.
[60] O. Hersent, D. Boswarthick, O. Elloumi, The Internet of Things: Key Applications and
Protocols, 2nd Ed Wiley, 2012.
[61] ASHRAE American Society of Heating, Refrigerating and Air-Conditioning Engi-
neers, Proposed Addendum ar to Standard 135-2010, BACnet A Data Communica-
tion Protocol for Building Automation and Control Networks, 2010.
[62] M. Neugschwandtner, G. Neugschwandtner, W. Kastner, Web services in building
automation: Mapping KNX to BACnet/ws, Proceedings of the 5th IEEE International
Conference on Industrial Informatics, 2007.
[63] OPC Foundation, OPC UA Part 1 Overview and Concepts 1.01 Specications, 2009.
[64] OPC Foundation, OPC UA Part 5 Information Model 1.01 Specications, 2009.
[65] A. Maka, R. Cupek, J. Rosner, OPC UA object oriented model for public transportation
system, Proceedings ofthe FifthUKSim European Symposium on Computer Model-
ing and Simulation, 2011.
[66] T.A.C. Vista, TAC Xenta Network Guide, 2001.
[67] P. Desai, A. Sheth, P. Anantharam, Semantic gateway as a service architecture for iot
interoperability, Mobile Services (MS), 2015 IEEE International Conference on 2015,
pp. 313319.
[68] IERC AC4, IoT Semantic Interoperability: Research Challenges, Best Practices,
Solutions and Next Steps, 2014.
12 P. Domingues et al. / Computer Standards & Interfaces 45 (2016) 112
... Another benefit is the simplification of signal conversion and transmission due to radio-based communication and direct connection. For several years, building automation systems (BAS) have faced interoperability issues due to the variety of existing communication standards [6], requiring gateways (GWs) to translate between different communication interfaces [7]. On the other hand, besides the field bus architectures, e.g., KNX, Modbus, BACnet, DALI, M-Bus, etc., the underlying field devices such as temperature probes or simple valve actuators operate with analog signals [6]. ...
... For several years, building automation systems (BAS) have faced interoperability issues due to the variety of existing communication standards [6], requiring gateways (GWs) to translate between different communication interfaces [7]. On the other hand, besides the field bus architectures, e.g., KNX, Modbus, BACnet, DALI, M-Bus, etc., the underlying field devices such as temperature probes or simple valve actuators operate with analog signals [6]. From an objective point of view, integrating IoT connectivity on an existing product's printed circuit board (PCB)-e.g., devices such as volume flow controllers, valve actuators, hydraulic pumps, room control units, etc.-would be the most-efficient option in terms of cost and resources, but requires the adaptation of product lines, and vendors would often couple this with their own services and without an option to customize the solution. ...
Full-text available
Due to its potential benefits in data transparency, maintenance, and optimization of operation, the Internet of Things (IoT) has recently emerged in the building automation system (BAS) domain. However, while various IoT devices have been developed, the integration into BAS remains a challenging task due to the variety of conventional interfaces used in existing BAS. From an objective point of view, integrating IoT connectivity on existing devices’ printed circuit boards (PCBs) would be the most efficient option in terms of cost and resources, but requires adaptation of product lines, and vendors would often couple this with their own services and without an option for customization. By contrast, the majority of research activities focus on developing alternative or additional measurement systems, rather than connecting with legacy system components. Furthermore, most research applications cover very simple and individual use-cases with a do-it-yourself character and limited applicability in industrial applications. In this study, we present a scalable, industrial-like embedded solution to connect to common interfaces in BAS applications and share all the hardware and software design as an open-source platform for public use, customization, and further enhancement. Moreover, a thorough measurement performance analysis was conducted, suggesting an acceptable trade-off among accuracy, flexibility, and costs, e.g., achieving a performance increase by over 75 and a cost reduction by roughly 34 compared to a previous design.
... Building automation systems themselves represent a potential solution to reduce energy consumption by controlling the HVAC system during building operation, enabling monitoring and maintenance, and thereby also providing user comfort. The development of building automation technologies is vendor-driven, which in practice often leads to integration problems due to inconsistent product standards and protocols (Domingues et al., 2016). ...
Full-text available
In view of the required energy savings in the building sector, there is an urgent need for innovative and sustainable solutions to increase the performance of building envelopes. Adaptive façades can make an important contribution, whereby passive low-tech strategies and active high-tech solutions are apparently incompatible. In current digitalization, new technologies and methods for the implementation of adaptive façades emerge in the framework of Cyber-Physical Systems. The investigation follows the research question: How can active and passive approaches of adaptive façades be mediated and what potential do Cyber-Physical Systems have for the implementation of hybrid solution approaches in the future? The article presents a comparative case study of the two research projects ADAPTEX and PRÄKLIMA as examples of passive and active adaptation strategies in the façade industry. In this context, the potential for further research of Cyber-Physical Systems in the application domain of adaptive façades as a catalyst for high-performance and multifunctional solutions, and as a mediator between both strategies, is highlighted. The main findings are the potential application of cyber-physical system technologies to the design and monitoring of passive adaptive façade solutions, as well as the possible integration of passively conceptualized components into active overall systems.
... Many IT companies use their self-defined standards to produce smart devices used in SHSs, with the result that the interoperability and interconnection of different elements in SHSs cannot be easily achieved [35]. Domingues et al. [36] investigated the primary technical specifications in building automation (BA) and believed that no existing method could perfectly overcome the problem of heterogeneity. High fragmentation hinders the interoperability between devices and increases the complexity and the cost of service deployment. ...
Full-text available
The rapid development and wide application of the Internet of Things (IoT) and sensor technologies have produced good opportunities for the development of IoT-based smart home systems (SHSs). However, during the rapid market expansion of SHSs, security challenges associated with SHSs have become a primary concern of people because they are so closely related to people’s daily lives. These security problems may damage information assets and pose a serious threat to people’s health and life. This study investigates security issues in SHSs and provides a comprehensive overview of research to date. In this review, after analyzing the existing definition and concept of SHSs proposed by authoritative encyclopedias and academic literature, we propose a more accurate, elaborated definition of SHSs, analyze their architecture, extract six natural and contextual features, and summarize spears (cyber-attack means) vs. shields (countermeasures) in detail in the context of SHSs. Then, the security frameworks and evaluation technologies in SHSs are discussed. Different scenarios for technology integration and the practical research results in SHSs, such as blockchain, cloud computing, Internet of Vehicles, and AI are presented meticulously. After that, two special issues related to security are discussed. We believe that future research on SHS security should focus on four aspects: the unification of architecture, resource limitation, fragmentation, and code and firmware security. In addition, research on SHS security should be given priority over its commercialization process.
... As a bridge, the communication network realizes the transmission of data from the physical world to the Internet and becomes an important guarantee for improving data quality [1]. Many previous studies have explored the application of communication technology in the field of building monitoring and made great contributions [2][3][4][5][6][7][8][9]. These monitoring systems use cable communication and wireless communication technology, and the monitoring scenarios include schools, hospitals, laboratories and residences. ...
Full-text available
ZigBee and LoRa are communication technologies widely used in the application of the Internet of things (IoT), especially in the field of smart building environmental monitoring. The main purpose of this study is to compare and analyze the transmission performance of ZigBee and LoRa wireless communication networks in the building. Through two indicators of packet loss rate (PLR) and round-trip time (RTT), this paper discusses in detail the transmission performance of ZigBee and LoRa technologies in whole buildings under the same working conditions. We set up three experimental scenarios of line-of-sight, horizontal and vertical to evaluate the communication performance of these two networks by changing the baud rate and packet length, and cost and power consumption were considered. Experiments have shown that LoRa networks outperform ZigBee networks in most cases and are the best choice for building communication networks. The experimental results provide basic data support and engineering reference for the application of these two technologies in buildings, especially for the deployment of communication networks throughout buildings. The innovation and contribution of this paper are to discuss the effect of packet length, baud rate, distance, and different locations within a building on the performance of ZigBee and LoRa transmissions, using RTT and PLR as metrics through three experimental scenarios.
... In residential buildings, most end-uses are controlled manually by occupants (e.g., lighting) [109] or by simple devices (e.g., thermostats) [140]. In large commercial buildings, more complex equipment (e.g., large HVAC systems) is controlled by building automation systems (BAS) [141] that are installed to automate multiple building services, such as thermal conditioning, lighting, and security systems [142]. ...
This paper seeks to address ten questions that explore the burgeoning field of Human-Building Interaction (HBI), an interdisciplinary field that represents the next frontier in convergent research and innovation to enable the dynamic interplay of human and building interactional intelligence. The field of HBI builds on several existing efforts in historically separate research fields/communities and aims to understand how buildings affect human outcomes and experiences, as well as how humans interact with, adapt to, and affect the built environment and its systems, to support buildings that can learn, enable adaptation, and evolve at different scales to improve the quality-of-life of its users while optimizing resource usage and service availability. Questions were developed by a diverse group of researchers with backgrounds in design, engineering, computer science, social science, and health science. Answers to these questions draw conclusions from what has been achieved to date as reported in the available literature and establish a foundation for future HBI research. This paper aims to encourage interdisciplinary collaborations in HBI research to change the way people interact with and perceive technology within the context of buildings and inform the design, construction, and operation of next-generation, intelligent built environments. In doing so, HBI research can realize a myriad of benefits for human users, including improved productivity, health, cognition, convenience, and comfort, all of which are essential to societal well-being.
... BAS provides several features: controlling lights, climate, HVAC, safety and security, comfort, energysaving, and entertainment. Mainly, BAS is capable of orchestrating the use of these features through the use of customizable logic [5,6]. This customizable logic is typically represented as if-this-then-that (IFTTT), or event-condition-action (ECA) rules [7][8][9], and it corresponds to users' behavior s (users' contexts). ...
Full-text available
Building automation (BA) strives to control interconnected physical devices by using software management systems on which end-users can personalize their environmental preferences. In large buildings, among the leading causes of IoT apps conflict are the shareable locations/devices amongst residents and the diversity of their preferences. Addressing such conflicts and ensuring the safety of residents are vital requirements in building automation systems. Consequently, the potential of IoT safety and correctness frameworks relies on supporting conflict detection. This paper provides a model for detecting and resolving IoT automation conflicts. These conflicts can result from shareable locations or devices. The proposed model is evaluated using a benchmark dataset and refined scenarios collected from competitor-related works (80+ IoT apps with 117+ rules). The proposed model surpasses state-of-the-art models by covering more conflicts (joint behavior conflict); moreover, it does not require events' chain between IoT apps like other models, one more advantage is that the proposed model uses a filtering process in conflict detection which leads to small detection run-time. Thereby, our proposed model can maximize the correctness and safety of building automation systems.
... To overcome this challenge, smart ways of data processing are required. In Ref. [20], the authors provided a more detailed overview by discussing the fundamental concepts, features, standards, and requirements of building automation systems. Different building automation technologies (e.g., BACnet, KNX, and ZigBee) were analyzed and compared according to the coverage of the functional aspects (i.e., grouping, event notification, alarm notification, historical data access, scheduling, and scenarios). ...
Full-text available
Building automation is one of the most popular trends in the 21st century, as it provides buildings with modern and luxurious touches. Furthermore, voice-controlled automation systems are very convenient for the current fast-paced life style as people need to quickly, efficiently, and safely control everything around them. The goal of this article is to provide a skeleton for implementing voice control to a building automation system. The article also presents and evaluates a use case of the proposed skeleton integrated with a KNX-based office automation system. Through the integrated system, lights and blinds are controlled and sensors are polled using voice commands from an authorized personal. This article serves as an educational reference for engineering students interested in applying authorized voice control capability to automation systems.
... The Building Automation System (BAS) is a system installed in buildings that is useful for controlling and monitoring building services and is responsible for heating, cooling, ventilation, air conditioning, lighting, life safety, security systems, and others [3]. BAS is intended for automatic control of all aspects of utility, energy, security, and safety of the building. ...
Full-text available
Fires and gas leaks are events that still occur frequently. This incident is usually caused by various factors including leakage of LPG gas cylinders, cigarette butts that are disposed of carelessly, short circuits of electric current and so on. Generally, fires and gas leaks can only be detected if the fire has already grown or a lot of smoke comes out of the building. Therefore, a monitoring system for detecting dangerous gases and fires in buildings based on the Internet of Things was created that can monitor the condition of the building through a website as well as send notifications to the Telegram application on smartphones. The detection system implemented uses a flame sensor as a fire detector, an MQ-2 gas sensor as a detector of hazardous gases (CO, CO2, and CH4), and NodeMCU as a module to transmit data. The system will work continuously in real time, if gas is detected that exceeds the threshold or a fire is detected, the system will send a notification to Telegram and the website will display the value and status of the sensor and a map of the area where the fire or gas leak occurred. The results of the detection system created to be able to provide solutions so that cases of fire and gas leaks can be handled early by detecting signs of fire or gas leaks and sending the information to users via the website and notifications.
Full-text available
Quality of data warehouse is very crucial for managerial strategic decisions. Multidimensional data modeling has been accepted as a basis for data warehouse, thus data model quality has a great impact on overall quality of data warehouse. Metrics act as a tool to measure the quality of data warehouse model. Various authors have proposed metrics to assess the quality attributes of conceptual data models for data warehouse such as understandability, maintainability etc. All the related research work inspires us to investigate the metrics proposed to measure data warehouse data model quality, the various quality factors assessed and to provide a ground work for research advancement in this field. A total of 22 studies were selected and analyzed to identify the various validation techniques used to prove usage and practical utility of metrics and the quality factors measured by these metrics. Opportunities for future work lie in the gaps that were found in the validation of the metrics and the lack of quality factors measured.
Conference Paper
The Internet of Things (IoT) is set to occupy a substantial component of future Internet. The IoT connects sensors and devices that record physical observations to applications and services of the Internet[1]. As a successor to technologies such as RFID and Wireless Sensor Networks (WSN), the IoT has stumbled into vertical silos of proprietary systems, providing little or no interoperability with similar systems. As the IoT represents future state of the Internet, an intelligent and scalable architecture is required to provide connectivity between these silos, enabling discovery of physical sensors and interpretation of messages between the things. This paper proposes a gateway and Semantic Web enabled IoT architecture to provide interoperability between systems, which utilizes established communication and data standards. The Semantic Gateway as Service (SGS) allows translation between messaging protocols such as XMPP, CoAP and MQTT via a multi-protocol proxy architecture. Utilization of broadly accepted specifications such as W3Cs Semantic Sensor Network (SSN) ontology for semantic annotations of sensor data provide semantic interoperability between messages and support semantic reasoning to obtain higher-level actionable knowledge from low-level sensor data.
An all-in-one reference to the major Home Area Networking, Building Automation and AMI protocols, including 802.15.4 over radio or PLC, 6LowPAN/RPL, ZigBee 1.0 and Smart Energy 2.0, Zwave, LON, BACNet, KNX, ModBus, mBus, C.12 and DLMS/COSEM, and the new ETSI M2M system level standard. In-depth coverage of Smart-grid and EV charging use cases. This book describes the Home Area Networking, Building Automation and AMI protocols and their evolution towards open protocols based on IP such as 6LowPAN and ETSI M2M. The authors discuss the approach taken by service providers to interconnect the protocols and solve the challenge of massive scalability of machine-to-machine communication for mission-critical applications, based on the next generation machine-to-machine ETSI M2M architecture. The authors demonstrate, using the example of the smartgrid use case, how the next generation utilities, by interconnecting and activating our physical environment, will be able to deliver more energy (notably for electric vehicles) with less impact on our natural resources. Key Features: Offers a comprehensive overview of major existing M2M and AMI protocols. Covers the system aspects of large scale M2M and smart grid applications. Focuses on system level architecture, interworking, and nationwide use cases. Explores recent emerging technologies: 6LowPAN, ZigBee SE 2.0 and ETSI M2M, and for existing technologies covers recent developments related to interworking. Relates ZigBee to the issue of smartgrid, in the more general context of carrier grade M2M applications. Illustrates the benefits of the smartgrid concept based on real examples, including business cases. This book will be a valuable guide for project managers working on smartgrid, M2M, telecommunications and utility projects, system engineers and developers, networking companies, and home automation companies. It will also be of use to senior academic researchers, students, and policy makers and regulators.
SCADA (Supervisory Control and Data Acquisition) systems are at the heart of the modern industrial enterprise ranging from mining plants, water and electrical utility installations to oil and gas plants. In a market that is crowded with high-level monographs and reference guides, more practical information for professional engineers is required. This book covers the essentials of SCADA communication systems focussing on DNP3, the IEC 60870.5 standard and other new developments in this area. It commences with a brief review of the fundamentals of SCADA systems' hardware, software and the communications systems (such as RS-232, RS-485, Ethernet and TCP/IP) that connect the SCADA Modules together. A solid review is then done on the DNP3 and IEC 60870.5 protocols where its features, message structure, practical benefits and applications are discussed. This book provides you with the knowledge to design your next SCADA system more effectively with a focus on using the latest communications technologies available.
Modbus, developed by Modicon, is a means for communicating with many devices over a single twisted-pair wire. Modbus is a master-slave system, where the master communicates with one or multiple slaves. The three most common versions used today are Modbus ASCII, Modbus RTU, and Modbus TCP. In Modbus ASCII, all messages are coded in hexadecimal, using four-bit ASCII characters. In Modbus RTU, data is coded in binary and requires only one communication byte per data byte. Modbus/TCP is simply Modbus over Ethernet, in which IP addresses are used and the Modbus data is simply encapsulated inside a TCP/IP packet. To communicate with a slave device, the master sends a message containing device address, function code, and data, and error check. The Modbus specification dictates how data is retrieved and what type of data can be retrieved. With a HART interface module that supports Modbus RTU, all the HART data can be brought to the control system simply and cost effectively. Modbus via wireless is transparent to the control system or host, and the slave.
Conference Paper
The availability of reference models for data warehouses lowers the obstacles that inhibit small and medium-sized enterprises (SMEs) from using business intelligence technology. Service providers may offer to companies a set of pre-configured reference models for various industries. Modelers may then customize the chosen reference model, tailoring the model to the specific needs of the individual company. This customization may consist of additions, omissions, and modifications with respect to the reference model. In this paper, we propose a metamodel and customization approach for reference multidimensional models. We emphasize simplicity and understandability in order to facilitate the introduction of business intelligence solutions in SMEs. Furthermore, we specifically address the explicit modeling of key performance indicators and their calculation rules as well as the definition of reference data marts for report building.