Wireless sensor networks in building automation

systems

Erik Pramsten, Daniel Roberthson

October 4, 2009
Abstract

Tiny devices communicating wirelessly, also called wireless sensor networks, have
developed rapidly the last few years. As the devices have been more energy ef-
cient and more reliable new application areas have become interesting, one
of them is building automation systems. Retrotting and additional tempera-
ture measurements are two interesting application areas to make the building
automation systems more cost and energy ecient.

The aim for the work preformed has been to investigate the possibility of
integrating wireless networks with existing building automation systems using
open and widely used standards. The work process has involved evaluating ex-
isting business automation protocols. Each protocol has then been evaluated
from an energy consumption perspective. The major dierent wireless technolo-
gies have been described in relation to the sensor networks. Finally a proof of
concept implementation has been developed on a wireless sensor network con-
necting to a building automation system. The implementation has been made on
the Contiki operating system, a lightweight operating system for small devices.

The work described in this master thesis shows that the Contiki operation
systems with BACnet can be used to enhance existing building automation sys-
tems with wireless sensor network support. All listed protocols however lacks
functionality for reducing number of messages required for protocol compara-
bility (and reducing power consumption).

Sammanfattning

Små enheter som kommunicerar trådlöst ofta benämnda som sensornätverk har
under senare år utvecklats i hög takt. Nya applikationsområden har blivit intres-
santa allt eftersom enheterna har blivit mer energieektiva och tillförlitliga. Ett
av dessa nya applikationsområden är fastighetsautomation, speciellt vi ombyg-
gnation och utökad temperaturkontroll. Dessa områden är intressanta eftersom
trådlösa sensornätverk kan innebära utökad kontroll och har en låg installation-
skostnad.

Målet med arbetet har varit att undersöka hur väl trådlösa sensornätverk
kan integreras med existerande system för fastigautomation. Metoden för detta
har inkluderat en genomgång av system för fastighetsautomation samt kända
protokoll för detta. Varje protokoll har evaluerats utifrån protokollets kommu-
nikationsmetod och uppskattad energiåtgång. Arbetet innehåller en genomgång
av olika trådlösa nätverksprotokoll och hur de relaterar till sensornätverk. Slut-
ligen har vi utvecklat en testapplikation på enheter anpassade för sensornätverk
och integrerat denna med BACnet ett protokoll för fastighetsautomation.

1
 Arbetet som beskrivs i denna uppsats visar att det går att integrera sys-
tem för fastighetsautomation med trådlösa sensornätverk. Däremot saknar alla
beskrivna protokoll för fastighetsautomation stöd för att minska strömförbrukn-
ing och kommunikation, vilket är en viktig del för implementeringen av större
trådlösa nätverk.

2
Preface

This report is a result of a master thesis work done at the Royal Institute of
Technology (Kungl. Tekniska Högskolan). A special thank to thank Thiemo
Voigt, Joakim Eriksson, Niklas Finne at SICS for their support and the unique
knowledge in wireless sensor networks. The authors would also like thank the
people at Larmia Control for sharing their experience in building automation
systems.

3
Contents
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Introduction 7
1.1 Problem overview and motivation . . . . . . . . . . . . . . . . . . 7
1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Background 9
2.1 Building Automation System . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Building Automation protocols . . . . . . . . . . . . . . . 10
2.1.2 Integration and automation . . . . . . . . . . . . . . . . . 11
2.1.3 Logical Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 Network characteristics . . . . . . . . . . . . . . . . . . . 14
2.1.5 Network Architecture . . . . . . . . . . . . . . . . . . . . 15
2.2 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Wireless Sensor Networks in the wireless spectrum . . . . 16
2.2.2 Wireless network topologies . . . . . . . . . . . . . . . . . 18
2.2.3 Energy management . . . . . . . . . . . . . . . . . . . . . 19
2.2.4 Security in Wireless Sensor Networks . . . . . . . . . . . . 21
2.2.5 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.6 Capacity of WSN . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Building automation systems and wireless sensor networks 25

3.1 Benets of using wireless sensor networks in building automation 25
3.1.1 Wireless sensor networks in building automation today . . 26
3.2 Requirements on building automation protocol . . . . . . . . . . 26
3.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . 27
3.2.2 Technical requirements . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Energy eciency requirements . . . . . . . . . . . . . . . 27
3.2.4 Flexibility requirements . . . . . . . . . . . . . . . . . . . 28
3.2.5 Detailed protocol requirements . . . . . . . . . . . . . . . 28
3.3 Protocol descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 BACnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.3 OPC - OLE for Process Control . . . . . . . . . . . . . . 35
3.3.4 KNX - Konnex . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.5 Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Protocol evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4
4 BACnet 46
4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Internetworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Communication Model . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.1 Message coding . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Design and implementation 58

5.1 System overview and overall goals . . . . . . . . . . . . . . . . . 58
5.2 General constrains . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Architectural strategies . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 System architecture . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5 Detailed design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.6 Operation of the device . . . . . . . . . . . . . . . . . . . . . . . 62

6 Tests and Results 63

6.1 Usability tests and results . . . . . . . . . . . . . . . . . . . . . . 65
6.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.1 BACnet implementation . . . . . . . . . . . . . . . . . . . 67

7 Conclusions and future work 70

7.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

List of gures 71
List of tables 72
Bibliography 73

5
Glossary
APDU Application Layer Protocol Data Unit
ASN.1 Abstract Syntax Notation One
BAS Building Automation System
BACnet Building Automation Control network
BIBB BACnet Interoperability Building Blocks
FFD Full Function Device
COV Change Of Value
CSMA/CA Carrier Sense Multiple Access With Collision Avoidance
HVAC Heating Ventilation and Air Conditioning
MAC Medium Access Layer
NPDU Network Layer Protocol Data Unit
RFD Reduced Function Device
SICS Swedish Institute of Computer Science
EMS Energy Management System
HES Home Electrical System
ICU Intelligent Control Unit
PLC Programmable Logical Control
SCADA Supervisory Control And Data Acquisition
TDMA Time Division Multiple Access Method
RAM Random Access Memory
RFID Radio Frequency Identication
ROM Read Only Memory
WLAN Wireless Local Area Network
Wireless Sensor Network Wireless Sensor Network

6
Chapter 1

Introduction

1.1 Problem overview and motivation

Is it possible to introduce wireless technology into building automation systems?
If so, how can it be done in a standardized way so that the least amount of eort
is needed, both in the wireless sensor network and in the building automation
system?

1.2 Goals
The goal with this master thesis is to investigate if it is possible to make a
successful integration of interconnecting wireless sensor network technology into
building automation systems. In order for the integration to be successful the
solution should be designed and constructed in a standardized way.
The key points with making a standardized integration is that the solution
will t into, and make use of, existing infrastructure; provide data exchange in
a vendor independent way and increase the potential of expanding the solution
to other functional domains such as security, light control and re alarms. The
solution should make use of standardized communication protocols or at least
be able to communicate with standardized communication protocols. The thesis
should end up in a measurable proof of concept design and implementation of
a wireless sensor networking node with building automation capabilities.

1.2.1 Limitations
The primary work of this report has been put to evaluate communication pro-
tocols used within automation, to nd the best suited protocol to use for a test
implementation. Because building automation is such a large area, we have
only taken the parts adoptable to today's sensor networks in consideration, i.e.
gathering of sensor data and limited control functionality.

7
 To build our test implementation we use a wireless sensor network platform
provided by the Swedish Institute of Computer Science (SICS). This platform
contains sensor network nodes, a lightweight operating system and a TCP/IP
communication stack, further described in section 2.3. We have focused our
work on implementing the building automation protocol. The application on
top of this protocol has only been created to provide functionality sucient for
measuring the power consumption.

1.3 Method
We started the work by performing a literature study on building automation
systems and wireless sensor networks. We looked at their history, how they are
used and the technology involved. When the basic characteristics of wireless
sensor networks were discovered, we performed an evaluation to nd the best
suited building automation protocol to use for an implementation. The general
design decisions were made to start the work with a test implementation to
see if it is possible to integrate wireless sensor network technology in building
automation systems. This implementation was tested together with vendor
independent applications and results fetched.

1.4 Outline
The rest of this report is outlined as follows. Chapter 2 will cover some back-
ground to building automation systems (BAS) and wireless sensor networks
(WSN). The following chapter 3 will cover the motivation of using WSN in
BAS, the requirements of the BAS protocols and a description of each evalu-
ated protocol. Chapter 4 will cover the selected protocol in more detail. Chapter
5 will describe our design followed by the implementation. The tests performed
on the implementation and the results from these tests are described in chapter
6. The thesis is concluded with chapter 7, conclusions and future work.

8
Chapter 2

Background

This chapter contains the necessary introduction to building automation systems

and the evolvement over the years to understand where it is now and also the
future trends. The second part of this chapter gives an introduction to wireless
sensor networks, dierent solutions and existing standards. There is also a short
introduction to the Contiki operating system and uIP communication stack.

2.1 Building Automation System

Building Automation Systems is the result of the ambition to create a fore-
seeable system to manage and control buildings. The primary goal of BAS is
to improve the indoor climate and reduce the costs. Heating, ventilation and
air-conditioning (HVAC) systems is what we in general associate with BAS.
To further reduce the costs and increase management and control of buildings;
lighting, safety, security and transportation supervision have been integrated.
A building automation system is a large investment. When looking at the
costs of a building during its lifetime, the construction cost is only one seventh
of the operational cost [1]. The right BAS can save a considerable amount of
money. In addition, BAS provide a climate controlled, safe and secure building.
Traditionally, BAS have been used in large buildings such as schools, hospi-
tals and oces. In the recent years this kind of technology has become available
on the consumer market. These systems are focusing more on comfort appli-
cations, such as remote controlled lighting and blinds. They also have built in
power saving mechanisms that control lighting and other electronic aperture in
the purpose to save energy. The falling prices on this kind of technology and the
increasing prices on energy have also made it more interesting to install such
systems in private homes.

9
2.1.1 Building Automation protocols
Automated buildings have been around for the last century. In the beginning,
HVAC systems were controlled by pneumatics. Electric, analogue electronic cir-
cuits and micro controllers have replaced the pneumatics and evolved the BAS.
In the last 30 years, a lot has happened in the building automation industry,
starting o in the early 1970's with the oil crisis. The sharp increase of the oil
price and the dependence of a few oil producing countries increased the interest
for BAS as a potential energy saver. As a result of this new way of thinking, the
term energy management system (EMS) appeared. The focus now moved from
strictly HVAC, to include energy saving and building management functionality
as well.
Along with the EMS functionality, such as shutdown of HVAC on non oce
hours, supervisory control and data acquisition (SCADA) systems were devel-
oped. A SCADA system is a centralised system that gives an operator the
possibility to monitor and control the equipment from a distance. The constant
monitoring of the equipment made it possible to detect abnormal behaviour and
trigger alarms that indicate the need for repairs or maintenance. This also made
it possible to save logs of system behaviour. The trend logs became a useful
tool for improving the scheduling and control mechanisms.
As an improvement of the centralised systems, manufacturers started to use
microprocessors for controlling in the early 80's. These controllers, called intel-
ligent control units (ICU's), were placed in between of sensors and actuators,
shown in gure 2.1a. The ICU is using the input from sensors to control actu-
ators in a given pattern. This way of system design is still used in other parts
of automation, for example in programmable logical control (PLC) systems. A
number of dierent communication protocols were developed for communication
between a central control unit and the ICU's inside an automation network.

S A S S

S ICU A
A S A
S A
(b)
(a)

S S
S=Sensor
A=Actuator

A S A =Control unit

(c)

Figure 2.1: Point-to-point centralised control (a), centralised bus control (b)
and distributed bus control (eld bus) (c).

Evolvement of BAS lead to the use of bus communication instead of point

10
to point connections, rst with centralised control and later with distributed
control, so called eld buses. With centralised control, shown in gure 2.1b, all
the sensors and actuators connected to the bus are controlled by a control unit.
In distributed control bus systems, gure 2.1c, all system nodes are so called
smart sensors and actuators. The nodes have a built in control unit, which
makes them act without centralised control.
The development of communication protocols and the bus technology was
a big step for BAS. These have improved the BAS in terms of exibility, ex-
tendibility, functionality and eciency [2]. The bus extends throughout the
whole network and is shared between all nodes. The nodes use the bus for
sending and receiving messages. By using a bus, the amount of wiring needed
is reduced substantially compared to point-to-point automation systems. A bus
usually consists of a couple of wires which the nodes are connected to, mean-
while every node has to have wiring similar to the bus directly connected to
the control unit in point-to-point automation. A bus network can be expanded
by adding extra wiring and connecting more nodes to the bus. Smart nodes
increase system stability. The nodes can continue to interact with each other,
measure and control even if some nodes do not work, the overall functionality is
not depending on a few nodes. Malfunctioning of a control unit in a centralised
system is of great inuence of the system functionality. Since there is only one
unit controlling all system functionality, this unit intends to become very com-
plex, which increases the risk of malfunctioning. In smart sensors, the built in
control unit is adjusted to meet the requirements of that particular node and
has therefore a low level of complexity.
The development and adoption of building automation systems is slow com-
pared to other areas, such as the IT branch according to the founder of Larmia
Control [3], one of the building automation system vendors. According to
founder, one reason is the demand of long system life-time, manufacturers and
building owners tend to choose well proven technologies, instead of new techni-
cal innovations. New technologies often have to become international standards
before they are adopted into the building automation area.

2.1.2 Integration and automation

Field bus systems have grown in complexity over the years when combining
dierent measuring and control functionality into one system to save resources.
Despite the fact that more functionality is integrated into the building automa-
tion system, some operations are often left alone. Life safety systems, e.g. re
alarms, are usually built as closed stand alone systems with low complexity to
guarantee operability [1]. The life safety systems can interact with the BAS to
inform about alarms that need actions from BAS as well, e.g. inform about a
re so that elevators can be stopped and evacuated.
To create a less complex system it is important to keep the number of in-
teraction points between the subsystems on minimum in order for a traceable
the control ow. Only information needed to perform the given task of ev-
ery subsystem should be exchanged. Interaction points are chosen, so that the
subsystem can achieve its primary task in an acceptable way even though the

11
connection to other subsystems are cut, e.g. HVAC operations are working on a
oor of a building when connections to other oors and the management station
is lost. When implementing a building automation system, the designer can not
adapt the system to existing requirements only, he also has to make the system
exible in a way that it is possible to add new features in the future. BAS are
long-lived, and hence not being able to adjust the system to new requirements
can decrease the system pay-o.
For automation and control of BAS, both open-loop and closed-loop control
are used. Most parts of the systems can use the simple open-loop control mech-
anism, without any feedback. Open-loops, shown in gure 2.2a, are controlling
on the basis of the input and currant state. A given input, always result in
the same output, e.g. push a light switch and the light is turned on. HVAC
processes are controlled with closed-loops, gure 2.2b, and are the most com-
plex processes in BAS. The control mechanism has to take several factors into
consideration, e.g. temperature, weather conditions, building occupancy and
load [1]. All these factors change over time and can not be exactly predicted.
The changes have to be sent back as feedback to the control mechanism, so it can
be used to calculate new control parameters. The control of indoor climate is
very slow, changes only happened gradually, therefore there are no requirements
for fast response times.

Open−Loop Controller

Setpoint value Result

Controller Process

(a)

Closed−Loop Controller

Setpoint value Result

Controller Process

Feedback
(b)

Figure 2.2: Illustration of the open and closed control loops.

2.1.3 Logical Hierarchy

The Home Electrical Systems (HES) committee merged logical hierarchy pro-
posals from French and American experts into the HES CB model [4]. The
HES CB model divides BAS functionality into three logical layers, descried in
gure 2.3.

Field level The lowest level is called eld level. This is where the interaction
with the physical world takes place. It consists mostly of sensors and actuators.
Environmental data is collected and transformed into a system representation,

12
 Operator
Workstation
Management Management
Level Station

Automation Unit Unit

Level Controller Controller

Field Level Unit

Controller

A S S S A

Figure 2.3: The three logical layers in BAS and functionality associated with
each level.

so it can be processed and sent. Parameters are also controlled by commands

from the system or physical controllers, e.g. light switches. Control elements
can be present on the eld level in fully distributed systems, shown at the left
in gure 2.3.

Automation level The distributed system control elements have tradition-

ally been placed in this level, especially when eld level units don't contain any
intelligence. Automation level units perform automatic control on data gen-
erated by the eld level, as well as setting up logical connections and control
loops. The processing units can also communicate values of interest to others,
between each other, e.g. outdoor temperature. Control units also prepare and
aggregate data needed by the management level.

Management level Information from the whole system is available at the

management level. An interface presents the BAS at an operator workstation for
manual supervision and control. Depending on the implementation, automatic
management, without an operator, is also available. The management level has
access to values at the automation level, including the possibility to modify
parameters, e.g. schedules. Management stations have rules set up for system
behaviour. Alarms are generated if abnormal sensor variations are detected,
such as technical faults and critical values. A management station uses data
gathered from the automation level to discover system trends, among other
things. This data can also be stored for long periods of time and used to
generate statistics and reports.
The amount of available data is increasing higher up in the hierarchy. The
tasks of both the eld level and the automation level are usually managed in
a distributed way. The distribution of these levels provides multiple benets,
such as reduced latency in control loop, avoids single point of failure, reduced

13
risk for bottlenecks to appear and allows the system to work, when subsystems
are out of service because of system failure or maintenance.
It is possible to see a trend where systems are getting a atter hierarchy. The
automation level is fading away, the supervisory control and the data aggrega-
tion is moved to the management level, while the eld level is taking care of
control on the basis of eld level measuring. This change is possible with more
intelligent eld devices. What hierarchy to use is dependent of requirements of
a system, for example, in large BAS the presence of the automation level can
help decreasing the enclosed complexity due to size.

2.1.4 Network characteristics

The key criteria to meet for quality of service in BAS are throughput, timeliness,
dependability and security [1]. Since measuring and control of the indoor climate
is a slow process there is no need of high speed control loops at the eld level.
Also, events from physical controllers rarely happen. Therefore, high loads of
trac occur seldom. However, high trac loads might occur when data used
for management is collected from all over the system to a central workstation.
This data do not have to be presented in real-time at the management level.
Dependability is important, the available data is supposed to be correct. The
network should be able to detect transmission errors, recover from such errors
and failure of other equipment and be able to meet the time requirements.
In most cases, some errors are acceptable. A certain level of fault tolerance
is needed on the eld and automation level, so that a failure of one node will
bring down the whole system. However, in life-safety applications, dependability
has to be guaranteed. Therefore, these systems are often built on stand alone
networks adjusted to the special requirements of the application.
High throughput is however important on the links connecting the automa-
tion level with the management level. Large data blocks are exchanged between
these, e.g. trend logs and data les, and high speed transferring is needed for
acceptable response times. The demand for timeliness is dierent between the
layers. Field and automation level is where the real-time data is exchanged.
With the low trac load on these levels, a possibility of stating an upper bound
of transmission delay is enough for most applications.
To manage large BAS with thousands of units, protocols have to support
dividing of the network into sub networks with appropriate addressing. It should
also be able to handle WAN-connections transparently.
Security has become an important issue lately, with the integration of sen-
sitive functionality, e.g. access control and intrusion alarm systems, and use of
shared media for communication. The security focus is on authentication, what
is going on is not a secret, but the one performing the action has to be eligible.
Remote access connection points have to be secured, because they usually give
access directly to management level functionality. A successful attack can cause
severe damage to the system. When using shared media, such as oce Ethernet
networks, wireless networks or power-line signalling, the network vulnerability
increases. The system has to be protected against congestion caused by other

14
applications and denial-of-service attacks. Wireless networks and power-lines
are easy to get access to without getting noticed, data sent over these media
has to be extra protected.

2.1.5 Network Architecture

The three automation levels, described above, could be translated into a three
level network structure, but that is not appropriate in a lot of cases. Units
can contain functionality from more than one of the layers. More intelligent
eld devices withhold control operations, making a network only for automation
control unnecessary. A three level architecture could also complicate the sharing
of devices between domains, mostly sensors. Also, a two level architecture has
become popular due to the possibility to use cost ecient devices. The lower
level is a control network, operating on the eld and automation level, containing
intelligent nodes communicating on low cost and low speed media with simple
implementations. High data rates are seldom transferred on this level, low
throughput is therefore not an issue, timeliness is more important here. To
handle the high amounts of data on the management level, generated by log le
and real-time monitoring transfers, a high speed network is used on this level.
A gateway is placed between the levels, to let the layers communicate with each
other.
Larger BAS usually consist of several control networks, e.g. one for each
oor of a building. These are connected to a backbone for central supervision
and control, remote maintenance and diagnostics. Traditionally, dedicated net-
works have been used for BAS. In modern buildings, data networks are present,
such networks cannot guarantee quality-of-service, but have high throughput
capacity. These networks can be used for transferring management level data,
where throughput is important and timeliness is not much of an issue.
When using a three level hierarchy, devices can be connected directly to
the controller or through a communication link to the automation layer, where
the application controller is located, shown in gure 2.3. A communication
link can be a router or a gateway. A router is used when the same protocol
and underlying media operates on both levels. The use of routers is preferred to
increase the network integration. Gateways have to be used when the underlying
media or the protocol diers between the connected networks. When translating
between dierent media, the gateway only has to encapsulate the data with new
network specic headers.
Gateways can also relieve pressure from the connected networks, by for exam-
ple performing trend logging. The backbone does not have to handle real-time
issue and it lowers the load of the control network. Gateways can also tunnel
data to another gateway so it do not have to translate messages between dier-
ent protocols, e.g. for remote administration or to send a lot of data on a high
speed link.
The translation between dierent protocols has proven dicult without
transformation software which involves manual conguration and setup. The
protocols might have dierent properties, and therefore some information can

15
not be translated, e.g. time channels. Translations between dierent protocols
are therefore avoided where it is possible.

2.2 Wireless Sensor Network

The term Wireless Sensor Network (WSN) is commonly used to describe low
powered, fault tolerant, embedded sensors with wireless communication capa-
bilities. The devices are usually small in size and limited in terms of energy and
computational power. They may have a sensing capability of either tempera-
ture, motion, pressure, sound or a combination of several sensors. The devices
are also characterized by the low unit price which makes the sensor networks
suitable for large numbers of independent sensing devices or devices located in
harsh environments where failure of a single device is not critical. [5]
Depending on the application of the specic sensor network, the network
architecture and communication method may vary. Most denitions of wireless
sensor networks include device properties such as self organised in multi-hop
networks. One or more of the devices are a sink device or network controller.
The sink device is the connection between the wireless and wired network or
the connection to the physical storage area. [6]

2.2.1 Wireless Sensor Networks in the wireless spectrum

There are a large number of wireless technologies available on the market. This
section describes some of the well known wireless communication standards.
Each standard is optimized for dierent application and some applications may
span over several standards and technologies. This section shortly describes
some of the technologies, where they are suited and how they can be used in a
building automation system. The dierent standards and their technical data
can be seen in table 2.2.1. [7]

WLAN The IEEE 802.11.a, b, g, n Wireless Local Area Network (WLAN)

standards target wireless computer networks. The standard operate on the li-
cense free 5 and 2.4 GHz frequencies allowing high data rates. The strongest
motivation and application for the WLAN technology is replacement of Ethernet
cables. The wireless technologies provide mobile and exible use of computers.
The theoretical maximum amount of concurrent users is however limited to 500
for IEEE 802.11.a. The WLAN also has a very high power consumption com-
pared to the other standards which makes it unsuitable for embedded devices
with energy constraints.

Bluetooth The Bluetooth standard targets users in the Personal Area Net-
work (PAN) segment. A majority of the popular applications are concentrated
around cell phones. The technology allows cable replacements with high data
rates in short distances with less power consumption than using WLAN tech-
nology. It allows device discovery in an ad hoc fashion. Bluetooth has limited

16
 Standard Data rate Frequency Eective range
IEEE 802.11.a 54 Mbit/s 5 GHz < 30m
IEEE 802.11.g 54 Mbit/s 2.4 GHz < 50m
IEEE 802.11.b 11 Mbit/s 2.4 GHz < 100m
Bluetooth 2.0 2.1 Mbit/s 2.45 GHz < 10 m
IEEE 802.15.4 250 kbit/s 2.4 GHz < 100m
40 kbit/s 915 MHz
20 kbit/s 868 Mhz
EnOcean 120kbit/s 868 Mhz < 300m
RFID Various 100-500 kHz < 1m1
10-15 MHz < 100m
2.4-5.6 GHz

Table 2.1: Common wireless technologies and their technical data.

networking support with up to eight nodes in each cluster. The power consump-
tion is less than WLAN but too high for long-term operating devices.

IEEE 802.15.4 There are several consortiums and companies, such as the
ZigBee alliance and Dust networks, using the IEEE 802.15.4 standard for WSN.
The standard has low data rates, and low data capacity compared to the wire-
less standards described above. However, the standard allows devices with re-
quirements on low device price, low battery consumption and advanced mesh
networking topologies.

EnOcean (TEC 120/130) The EnOcean wireless technology is constructed

with low power consumption as the primary priority. The wireless devices com-
municate with power scavenged from the surrounding environment which gives
the technology its characteristics. [8]

RFID The purpose of Radio Frequency Identication (RFID) is to provide

data in transponders, known as tags, and to read or receive the data using
wireless communication. The data in the tags carry identication information
which can be used in for example: marathon races, luggage tracking, asset
tracking or as a bar code replacement. There are two types of RFID tags,
passive and active. The passive RFID tag has no power in the device. Instead
the electrical current generated in the sending antenna is sucient for the device
to transmit a response.
Active RFID tags have internal power and have greater communication
length. The active RFID tags also have more resistance to noisy environments
and allow higher communication rates. Some RFID tags have a writable part,
allowing changing of certain data. The RFID tags have no sensors and no
networking support.
1 The range depends on the frequency and whether the tag is passive or active.

17
2.2.2 Wireless network topologies
There is a wide range of dierent network topologies developed up till this dates.
The network topology describes how the nodes within the network communicate
with each other. What nodes are reachable through direct communications and
how to reach nodes not directly connected. The architecture of the topology,
convey dierent pros and cons when used in dierent types of networks. This
section handles the best suited topologies to be used within a sensor network,
gure 2.4, and the advantages and drawbacks of each topology considering wire-
less sensor networks.

Star Fully connected

Tree Mesh

Figure 2.4: Four commonly used topologies in wireless networks.

Star topology Within a star topology network, there are two dierent types
of nodes: the leaf nodes and the coordinator node. All leaf nodes in the net-
work have to be able to reach the coordinator, otherwise they will not be able
to communicate. The coordinator node has to have better communication and
packet processing capacity then other nodes in the network, since it handles all
communication and routing within the network. The idea that every node in
the network only has to communicate with the coordinator conveys a simple
connection implementation and a possibility to use nodes with low computa-
tional power. If one communication link or one node stops functioning, it will
not aect the whole network, only one node. The issue with this kind of topol-
ogy is instead the coordinator. If there is a lot of communication inside the
network, the coordinator might become a bottleneck. An even worse scenario
is if the coordinator itself stops working, then the whole network will be out of
order until the coordinator is back online. The distance from the coordinator is
limited by the communication range for every node.

18
Fully connected topology All network nodes have a connection to every
other node within the network. For a physical network this means that every
node has to have one cable to every other node. For large networks this is
untenable. On the other hand, when using wireless communication, the number
of links isn't an issue, all nodes simply listen for data addressed to them and
only process these packets. The communication is therefore very simple, the
sender puts the data on the shared media and the receiver picks it up. When a
great part of the communication takes place between the nodes in the network
this is a simple and robust solution. If one node is not working properly it only
eects the communication to and from that node. To communicate outside the
network, a gateway node is needed. The functionality of this node is similar
to the coordinator in the star topology, with the exception that only the trac
directed from/to the network goes through this node. Since all nodes within
the network have to be able to reach each other, the diameter of the network
can't extend the communication radius of the node with the shortest range.

Tree/Cluster topology This topology has a built in hierarchy, containing

leaf nodes and coordinators. The leaf nodes communicate with its coordinator,
i.e. star topology. The coordinator then communicates with the coordinator
one step higher in the hierarchy, and so on until it gets to the single coordinator
at the top. Communication between two leaf nodes can be routed over one or
several coordinator nodes depending on where in the network the leaves are
located. By building the network like this, it is possible to cover a wider area.
The leaf nodes has to be in range of there coordinator, the coordinator in range
of its coordinator and so on. The drawbacks of this topology are similar to those
for star topology. If one leaf doesn't work it only eects the communication with
that particular node. If a coordinator has stopped working, the whole underlying
branch is unable to reach the rest of the network.

Mesh topology In a mesh network, the nodes are connected to their neigh-
bours. By using this implementation the network becomes more redundant and
robust. Since most of the nodes have the option of sending data in more than
one direction to get to the destination, a node can decide to send data in a
direction to avoid e.g. congestion or an unavailable node. A mesh network is
complex to implement, considering the fact that it for example has to be able to
calculate routes and detect congestion. Mesh networks are often used in battery
powered wireless sensor networks. Because they have good scalability and the
possibility to communicate even though some nodes are out of power or sleep-
ing. A mesh network can be considered to be a collection of fully connected
networks where all nodes have to be able to reach their neighbours.

2.2.3 Energy management

Optimizing the energy management is a key point of designing a successful
wireless sensor network since most devices will be battery powered. The energy
cost for communicating over a wireless connection is around 10 times the cost of
calculation. For the sensor devices there are typically four areas which increase
the battery consumption.

19
 Bad placement of the sensor devices will result in high retransmission rate
due to disturbance and low communication rate. Sensor devices with many
sensor changes will have to communicate the changes resulting in high commu-
nication rate and increased power consumption.
Sensor devices located too close to each other will interfere and result in a
high retransmission rate [9].
The hidden terminal problem with two communicating devices out of range
with each other but at the same time trying to communicate with a third device
in range with both devices.
Talkative protocols will by design have a high communication rate and high
battery consumption.
The techniques for optimizing the energy management of a WSN will be
described with the OSI network layer in mind. Each optimization is in large
extent independent and could be introduced without interference of other opti-
misations.

Device The rst optimization can be made on device level by the use of energy
scavenging methods. Depending on the location and purpose of the device it
might be possible to scavenge energy from the surrounding environment, either
by using solar cells, piezo-electrics or coils for gaining energy form induction.
Recent radio circuits have the possibility of using a two phase energy level.
The rst level uses low energy cost sensing radio. As the radio wave energy
increases the second level radio will be turned on with full receive and transmit
functionality.

MAC layer On the next level the medium access layer (MAC) is respon-
sible for managing communication and avoiding collisions with other devices.
Common attributes of a MAC protocol includes fairness, throughput, latency
and maximising the utilisation of the bandwidth. For WSN the MAC protocol
should also handle new sensor devices joining the network and devices leaving
the network. In a WSN, energy conserving may be even more important than
the common attributes. The time window approach targets the problem of
sensor devices located close to each other by eliminating collisions of packages.
The time division multiple access method (TDMA) is a common used method
used in cell phone technology such as the GSM network. A device communi-
cating trough a time synchronised protocol uses a time window. Within this
window the device is allowed to send data to listening devices. When the device
is out of its communication window it can save power by entering a sleep mode
or power down the radio circuits. The drawback with this technique is that all
devices must have synchronised clocks and the TDMA techniques doesn't scale
on larger networks. The work that has been done on this area tries to address
this drawback by grouping sensor devices in TDMA subgroups and allow each
subgroup to decide its own time slots.
The S-MAC protocol suggested by Ye et al [10] is a TDMA based protocol
with energy and ad-hoc as main features while reducing fairness and throughput.

20
S-MAC allows devices to turn o the radio completely when it is out of the
window. The protocol also addresses the problem with scale in large networks
using virtual clusters. Each WSN device is allowed to make own decisions about
its time schedule. Devices communicate their schedules using broadcasts. Each
device then has schedule tables of neighbour devices. When two devices want
to communicate to the same device S-MAC uses RTS (Request To Send)/CTS
(Clear To Send) mechanism.

Application layer On the top layer, the actual application or application

protocol used will have the most inuence on the energy consumption. There
are a few ways of reducing trac and hereby conserve energy. Using dierent
communication methods may be possible on some devices. For instance, a de-
vice that only sends data on changes can sleep or power down the radio circuits
completely and therefore drastically reducing the energy consumption. This
may or may not be possible depending on required functionality and demands.
The application layer may also compress or reduce the packet length resulting
in fewer collisions and transmission errors. Transmitting fewer but bigger pack-
ages using better aggregation mechanisms may be possible in some applications.
Using distributed calculations of the data may be possible. By allowing devices
to make active decisions on how to act on dierent data changes could reduce
the need for communicating each value.

2.2.4 Security in Wireless Sensor Networks

The level of security in the network determines the amount of control and func-
tionality that a communication network can handle. The security demands in a
WSN dier on the usage and function of the WSN. A data acquisition network
with non critical information may not need the same security considerations
as a WSN with full BAS functionality. The development of WSN and the ap-
plications have in many cases not dealt with security. Similar to traditionally
computer related development, security has been of secondary concern. The
lack of computing power, the low transmission power and the possibility of
WSN nodes being tampered with, makes WSN security even more challenging.
The goal of WSN security is to provide a robust, reliable and private communi-
cation channels. The denition of a WSN as a scalable network has to be taken
in consideration when designing security for WSN.
The rest of this sub section rst presents possible threats of a WSN and
then presents possible design solutions and counter measurements for designing
a secure WSN. [11]

Threats The physical size of the sensor device and the amount of devices
makes WSN vulnerable for capturing of the actual device. A captured sensor
device is easier to tamper with than the network itself. The physical interface
of the node may be used for analyzing the software and the network keys.
Reverse engineering and changing of the sensor device software may result in
false operation of the device itself and network as a whole. The capturing of
a sensor device is close related to the threat of adding a false node not part

21
of the original WSN. Depending on the application this may be a more or less
important threat. Some of the sensor devices may be exposed and physical
protection of sensors devices may be dicult. Failure of a particular node may
be important and disturbing the communication of a single sensor device may
be tough to handle.
Jamming the network is another threat of the WSN as whole. This threat is
shared by all computer networks and wireless networks in particular. Introduc-
ing network trac may drain batteries and destroy the function of the network.
The operation of a single node may be disrupted by introducing lots of radio
trac.

Solutions Using the WSN for appropriate applications is one of the most im-
portant considerations. The WSN is a low cost network with limited computing
power, sensor devices that might be captured and network trac that might be
captured or jammed. This insight should make the WSN designer aware of not
using the WSN for critical application or have redundant sensor devices.
Application layer security is maybe the most obvious solution using encryp-
tion with key management for securing the communication. Some of the BAS
protocols listed below describes how encryption and key management can be
applied to the application layer.

2.2.5 ZigBee
The ZigBee alliance is an association of companies owning and developing the
ZigBee communication stack. The goal of the ZigBee alliance is to provide a
widely adopted standard with high interoperability for sensors and control de-
vices. Focus is on low latency and low energy consumption rather than a high
bandwidth. The ZigBee standard has in a short period of time gained much
popularity. The standard is based on the IEEE 802.15.4 communication speci-
cation. The specication denes how multiple radio devices can communicate
on a medium access layer (MAC) while the upper layers in the protocol stack
are dened by the ZigBee standard. In the reaming chapter no distinction will
be made between IEEE 802.15.4 specication and the ZigBee standard. The
ZigBee devices can operate on three license free frequency bands from 868 Mhz,
915 Mhz to 2,4 Ghz allowing maximum data rates from 20 kps, 40 kps to 250
kps.
The network topology supports star, mesh and a hybrid of both. To support
the network topologies, there are four logical device types dened, but only two
dierent physical devices are used in the ZigBee network: a full function device
(FFD) and a reduced function device (RFD).
The FFD can communicate with any other device types. It is required to be
operational at all times. The requirement is necessary since the device may need
to act as a router and route data trac. Because of the operational requirements
the FFD is usually line powered. It can function both as a coordinator and
a network coordinator. The network coordinator maintains knowledge of the
entire network. The RFD is limited to a star network topology. They are dened

22
 Coordinator (FFD)

Router (FFD)

End Device (RFD or FFD)

Figure 2.5: Zigbee network with a coordinator, routers and end devices.

as logical ZigBee endpoints. The endpoints can only communicate with a single
device and cannot function as network coordinators. The restrictions of the RFD
make them more suitable for low cost implementations. The RFD is usually
battery powered The network requires at least one FFD in order to function.
In the simple case the single FFD will function as a network coordinator and
initialize the network. The most simple network architecture is the star topology
with a single FFD in the centre and FFDs or RDFs acting as ZigBee endpoints
communicating with the network coordinator. In order for dierent brands
to communicate in the same application area dierent application proles are
dened. There is a Home Lightening application prole for example dening how
such products shall communicate. ZigBee denes tree security levels, unsecured
mode, access control list (ACL) and secured mode. In unsecured mode no
restrictions is implied on the communication. On ACL mode only packages
from the known devices are accepted. On secure mode the devices can use
ACL in combination with MAC layer encryption. The encryption utilises AES
128 bit encryption. In the secure mode frame integrity and sequential order is
supported. [12]

2.2.6 Capacity of WSN

The capacity of ZigBee-based WSN has been investigated in a few reports [13, 9]
and the conclusions are important, not just for ZigBee-based networks, but for
all CSMA/CA access based networks with multi hop support such as many of
the WSN that are available today. In the fundamental paper by Gupta and
Kumar [14], they conclude that the bandwidth decreases with the number of
nodes at O( √1N ) where N is the number of nodes. If the issue of hot spots is
included the performance decrease is in order of O( N1 ).
An article describing the capacity of CSMA/CA networks and ZigBee in par-
ticular suggests that the major cause of network bottlenecks is collisions in data
transmissions. The collisions have two main causes. With the CSMA/CA access
techniques two devices sending at the same time will cause trac problems for
both devices. The second problem is the hidden terminal problem.
The collisions result in broken routes resulting in router rediscovery intro-

23
ducing even more trac. The author of the article suggests two solutions for
the capacity problem. Either introduce a time window on the application layer
or introduce a RTS/CTS schema on the MAC layer.

2.3 Contiki
The Contiki operating system is an open source system developed at SICS, for
resource constrained embedded systems. Contiki is a networked multi-tasking
system that is highly portable. What distinguishes Contiki from other embed-
ded operating systems is the possibility of loading and unloading modules and
applications during run-time. Contiki has a simple event-driven kernel. Ap-
plication programs written with lightweight threads, so called protothreads, are
placed on top of the kernel. Even though the kernel is event-driven, Contiki sup-
ports pre-emptive multi-threading on a per-process basis. This makes Contiki
very exible, yet it is still small enough to run on resource constrained devices.
The operating system is divided into two parts: the Contiki core and the
loaded applications [15]. The core contains the Contiki kernel, the program
loader, the language run-time and the device drivers for communicating hard-
ware. The program loader is used to load applications into the system, either
through the communication service or directly attached storage.
The Contiki kernel has been designed to only provide the most basic func-
tionality for applications, CPU multiplexing and message passing [16]. More
complex functionality is implemented in libraries and is linked into the system
when needed. One of those is multi-threading. This lowers the resource re-
quirements in terms of ROM and RAM usage and the complexity of the kernel.
All Contiki processes are sharing the same address space and are using message
passing for inter-process communication. There are two types of events used
for passing messages: synchronous and asynchronous. Synchronous events are
executed immediately and asynchronous are queued for execution until the CPU
is available.
Apart from applications, services can be loaded in the system. A service is
a shared library that the other applications can call for specic functionality. A
communication stack or sensor device drivers are typical services.

Protothreads The protothread library oers linear code execution for event-
driven systems. No complex state machines are needed which simplies applica-
tion development. Protothreads are especially designed for memory constrained
systems and provide blocking-wait functionality without using any extra stack.

uIP The uIP TCP/IP protocol stack provides TCP/IP support for small em-
bedded systems. The uIP implementation is designed with only the most nec-
essary features for full Internet connectivity. For example, the stack can only
handle one network interface and the most common protocols (ARP, IP, TCP,
UDP and ICMP). Therefore the memory requirements are very low, the uIP code
size is only a few kilobytes and RAM usage only a few hundreds of bytes [17].

24
Chapter 3

Building automation systems

and wireless sensor networks

This chapter considers the area where BAS meet WSN. The benets of using
WSN technology in BAS are described together with some existing products in
this area. The WSN demands that have to be fullled by a BAS protocol
to be able to make use of those benets are described. Some of the most
commonly used protocols in BAS are described and evaluated to nd the best
suited protocol for an implementation on a WSN.

3.1 Benets of using wireless sensor networks in

building automation
By using radio for transporting BAS data, limitations with wired communication
can be avoided. Radio oers advantages in forms of low costs, exibility and
ease to use.
The cost for wireless technology is decreasing, especially for installation and
maintenance. Meanwhile costs related to wires have increased, because of the
high amount of labour involved. For example, installation cost for a sensor is
about 20% to 80% of the total cost of that network point [6], lowering or remov-
ing that cost, has substantial eect of the total system cost. Most failures in
automation networks depend on aging wires or failing connectors [18]. Wireless
technology eliminates these problems, and renders the possibility of attaching
sensors on moving devices.
The decreased installation cost will make it economically possible to use
more sensors. The increased spatial resolution with more sensing nodes oers a
ner grained measuring. More localized and personalized control of the indoor
climate can be performed. The system behaviour can be analyzed by using these
measures, to detect problems within the system. Throughout the measuring
analysis, the system can be adjusted to be more energy ecient.

25
 In [6], WSNs are connected to BASs to demonstrate there advantages. Two
dierent installations were made. In the rst, the WSN were able to detect
uneven air distribution. When the system was repaired, they were able to
eliminate occasional use of space heaters. Apart from increased thermal comfort,
they managed to save a considerable amount of money. The second installation,
sensors were installed in every room in an oce building to measure temperature
and presence. A night setback mode was turned on for empty rooms after a
certain time, the amount of energy saved with this feature turned on was high.
WSN technology oers cost ecient upgrades for BASs to improve indoor
climate comfort as well as increasing the total energy eciency of the system.

3.1.1 Wireless sensor networks in building automation to-

day
EnOcean EnOcean is a Siemens spin-of company, providing control and sens-
ing devices using wireless technology. The primary products from EnOcean are
smart energy sensors, wireless devices using energy scavenging such as piezo-
electric, solar and electrodynamics, instead of batteries. A typical building au-
tomation product from EnOcean is a wireless light switch using a piezoelectric
element to generate enough power to send an on/o signal to the coordinator.
The devices uses the free frequency band 868 MHz, but 915 MHz and 2,45 GHz
can also be used. Each device, using energy scavenging, connects to a battery
or line powered coordinator in a star topology network. Each coordinator can,
to extend the network range, connect to other coordinators using ZigBee in a
star/mesh network. A proprietary transmission protocol is used within EnOcean
networks to communicate with the wireless devices.

Thermokon A company using EnOcean technology is Thermokon. They

provide wireless sensor and control products using wireless technology. Their
products are focused on room control with wireless communication, temperature
and humidity sensors. Most of their products use energy scavenging such as solar
power. Thermokon enables communication with other BAS using LON which
will be described in more detail later in this chapter.

3.2 Requirements on building automation proto-

col
The requirements on a BAS protocol used on a WSN may dier depending on
what domain of the BAS the sensor network is used in. For example, in intru-
sion detection systems the timeliness requirements are very strict, meanwhile
timeliness in HVAC applications may be much more relaxed. The thesis is fo-
cused on the HVAC domain. The demands from measuring and controlling a
HVAC system, together with the characteristics of a WSN, forms the require-
ments on the protocol used in this environment. We have chosen to categorize

26
the requirements as follows: functional, technical, energy eciency and exibil-
ity requirements. The energy eciency and the exibility requirements might
as well be covered by the other two categories, but we have chosen to separate
them because of their importance in WSNs.

3.2.1 Functional requirements

Our investigation of WSN in BAS is focused on sensing wireless network nodes.
The communication protocol and the network mechanisms should not however
be limited to sensing only. There is a growing market for wireless controlling
nodes so the network and communication protocol used should be able to han-
dle double directed communication. The sensing nodes should also be able to
report changes within a reasonable period of time. The denition of reasonable
time depends on the restrictions and demands by the application. The area of
BAS consists of large amount of dierent requirements and demands. For ex-
ample, the timing and accuracy demands may dier depending on the location
of a temperature sensor. A sensor located in the middle of an oce building
may experience slow temperature variances and does not have a high accuracy
demand. In contrast, a sensor located at a warm water pipe controlling the
heat for the entire building has a completely dierent requirement. That sensor
must be very accurate and deliver changes at a far higher rate than the sensor
located in the middle of the oce. The network mechanisms and communication
protocol should be able to deal with these diering needs and demands.

3.2.2 Technical requirements

As stated in the functional requirements, the communication has to be fast
enough to handle values and state changes. The communication also has to be
asynchronous or event driven. This may not be obvious but in order to handle
alarms and signicant value changes without one central node requesting replies
of each node, the node itself must be able to initiate communication. As stated
in Section 1.2 the communication should be designed and constructed using a
standardized communication protocol or at least be able to exchange data with
a standardized protocol.

3.2.3 Energy eciency requirements

As stated in section 2.2.3, WSN nodes have a limited energy budget. The pro-
tocol should have the possibility, in one way or another, to limit the energy
consumption of nodes. In WSNs, radio communication is by far the biggest
energy consumer. To save energy, the communication has to be reduced. Tra-
ditionally, BAS communication has been wired. Because of this, there haven't
been any demands on the protocols to think of communication in terms of en-
ergy consumption. Instead the concern have been reliability and congestion
control.

27
3.2.4 Flexibility requirements
Within the WSN, automation data should be exchanged over an open, widely
used protocol, preferably standardized, to maintain exibility. By using a pro-
tocol like that, the WSN can easily be connected to the majority of BASs, either
directly or through a gateway. It also gives the possibility to expand the WSN
with new features at a later state if the protocol specication is updated. In
consideration of the limited resources of WSN nodes, it would be preferred that
only functionality relevant for a node to perform its task has to be implemented,
instead of the whole protocol. The protocol should support adding and remov-
ing of nodes to the network without unnecessary additional work for the network
manager.

3.2.5 Detailed protocol requirements

The requirements described above can be summarized in the following way:

Openness The protocol should be open, standardized, free of unit licenses and
widely used. This guarantees that the protocol fulls its purpose and is well
functioning. It also enables connectivity to systems from dierent manufactures
as well as a large user base. If the protocol license has a fee on each device
it would be contradicting with the goal of a large amount of wireless sensor
devices.

Modularity The protocol should be modular with only a subset of the pro-
tocol required for operation. The protocol should be possible to extend with
additional modules that do not interfere with existing once. Adding new func-
tionality should be possible without major changes in the existing modules.
The protocol should be able to support several of the logical levels described in
section 2.1.3.

Protocol code base The protocol code base including underlying protocol
requirements should be small enough to t the resource constrained sensor de-
vices. If the protocol stack extends the available space, it should be able to only
implement necessary functionality.

Node management Due to the ad hoc nature of the WSN the BAS protocol
should have support for individual management if the sensor nodes. Hence
sensor nodes leaving and joining the network should be managed without a
requirement to recongure the network as whole or renaming individual nodes.

Communication The protocol should be "energy aware". With energy aware-

ness we mean that the protocol is designed with energy constrained devices in
consideration. A talkative protocol will consume more energy. The communica-
tion should therefore be eective in terms of amount and size of packets needed
for normal operation.

28
 To have the possibility of individually adjustable times for data acquisition
based on the location and data accuracy of a unit. This requirement is important
if the goal with the WSN - BAS integration is a complete replacement of wired
control and communication. Some sensors might be connected to devices that
are life supporting or causes extended economical damage if failing. The protocol
should therefore allow the sensor device to turn of the radio and enter sleep mode
to conserve energy.

TCP/IP support The TCP/IP protocol stack is the only communication

technique used in BASs also supported in WSNs. Other supported technologies
are working on a lower abstraction level and require wired connection between
devices. The BAS protocol should have support for TCP/IP communication or
tunnelling of the protocol over IP, with messages encapsulated into IP packets.

3.3 Protocol descriptions

There are many dierent platforms and protocols used within building automa-
tion. Many of these are proprietary and not open for public use. We have chosen
some of the more commonly used building automation protocols on the market
and described them in more detail below. Every protocol description begins
with some background information, followed by a functional and technical de-
scription. At the end, we explain how well the protocol fulls the requirements
stated in the previous section.

3.3.1 LonWorks
The LonWorks platform is developed by Echelon Corp and was rst released
in 1988 [19]. It is developed to cover all communication needs within control
networks. The technology is general and is used for automation in dierent
areas, for example in trains, production facilities and buildings. A LonWorks
system is built around a protocol stack called LonTalk, a controller and a net-
work management tool. The LonTalk protocol stack and the physical media
supported was standardized in America by ANSI/EIA in 1999, ANSI/EIA-709,
and in Europe by CEN in 2005, EN-14908. The controller handles attached
units, network access and applications that run on a device. For management,
conguration and installation of LonWorks networks, a network management
tool is used.

Functional description

The LonWork platform is built on a philosophy that the same language should
be used for communication throughout the whole system. The only thing that
changes around the system is the physical media used. This was done to make
interoperability easier [1]. The architecture is at and all the nodes can commu-
nicate with each other. The at architecture results in that no simple or dumb

29
nodes can be used. All network nodes have to be intelligent to be able to en-
force the standard, therefore, all nodes are provided with a dedicated controller.
The controller contains a full implementation of the LonTalk protocol stack for
communication with other system devices [20]. It also runs the node specic
application software. The application program on the node handles attached
sensors and actuators, sending state updates and controlling on the basis of
incoming data.
The application on a device is divided into one or several functional blocks [21].
A functional block is performing a specic task, e.g. control an actuator, by
receiving congurations and operational data, process the data and send oper-
ational data. The functional block can send or receive data form the network,
attached hardware and other functional blocks on the device. All application
functions that are supposed to communicate its data have to be implemented as
a functional block. A functional block object has network variables and cong-
uration properties as object members. The network variables work as input and
output of operational data, meanwhile the conguration properties are used to
congure the behaviour of a network variable or functional block.
The LonTalk standard is using a data-oriented application layer that sup-
ports sharing of data instead of sending commands. Applications exchange data
through the network variables. A network variable has a direction, a type and
a length. The direction determines whether it is an input or output variable.
Variables with the same type and length, but opposite direction can be con-
nected to each other, e.g. a lighting device can have a switch input and a light
switch a switch output, this can be connected to control the light, shown in
gure 3.1. One output network variable can control several input network vari-
ables and vice versa. When a network variable has changed, a message is sent
to connected variables. Applications do not know where data is received from
or sent to. They simply send and receive data from the LonTalk stack. The
conguration of network variable relations is performed during design and im-
plementation of the system. There are standard network variable types (SNVTs)
and user network variable types (UNVTs).

Switch Block Lamp Block

Physical
Input Binary In Variable Binary In Variable

Conf. Property Conf. Property

Physical
Binary Out Variable Binary Out Variable Output

Conf. Property Conf. Property

Figure 3.1: Two blocks used to control light. When the Switch Block gets an
input from a light switch. It sends this to the Lamp Block who changes the
state of the light.

The conguration properties are controlling the behaviour of system devices.

A conguration property applies to the whole device, one or a series of network
variables or functional blocks. One example of a conguration property can be

30
a maximum send time property for an output network variable. There are some
standard conguration property types (SCPT), e.g. hysteresis thresholds, and
user conguration property types (UCPT).
Every functional block has to be dened by a functional prole. A functional
prole is a template for a functional block. The functional prole consists of a
description of the prole and species its members, i.e. network variables and
conguration properties. Prole members can be mandatory or optional.
To create the demanded interoperability between devices from dierent ven-
dors, the LonMark organization has released implementation guidelines and
resource les. The resource les include denitions of all SNVT's, SCPT's and
standard functional proles. Every standard functional prole describes certain
common system functionality, e.g. temperature sensor or calendar. To certify
Lon-based products, standard functional proles have to be implemented and
the guidelines have to be followed. LonMark International is managing the
certication process. The LonMark guidelines and proles are not part of the
formal Lon-standard, ANSI/EIA-709.
Devices, network variables and conguration properties are bound together
during design and installation of a system. A network management tool is used
for that. The network management tool congures network nodes, assigns logi-
cal addresses to them and monitoring the system. The tool saves a copy of the
network conguration, so that exchanged devices easily can be integrated into
the system. Most network management tools are based on Echelons LonWorks
Network Operating System, refereed to as LNS. LNS also support management
of vendor-specic parameters through a plug-in interface.

Technical description

All LonWork devices are built around a system-on-chip micro controller, called
Neuron (some similar controllers are also used). The Neuron chip consists of
three CPUs, one for applications and two for network control, memory, general
I/O ports and a complete LonTalk stack [22]. Between the Neuron and the
physical network, a media dependent transceiver is placed. The transceivers
support communication over twisted pair cable, power lines, bre optics, IR
and radio. Transceivers can also tunnel LonTalk messages over IP-networks.
A LonWorks domain consists of sub-networks in a tree hierarchy. Routers are
used on sub-network borders and between dierent media. All nodes have a
unique node id that can be used as an address for conguration and management
purposes. For normal communication a logical address is set, determined by the
domain id, sub-network id and node id within the sub-network.
Acknowledged and unacknowledged messages can be sent as both unicast
and multicast. Unacknowledged messages can be sent in two ways: one message
sent once or one message is sent a xed amount of times. LonTalk also supports
acknowledged challenge-response authentication. The mechanism used is con-
sidered weak and is therefore of limited use [23]. There is no built in support for
encrypted messages. On the other hand, LonTalk supports generic application
specic messages. This makes it possible to communicate non LonWorks data
inside the network, e.g. BACnet over LonTalk.

31
 Communication in LonTalk is based on many small packets that are sent
often [20]. Messages sent inside the system are not prioritized in any way, the
latest action will be performed. If a smoke detector signals a fan-controller to
turn the fan o, to prevent the smoke from spreading, an air-quality sensor in
another room can tell the fan-controller to turn it on again because of the need
of fresh air. To prevent this, a special input can be setup on nodes. These
inputs are overriding any other messages sent to the node [24].

Requirement fullment

The LonWorks platform is standardized and widely used. In order to build

a successful LonWorks implementation it is necessary to use special hardware
and software, i.e. Neuron chips and a network management tool. To use these
management tools, you usually have to become a licensee and pay a license fee
on a per node basis [25].
The concept of using functional blocks to create applications and network
variables to communicate between these blocks make it easier and more exible
for developers. The blocks make it possible to develop applications with little
memory usage, even though this might not be so important since the memory
included in the Neuron should be large enough to contain the most advanced
applications in the network. New functional blocks can be developed and added
to extend the functionality of a node without major rework on the existing
code base. By combining several small functional blocks, that performs specic
tasks, it is possible to create nodes with complex functionality and still keep the
complexity of the whole software implementation to a minimum.
Replacement of malfunctioning nodes can easily be done. The saved manage-
ment tool conguration can just be downloaded to the new node and the system
is functional again. On the contrary, adding, removing and moving nodes in the
system during run-time can lead to changes in the system architecture, with
reprogramming of logical connections as one side eect.
The event-driven update of system data and the possibility to set variable
specic properties makes it look like it is possible to introduce energy saving
mechanisms. On the other hand, the nodes that are connected to each other
through a network variable are not aware of the characteristics of the other part.
The communication stack sends the variable to a predened location and ex-
pects the remote part to receive the data. Another LonWork characteristic that
can limit energy savings is the high communication rates, even if conguration
properties are used to relax the timing constraints, the protocol tend to commu-
nicate often. To be able to use Lon in a successful BAS/WSN implementation,
the high communication rates and unawareness of others should be corrected.
This implies changes in the LonTalk stack, but that is not possible at this point
since the stack is not open.

3.3.2 BACnet
BACnet (Building Automation and Control network) is a pure building automa-
tion protocol. The work on BACnet started back in 1987 when the American So-

32
ciety of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) was
not able to nd a protocol that fullled there criteria for a building automation
and control protocol [1]. ASHRAE released the rst BACnet version in 1995
and it became an American standard later that year. Since then ASHRAE have
maintained and developed BACnet to become a complete building automation
protocol. BACnet can operate on all logical levels in the automation hierarchy
as well as in all areas of building automation (e.g. HVAC, security, re alarm
and lighting control). In 2003, BACnet became a world (ISO 16484-5) and
European (EN/ISO 16484-5) standard. The protocol is open and can be used
freely by anyone without any license fees. There are a number of organizations
that promote BACnet and oer educational programs. The largest is BACnet
International. It consists of companies working with BACnet, who also have es-
tablished the BACnet Testing Laboratory, for compliance and interoperability
testing and certication of BACnet devices.

Functional description

BACnet has been constructed to be a truly open building automation standard

that allows interoperability between equipment from dierent manufacturers.
The BACnet protocol covers the full range of building automation. With BAC-
net, only one protocol has to be implemented to cover all needs in building
control. The wide range of built in functionality in BACnet allows it to run on
simple eld level devices as well as on management level operator workstations
and human machine interfaces. BACnet is also often used to interconnect pro-
prietary systems, and to operate and monitor more eld level focused solutions
on the management level. These are connected to BACnet gateways. The pow-
erful management capabilities of BACnet are for example often used together
with LonWorks and KNX [26].
BACnet is based on a layered architecture similar to the one in the ISO/OSI
model. Four of the ISO/OSI layers are present in BACnet. Those are physical,
data link, network and applications layers. The main focus of BACnet is in the
two higher layers, for interoperability and functionality. The physical and data
link layer technologies dened in the specication are therefore mainly adopted
from existing standards [27].
In BACnet, network data is distributed throughout the network and en-
capsulated in objects. Every object type is a collection of data elements that
together represents a certain capability. The data elements within an object are
called properties. The properties are describing the object, its general identi-
ers, the status, limitations and how to access its information. The dierent
object types support dierent properties, some are required and some are op-
tional. BACnet devices only have to implement objects and properties needed
to perform its given task. The specication also allows vendors to implement
their own objects and extend objects with new properties. This might not be
supported by products from other vendors, but objects with extended properties
will function as if they did not have them.
The objects and their properties are available to all devices within the net-
work. For accessing object data and send commands to the objects, a message

33
exchange mechanism called services is used. Numerous services are described in
the standard to address the dierent needs in building automation. There are
services available for object access, le access, alarms and events, device man-
agement and virtual terminal. The services for object and le access enables the
possibility to read, modify and write object properties and les, as well as more
complex variants of them. The alarm and event services can inform network
nodes about updates and abnormal behaviour of nodes. Device management
can be used to locate and identify system parts dynamically, synchronize clocks
and control communication. The virtual terminal service can be used to set up a
peer-to-peer connection to a BACnet device for conguration or commissioning.
The service communication is based on a client-server model, where the client
sends a request to the server and receives a response when the request has been
performed. For the alarm and event services, it is the other way around, the
server sends the request and the client responds.
When developing BACnet devices, vendors can almost choose freely what
objects and services to implement. There is one object type and one service
that have to be present in every BACnet device, the device object and the read
property service. The device object describes the device and its existing objects,
and is used to control its characteristics. The read property service is used to
read device and object properties, needed to be able to access device information.
Apart from these, zero or more objects and services can be implemented on a
device.
The BACnet specication species a number of standardized proles for
dierent BACnet devices. The proles describe the minimal functionality a
device has to implement to be of that particular device type. One example
is a smart sensor. A smart sensor only has to be able to respond to a read
property request, but it can also implement events to inform on data updates.
A smart sensor can be any type of sensor, the description of the type and unit,
e.g. temperature sensor and degree Celsius, is present in the object.

Technical description

As the BACnet specication is designed, the developer gets a great freedom

of choice when it comes to hardware, network media and how BACnet is im-
plemented. Any hardware can be used to implement BACnet devices. The
hardware choice is usually based on the size and functionality of the device.
Since a BACnet device only has to implement the general BACnet functionality
needed for communication, devices can be made very resource constrained.
The way BACnet is designed renders the possibility to run BACnet over al-
most any network media [1]. ASHRAE have however standardized a number of
media types to increase the probability that devices are using the same type, to
be able to interact. They range from simple low cost twisted pair cable to high
capacity Ethernet networks. The standard also species BACnet communica-
tion over the IP-protocol, BACnet/IP. This specication has made IP-networks
a native part of BACnet that can be used directly, instead of tunnelling BACnet
packets.
BACnet uses a tiered network topology. Devices are attached to segments

34
(physical media, e.g. Ethernet). One or more segments form a network and
networks can be connected through routers to form a BACnet inter-network.
Device addresses are split into two parts, one is a unique node address (within
the inter-network) and the other part is a network number. This was made to
simplify the routing between networks.
BACnet supports both unicast and multicast messaging. Multicasting is
mostly used for network discovery. Even though the client-server model is used
for the services, some services do not follow this strictly. There are services that
do not require responses to there requests (unconrmed) and some can be used
in both ways (as conrmed or unconrmed). The messages sent inside BACnet
can be encrypted and a client can be demanded to authorize before commands
will be processed.

Requirements fullment

BACnet is a truly open protocol that has received great acceptance in the build-
ing automation sector because it is a world wide standardized and free to use.
The way BACnet is designed, with objects, properties, services and underlying
physical layers, makes it easy to extend when the specication is extended to
meet new market demands. BACnet has become a large protocol that is able to
address all areas of building automation, but allows developers to only imple-
ment necessary objects and services into a device for performing its task. This
prevents devices from becoming unnecessary complex and makes it feasible to
use cheap resource constrained units inside the network.
BACnet devices have services for dynamic network discovery, to inform
about themselves and ask others for certain objects. To bind nodes together,
e.g. a smart sensor and a smart actuator, a conguration tool has to be used.
The binding is simplied because devices and objects can be obtained through
these services.
Devices can use events to inform about changes. Therefore it is possible to
use the system resources more eectively compared to asking for object changes
continuously. But on the other hand, the protocol assumes that network nodes
are available at all times and therefore requests can be received at any time.
To be able to support characteristics of WSN:s, e.g. low communication rate
and sleep mode, the communication stack needs to be modied. This is possible
since BACnet is an open protocol, but this will probably lead to interoperability
problems with other BACnet systems.

3.3.3 OPC - OLE for Process Control

OPC is a series of specications dening interfaces for communication between
systems, devices, and applications in the process control industry. The purpose
of OPC is to oer standardized communication in a fast and robust way to
interconnect systems and devices from dierent vendors. The rst OPC speci-
cation was released in 1996 and was the result of collaboration between some
large automation companies and Microsoft. They formed the OPC foundation

35
to maintain the specication. The OPC foundation has since then released nu-
merous specications and more are under development. All OPC specications
are open and many of them are widely used in automation related networks and
applications. The OPC specication has never been formally standardized, but
is seen in the automation industry as a de facto standard [28].

Functional description

OPC enables the possibility for companies to integrate dierent plant systems
into one large system for real-time monitoring and control. Examples of this can
be a production system and a BAS working together with a business system.
The dierent specications from the OPC foundation have been developed to
bridge incompatible protocols and proprietary systems. The core of OPC con-
sists of a client/server model, but it is also possible to subscribe for data updates.
OPC decreases the overall system complexity and increases the exibility, by
implementing a server in a system or a device that can be accessed by one or
more clients for system information.

Client

Server Interface

DA AE DX

Stored Data

Hardware Interface

Server

Hardware

Figure 3.2: A simple illustration of an OPC server.

An OPC server can be seen as a PC-based software gateway between a de-

vice or a system, and the client who wants to access its data. In general an
OPC server consists of standardized front-end interfaces for OPC communica-
tion, OPC objects, stored data and a back-end for communication with the
hardware [29], shown in gure 3.2. A front-end interface is used by a client to
access the server objects. When objects are accessed, they use the stored data
to read parameters from the connected system or control the system behaviour.
The back-end updates the stored data with the latest data from the system and
reads control parameters.
The communication interfaces and the objects are part of the OPC spec-
ication, meanwhile the other parts of the server are up to every vendor to
implement in the best way suited for their system or device. For access to OPC
objects a hierarchical address space is built up within the OPC server, with fold-
ers, sob folders and items, shown in gure 3.3. The root of this hierarchy can
for example be a communication channel (e.g. eld bus or Ethernet network),
the devices connected to the channel can be the folders and the dierent parts

36
 Ethernet

Room Controller

Sensors

Air quality
Temperature
Actuators

Light switch

Figure 3.3: An example of the address space within an OPC server.

of the device can be sub-folders. The properties of the devices are OPC items
and are the leaf nodes in this hierarchy, a temperature of a temperature sensor
is an example of an OPC item [30].
As mentioned earlier, OPC is a series of specications. Some are Data
Access (DA), Alarms and Events (AE) and Data eXchange (DX) [31]. The
DA specication was the rst launched. It is used for reading and writing of
server data. A client can query the server as well as subscribe for automatic
data updates, either at xed intervals or when data is changed. AE is used to
notify clients when for example certain actions appear and critical thresholds
are reached. Clients have to subscribe to alarms and events. To acquire only
relevant alarms and events, a client can set up lters on for example alarm type
and event source. DX has been developed to support exchange of information
between eld busses. A DX-server has both a built in DA-server and a DA-client
to be able to perform server-to-server communication.

Technical description

OPC client and server communication was at the start based on Microsoft's
OLE COM (Component Object Model) and DCOM (Distributed COM). The
COM technology is a common way for communicating between objects, COM on
a local machine and DCOM for remote communication within a LAN. A server
is dening a communication interface, that a client has to know about to be
able to connect. This interface is used by a client to access server functionality.
Despite the client-server nature of COM, is it possible for a server to notify
clients on server events. Clients have to implement a specic call back interface
for this to work, as well as subscribe at the server. The dierent specications
are implemented separately, shown in gure 3.2. They share some interfaces as
well as implementing some specication specic.
Microsoft is providing a full communication framework with a lot of built in
functionality for connecting clients with servers. This makes it easier for devel-
opers to create applications, but also makes OPC tightly tied to the Windows
platform [32]. To make OPC platform independent, the OPC foundation has
initiated the work for a new OPC specication called OPC Unied Architecture
(UA). The specication is going to contain the complete functionality of all ear-
lier OPC specications and the communication will be based on web services.
OPC can then be ran on any device that support Internet-based communication.
Some parts of this specication have already been released, e.g. Data Access

37
and Security. Data Access has the same functionality as the old one, but the
data is now represented in a format based on XML. Security has been introduced
to protect the data sent over public media. It species for example the use of
VPN (Virtual Private Network) and HTTPS (encrypted HTTP).

Requirements fullment

The OPC protocol is open and widely used to interconnect systems on the
management level. To run OPC, apart from some functionality, both the server
and the client have to be implemented on a Windows based system. This makes
it impossible to use OPC on low cost hardware. The platform independent OPC
specication is at this point only available with limited functionality. Packets
with data represented in an XML format tend to be large because all data is
sent in plain text. The data is also in a rather complex structure which requires
a xml stack and a xml schema to parse. This makes it challenging to use on
resource constrained devices. The data exchange inside OPC is exible, most
data is communicated through queries, but clients can also be notied when
items are updated or at certain intervals.

3.3.4 KNX - Konnex

KNX is a eld bus technology standard for home and building control. It fea-
tures security applications, lighting control, HVAC control and more. The KNX
standard is maintained by the Konnex Association, who also takes care of cer-
tication of test labs and training centres. KNX is the result of a strive for a
single European standard in the Home and Building Electronic Systems eld. In
2002, three European solutions merged to form the KNX standard, namely the
European Installation Bus (EIB), European Home System (EHS) and Batibus.
The KNX standard combines the best of the three [1]. It is built around EIB's
communication stack, extended with additional physical media, conguration
modes and application proles from EHS and Batibus. KNX became a Euro-
pean Home and Building Electronic Systems standard in 2003, EN-50090, and
in the summer of 2006 an international ISO/IEC standard, ISO/IEC-14543 [33].
During 2006, KNX has also been accepted as a standard for building automa-
tion, in EN 13321-1.

Functional description

KNX is designed to improve electrical installations in homes and buildings by

taking their specics in consideration. KNX can handle a large number of units
with relaxed real-time requirements. KNX is an event-based system with dis-
tributed intelligence and without centralised control. All network nodes support
KNX communication and are connected to lines, the smallest unit in the net-
work hierarchy. Lines can be connected to a main line to form an area and areas
can be connected to a backbone to create a domain. The devices that inter-
connect lines and backbones, line couplers and backbone couplers (KNX names

38
for routers), are intelligent and can perform given tasks, e.g. block irrelevant
messages from passing to decrease network load [26].
All units in a KNX network can be addressed in two dierent ways. Every
unit has a unique physical address, which corresponds to the location within the
network topology. This address is set during installation and is used for point-
to-point communication with the device, to download applications, set or update
parameters and download group addresses. For run-time communication, KNX
uses group addressing (i.e. multicasting). A group address is assigned to every
network-wide shared variable, to get updates on this variable, network nodes
joins the group. Group messages sent, are received and processed by all group
members at the same time. Group addressing simplies device communication
and reduces network trac.
A device application in a KNX network is a collection of sending and receiv-
ing data-points. These data-points are linked together to create a distributed
application [34]. Shared data-points (variables) are refereed to as group objects.
Group objects can be readable, writable or both at the same time. The latter
is not recommended because it complicates connection dependencies. All group
objects on a device can individually become members of groups, one object can
be a member of several groups at the same time. Group members are bound
together by the group address, which is also used for communication. By using
group objects, nodes only have to keep track of its shared data-points and the
corresponding group addresses. Applications only see the group objects as read-
or write-only variables, the communication stack informs the application when
a receiving group object has been updated and the application informs the stack
when a sending group object is updated. When receiving an update, applica-
tions use the incoming data to update an internal state, control another node by
updating a sending data-point or control a physical output. Variable updates
are usually sent to group members as events, but there is also a possibility to
send a query to a node to see if a sending data-point is updated.
To describe the properties of nodes and applications, interface objects are
used. The system interface object is used for network management, to update
the network binding information and accessing the loaded application. Appli-
cation interface objects describe the functional blocks and conguration param-
eters inside the application. The interface object contains information of the
sending and receiving data-points, the variable names and types. Some of these
properties are only accessed during setup, meanwhile others are accessed during
run-time through group objects.
The KNX standard supports three dierent modes for network congura-
tion. The three modes are: S-mode (System), E-mode (Easy) and A-mode
(Automatic). The modes oer dierent levels of functionality and conguration
exibility as well as demands on KNX knowledge. KNX devices are developed
to support one or more of these modes. The S-mode is the most advanced.
S-mode supported nodes are freely programmable and oer high functionality.
Networks built with S-mode nodes are commissioned and maintained by a soft-
ware tool. The tool is used for system design, binding and conguration of
devices. Manufacturers of S-mode nodes supply product templates, contain-
ing all possible functionalists of a device. These are gathered into a product
database for use together with the tool. The most commonly used tool for con-

39
guration of KNX devices is ETS (Engineering Tool Software), maintained by
the Konnex Association.
E-mode devices are pre-programmed by the manufacture and are loaded with
a default set of parameters. This limits the functionality, but on the other hand
simplies conguration. These devices do not need an advanced software tool,
like ETS, to be congured. To congure E-mode networks, special buttons,
DIP switches, code wheels or handheld conguration devices are used instead.
Groups are for example created by assigning the same DIP switch value to the
group objects you want to link together. E-mode devices operate on a single
logical segment, i.e. line.
The automatic conguration mode is intended for the consumer market,
where persons with no or very limited KNX knowledge should be able to in-
stall a KNX network. A-mode components are loaded with a xed number of
parameters and a library of instructions how to communicate with others. A
network of A-mode nodes usually has a dedicated Application Controller, who
also takes care of the conguration of for example group addresses.
To enforce interoperability between devices from dierent manufacturers,
the Konnex Association has grouped system features into proles. By following
a prole or a set of proles while developing, the product will easily be certied
and integrated into a KNX system. Proles are a part of the KNX standard
and are available for all conguration modes, routers and management clients.

Technical description

The KNX standard demands that a network unit implements a full KNX com-
munication stack and can communicate over one of the four supported media.
A manufacturer can freely choose the hardware best suited for every product.
A KNX product implements one or more proles. Depending on the number
of and the size of selected proles, implementations can run on anything from
8-bit microprocessors up to PC-computers. Some node applications only need
5Kb of memory.
The KNX specication contains standard system components that are avail-
able as OEM solutions for companies that do not want to develop their own
hardware. A bus coupler unit (BCU) is one of these components. It contains an
interface towards the network media, a full network stack, a small application
environment and an interface for adding modules like sensors and actuators. For
large and complex applications that do not t inside a BCU, controllers that
operate up to the link layer are available. An attached application controller
implements the remaining network stack and the application program.
KNX can be transported over four dierent types of media, as mentioned
above. These are twisted pair cable, power lines, radio and over IP. KNX radio
devices can use both bidirectional and unidirectional communication, to lower
device costs and use batteries as a power source [35]. KNX supports tunnelling
over IP as a backbone and for remote maintenance.
KNX group addresses are added as low as the MAC layer. This reduces the
packet processing needed to decide destination. Packets sent to group addresses

40
can be routed through the whole network, routers use group member tables to
decide where to route packets. The use of this messaging model result in lack
of security, no authentication or authorization is possible to protect the system
from injected messages.

Requirements fullment

KNX is open and standardized. It is used above all in lighting and electrical
installations [25], but also supports building automation. The management
level within KNX is very limited [36]. Large installations therefore tend to use
another protocol, e.g. BACnet, for system monitoring and control. KNX uses
proles to describe certain functionality and combines these to build device
applications. The prole size, prole complexity and the number of proles
implemented determines the size of an application. Simple nodes with limited
functionality do not need many or advanced proles, and can therefore be kept
small.
Management of nodes dier depending on the conguration mode used. A-
mode nodes are managed automatically, meanwhile every E-mode node has to
be managed physically by a manager. Larger and more complex systems, e.g.
BAS, use the S-mode that has to be managed by software tools. To add or
remove nodes in E-mode and S-mode demands management by a manager. On
the other hand, movement of nodes can be done without changing the congura-
tion, because of the use of group addressing (routers might have to be updated
when a nodes moves into a network part where no node have used that group
address before). Since KNX uses events to update network data and nodes can
use unidirectional communication, it seams to be possible to implement power
saving mechanisms on devices. An aggravating circumstance can be that group
addressing is used for communication between network nodes. If one of the
nodes in a group is asleep or have the radio turned o when an update is sent,
will either result in the node not getting the update or in retransmissions until
all nodes are awake at the same time.
KNX is tightly bound to its supporting transportation media. To only sup-
port tunnelling of IP-packets in backbone networks, limits the possibility of
implementing the protocol on top of new technologies.

3.3.5 Modbus
Modbus is a widely used protocol in all areas of the automation industry. It
is an open protocol, but has not been standardized. Developed in the late 70s
by Modicon to be used in industrial automation systems [37]. Today, Modbus
is supported by the majority of the PLCs on the market. The protocol is
maintained by Modbus-IDA, a group of Modbus users and suppliers. The fact
that there is no license fee for implementing the Modbus protocol makes it an
attractive choice even in building automation [1]. The simplicity and exibility
of Modbus have made it possible to meet the diverse requirements from the
building automation industry.

41
Functional description

Modbus is an application layer protocol. It can run on any physical media.

A Modbus message consists of two parts to facilitate Modbus communication
over dierent media inside the same network. There is a media independent
protocol data unit (PDU) and a media dependent application data unit (ADU).
The ADU encapsulates the PDU and contains link layer specics like, device
address and codes for error checking. Meanwhile the PDU contains a function
code for the requested action and a eld with data needed to perform the action.
The Modbus protocol is using master-slave architecture for communication
inside the network. This means that the master is initiating communication
with a slave by sending a request. The slave performs the requested action and
responds to the master. A slave node can therefore not report changes back to
the master, it has to wait for an incoming request on that specic data. The
master node accesses all data objects on the slaves periodically and has to keep
track of state changes [38].
A slave application program is a simple server program with accessible func-
tions used to reach shared variables. The standard variables can be of analogous
or binary type, and are read-only or read-write. Read-only variables are used
to hold sensor data. The read-write variables are used for control of actua-
tors. Those are read for system monitoring and written to change the state of
a controlled unit.
A network accessible function performs a task when contacted by the master.
The most common tasks are to read or write shared variables. Every function is
identied by a function code. There are three dierent categories of functional
codes: public, user-dened and reserved functional codes. The public codes
are well dened, tested and documented by Modbus-IDA, and guaranteed to
be unique. User-dened codes can be used to address specic functionality
implemented by a user. These functions are only accessible inside the users own
network, but can become publicly accepted and assigned a public code. Reserved
codes are not available for public use. They are used by some companies for
products that have inherited them [37]. The master unit contains all logic
and rules of the system. It collects measurements from the system and uses
these measurements to come to decision on system control. The protocol does
not support that slave nodes can inform the master on matters regarding a
variable, e.g. what the variable represent. This must be set within the master
manually by a human operator or by using user-dened functions. By using this
centralized way of control, slave nodes can be made very simple and cheap [39].

Technical description

A developer of a Modbus system can freely choose what platform and physical
media to use. Several media can be used within the same network, gateways
are used to adjust the ADU for the dierent media. The protocol was rst
used on a twisted pair cable technique called RS-485 and has inherited some of
its limitations, e.g. the maximum size of the PDU. Every device is addressed
through a network unique device address, independent of the network structure.

42
 There are two dierent communication modes for Modbus: RTU (Remote
Terminal Unit) and ASCII. RTU is the compact mode, meanwhile ASCII sends
every byte as two ASCII characters. RTU is used for better throughput and
ASCII because it is readable and easier to trouble shoot. Modbus RTU is used
in the majority of the Modbus implementations [39].
Modbus can also be used on top of TCP/IP. A special specication has been
released for Modbus TCP/IP to adjust Modbus to the TCP/IP standard. Mod-
bus TCP/IP is very similar to Modbus RTU, the dierence is the transmission
inside TCP/IP packets and the format of the ADU. No error checking code has
to be included in the ADU, handled by TCP/IP, but a eld for the PDU length
is included for the receiving device to detect if the message has been split up
during the transmission [40].
When sending a request, the master is waiting for a response before perform-
ing another action. This means that if there is only one master in the network
(the usual case), only one message is sent through the network simultaneously.
There are two possible responses to a sent request: response or exception re-
sponse. A response PDU contains a copy of the function code from the request
and the requested data. Meanwhile an exception response contain a copy of the
function code with the most signicant bit set to 1, to inform about the excep-
tion and what function request caused it. The data eld then contain further
information about the exception.

Requirements fullment

The Modbus protocol is open and widely used in dierent automation areas.
The protocol is simple and can easily be implemented in a resource constrained
environment. The Modbus specication only includes basic automation func-
tionality. More advanced functionality has to be implemented as user specic,
which is not supported by products from other vendors.
All network node management is handled by the master. When adding
nodes to the network, most work has to be done manually by an operator since
slave nodes cannot inform the master of their functionality. The master-slave
communication used in Modbus is not ideal for wireless sensor nodes. Power
saving is not feasible when the node has to stay awake, waiting for requests.
Power saving functionality, like negotiation of times for communication and
event based communication, can be implemented as user-dened, but again,
this is only supported inside one vendor's network.

3.4 Protocol evaluation

The section 3.2 describes what is required of the BAS protocol for use in a
wireless sensor network. Fullment of the detailed protocol requirement will be
described in this section and end up in a decision of the protocol best suited
for BAS and WSN integration. The evaluation result is visualized in table 3.1
below.

43
 The requirement of openness is fullled by all the investigated protocols.
They are commonly used in dierent areas of building automation and stan-
dardized or have a large user base. There are some concerns that can be seen
as a disadvantage for two of the protocols. The Modbus protocol is seen as old
and outdated, and will decrease in popularity in favour of other protocols. In
LonWorks, the LonTalk protocol stack is proprietary, vendors specic function-
ality cannot be implemented in the communication layer, e.g. to better support
WSN. LonTalk also requires a license fee for using the stack in a device.
BACnet is the only protocol that fully meets the modularity requirement.
Modules can be added and removed from both the communication part and the
application part of the protocol with little eort. KNX is close to BACnet when
it comes to modularity, but it is not as good on the communication layer and
when it comes to the logical levels. KNX lacks support for the management
level meanwhile BACnet supports all logical levels.
All protocols except OPC can be seen as having a small code base and are
possible to use on wireless sensor devices. OPC on the other hand requires a
Windows operating system or a full XML stack to operate. For the other pro-
tocols it is also possible to adjust the size of an implementation on a node. This
can mainly be done with the applications on a node, but in for example BACnet
it is also possible to limit the number of available communication services.
The node management requirement is not fullled by any of the remaining
protocols. When adding and removing network nodes in Modbus and LonTalk
networks, the system architecture has to be redesigned. For KNX, the congu-
ration tool have to be used to add a node in the network. BACnet is closest to
a complete node management support with an ARP like discovery technique.
By using this technique, little eort is needed at a well designed management
station to connect objects to each other.
All protocols expect all system devices to be reachable at any given time
and there is no possibility to schedule communication with particular devices.
Therefore it is not possible for a node to enter sleep mode in a good way. It
could be done in BACnet and KNX for sensing nodes that are congured for
change of value reporting. This is a deviation from the protocol standard and
makes it impossible for reconguration and node management.
The TCP/IP requirement is partially supported by all the protocols. Lon-
Works and KNX only support tunnelling for backbone connectivity purposes.
It is only possible to transport data over TCP/IP between networks in a BAS,
not to communicate with a single network node. In the other three protocols,
BACnet, OPC and Modbus, that implements a native TCP/IP stack for com-
munication within the network is it possible to use TCP/IP for node to node
communication.
We have also noticed that BACnet, KNX and Modbus can run on any hard-
ware platform, even though some platforms and technologies are preferred to en-
force interoperability between dierent vendors. BACnet also implement mod-
erate security features which is good when sending information over the air.
We nd BACnet to be the best suited protocol for our proof of concept
WSN/BAS integration. Using any type of hardware and TCP/IP for communi-

44
 LonWorks BACmet OPC KNX Modbus
Open Yes Yes Yes Yes Yes
Native IP - Yes Yes - Yes
IP-tunneling Yes Yes - Yes -
Small or Yes Yes Yes Yes Yes
adjustable
code size
Simple node - - - - -
management
Event based Yes Yes Yes Yes -
communication
Adjustable Yes Yes Yes Yes Yes
deadlines
Standard Yes Yes - Yes -
proles
Logical 1 1, 2, 3 3 1, 2 1
operation levels
Platform - Yes - Yes Yes
independent
Security Very Moderate DCOM Very -
features limited security limited

Table 3.1: Comparison between the evaluated BAS protocols.

cation makes it possible to take advantage of the processors and radio techniques
best suited for WSN and still compile with the standard. An other important
factor why choosing BACnet, primarily over KNX, is the fact that it is possi-
ble to only implement parts of the available services to save memory on simple
devices and to build very cheep network nodes.

45
Chapter 4

BACnet

This chapter contains a presentation of BACnet [41] [42] [43]. Its architecture
and other parts of BACnet are described, as well as communication between
network devices, how data is exchanged and how this is kept secure. There is
also a description of how the interoperability of products from dierent vendors
is enforced.

4.1 Architecture
The architecture of BACnet is based on a four-layer model. The four layers have
been brought from the ISO/OSI model with respect to features and requirements
for building automation applications. The architecture implements the physical,
data link, network and application layers, shown in Figure 4.1a. Three layers of
the ISO/OSI model were left out to decrease implementation complexity and to
lower the protocol overhead. Required functionality of those layers has instead
been implemented on the application layer.
BACnet/IP

Application BACnet Application Layer BAC App

Network BACnet Network Layer BAC Net

BVLL
Datalink Ethernet MS/TP PTP Transport
LonTalk Network
Physical Link
Physical Ethernet ARCNET RS485 RS232
Physical

(a) (b)

Figure 4.1: The BACnet four-layer architecture (a) and BACnet/IP architecture
(b).

46
 A device's application program uses the application layer to communicate
with other BACnet devices. The application layer implements the BACnet
services supported by the device and an interface towards the objects describing
the functionality of the device (services and objects are further described below).
Service requests initiated by the application program are encapsulated in a
uniform way to create an Application Layer Protocol Data Unit (APDU). The
APDU consists of a header, describing a service request, and a service request.
The APDU is then passed down to the network layer.
The network layer enables communication between devices on dierent net-
works within a BACnet inter-network. This is achieved through BACnet routers.
BACnet has been designed in a way that lowers the complexity of this layer.
Some network layer functionality is absent compared to the network layer in the
OSI model. This is achieved by constructing networks without multiple routes
and by not allowing network layer fragmentation. The network layer implements
two services used between the network and application layers. The rst one for
the application layer to use when it wants to send and the second one for pass-
ing incoming messages to the application layer. When the application layer is
passing an APDU, it is encapsulated into a network layer frame called Network
Layer Protocol Data Unit (NPDU). In front of the APDU a header is placed.
The header, size and present elds are adjusted depending on the source and the
destination of the message that is about to be sent, shown in Figure 4.2. This
is used to lower the network overhead by not sending redundant information.

Version
Control
D−NET
Version D−LEN
Control D−ADDR
D−NET S−NET
D−LEN S−LEN
Version D−ADDR S−ADDR
Control Hop Count Hop Count

APDU APDU APDU

(a) (b) (c)

Figure 4.2: BACnet NPDU's: (a) Source to local network, (b) Source to another
network (directed to a router), (c) Router to router

On the data link layer, the NPDU is prepared to be sent out in the LAN
by the physical layer. BACnet uses well tested industry standards on these
layers and therefore looks dierent depending on which one is used. This is
possible because the OSI model is used for the architecture. Any protocol using
this model can be used to transport BACnet messages. ASHRAE have decided
to support ve dierent physical media who together cover the whole spectra
of building automation. The ve are MS/TP (Master-Slave/Token-Passing),
ARCNET, Ethernet, PTP (Point-To-Point) and LonTalk. MS/TP, ARCNET
and Ethernet are local area network protocols that cover dierent segments

47
when it comes to price and performance, where MS/TP is the cheapest and
simplest. PTP oers the possibility to connect to a network through a dial-
up modem or other PTP equipment. BACnet can also be transported inside
a LonTalk network. BACnet can make use of the physical media available in
LonTalk (e.g. power lines) and be implemented on top of an already existing
LonWorks installation.
BACnet can also use TCP/IP to transport messages. BACnet/IP species
how TCP/IP is used to transport BACnet messages in a similar way as the pro-
tocols normally used on data link and physical layers. BACnet/IP implements
an interface between the BACnet network layer and TCP/IP, called BACnet
Virtual Link Layer (BVLL), shown in Figure 4.1b. TCP/IP is now seen as any
data link layer by the higher BACnet layers . The BVLL implements function-
ality so that TCP/IP can perform unicast and broadcast (local, remote and
global) services like BACnet.

4.2 Internetworking
A BAS based on BACnet consists of one or more networks. A BACnet net-
work uses one of the above mentioned media to connect devices. The media
type chosen for a network is very much decided by the certain requirements
of the network devices. In large systems, devices with similar requirements
can be grouped together to lower the overall system costs. Devices like sen-
sors only need simple low speed networks, meanwhile workstations for system
monitoring collect data from all over the system and therefore require high
speed and throughput. Networks (with the same or dierent media type) can
be connected to each other through routers and are then forming a BACnet
internetwork. BACnet can also be used together with other open or proprietary
protocols, for management or to render it possible for them to interact. Then
a gateway has to be implemented between the BACnet network and the other
system, one example of this is KNX, who often uses BACnet as a management
protocol through a gateway. Figure 4.3 is showing a possible BACnet system
architecture.
For communication with devices within a BACnet system, a BACnet address
is used. This address corresponds to the data link layer address. In BACnet/IP
networks, TCP/IP is seen as the link layer, the IP-address and the port is
therefore the BACnet address. The format and size of this address may dier
depending on the LAN technology used in the dierent networks. The network
layer is also using this address to reach remote devices. The source, destination
and related elds are only present in the network layer header when they are
really needed. Examples of this can be seen in gure 4.2.
To simplify for BACnet routers and to make the routing tables more ecient,
a eld with the network number is added in front of the address. Routers use
this eld to make routing decisions. The device address is only used when
the network is reached. This eld together with the decision to only have one
message path between any two devices inside an internetwork simplies the
routing tables. A table only needs to contain the next hop for every present

48
 BACnet Workstation

BACnet/Ethernet

Vendor Vendor
A B Ethernet BACnet/Ethernet
Router Gateway
MS/TP KNX/PL110

BACnet/MS/TP KNX/PL110

Vendor Vendor Vendor Vendor

B C D D

Figure 4.3: A possible BACnet system architecture. Products from dierent

vendors that use dierent communication protocols. They work together as a
complete building solution.

network number. Routers use self-learning to build up their routing tables.

They know about directly connected network numbers and can from there use
certain network layer protocol messages to learn the rest of the topology, e.g.
Who-Is-Router-To-Network. The routers also rebuild the network layer header
to only contain necessary information, if the link layer source address is the
same as the initial source address, the source is absent in at the network layer.
Figure 4.2b and gure 4.2c show how the network layer header is changed at
the rst router if a message has to be routed through another network before
entering the destination network.

4.3 Objects
To represent the functionality of a device, BACnet uses an object oriented ap-
proach. The objects are constructed in a uniform way to enable access to object
information over the network. A BACnet object describes certain device func-
tionality, e.g. information about a physically attached input (analogue or binary
input). Every object encapsulates a collection of data elements that represent
the functionality. The data elements are called properties. The properties are
used to describe the object and its status to other BACnet devices inside the
network. The object behaviour can also be controlled by other devices through
the properties.
The BACnet standard species a number of standard objects. These objects
cover most of the functionality needed in BAS. There are objects for managing
analogue and binary in- and outputs, collecting trends, scheduling of operational
hours and describing control loops. A BACnet device does not have to imple-
ment all standard objects to withhold the standard specication. The objects to
implement are based on the requested functionality of the device. Every device
has to implement one object to make the device available on the network and
to describe it. This object is called device object. The device object presents
the device and its characteristics to others in the network and can be used to

49
control the device behaviour, Figure 4.4 shows a simple device. For example
the device object contains a list of all other implemented objects on the device.

Smart Sensor
Device Object Analog Input Object

Object_Identifier 100 Object_Identifier 1

Object_Name Smart Sensor Object_Name Sensor #1
Object_Type Device Object_Type Analog Input 22.0 C

Vendor_Identifier 0 Present_Value 22.0

Object_List 1 Description Room Temperature
Units Degrees−Celsius
Resolution 0.1

Figure 4.4: Smart sensor device with a device and analog input object, showing
some of their properties.

There are a large number of dierent standard properties to describe objects.

For every standard object, the available properties are listed. The behaviour of
every property is described in the specication. Some of these properties are
mandatory to implement and many of them are optional. In an analogue input
for example, the present value property is mandatory to represent the input
value and the resolution property, which shows the smallest change in present
value is optional, shown in gure 4.4. There are a few properties that have to be
present in every object, object identier, objects name and object type. These
are used inside the system to keep track of the objects. All implemented proper-
ties are required to be readable, some might be writable and some are required
to be writable. By making many properties optional, the object functionality
can be adjusted to the needs in every situation.
The object model used in BACnet makes it easy to extend BACnet with
new objects and properties, both through adding them to the standard and
implementation of vendor specic objects and properties. This can be done by
anyone, the only thing needed is a vendor identier (handed out by ASHRAE)
to label the object with, to not interfere with objects from other vendors. De-
vices with vendor specic objects have to obey the standard and implement a
device object and the other objects have to contain the three required properties
mentioned above. If this is fullled, standard objects on a device can fully func-
tion with devices from other vendors even though the vendor specic objects do
not.
To access objects, the object identier is used. The object identier for
an object has to be device unique, meanwhile the object identier for a device
object has to be unique in the whole BACnet internetwork. The object identier
consists of two parts, rst a number stating the object type (e.g. analogue input
have number 0) followed by the number of the entity. ASHRAE have reserved
numbers between 0-127 for standard objects. The following numbers, from 128
to 1023 are open to use for vendor specic objects. By combining this with the
vendor identiers, every vendor gets great possibilities to extend their BACnet
products with extra functions.

50
4.4 Services
In BACnet devices use services to pass information between each other. Through
services, BACnet devices can fetch information about other devices and objects,
command devices to perform certain actions and inform other devices that an
event has occurred. The BACnet specication describes a number of standard
services. Depending on the area they are used in, they have been divided into
ve dierent groups: File Access Services, Object Access Services, Alarm and
Event Services, Remote Device Management Services and Virtual Terminal Ser-
vices.
Similar to the objects and properties, not all services have to be supported
by a device. The services supported can almost freely be chosen by the devel-
oper. One service is required, the ReadProperty service. It is needed for device
access and to acquire information about the device. To achieve desired device
functionality other services can be implemented. Some are tightly connected
to objects and properties, and require certain of them, e.g. for an analogue
input to support change of value reporting, the COV_Increment property has
to be present (described further below). It is also possible to add vendor specic
services to acquire data or control objects in a way that is out of the scope of
standardized services.
Services in the File Access group are used to read and write les. A le in
BACnet is a collection of data bytes of an arbitrary length. File services are
typically used to transport larger amounts of data, e.g. statistics or programs,
but can be used for any kind of information, e.g. device settings if the device
uses a le to store these. To be able to access a le through a le service, the
le has to be represented by a le object with descriptions of the le.
The Object Access Services are a collection of services to access and modify
object properties, and to create and delete objects. Properties in any BACnet
object can be accessed through these services regardless of their functionality,
both standardized and vendor specic. This group contains the most commonly
used services, the read and write property. There are also more powerful versions
of these services, to read or write multiple properties at the same time or to
read properties at certain conditions. Some object types can also be created
and deleted with object access services, often used for calendars and schedules.
The Alarm and Event Services are used to handle the communication re-
garding events. These events can be value changes for certain properties and
changes in object state that meet predened criteria, those considered serious
are reported as alarms. To meet the dierent needs in event reporting, BACnet
species three dierent mechanisms: change of value (COV), intrinsic and al-
gorithmic change reporting. With COV, a device subscribes to receive updates
of a property when it changes with a predened amount since the last update,
Figure 4.5 describe this scenario. Objects can have intrinsic functionality to
generate event notications at certain points, e.g. when a present value extends
its normal range. COV and intrinsic reporting is limited to certain proper-
ties in certain objects. To be able to report more general events, algorithmic
change is used. It makes use of special objects to decide when to report events.
Those objects can generate dierent event types depending on what happens to

51
a property.

Smart Sensor
Subscribe_COV Analog Input Object
Present_Value 22.0 C

COV_Notification Present_Value 22.0

Client
PV=22.0 Unit Degrees−Celsius
COV_Increment 0.5

(a) Last Sent

Smart Sensor
Analog Input Object 22.5 C
COV_Notification
PV=22.5 Present_Value 22.5
Client
Unit Degrees−Celsius
COV_Increment 0.5

(b) Last Sent 22.0

Figure 4.5: A client subscribes to COV on the Present_Value property in

the Smart Sensor and recieves a Present_Value notication (a). When the
Present_Value has changed with COV_Increment, a new notication is sent to
the client (b).

Services associated with Remote Device Management are used to control and
locate devices and objects. Clocks can be synchronized and device communica-
tion disabled. The most important services in this group are those for locating
and identifying devices and objects. Those services can make system installation
and conguration a lot easier. There is also a service available for encapsulat-
ing messages to vendor specic services, this way non-standard services can be
described in a standardized way.
The Virtual Terminal Service makes it possible to directly connect one BAC-
net device to another. Through this terminal, commands can be executed on a
device without going through any other message service. This service has often
been used for the conguration and commissioning of devices, now days this is
often replaced by web-based tools [1].

4.5 Communication Model

BACnet services use a client-server model for communication between devices.
The client sends a request for information to the server, who responds with the
requested data. This leads to a simple communication architecture. The com-
munication is connectionless. A client can send a request at anytime, without
negotiating with the server to set up a connection. A relation between a client
and a server usually lasts during the request-response period. There are some
relations that work dierently and lasts longer periods, e.g. COV, where the
server sends value updates to clients for a period of time or until they unsub-
scribe.

52
 Even though messaging follows the client-server model, BACnet networks
are also built on peer-to-peer philosophy. Peer-to-peer means that all nodes can
communicate with each other. BACnet devices are not restricted to be either
clients or servers. Units can at one moment respond to a request sent by another
unit and in the next, request data from another device. Some devices are still
limited to be either a client (monitoring device) or a server (smart sensor).
BACnet supports two dierent message types for services to use when send-
ing information inside a system: conrmed and unconrmed messages. Con-
rmed messages require a response to be sent back to the initiator. Conrmed
messages are used for all queries and when an initiator requires a guarantee that
a message was transferred correctly. Unconrmed messages are used for broad-
casting/multicasting and when delivery requirements are more relaxed. Most
services are restricted to use conrmed messaging only. Some use unconrmed,
e.g. I-Am, and a few can use both, e.g. COVnotication.
The BACnet protocol stack contains two dierent types of message priorities
on two dierent layers: at the network layer and at the application layer. At the
network layer, the priorities are used to decide what message to process when
multiple messages arrive to a router or device. The network layer implements
four levels of priority. At the application layer, the dierent priority levels are
used to decide what message to use for control. There are 16 priority levels; ve
of them are specied in the standard, e.g. life safety and manual operator. The
others are available for any use inside a system, e.g. priority for energy saving.
The assignment to the available priority levels are often related to the system
management goals.

4.5.1 Message coding

The BACnet service parameters used when communicating are encapsulated
inside an APDU. These parameters can be of many dierent types depending
on the accessed object. To make the encoding and decoding of messages as
generic as possible, ASHRAE have decided to use a coding scheme called ASN.1
(Abstract Syntax Notation One). The idea of ASN.1 is that messages can
be decoded without knowing the message format. Every data element in the
message is represented by three pieces: identier, length and the data. By
using these elds to represent data, result in great exibility, as well as a large
overhead.
To make the transportation of messages more ecient, in terms of simplicity
and compactness, ASN.1 is not used on the whole APDU. The APDU has been
divided into two parts, a xed and a variable part. The xed part contains
protocol information and the variable part service related information. Only
the variable part of the APDU uses ASN.1 encoding. This approach leads to
less overhead and retained exibility for service information.
The service parameters are represented as mentioned above, as a tag (iden-
tier and length) and data. In BACnet two dierent types of tags exist: appli-
cation and context specic. Application tags represent all fundamental BACnet
data types, e.g. boolean, string, real and BACnetObjectIdentier. Context
specic tags are used to identify data from the context they are used in, e.g.

53
from the order in a certain service request. Apart from deciding the tag type,
the tag also contains the tag number and a eld used for length, value or type
of data followed. The type can be either primitive or constructed. If the type
is primitive, only data follows the tag. For the constructed type, tagged data
follows the tag. If the tag indicates constructed data, the tag is said to be an
opening tag. The constructed data then have to end with a closing tag referring
to the tag it closes. The eld is only used to represent a value in one case, when
an application tag is of type boolean. In any other case, the eld contains the
length of the data. Figure 4.6 shows the variable part of an encoded read prop-
erty request for a present value in an analogue object and the corresponding
response. The concept of application, context specic, opening and closing tag
is also shown in this gure.

Request:
X’0C’ SD Context Tag 0 (Object Identifier, L=4)
X’00000005’ Analog Input, Instance Number=5
X’19’ SD Context Tag 1 (Property Identifier, L=1)
X’55’ 85 (PRESENT_VALUE)

Response:
X’0C’ SD Context Tag 0 (Object Identifier, L=4)
X’00000005’ Analog Input, Instance Number=5
X’19’ SD Context Tag 1 (Property Identifier, L=1)
X’55’ 85 (PRESENT_VALUE)
X’3E’ PD Opening Tag 3 (Property Value)
X’44’ Application Tag 4 (Real, L=4)
X’4290999A’ 73.3
X’3F’ PD Closing Tag 3 (Property Value)

Figure 4.6: The variable part of a read property request and response, showing
the concept of context and application tags, primitive and constructed (opening
and closing tags) data.

4.6 Security
Security becomes an important issue in BAS when open technologies and shared
media are used. BACnet oers limited security architecture to address this
problem and it is an ongoing process to extend BACnet in this eld [44]. This
architecture contains the basic needs to secure messages sent over the network
and is optional to implement. The purpose is to provide data condentiality,
data integrity and authentication of peers, data origins and operators. Extended
security for systems that require a higher security level can be implemented as
vendor-specic.
The central parts of BACnet security are a key server and the symmetric
encryption algorithm DES (Data Encryption Standard). The key server dis-
tributes session keys for communication between BACnet devices. The DES
algorithm is used for authentication and message encryption.
To set up a secure connection between two BACnet devices, the two have

54
to acquire a session key from the key server. The initiating device sends a
message to the key server with a request for a key. This message contains
the addresses of the initiating device and the remote device. The request is
encrypted for protection with the initiating device's private key, only known
by the device itself and the key server. The server processes this request and
sends an encrypted response message to respective device containing the session
key and corresponding address, as shown in Figure 4.7a. When this process is
completed, authentication can take place and encrypted messages can be sent.

Key Request
Request
FPKA(Addr A, Addr B)

Key Server
Device A

Device B
Response Response
FPKA(SK AB, Addr B) FPKB(SK AB, Addr A)
(a)

Device Authentication
Challenge
FSK(Random number)
Device A

Response Device B

FSK(Modified number)
(b)

Figure 4.7: Distribution of session keys (a) and device authentication (b).

To authenticate another device, BACnet uses a challenge-response handshak-

ing mechanism, shown in Figure 4.7b. The device sends a challenge message,
containing a random number, to the remote device encrypted with the session
key acquired from the key server. The remote device decrypts the challenge,
modies the random number and sends an encrypted response. The modied
number is tested to see if it has been modied in a correct way. If the number
passes this test the device is considered authenticated. The remote device is the
only device with access to the same session key and is therefore the only device
who can give a correct answer to the challenge. By adding optional parameters
in the challenge message, the origin of data and operators can be authenticated,
and encrypted messaging can be turned on and o. When sending encrypted
messages, only the payload of the APDU is encrypted. The APDU header and
the lower layers are left untouched.
The BACnet specication does not specify the generation of private keys
and session keys, or how private keys are distributed to the devices throughout
the network. This is for the developer to decide.

55
4.7 Interoperability
Interoperability between devices from dierent manufacturers is important for
open solutions. Manufacturers competing lead to products of higher quality
and lower prices compared to a market with proprietary solutions. To achieve
interoperability, the BACnet standard species three parts that help manu-
facturers to develop products with a predictable behaviour and to describe the
product functionality to others. These parts are BACnet Interoperability Build-
ing Blocks (BIBB), Device Proles and Protocol Implementation Conformance
Statements (PICS).
The BIBB is used to describe the functionality supported by a product. The
BIBB is divided into ve areas to describe the dierent parts of BAS: data
sharing, alarm and event, scheduling, trending and device and network manage-
ment. Every BIBB describes one communication capability, which contains one
or more services to perform that capability. Most BIBB are direct mappings
of standardized BACnet services, e.g. Data Sharing - ReadProperty is Read-
Property, meanwhile some are a collection of services, e.g. Data Sharing - COV
include all three COV services. A BIBB is described from two angles, from the
client side (called A) and from the server side (B), shown in Figure 4.8. For each
one of these it is described whether it is an initiator or executor of a request. As
mentioned above, some services require certain objects and properties. These
are also required for the BIBB including those services.

Data Sharing−COV−A (Client side) Data Sharing−COV−B (Server side)

BACnet Service Initiate Execute BACnet Service Initiate Execute

SubscribeCOV X SubscribeCOV X
ConfirmedCOVNotification X ConfirmedCOVNotification X
UnconfirmedCOVNotification X UnconfirmedCOVNotification X

Figure 4.8: The Data Sharing - COV BIBB and included services.

A BACnet Device Prole is a generic specication of a BACnet device. These

devices come in six dierent types corresponding to commonly used building
automation units: operator workstation, building controller, advanced applica-
tion controller, application specic controller, smart actuator and smart sensor.
Every prole is a collection of BIBB. The proles describe the minimal require-
ments for a device of that type to full its functional needs. A prole can be
extended with any number of BIBB or vendor-specic services for additional
functionality. The simplest device type, a smart sensor, only needs to imple-
ment one BIBB, the server side part of the read property service, meanwhile
the most advanced, building controller, requires as many as 25.
For all devices conforming to the standard a PICS have to be present. The
PICS is a document created by the manufacturer. The document provides de-
tailed information about what BACnet capabilities the device implements. The
information contained in the document includes the following: product descrip-
tion, prole supported, BIBB implemented, standard and proprietary objects
supported, optional and writable properties for every object and underlying

56
transportation media supported. When certifying products, the features de-
scribed in the PICS are tested to guarantee compliance to the standard and
other BACnet products. The PICS is a document open for everyone and can
be used by network installers to nd suitable products for an installation.

57
Chapter 5

Design and implementation

This section describes the design of the WSN and BAS integration and the
operation of a sensor node based on the dierent requirements described in the
previous sections.
The goal with our design is to allow wireless sensor network devices to inter-
act and add value to existing building automation systems. The design should
also be easy to extend and should be able to suit as a baseline for a fully
functional implementation. We will realize this by implementing BACnet func-
tionality directly on the WSN devices. This design allows the wireless control
and sensor devices to communicate with other parts of the building automation
components without any additional requirements using so called native BACnet
protocol over IP. Our design does not cover a complete production ready sys-
tem so the general constrains section describes the limitations. We motivate the
most important architectural strategies followed by system architecture. Before
the detailed design we list some minor design limitations.

5.1 System overview and overall goals

In this section we dene two goals for the BAS and WSN integration, a robust
integration and a low sensor cost. A desired property of a modern BAS is a
robust distributed system with decentralised control units. In this setup each
control unit communicates with the required sensors. Statistical information
and alarm levels are stored in the controlling node and alarm information is
communicated externally as required.
The network is built up by several controlling and sensing nodes, both wired
and wireless. The logical architecture is independent of the wireless network
setup but in order to have a robust network the wireless nodes should be able
to connect to several dierent sink devices as illustrated by gure 5.1 below.
The dierent sink devices may overlap each other for increased redundancy and
make it possible to take one sink device o line and still have a full functionality
of the network.

58
 One of the goals with sensor network is that each sensor node should have
a low cost to lower the overall cost for the building automation system. This
implicates long service intervals. In order to achieve this, the battery consump-
tion of the devices has to be supervised. The most energy consuming part of
the device is the radio. An essential part of a good power reduction design is
to have a protocol that allows us to turn the radio o and put the device in
standby mode.

BACnet Workstation

BACnet/Ethernet

Vendor Vendor Ethernet Wireless

A B Ethernet
Router Sink Gateway
MS/TP

BACnet/MS/TP
Wireless
Vendor Vendor BACnet
B C

Figure 5.1: Wireless interaction with a BACnet network.

5.2 General constrains

We dene two types of nodes, sensing nodes - also refereed as servers; and
controlling nodes - also refereed as clients. Sensing nodes have one or more
inputs such as temperature or binary buttons. Controlling nodes can have one
or more outputs, such as a buzzer or fan controller. A node can contain one or
more clients and or servers.
A client node either fetch information for sensors, receives value change no-
tications or operator overrides. Based on the information the node performs
a dierent control or alarm actions. This limits the possibility of power con-
straint nodes. For that reason our implementation will have a focus on server
nodes. The protocol and design however does not prevent controlling nodes to
be implemented.

ESB The implementation will be realized on the ESB (Embedded Sensor

Board). The ESB is a multi purpose test device which can be used for demon-
strations and development. It has a number of sensors and allows communica-
tion using either the wireless radio or the RS-232 with SLIP (Serial Line Internet
Protocol). The ESB consists of a:

• MSP-430 low power micro controller

59
  2 kilobyte RAM
 60 kilobyte ash ROM.
 32 kilobyte EEP-ROM
 TR-1001 radio transceiver.
 JTAG port and RS-232 interface.

• Sensors
 beeper
 passive IR for detection of movement
 active IR sender and receiver
 vibration and tilt
 microphone
 temperature.

5.3 Architectural strategies

The protocol evaluation section motivates the use of BACnet over WSN as BAC-
net provides a complete application layer with support for several underlying
protocols including IP. In our design, we argue for the use of native BACnet
for direct use on a wireless sensor network with IP support as key part of the
solution. A native BACnet implementation with the UDP protocol does not
depend on other protocols than IP.
BACnet is an open standard and there are dierent implementations avail-
able both open and closed source. We will extend an existing open source
BACnet stack for embedded systems [45]. Using an available open source stack
will reduce development time since it has some basic support for the device
object and a number of services implemented.
The BACnet service Change Of Value (COV) is however missing in the
current implementation and will be implemented and added to the stack. The
COV service allows a node to send updates upon value changes and reduces
the network trac and the power consumption. As the operating system of
the sensor device needs to be scalable for dierent sensor nodes and resources
we will use Contiki. It has support if various sensors, both wireless and SLIP
networking capability in a POSIX like syntax and some thread support.

5.4 System architecture

The architecture will support a star network topology with one single sink de-
vice. The architecture will consist of a native BACnet network using UDP/IP
as the network protocol. In the wireless network a sink device will communicate
to the wired network. The sink device will only act as access point and not be
a part of the BACnet network. The sink device will also act as the coordinator

60
node in a single star network topology. Each BACnet device will be leaf nodes
communicating directly to the coordinator node. The communication between
the leaf nodes and the sink device will not on BACnet but MAC layer.
To incorporate with the BACnet standard one BACnet prole will be imple-
mented. The prole BACnet Smart Sensor (B-SS) is one of the smallest proles
for BACnet and contains besides the device object one or several objects and
allows data sharing using the Read Property (RP) service. The device does not
need to support alarms, scheduling or trending.
Only using the required services for the B-SS prole will result in a talkative
and energy consuming protocol since the client has to query the sensor each time
it want to get the values. A more energy ecient implementation is to extend
the B-SS with the server side change of value service described below. The
design will therefore support the B-SS standard with the change of value service
extension. Only minimal application functionality and logic is implemented on
the sensor node and the implemented BACnet objects are not scalable in this
implementation

Change of value service The change of value service uses a publish sub-
scribe model where clients subscribe to object changes. When a value change
occurs, the server sends out the new current value to all subscribers. The object
itself needs to support the change of value property. The standard objects such
as the analogue and the binary object supports the change of value property. To
implement the change of value service the device object will be extended with
a subscription list. Active subscriptions for dierent objects will be included
in subscription list. The service has two variants, conrmed and unconrmed
change of values. Conrmed change of values are transmitted until the sub-
scriber send a receive acknowledgment.
We will continue and describe the unconrmed change of value service which
we have chosen to implement in the solution. The client rst subscribe for
changes using the UnconrmedCOVNotication service request. The subscrip-
tion request contains:

• the BACnet identication of the requester,

• identication that the requester can use when receiving notications,
• identication of the object for which notications should be received
• identication of the subscribed property
• subscription lifetime (optional)
• minimum change that will cause a notication

If the subscription was successful a change notication will be sent as a reply.

The same type message will be sent when value change has occurred. The
notication message contains:

• identication provided by the requester

61
 • identication of the requester
• identication of the monitored object
• identication of the monitored property
• subscription time remaining
• list of changed values

The notication server will continue to send out change of value notications
until the subscription of the client has ended or the client ends the subscription.

5.5 Detailed design

In our implementation sensor devices will contain two objects beside the BACnet
device object, an analogue object and a binary object. The analogue object will
hold information about the onboard temperature sensor and the binary object
will be connected to a button on the device.
Due to the limited RAM memory of our sensor devices we will restrict the
communication to 50 bytes per packet. This will however not impact the amount
of packets since the data trac generated by the implemented services does not
exceed the packet size boundary. Only basic power conserving mechanisms will
be implemented. The rst implementation will allow the sensor nodes to enter
sleep mode in a precongured manner.

5.6 Operation of the device

In the start-up phase the wireless sensor device will broadcast a BACnet con-
trol message using the I-Am service describing communication capabilities of
the device. The I-Am service, do not need any reply and includes the BACnet
identication, max packet size, segmentation support notication and vendor
identication. This service is not required but simplies setup for the clients.
When the device is known by the client it can continue and use the Read Prop-
erty service on the device object. In our setup the client will then subscribe
to all objects supporting change of value (analogue and binary). The wireless
sensor device will then operate in a single loop reacting on incoming requests,
reading changes to sensors and eventually transmit them as change of value.

62
Chapter 6

Tests and Results

This chapter describes the tests and results of the implementation and the mea-
surements made on the device. We also discuss these results at the end of this
chapter. To ensure that the nodes behave properly and that the node operations
are meaningful, some function and system tests have to be performed. Since
the size of the implementation is very important for the success on the memory
constrained devices, we have created a series of dierent node implementations.
The dierent node implementations are measured in terms of binary code size
and RAM usage. For testing the integration success of our solution we have a
series of usability tests. Only the results of the latter tests will be discussed.

Test setup The complete test setup includes two ESB devices and two com-
puters. One of the ESB devices is acting as a wireless sensor device, running
our wireless BACnet implementation (BACnet Smart Sensor). The other ESB
is acting as a sink device. The sink is connected to one of the computers through
its serial interface, using SLIP to forward packets from the wireless device. The
sink is only running the Contiki core that makes it possible to relay incoming
radio data to the RS-232 interface and vice versa. The computer connected
to the sink is acting as a router of IP trac and is also the interface for the
BACnet/IP network. The sink/computer pair is the gateway between wired and
wireless BACnet. The PC connected to the routing computer is the BACnet
workstation.
For testing our solution have we used the following applications: Virtual
Test Shell (VTS) [46], BACnet for Linux [45], BACnet-OPC bridge with Larmia
Atlantis as the building automation workstation.

Function and system tests To test the functionality implemented in the

node we directly connected the BACnet node to a computer running VTS and
BACnet for Linux. In order to verify that the node is functioning according to
the BACnet specication we used VTS to generate BACnet packets with specic
content that would execute the dierent parts of the implementation. When
these parts where executed, events where trigged on the node, for example to

63
lit a diode, to give immediate feed back about the behaviour. To verify that the
node generated correct BACnet packets we used the network protocol analyzer
Wireshark [47], which have support for the BACnet protocol, to analyses the
packets incoming to the computer.
When the basic functionality was tested with VTS, we used BACnet for
Linux to simulate the behaviour of a simple BACnet workstation, rst with the
node directly connected to the computer and then using the sink and the ra-
dio to see that the wireless connection worked and was able to handle BACnet
communication. BACnet for Linux uses the Remote Device Management Ser-
vices to locate and identify devices, then uses the ReadProperty service to gain
knowledge about the device. BACnet for Linux continues to ask for property
values to always be able to present valid data on its web interface to the user,
for example the value of an analogue input object. It is also possible for the
workstation to subscribe to COV and receive notications of value changes. By
using BACnet for Linux we where able to test all the functionality implemented
in our BACnet Smart Sensor Device.
These tests included the analogue input, binary input and binary output
objects. We used the ReadProperty and COV services to access and fetch data
from the device. We also performed some limited tests together with VTS to
control an object with the WriteProperty service, in this case turning on and
o a led (binary output).

Implementation size The ESB device only has 60 kilobyte of Flash ROM
and 2 kilobyte of RAM. Therefore, we have to make sure that our implementa-
tion does not exceed these limits. Exceeding those limits can lead to dierent
system errors.
The behaviour when the 2 kilobyte RAM limit is exceeded is unpredictable.
In Contiki, the memory management is very limited, especially when it comes
to protecting the heap. If for example the stack size increases so that it will
very close to the heap, it is possible the overwrite data stored there. This might
destroy heap data and result in execution with incorrect parameters and failing
devices. Therefore it is very important that we make sure there is some free
space between the stack and the heap.
To give a picture what is possible to implement on an ESB device, in terms
of BACnet functionality, we have measured these two parameters for eleven
dierent node congurations (shown below), the results of these tests are listed
in table 6.
To check the size of the implementation, we use a tool that comes with
Contiki. This tool uses the compiled binary, the output le from the compiler,
to calculate the size needed on the ESB Flash ROM.
To calculate the RAM usage is not as trivial as calculating the ROM usage.
We had to use the Contiki simulator Cooja [48], which contains a ESB simulator.
With the simulator we were able to get the lowest stack pointer address. This
address together with the stack starting point and the size of the heap made
it possible for us to calculate the total amount of RAM used. Calculating the

64
 Test Flash usage (Kb) Ram usage (Kb)
Test 01 20120 922
Test 02 36096 1687
Test 03 38790 1737
Test 04 39356 1755
Test 05 38730 1793
Test 06 41146 1801
Test 07 39524 1749
Test 08 43274 1843
Test 09 43162 1845
Test 10 43178 1927
Test 11 43682 1853

Table 6.1: Memory allocation for each test.

RAM usage in a simulator might not be totally accurate, but it will give an
indication of the RAM size needed for the dierent congurations.

• Test 01: Only Contiki and uIP

• Test 02: The BACnet base, read property service and device object, no
additional objects added.
• Test 03: The BACnet base and one analogue input object.
• Test 04: The BACnet base and one binary input object.
• Test 05: The BACnet base and one binary output object.
• Test 06: The BACnet base and one analogue output object.
• Test 07: The BACnet base with one analogue input and one binary input
object.
• Test 08: The BACnet base and one object of each type.
• Test 09: The BACnet base with one analogue input object and the COV
service with one possible subscriber.
• Test 10: The BACnet base with one analogue input object and the COV
service with two possible subscribers.
• Test 11: The BACnet base, one analogue output and the write property
service.

6.1 Usability tests and results

These measurements show the energy consumption of an ESB sensor device
used to report temperature changes in a room. The setup for the ESB sensor

65
device includes three AA batteries and has been placed in an apartment room
to measure the temperature during four days (96 hours). For this test we used
an analogue input object for the temperature and the COV service to report the
temperature changes. The granularity of the temperature sensor on the node is
not that accurate. Therefore we only report changes when the temperature has
changed at least one degree Celsius. By using the COV service we can calculate
the estimated energy consumption when energy saving mechanisms is used.
When the test was performed, the device was constantly running with all
sensors and the radio turned on. To save energy, it is possible to turn o
the radio and to enter a deep-sleep mode. In deep-sleep mode only the clock is
running to be able to wake the node up at certain points. To be able to calculate
the energy consumption when using deep-sleep mode from these measurements,
we have added some functionality to the node to simulate that the node is
entering deep-sleep mode and reporting the measurements on wake up.
Average voltage and current value for the ESB sensor device [49].

• Voltage: 3V
• a) ESB with sensors and radio running: 20mA

• b) ESB with sensors running: 12mA

• c) ESB in deep-sleep mode: 8µA

Energy consumption calculation

Calculating the power usage: P (W ) = I(A) ∗ U (V )
Calculating the energy usage: E(J) = P (W ) ∗ t(s)

Test result During the test period, the measuring node sent 9 COV noti-
cations on temperature updates. The time it takes to send an update and/or
check for an update is one second because of an event timer used in the appli-
cation. This timer, as well as other parameters can be adjusted to minimize the
time used in high power consumption modes. Due to the inaccuracy and the
obvious optimizations these calculations should only be seen as an indication of
the energy consumption and life-time in the dierent modes.

1. The processor, all sensors and the radio are constantly turned on.

2. The processor and all sensors are constantly turned on, the radio is on
when sending updates.

3. The node run in deep-sleep mode, waking up every 5 min to check for
updates, turning on the radio when sending updates.
During the test period, the simulated wake up function was run 1180 times
(should have been 1152, but the node clock is a bit faster then the wall
clock). Nine of these times the node was sending updates, the other times
it only checked for changes.

66
 To give an assumption of how long the sensor can operate without changing
batteries in the current setup we have performed some simple battery life time
calculations. The ESB sensor device consists of three batteries with a total of
2700 mAh. For these calculations we use the third test presented above.

• Average power consumption: I ≈ 0.12mA

• Battery life time: T ≈ 2.55years

6.2 Discussion
This section contains a discussion of the implementation and the results of the
tests and measurements.
With the dierent test results as a basis we conclude that an integration of
BAS and WSN is possible using the BACnet protocol. The tests and measure-
ments also pinpoint some problematic areas. Our proof of concept implemen-
tation with substantially of code and compilation optimizations still required
runtime memory close to the stack boundaries. Continued development and
further testing will require a device with more RAM. The usability results show
that crucial for the energy consumption and the life time of a device is how
much the device can enter sleep mode. The ESB device is a multi purpose test
device. Dedicated temperature devices for instance would probably yield much
better energy results. It should be noted that the BACnet protocol requires
each node to be available at all times. Entering sleep mode for ve minutes
does not comply with the protocol.

6.2.1 BACnet implementation

Using the BACnet protocol directly on a wireless sensor device is a good way of
integrating WSN and BAS. Instead of using a proprietary protocol or a propri-
etary designed middle layer protocol. The implemented solution is extendible
and allows a broad integration with dierent vendors and products. As discussed
earlier, the BACnet protocol does not have all of the desired WSN properties.
Most important, the BACnet protocol is not energy aware. The importance of
energy awareness is shown in our usability results. Without the change of value
services the protocol is talkative when using the readProperty. For each prop-
erty of an object the controlling node has to issue a request. This behaviour
can be improved or remedied by either adding support for the BACnet Read
Property Multiple service or the change of value service.
The BACnet protocol also requires that the device is available for requests
at any time. This will be the most limiting factor of the device lifetime and the
maintenance cost.
We suggest a dierent approach to the energy awareness problem. Battery
powered sensor devices with a limited lifetime would benet from a communica-
tion schedule similar to the S-MAC protocol with a communication availability
0 Energy usage in percent compared to have everything turned on all the time.

67
schedule. The schedule indicates when the device is available for communica-
tion. Extending the nodes with support for the communication schedule would
allow the device to enter sleep mode or turn o radio to conserve power.
As described earlier the S-MAC protocol operates in the lower layers of
the network stack. The imposed communication limitations hides important
information from the upper layers and can cause problems for critical building
automation systems.
We suggest instead an application level or BACnet conscious S-MAC like
communication schedule. The information of the communication schedule would
in this case be stored in a new BACnet "communication schedule object". The
normal BACnet services to set and to get data and parameters from the object
could be used to fetch and update the communication schedule. Existing ser-
vices for Read and Write Property would be sucient for changing and fetching
the time table information. It would also be possible and even necessary to
use the change of value service to inform other nodes of any changes in the
communication schedule.
The addition of the new BACnet "communication schedule object" will also
introduce additional rules for communication:

• Messages that are to be sent to nodes using the "communication schedule

object" need to be queued with a timer indicating when the messages can
be transmitted. All BACnet devices that need to communicate with a de-
vice using the "communication schedule object" must therefore implement
this message queue.

• When the device (using the "communication schedule object") turns on

the radio it should send out an I-am request to notify any new devices of
its existence.

• The device should be available for communication long enough for any
other devices to read and write properties on the device including new
properties for the communication schedule object.

• All devices must contain clocks that are synchronized. The I-am request
message sent from the device using the "communication schedule object"
should therefore be extended with the current time of the device. The
devices need to implement a time synchronization protocol.

• The communication restriction is only directed inbounds to the device

with the "communication schedule object". The device may still send
change of value notications to other devices. The same communication
rules do however apply to this device if the notication recipient also has
a "communication schedule object".

The "communication schedule object" will have to contain the following

properties:

• a timestamp from when the communication constraint applies

68
 • a time length for how long the device is available for communication in
the awaked state
• a sleep time, the time the node is asleep
• a node behaviour description during sleep (this property be used to dene
if the device is allowed to suspend the radio only or the whole device).

Since one of the requirements of a BACnet device is that it is available

for request at any time, the imposed communication restrictions would need
a change in the BACnet protocol. Devices with the "communication schedule
object" should be excluded from the availability rule. Other devices that want
to communicate with a schedule restricted device should request the communi-
cation schedule when the device joins the network or sends out a I-am request.

69
Chapter 7

Conclusions and future work

This chapter concludes our thesis and proposes future work to be made on the
subject.
As the literature study has shown wireless sensor networks can be suited for
building automation tasks. The obvious tasks for a wireless sensor device could
for instance be air temperature and moisture measurements. There are today a
small number of products available on the market but we expect it to grow as
the WSN standards and BAS standards evolve.
One important task was to investigate the dierent BAS protocols available
and how the integration should be done. The method of using a building au-
tomation protocol on direct use on top of the WSN has been proven successful.
Common for all of the investigated BAS protocols is the lack of energy aware-
ness. The BACnet protocol has the most potential in providing such features
in the future. We have suggested a high level, S-MAC like, energy conservation
mechanism extension to the BACnet protocol, using the BACnet model with
objects, properties and services.
The big picture of wireless sensor networking and building automation sys-
tems is very interesting. The nature of WSN with a large amount of devices
communicating value changes, more ne grained sensing and control will allow
a dramatic change in philosophy for building automation. The rst argument
is the possibility with more sensing points, a ner grained measurement and
control leading to energy and cost optimization for the building life cycle. The
second argument is decreased installation and retrotting costs with cheap nodes
and simple wireless installation.

7.1 Future work

We argue that the eld of integrating BAS and WSN has a large potential.
We see two obvious areas for improving our solution towards a real application.
The rst obvious step would be to extend the implementation with support
for more complex networks such as the mesh network with more than one sink

70
device. This would allow the wireless sensor network to spread in larger areas
of a building.
The next obvious step would be to improve the energy conservation mech-
anisms making the BACnet protocol energy aware. We suggest an extension
to BACnet with new objects, properties and services for an application layer
implementation of an S-MAC like protocol.
Beyond the improvements of our solution we see that the computing power
of the wireless sensor devices is enough for distributed decision and control in
the building automation area.

71
List of Figures

2.1 Point-to-point centralised control (a), centralised bus control (b)

and distributed bus control (eld bus) (c). . . . . . . . . . . . . . 10
2.2 Illustration of the open and closed control loops. . . . . . . . . . 12
2.3 The three logical layers in BAS and functionality associated with
each level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Four commonly used topologies in wireless networks. . . . . . . . 18
2.5 Zigbee network with a coordinator, routers and end devices. . . . 23

3.1 Two blocks used to control light. When the Switch Block gets an
input from a light switch. It sends this to the Lamp Block who
changes the state of the light. . . . . . . . . . . . . . . . . . . . . 30
3.2 A simple illustration of an OPC server. . . . . . . . . . . . . . . 36
3.3 An example of the address space within an OPC server. . . . . . 37

4.1 The BACnet four-layer architecture (a) and BACnet/IP archi-

tecture (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 BACnet NPDU's: (a) Source to local network, (b) Source to
another network (directed to a router), (c) Router to router . . . 47
4.3 A possible BACnet system architecture. Products from dierent
vendors that use dierent communication protocols. They work
together as a complete building solution. . . . . . . . . . . . . . . 49
4.4 Smart sensor device with a device and analog input object, show-
ing some of their properties. . . . . . . . . . . . . . . . . . . . . . 50
4.5 A client subscribes to COV on the Present_Value property in
the Smart Sensor and recieves a Present_Value notication (a).
When the Present_Value has changed with COV_Increment, a
new notication is sent to the client (b). . . . . . . . . . . . . . . 52
4.6 The variable part of a read property request and response, show-
ing the concept of context and application tags, primitive and
constructed (opening and closing tags) data. . . . . . . . . . . . . 54
4.7 Distribution of session keys (a) and device authentication (b). . . 55
4.8 The Data Sharing - COV BIBB and included services. . . . . . . 56

5.1 Wireless interaction with a BACnet network. . . . . . . . . . . . 59

72
List of Tables
2.1 Common wireless technologies and their technical data. . . . . . 17

3.1 Comparison between the evaluated BAS protocols. . . . . . . . . 45

6.1 Memory allocation for each test. . . . . . . . . . . . . . . . . . . 65

73
Bibliography

[1] W. Kastner, G. Neugschwandtner, S. Soucek, and H. Newmann,

Proceedings of the IEEE 93, 1178 (2005).
[2] C. Tamarit-Fuertes, Automation System Perception First Step towards
Perceptive Awareness, PhD thesis, Technische Universität Wien, 2003.
[3] H. Bolöv, Building automation evolvement interview, Interview, 2006.

[4] K. Wacks, ISO/IEC JTC 1 SC 25 WG 1: Interconnection of Information

Technology Equipment Home Electronic System, Technical Report N 844A,
ISO/IEC JTC 1 SC 25 WG 1, Berlin, 1999.

[5] M. e. a. Vieira, Survey on Wireless Sensor Network Devices, in in Proc.

IEEE ETFA'03, Vol. 1, pp. 537544, Sept. 2003., 2003.
[6] M. Kintner-Meyer and R. Conant, Opportunities of Wireless Sensors
and Controls for BuildingOperation., in In Proceedings of 2004 ACEEE
Summer Study on Energy Eciency in Buildings, pp. 31393152, Amer-
ican Council for an Energy-Ecient Economy, Washington, DC., 2004.

[7] S. Cheekiralla and D. Engels, A functional taxonomy of wireless

sensor network devices, in Broadband Networks, 2005 2nd International
Conference on, pp. 949956Vol.2, 2005.
[8] EnOcean, The power of unused energy, Web page,
http://www.enocean.com.

[9] N. Aakvaag and E. Undheim, Capacity of ZigBee-based Wireless Net-

works, 2005.
[10] W. Ye, J. Heidemann, and D. Estrin, An energy-ecient MAC protocol
for wireless sensor networks, in INFOCOM 2002. Twenty-First Annual
Joint Conference of the IEEE Computer and Communications Societies.
Proceedings. IEEE, volume 3, pp. 15671576vol.3, 2002.
[11] S. Avancha, J. Undercoffer, A. Joshi, and J. Pinkston, Security for
wireless sensor networks, Norwell, MA, USA, 2004.
[12] ZigBee-Alliance, ZigBee Specication v1.0, 2004, ZigBee Document
053473r00, Version 1.00 http://www.zigbee.org.

74
[13] N. Aakvaag, M. Mathiesen, and G. Thonet, Timing and power issues
in wireless sensor networks - an industrial test case, in Parallel Processing,
2005. ICPP 2005 Workshops. International Conference Workshops on, pp.
419426, 2005.

[14] P. Gupta and P. Kumar, Capacity of wireless networks, 1999.

[15] A. Dunkels, B. Grönvall, and T. Voigt, Contiki - a Lightweight

and Flexible Operating System for Tiny Networked Sensors, in Proceed-
ings of the First IEEE Workshop on Embedded Networked Sensors, Tampa,
Florida, USA, 2004.

[16] A. Dunkels, The Contiki Operating System, Web page, 2006-10-10.

[17] A. Dunkels, The uIP Embedded TCP/IP stack, Web page, 2006-10-10.

[18] Industrial wireless community, Industrial Wireless Technology for the 21st
Century, San Francisco, 2002.
[19] F. Capuano, Open Systems: LonWorks Technology and BACnet Stan-
dard, White paper, 2001.

[20] Westensons presentation av LonWorks tekniken, Web page,

http://www.lonworks.se.

[21] LonMark International, LONMARK Application-Layer Interoperability

Guidelines, version 3.4 edition, 2005.
[22] L. Sharpe, IEE Review , 35 (2001).

[23] A. Schwaiger, C. Treytl, Smart Card Based Security for Fieldbus

Systems, in Emerging Technologies and Factory Automation, 2003. Pro-
ceedings. ETFA '03. IEEE Conference, pp. 398406 vol.1, 2003.
[24] D. Snoonian, IEEE Spectrum , 18 (2003).

[25] J. Risén, Standardprotokoll, Presentation.

[26] W. Kastner, P. Palensky, T. Rausch, and C. Roesener, A closer

look on today's home and building networks, in 7th AFRICON Conference
in Africa , vol.2, pp. 12391244, 2004.
[27] F. Rubinstein, S. Treado, and P. Pettler, Standardizing communi-
cation between lighting control devices: a role for IEEE P1451, in Indus-
try Applications Conference, 2003. 38th IAS Annual Meeting, pp. 805811
vol.2, 2003.

[28] L. Zheng and H. Nakagawa, OPC (OLE for process control) specication
and its developments, in Proceedings of the 41st SICE Annual Conference,
pp. 917920 vol.2, Osaka, Japan, 2002, SICE 2002.

[29] Z. Ling, W. Chen, and J. Yu, Research and Implementation of OPC

Server GUI Based on Data Access Specication, in Proceedings of the 5th
World Congress on Intelligent Control and Automation, pp. 14751478,
Hangzhou, P.R. China, 2004.

75
[30] OPC Technology, Web page, http://www.codeproject.com/useritems/opctechnology.asp.

[31] The OPC Foundation, Web page, 2006-11-10.

[32] Why do we need OPC?, Web page, 2006-11-10.

[33] Konnex Association, Web page, http://www.konnex.org.

[34] Konnex Association, System Architecture, 2004.

[35] P. Bernard and N. Kalischek, Physical layer implemetations on Radio

Frequency, 2004, Presentation.

[36] A. Kell and P. Colebrook, Open Systems for Homes and Buildnings:
Comparing LonWorks and KNX, 2004.

[37] Modbus-IDA, MODBUS APPLICATION PROTOCOL SPECIFICA-

TION, version 1.1a edition, 2004.
[38] Q. Liu and Y. Li, Modbus/TCP based Network Control System for Water
Process in the Firepower Plant, in Proceedings of the 6th World Congress
on Intelligent Control and Automation, pp. 432435, Dalian, China, 2006.
[39] ProtoCessor - RTU Protocol Overview, Web page, 2006-11-07.

[40] Modbus-IDA, MODBUS MESSAGING ON TCP/IP IMPLEMENTA-

TION GUIDE, version 1.0a edition, 2004.
[41] ASHRAE, BACnet - A Data Communication Protocol for Building Au-
tomation and Control Networks, ansi/ashrae standard 135-2004 edition,
2004.

[42] J. Risén, BACnets Byggstenar, Online, 2006.

[43] L. Haakenstad, The Open Protocol Standard for Computerized Building
Systems: BACnet, in Proceedings of the 1999 IEEE International Con-
ference on Control Applications, pp. 15851590, Kohala Coast-Island of
Hawaii, Hawaii, USA, 1999.

[44] J. Risén, BACnets Byggstenar (3) - Tjänster ger order, Online, 2006.

[45] BACnet for Linux, Web page, 2005, http://bacnet4linux.sourceforge.net/.

[46] Virtual Test Shell, Web page, 2006, http://sourceforge.net/projects/vts.

[47] Wireshark, Web page, 2005, http://www.wireshark.org/.

[48] N. Finne, J. Eriksson, A. Dunkels, F. Österlind, and T. Voigt,

Cross-level sensor network simulation with Cooja, in Proceedings of Real-
Time in Sweden 2007, Västerås, Sweden, 2007.
[49] ScatterWeb, The self-conguring wireless communication platform, Web
page.

76