Using the KNX model to enhance houses intelligence · 2017. 2. 22. · This paper will show that...
Transcript of Using the KNX model to enhance houses intelligence · 2017. 2. 22. · This paper will show that...
KNX Scientific Conference 2010 From home automation to smart homes
From home automation to smart homes
Using the KNX model to enhance houses
intelligence
Mathieu Gallissot — Olivier Gandit
SIRLAN Technologies
12 bis rue des Pies,
38360 SASSENAGE
FRANCE
[email protected], [email protected]
ABSTRACT. This paper will show that the KNX application model, used as a
middleware, can be the main basis of the Smart Home concept implementation. We
will also show that this architecture meets marketing, end users concerns as well as
state of the art technology and standards integration.
KEYWORDS: Home automation, smart homes, middleware, KNX
1. Introduction
To answer to the home automation growing needs, industrials
started to develop systems in the early 70’s, and nowadays, home
automation systems are widely available. Despite the strong
disparities amongst cultures and installations standards, the KNX
protocol was successfully normalized at a worldwide scale to
constitute a “worldwide standard for home control”. This protocol
synthesizes the state of art of available solutions for home
automation, providing HVAC, Lighting and Energy control for the
residential market.
KNX Scientific Conference 2010 From home automation to smart homes
In recent years, new visions such as ubiquitous computing and
pervasive computing have largely developed with the constant desire
to bring people and machines closer. Thus, IT has made a place in
everyday life, through mobile terminals, digital televisions, on-board
computers and other digital services. Due to sustainable development
problematics, the housing has become an attractive focus for
industrials. This has led to many innovative projects initiatives on
energy savings, comfort gain and elderly dependency management.
The combination of these visions had brought a new paradigm, called
“smart homes”. The main difference with home automation would be
the transversality of the solution. In order to succeed, smart homes
would need an overall architecture, including a home automation
system (usually autonomous) and external services, such as web
services (weather stations, A/V streams…), smart phones (user
interaction)...
SIRLAN Technologies, a company built after the SIRLAN
European project (IST 12295), had specified in 2003 a Home
Intelligent Terminal (HIT) primarily designed to integrate such
architecture. As part of recent research and with the recent launch of
a residential “home automation” market called “Comfortice”, the
company extended its initial design to integrate some “smart homes”
concepts. Requirements and architecture for this integration will be
presented in this paper, considering technical issues, and marketing
prospects.
2. Reasons to go “smart”
2.1 Home automation: high cost and poor usage
Over the years, home automation has suffered from a low market
development related to a poor public image. Reasons of this poor
market image are linked, according to surveys, to high costs and
technology adoption difficulties.
KNX Scientific Conference 2010 From home automation to smart homes
The first axis of inadoption is explained by Ph. Mallein with the
CAUTIC method. First home automation products was highly
technological, and in disruption with both installer and user habits.
Focusing on the couple product/service, Ph. Mallein states that
products didn’t match the user needs, and were more about a
technological demonstration about the state of art which existed. This
vision is confirmed by professional press, were the idea of “products
conceived by engineers for engineers” is often recalled.
This technological disruption had a direct impact on prices. By the
time, installers was unfamiliar with this technology, and had to use
qualified workforce such as integrator services in order to manage
installation. This extra cost was non-negligible, and penalized
development of the home automation market.
2.2 The 21st century home
Since the early nineties, digital devices arrived slowly in the home,
starting with PC and internet. With the development of these
technologies, wireless and mobile devices followed. Nowadays, TV,
video game platforms, media centers, picture frames are just a small
number of connected devices which can be found in somebody's
home.
In this context were devices are more and more present into user's
lifestyle, usages and acceptance to new technology develops in a
way were home control is wanted.
3. Smart home service infrastructure requirements
3.1 Adaptation to environment diversity
As commonly admitted, each building is unique, regarding its
architecture, its location and its usage. Other diversities, more
specific to home automation and smart homes, can be also found
dealing with legislation (from one country/continent to another) and
KNX Scientific Conference 2010 From home automation to smart homes
amongst technical specificities (protocols and specific
implementations).
Considering for example the French market, insurances
companies did not approve the KNX standard to be used for alarms
systems. Therefore, other standards or proprietary technology must
be used, and interfaced with the infrastructure in order to be
compliant with housing insurance contracts. Technical specificities for
this same market includes HVAC control with the “Fil Pilote”, and a
energy metering proprietary protocol “Téléinfo” installed for each
domestic and industrials electric meter.
On the other hand, while typical home automation system has a
relatively long life cycle (with an average of 25 years, identical to
electrical installations), brown and white products have a shorter
cycle of life, with renewing every 5 - 10 years (average for recent
products given manufacturers datasheets). The technology
associated to these products also changes faster, and therefore,
systems must adapt in consequence.
As a consequence, smart homes should be adaptable to each
possible configuration. This adaptation concerns multiple field buses /
control protocols management, host hardware / system and dynamic
service deployment. Most of these constraints has led to the OSGi
specification, which, with a service oriented approach, allows
software to evolve with its environment.
3.2 The need for a middleware
3.2.1 KNX easy mode virtualization
In the smart home, embedded automatisms collaborate to provide
to end users the best balance between comfort and costs. These
automatisms may located in embedded devices, controllers, and
even in the server (see next section).
KNX Scientific Conference 2010 From home automation to smart homes
But we need first to setup a model for these automatisms that is
able to:
● cover all kinds of automatisms,
● adapt to existing installations,
● be future-proof or even propose a vision for unifying the
automatism concept,
● be easily understandable by installers which job will be linking
automatisms together.
We think the best model for such automatism is the KNX easy-
mode channel.
The KNX easy-mode channel is a black box that includes an
assembly of automatisms named functional blocks. It communicates
with the outer world through:
● input datapoints that handle input data from the bus,
● output datapoints that handle output data to the bus,
● parameters used to configure the channel from the bus,
● IRIs, a SIRLAN Technologies add-on to the channel concept
that models IOs with channel user interfaces.
Channels datapoints are associated with a set of connection codes
that technically and semantically qualify each datapoint. To make it
simple, KNX easy mode rules establish that only datapoints with the
same connection code can be connected together.
With the channel and connection code concept, installers can
easily link automatisms together without bothering about setting
group addresses between datapoints. The controller job is then to
calculate the group addresses implies by links between channels.
The channel model is already used in all KNX easy-mode devices.
In our smart home infrastructure, we also centralize channel
instances in the home controller and also on the server.
As all automatisms are modeled as channels, we then have a
seamless graph of bound channels that is distributed across all
KNX Scientific Conference 2010 From home automation to smart homes
hardware nodes: devices, home controller, and server. On this graph,
runtime data is exchanged independently from the fieldbus hardware.
3.2.2 Distributed infrastructure for distributed services
As seen previously, in the smart home automatisms (or channels)
are distributed across the whole infrastructure: end devices,
controller, and server. So we can consider the complete system as a
distributed service infrastructure powered by a distributed middleware
layer.
In this model, service deployment management is a key activity,
and must be considered as one of the main goals of the middleware
layer. Service deployment must be adapted to each target building
and, consequently, be in charge of identified operators who have the
responsibility of each target building.
Services deployment management is also performed in
accordance with automatisms configuration that is held by the
installer electrician. Services may also be upgraded seamlessly, in
other words without shutting down the whole installation. Likewise,
services may be uninstalled without blocking the rest of the
installation.
3.3 Costs control
Smart home services individually have a very low psychological
price, especially in the residential area. Organized as service
bundles, the services may become more tangible.
Consequently, service operators are compelled to consider large
infrastructures so that a volume effect compensates prices low level.
This implies that the smart home concept must genetically include
strong cost control mechanisms in all steps of the smart home setup
process.
We have identified following steps:
KNX Scientific Conference 2010 From home automation to smart homes
● Service development: we expect that many services could be
developed, provided that service development costs can be
minimized.
● Installation setup: this step is performed by installer electricians.
Again the installation process should be worked out so that
installation setup costs are minimized.
● Infrastructure operation: operation costs should grow as low as
possible with the size of the infrastructure.
3.3.1 Service development
To minimize service development costs we suggest the following
principles:
● Use widespread development standards so that many
developers (and not only specialists) can develop services.
● As much as possible limit the development effort to service
business logic by hiding the complexity of service deployment,
setup and operation and providing standardized generic
services. This is exactly the job of a middleware. Besides, as
the middleware implements a KNX channel container, the job
of service developers is reduced to develop what’s within the
channel black box, which is exactly the business logic of the
service.
● Provide a simple SDK that does not imply a long training for
developers
Nevertheless, these intentions cannot mask the fact that many of
these services will be developed for embedded environments, which
implies a specific training for developers we cannot avoid.
3.3.2 Installation setup
Many measures help reducing and controlling installation setup
costs performed by electrician installers.
First the configuration tools must be designed with the installer
state of mind so that installers handle the tool as an evolution of their
KNX Scientific Conference 2010 From home automation to smart homes
current job and not a revolution. We are convinced that the KNX
easy-mode channel model (which represents one automatism) is
handled better by electricians than datapoints.
Besides, we suggest the idea is to provide to electrician installers
a unified configuration tool that would be able to configure the same
way physical channels (i.e. end devices) as well as virtual channels
(i.e. centralized automatisms). This of course includes that all
automatisms are bound the same way regardless of their virtual or
physical nature. The configuration tool should also be able to setup
user interfaces according to installed automatisms. To sum up, we
need a unique configuration tool for the whole installation.
3.3.3 Operation
In solutions using both products and services, the service
development costs must be addressed with extreme care. Product
prices decrease with higher volumes but we cannot expect the same
with services for following reasons:
● service diffusion won't be as widespread as products,
● we expect many more services than products,
● services will evolve more quickly than the hardware they rely
on.
Consequently, service development costs control is a key
requirement, which implies that:
● service development job should focus as much as possible on
service business logic and put aside deployment,
configuration, integration, operation concerns,
● required service development skills are precisely scoped, are
based on widespread technologies and can easily be
transmitted to new developers.
We expect that a great part of building automation installation
costs will be taken by setup costs, as it is already nowadays. So we
must make sure that these costs won't become prohibitive in this
solution approach.
KNX Scientific Conference 2010 From home automation to smart homes
This implies the installation must remain as simple as possible
from the electrician point of view. Consequently, processes including
workshop pre-configuration steps, centralized operation and simple
local validation must be studied.
3.4 Security
Security is a key point in the smart home adoption. Within this
concept, many needs should be addressed like privacy, access
control, confidentiality, persistence, availability, logging, and many
more.
These security services are provided to the smart home users by
professionals. Our key idea in this area is to centralize its operation
on the infrastructure servers. This implies that the link between the
controller and the server must be designed carefully regarding
identification, authentication, integrity, confidentiality and liability.
4. Examples
4.1 SIP Video door station
A recurrent demand from clients to integrators is the possibility to
include access management with the home system. Typical example
is about door/portal stations, optionally equipped with a camera.
These systems are often autonomous, using remote control (for
portal opening) and indoor handset with a push button. Integration
case would include combining timed lighting with portal actions, and
remote access. If sometimes portal actuator has on board inputs and
outputs that can be connected to a home system, it is more
complicated dealing with handset’s capabilities to ensure remote
access management.
Illustrating the adaptability (section 3.2) and distributed service
architecture (section ) requirements for a smart home, we had
integrated SIP capabilities to our middleware using a KNX channel to
KNX Scientific Conference 2010 From home automation to smart homes
manage and inform about door operations, and the distributed
architecture to connect remote SIP clients.
4.2 iCal based scheduler
A great function about home and building management systems
would be scheduling. They are often require for energy management
(using some devices during low tariff options), or heating (adapting
the HVAC mode given presence, energy tariff and energy
availability). Thus, physical home automation schedulers are often
“user reluctant”. If the upside is a great stability over time, and
reliability, the downside would be to be inaccessible for users, mostly
for modifying schedules requiring physical intervention).
With the evolution of IT, and moreover cloud services, trend is to
use virtual agendas. Standardized with iCalendars (RFC 5545), they
prove to be adopted by most mail clients (Outlook, Thunderbird, ...),
available on most Smartphone and desktops or web widgets.
In order to simplify scheduling management for inhabitants, we
designed an iCalendar based scheduler with an adapted GUI. If the
scheduling function remains the same, the input of time slots is done
using an iCalendar compliant files (or URL) instead of using
dedicated software on a physical device. Also, services such as time
synchronization can be added using another IT standard, NTP.
This solution main advantage, in addition of being user friendly, is
the cost reduction due to virtualization. A hardware solution remains
expensive due to electronics and installations costs.
4.3 A/V integration with UPnP
In many movies people can see a great seducer in is Manhattan-
like fashioned loft, pushing a button on a remote control to set up a
romantic scene: fireplace turns on, light is dimmed, shutters are
closing... and the music is turning on with smooth tunes. If this
scenario may be perceived as a cliché, the integration of audio and
KNX Scientific Conference 2010 From home automation to smart homes
video control in an home system may be useful, for multi-room
management, vocal notifications or helpful automatism such as
reducing the volume level when the phone is ringing (such as in
cars).
Thus, home control and multimedia has been distinct from quite a
while: distinct manufacturers, distinct technology (and so distinct
protocols) and distinct market. As KNX trends to be worldwide
adopted for home control, it is the same with UPnP concerning brown
products, especially with its A/V specifications which are better known
as DLNA.
The integration of UPnP with KNX raises a major challenge,
concerning interoperability, in which the Easy Mode channels prove
their efficiency. Wrapping UPnP services into KNX channels allowed
us not only to integrate UPnP functions into a KNX system, but also
to extend UPnP services with scene management.
5. Conclusion
Smart homes are for sure an upcoming challenge. If research
works trend to explore and share promising results concerning this
concept, adoption by industry would imply many efforts.
We have presented in this article our responses to adoption
efforts. We think that using the KNX model, in particular the Easy
Mode specifications, eases the integration of existing technologies
and services into a single, open and standardized system. Even
more, this model can ease market adoption, by abstracting home
automation hardware and focusing on end user services.
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Proxy-based Approach to Expose
KNX Devices through Pervasive
Computing MiddlewareVladimir Palacka1, Markus Taumberger2, Kostas Anagnostopoulos3, Jozef
Koyš1, Jan Prekop1, Juraj Chabada1, Jarosław Domaszewicz4, Tomasz
Paczesny4, Spyros Lalis5
1
KNX Scientific Conference 2010
4th–5th Nov . 2010
1 SAE – Automation, s.r.o. Nova
Dubnica, Slovakia
{vladimir_palacka, jozef_koys,
jan_prekop,
juraj_chabada}@saeautom.sk
2 VTT Technical Research
Centre of Finland
Oulu, Finland
3 Centre for Renewable
Energy Sources, Athens,
Greece [email protected]
4 Institute of
Telecommunications
Warsaw University of
Technology
Warsaw, Poland
{domaszew,
t.paczesny}@tele.pw.edu.pl
5 CERETETH&University of
Thessaly
Volos, Greece
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
What is the presentation
about
21st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Using of POBICOS and KNX together to create
applications with pre-planned infrastructure and ad hoc
added objects
31st year review, Brussels, Belgium1.-2.7.2010
Application using
different objects with
embedded controllers
Pervasive
distributed
computing
platform
Objects are
added ad hoc
Pre-planned
building/home-
automation
infrastructure
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Contens
• POBICOS – what is it
• POBICOS application example
• Application programmer tools supporting creation of
applications with opportunistic behavior in POBICOS
• POBOCOS proxy and POBICOS centralized runtime
• How can be the POBICOS application creation
methodology useful for KNX
• Demand/Response application – implementation
example
• Conclusions
41st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS – what is it
51st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS - what is it
The POBICOS project goal: development of platform and
middleware supporting opportunistic pervasive computing applications,
enabling an easy programming of partially unknown, heterogeneous
object communities.
POBICOS distributed applications are implemented as concurrently running
and interacting micro-agents.
Easy deployment also for complex ad-hoc built systems
Abstract access to resources using ontologies.
Ontologies mainly for home and building automation.
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS objects, nodes, micro-agents, virtual machine
71st year review, Brussels, Belgium1.-2.7.2010
POBICOS Node
Application
program
parts
Middleware
Ge
ne
ric
No
n-g
en
eri
c
Resources
Non-
gen.
agent
Inte
rna
lE
xte
rna
l
RAM
Flash
memor
y
Gen.
agent
GE
GI
POBICOS software
Non-
gen.
agent
NGI
NGE
Resource
descriptors
None-
POBICOS
software
IsOn/isOff
SwitchOn/SwitchOff
POBICOS Object - Lamp
POBICOS enabled nodes
Virtual machine running application
micro-agents
Resources descriptors enable proper
placing of micro-agents on nodes
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS application example
81st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS application example 1/3
Demand/Response application
91st year review, Brussels, Belgium1.-2.7.2010
Gen. agent
Root
D/R
device
NG agent
1
Request
NG agent
User
NG agent
D/R
device
NG agent
2
D/R
device
NG agent
n
Room 1
gen.
agentHuman
presence
NG agent
Room user
preferences
NG agent
...D/R
device
NG agent
1
D/R
device
NG agent
2
D/R
device
NG agent
n
Room n
gen.
agentHuman
presence
NG agent
Room user
preferences
NG agent
...
...
Gross
consumption
NG agent
At design time, it is not
known how many rooms
and how many devices
there will be in the
application run time.
Tree type
structure of
the micro-
agents in the
application
created step
by step from
root
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS application example 2/3
Demand/Response application
• When the application receives a “please lower your power
consumption” request from the energy supplier, it lowers the mode
of operation or turns off all appliances whose (full-mode) operation
is not crucial. After notice from the energy supplier, it resets the
appliances to their normal operation mode.
• The application does not need to know the exact type of devices at
runtime. All that is needed is a high-level classification of
appliances in terms of power consumption and criticality of
operation as well as the ability to query their status (and power
consumption) and trim their operation or switch them on/off. In this
way it demonstrates opportunistic behavior.
• The goal definition: Reducing of electric power consumption of
various demand response (D/R) enabled devices on request.
10
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS application example 3/3
Demand/Response application
111st year review, Brussels, Belgium1.-2.7.2010
Gen. agent
Root
D/R
device
NG agent
1
Request
NG agent
User
NG agent
D/R
device
NG agent
2
D/R
device
NG agent
n
Room 1
gen.
agentHuman
presence
NG agent
Room user
preferences
NG agent
...D/R
device
NG agent
1
D/R
device
NG agent
2
D/R
device
NG agent
n
Room n
gen.
agentHuman
presence
NG agent
Room user
preferences
NG agent
...
...
Gross
consumption
NG agent
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Application programmer tools
supporting creation of applications
with opportunistic behavior in
POBICOS
121st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS support for applications with opportunistic
behavior
POBICOS platform facilitates development of applications with the
ability to discover and exploit whatever resources are available at
runtime in order to achieve the best possible functionality according
to the application requirements.
Main application programmer tools to implement opportunistic
behavior in POBICOS:
• Abstract access to resources – it enbles write a programm code for
incompletely specified (at design time) object communities
• Using of concept descriptors or concept ranges on various
abstraction levels in a taxonomy tree for proper placement of micro-
agents on nodes
• Evaluation of events on various abstraction levels
• Using of instructions on various abstraction levels
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
2nd year review, Sophia-Antipolis, France1.-2.7.2010
Abstract access to resources
alert
alertVisually
alertByDisplayingTextalertByBlinking
alertBySirenSound
alertByVoice
alertAurally
alertBySound
provides
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Choosing of nodes for agents placement using of the concept
ranges conjunction from different ontology taxonomies
Descriptors to locate a node
for a micro-agent
placement are chosen from
one ore more ontology tries
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBOCOS proxy and
POBICOS centralized runtime
161st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
POBICOS application can use except of typical
POBICOS node also POBICOS proxy node
POBICOS Node
Application
program
parts
Middleware
Ge
ne
ric
No
n-g
en
eri
c
Resources
Non-
gen.
agent
Inte
rna
lE
xte
rna
l
RAM
Flash
memor
y
Gen.
agent
GE
GI
POBICOS software
Non-
gen.
agent
NGI
NGE
Resource
descriptors
None-
POBICOS
software
IsOn/isOff
SwitchOn/SwitchOff
POBICOS Object - Lamp
17
Typical POBICOS node built
into the POBICOS object
lamp
POBICOS proxy node enabling access to the
non-POBICOS objects
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
The POBICOS proxy node
18
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Using of individual modules of a legacy system as
external resources for POBICOS nodes
191st year review, Brussels, Belgium1.-2.7.2010
Legacy system bus
Legacy
system
node
External
resources
of the
legacy
system
node
Node
Access
to th
e ext
ernal
reso
urces
Legacy
system
node
Node
External
resources
of the
POBICOS
node
Legacy
system
node
External
resources
of the
legacy
system
node
Node
Access
to th
e ext
ernal
reso
urces
Node
Legacy
system
node
External
resources
of the
POBICOS
node
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Using the whole legacy system as one „POBICOS mega
node “
201st year review, Brussels, Belgium1.-2.7.2010
External resources
of the POBICOS node
Legacy system bus
Mega-Node
Node
External
resource
s
of the
POBICOS
node
Node
Node
External
resource
s
of the
POBICOS
node
Node
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Creating of virtual objects using access to different data
points on a legacy system bus
211st year review, Brussels, Belgium1.-2.7.2010
Virtual
POBICOS
object
created
by grouping of
data points from
more EIB/KNX
devices within
one POBICOS
node.
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Centralized POBICOS runtime
221st year review, Brussels, Belgium1.-2.7.2010
• Centralized POBICOS Runtime (CPR) -
one controller or computer used to run
more POBICOS nodes.
• Real POBICOS nodes running on CPR -
there is more independent node
instances within one CPR
• Virtual POBICOS nodes – nodes are
only simulated within one compact
application (e.g. POSIM described later)
which is able to fulfill a functionality of
the POBICOS API
• CPR is well usable to interact with
EIB/KNX installation because then only
one gateway to EIB/KNX bus is needed
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Opportunisms in hardwired legacy system modules
• Is it reasonable to speak about ad hoc implementation of the D/R
application when using devices hardwired to EIB/KNX?
• When we buy new real POBICOS nodes usable by an
opportunistic POBICOS application, the application should
recognize this node and be able to use the resources of the node.
It is not necessary to enhance or change the application because it
opportunistically uses the new accessible resources. By analogy,
when we create a new virtual POBICOS node using a set of
information accessible on the legacy system bus instead of buying
a new node, the opportunistic application does not need to be
changed to use the resources of the new virtual node.
23
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
How can be the POBICOS
application creation
methodology useful for KNX
241st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
KNX A-mode
251st year review, Brussels, Belgium1.-2.7.2010
KNX model
“Plug-and-Play” configuration
aimed primarily at consumer
products such as White and
Brown goods.
• appliances are provided with the
self-acquisition of the individual
address
• Application Controller usually also
being the Configuration Master for
its application
• configuration of the group
address is done dynamically by the
Configuration Master
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Using of POBICOS centralized runtime as KNX
application controller for A-mode
261st year review, Brussels, Belgium1.-2.7.2010
Centralized
POBICOS
runtime
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Demand/Response
application – implementation
example
271st year review, Brussels, Belgium1.-2.7.2010
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
The Bioclimatic building (BEMS) in The Centre for
Renewable Energy Sources and Saving, CRES (Athens,
Greece) where application runs
28
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
291st year review, Brussels, Belgium1.-2.7.2010
Interfacing POBICOS nodes and EIB/KNX
installation - solution
Centralized
POBICOS
runtime
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Associating data points to ontology concepts
30
Example: mapping of POBICOS
instruction and events for the device of
the type „Human presence sensor“ (HPS)
in the room A4 and A5
Location of the HPS:
For the roomsA4: PONGO_MEETING_ROOM
A5: PONGO_OFFICE_8
Used data points (OPC variables) for
rooms:A4: \\NETxKNX\\192.168.8.2\\11/0/008
A5: \\NETxKNX\\192.168.8.2\\11/0/007
The instruction and events
ontology concepts are the
same for all devices of the
same type
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Using of the instruction and event taxonomies in non-generic agents
31
The D/R
devices
agent
types
The
human
presence
sensor
agent
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Using of POSIM as centralized POBICOS runtime
321st year review, Brussels, Belgium1.-2.7.2010
One compact
application (able to
work with POBICOS
API) with virtual
POBICOS nodes
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
331st year review, Brussels, Belgium1.-2.7.2010
Centralized
POBICOS
runtime with
real nodes –
every node
runs over own
instance of
the TinyOS
simulator
TOSSIM
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
34
Populating an existing community
Testing small demo applications in CRES
• Four imotes are joining the community of the
six virtual nodes
• One of the imotes plays the role of the
gateway to the configuration tool, the PAM
• PAM tool is used to monitor the status of the
network
• An imote is ZigBee-gateway for interfacing
the imotes with the virtual nodes
• Two imotes simulating the heating objects in
rooms A4 and A5
• PC2 is connected to the KNX as well as the
sensors and the actuators in both rooms
• The user interface consists of the PAM tool
and the PC1 which hosts the PAM tool and is
connected to the PAM gateway
PC 1network control
GatewayPAM
KNXGateway
PC 2virtual nodes
Micro-agent
A4-Fan
Micro-agentA5-Fan
Micro-agent
A4-Lights
Micro-agentA5-Lights
Room A4
Lights
Fan
Heating
object
Micro-agent
A4-Heating
Room A5
Lights
Fan
Heating
object
Micro-agent
A5-Heating
User interface BEMSPOBICOS
OPC-Client
A4-Fan
OPC-ClientA5-Fan
OPC-Client
A4-Lights
OPC-ClientA5-Lights
Centralized
POBICOS
runtime
POBICOS — Platform for Opportunistic Behaviour in Incompletely Specified, Heterogeneous Object Communities
Conclusions
• The POBICOS plan-free deployment model is
complementary to the one mostly used by KNX.
• POBICOS platform as well as KNX A-mode enables
creation of the ad hoc built systems.
• POBICOS proxy node and centralized runtime together
with KNX modules can be used together to build complex
applications with ad hoc added objects.
• POBICOS application creation methodology can be used
for KNX A-mode applications.
351st year review, Brussels, Belgium1.-2.7.2010
Proxy-based Approach to Expose KNX Devices through Pervasive Computing Middleware:
Architecture and Implementation
Vladimir Palacka1, Markus Taumberger
2, Kostas Anagnostopoulos
3, Jozef Koyš
1, Jan Prekop
1, Juraj
Chabada1, Jarosław Domaszewicz
4, Tomasz Paczesny
4, Spyros Lalis
5
1 SAE – Automation, s.r.o. Nova Dubnica,
Slovakia
{vladimir_palacka, jozef_koys, jan_prekop,
juraj_chabada}@saeautom.sk
2 VTT Technical Research Centre of Finland
Oulu, Finland
3 Centre for Renewable
Energy Sources, Athens, Greece
4 Institute of Telecommunications
Warsaw University of Technology
Warsaw, Poland
{domaszew, t.paczesny}@tele.pw.edu.pl
5 CERETETH&University of Thessaly
Volos, Greece
Abstract— This paper describes an approach to interface
KNX systems to a novel pervasive computing middleware
called POBICOS1
. The platform does not rely on pre-
planned infrastructure; instead, it exploits objects that are
already available in the home and exposes their joint
sensing, actuating and computing capabilities to home
automation applications. Contrary to a system engineered
for a specific purpose, there is no a priori specified
arrangement or reliance on infrastructure. Incidentally,
such a plan-free deployment model is complementary to the
one mostly used by KNX. POBICOS aims to design,
implement and test a platform that simplifies the
development and the deployment of applications for
heterogeneous and partly unknown object communities.
This is done by providing a middleware transforming an
object community into an open pervasive computing
environment. The key challenge is to enable applications to
take the best advantage of whatever “resource
opportunities,” provided by the available objects, exist at
runtime. The platform aims to make such “opportunistic”
behaviour largely transparent to the programmer. The
paper also reports on a specific implementation of the
architecture. We used the KNX infrastructure deployed at
the Bioclimatic Building at The Centre for Renewable
Energy Sources and Saving, CRES (Athens, Greece). This
paper presents an approach to use an existing KNX
infrastructure through the POBICOS middleware. Proxies
are used to expose groups of KNX devices as POBICOS
objects to POBICOS applications. A general-purpose
architecture of a POBICOS-KNX gateway is presented.
KNX offers a rich set of configuration modes. However, the
POBICOS methodology for the development and
deployment of opportunistic applications, when applied to
existing KNX infrastructures, complements these “native” KNX possibilities with a new type of KNX applications.
1 This work was supported in part by the European
Commission under the FP7 ICT program, in the scope of
the project POBICOS (Platform for Opportunistic
Behavior in Incompletely Specified, Heterogeneous
Object Communities), contract FP7-ICT 223984.
Keywords—Sensor and actuator networks, ubiquitous and
pervasive computing, EIB/KNX applications, smart homes,
applications with opportunistic behaviour, demand/response
applications, opc, web services.
I. INTRODUCTION
The continuous technological developments in the area of embedded computing and networking make it possible to digitally augment regular home objects with computing, sensing, actuation and communication capabilities, making them not only smart but also capable of cooperation with each other. In the near future, the household is likely to be populated with a host of such objects, ranging from usual appliances like a refrigerator, an electric kettle, or a TV, to infrastructural elements like doors, windows, and lamps, down to small devices such as temperature sensors, smoke detectors, and motion sensors.
Significant potential for advanced functionality can be
created by transforming a collection of digitally-
augmented regular objects into an open pervasive
computing platform that allows home automation
applications to exploit the different sensing and actuation
capabilities of participating objects in a combined way.
The collection of digitally-augmented regular objects
should be able to cooperate with traditional home
automation systems and use their modules as own
external resources. One example of application where
such cooperation is meaningful is the Demand-response (D/R) application (Figure 1.). This application should
provide the fulfilment of requirement from electricity
power supplier to reduce the power consumption of
different electrical devices by the initiation of the device
power saving mode with minimizing of impact on the
users comfort. The biggest electricity consumers in
household are heaters, air conditioners and lighting. These
devices are mostly controlled by traditional home
automation system. Devices as washing-machine,
refrigerator and iron … are usually not controlled by that.
But, they also have considerable power consumption and
so should be controllable by D/R application as well.
The D/R application according to the Figure 1
contains the interface with utility system module
providing communication with a utility company to
receive demand to reduce the power consumption and
optionally also to provide a feedback how demand will be
applied – e.g. how much will be the consumption reduced.
The primary optimization module task is to provide that
demand from energy supplier will have only acceptable
impact on inhabitants. The secondary one is to reduce
energy consumption according to the demand. What is
acceptable for inhabitants can be defined using an optional user interface, which can be used also for user
feedback. Interface sensors and actuators provide
recalculations of the requirements from optimization
module to physical values of the different sensors and
actuators. Home automation network can be
heterogeneous using wired and also wireless
communication providing communication within standard
HVAC system as well as between other devices in home
e.g. white and brown goods.
The A-mode mentioned in KNX specifications is
supposed to be used for devices to configure themselves
automatically, and are intended to be sold to and installed by the end user. It can be used just for including white
and brown goods to the applications as mentioned above.
Differently, as by other KNX configuration modes, there
is still very little applications where KNX A-mode is used
and also very little devices prepared to use this mode. We
have also not found any concrete description how to
proceed to create KNX application using A-mode. Using
of POBICOS platform as described below together with
KNX installations can be perceived also as one of
possible implementations of A-mode within applications
using KNX.
II. POBICOS PLATFORM
POBICOS is platform supporting development of
applications for not in advance defined communities of
objects. This kind of applications can be called
opportunistic because they have to be able to use
opportunities which offer different objects just present in
the area covered by the application. For the mentioned
D/R application, it means that the same application code
can be used regardless of in a home only 1 or 3 air conditioners are used, if there is dish washer or not, if
there are 20 or 50 different light sources… The
application should be able to use for example a very easy
user interface (UI) with a few LED’s and push buttons or
more sophisticated UI with TV and set-top box if
available, or a mobile phone.
For development of this kind of applications, we need
to have (1) proper categorization of objects used in
different applications, (2) mechanism for the distributed
application module placing on application objects in
runtime, (3) abstractions and mechanisms for physical
node and topology transparency. As for the point (1), an ontology-driven approach is
used for categorization of objects and also events
happening in these objects and instructions usable in
application programs.
A POBICOS distributed application consists of a set
of software micro-agents which can be moved between
objects when starting the application and in runtime (for
example if an object is added or removed from an
application objects community). The proper placement of
micro-agents is provided by matching of descriptors in
micro-agents and in POBICOS enabled objects containing POBICOS nodes.
To provide abstraction and mechanisms for physical
node and topology transparency (Figure 2) a middleware
layer is used.
boxYet another application could double check that a
POBICOS platform is developed primarily for wireless sensor networks. The first implementation uses
the ZigBee communication standard. But, as the emphasis
is on the application layer (support for creating of
opportunistic applications), it is supposed to be usable on
Figure 1. Communication within Demand-response
application
Figure 2 [1]. Middleware layer for physical node and
topology transparency in a POBICOS distributed
application consisting of software micro-agents
different hardware platforms, different communication
layers and physical media, including those defined in the
KNX standard specifications. POBICOS platform consists
of, except of the middleware core, also from development
and debugging tools.
POBICOS application functionality is provided by POBICOS nodes built into POBICOS enabled objects. A
firmware for POBICOS nodes (Figure 3) is composed
from node (N) and hardware (H) specific (S) and
independent (I) parts. The hardware and node
independent (HINI) part is the most expanded in the entire
middleware. Environment to cooperate with micro-agents
on application layer are only hardware independent parts
HINI and HINS.
HINI is a core middleware part, the same for every
POBICOS-enabled object. It builds on top of the Host
Platform Abstraction API and the Networking and
Security Abstraction API. It uses the node descriptor information received from the node-specific part (HINS);
it passes non-generic instructions to HINS and receives
non-generic events from HINS. There are two types of
micro-agents – generic ones using only HINI part and
non-generic using functionality specific for different
types of nodes. For example, micro-agent enabling to read
actual value of the temperature on the object with
temperature sensor is non-generic one. There is a big
variety different types of nodes, and because of this,
putting only for a concrete node specific part of the
middleware on this node enables substantially reduce requirements on the node memory resources.
Micro-agents are run in a node on top of virtual
machine (VM). Communication between micro-agents
and VM is provided by events which are used by VM to
inform micro-agents what is happening in the node, and
instructions used as request from a micro-agent to fulfil
an action by VM. For example, after changing of a value
on a binary input of the node, an event can be generated.
To change a value on a binary output the micro-agent
sends the instruction for VM. (In fact, terms as e.g. binary input and output are used in POBICOS as little as possible
because they have weak semantics.) There are
programming primitives as generic events (GE) and
instructions (GI) which are used on every node and non-
generic ones (NE and NI). A node descriptor informs
which non-generic programming primitives (events and
instructions) are available on a node. Non-generic micro
agents are automatically placed only on nodes having
implemented necessary non-generic events and
instructions to work with node specific resources as
sensors and actuators. But, the node descriptors based on
used NE and NI are not the only used. A POBICOS object with integrated POBICOS node per se can have many
attributes non depending on NG and NI. For example, the
descriptor for object types as desktop lamp or wash
machine. Descriptor can characterize also e.g. a
POBICOS object placement.
Descriptors within POBICOS platform are not used
only this straightforward way. In fact, methods to work
with descriptors in the POBICOS platform constitute the
main mean enabling creation of applications with
opportunistic behaviour.
There can be different sets of descriptors defined for different application domains organized in domain-
specific ontologies.
Structuring of descriptors in ontologies simplifies the
task of the application programmer when he refers to
incompletely specified (at design time) object
communities. It should be possible to avoid a tedious,
explicit discovery process of individual objects, sensors,
and actuators. As to these entities, it should be possible to
express requirements that are (1) mild (i.e., not overly
restrictive) or (2) soft (i.e., those that need not necessarily
be strictly met) [4]. Finally, it should be possible to
express the requirements using only interesting aspects of the entities in question.
POBICOS enables the application programmer to
think directly in terms an application domain. The
domain model in POBICOS is ontology. Ontologies are a
state-of-the-art technique to model a domain, able to
capture many different relationships (they have so-called
high expressivity). In particular, the fundamental sub-
class/super-class relationship, a cornerstone of
ontological modelling, is ideal as a means of representing
resources at multiple levels of abstraction. Such a “multi-
resolution” representation is advocated by POBICOS as an enabler of opportunistic behaviour comes from one
taxonomy tree in the ontology. Using of combinations of
more abstract and less abstract ontology concepts from a
H – hardware, N-node, S-specific, I-indenpendant, µA-micr-agent
Figure 3. Structuring of the micro-agent firmware [4]
taxonomy tree within micro-agents code enables to create
very flexible micro-agents placement schemes.
Structure of POBICOS domain model and Descriptors are multidimensional – every dimension.
III. THE POBICOS APPLICATION STRUCTURE
A POBICOS application is a collection of lightweight,
distributed, cooperating components, called micro-agents.
The agents of an application are organized into a
hierarchical tree-like structure. The collection is instantiated on top of the POBICOS object community.
The leaves of the tree are agents that interact with the
physical environment by acquiring context information
through sensors or effecting change through actuators.
Intermediate agents typically perform information
aggregation or processing tasks. It is important to note
that the agent tree has no relation whatsoever to the
physical topology of the object community [5].
The root agent is created automatically by the
POBICOS middleware put on one special type of node
called application pill when the application is started. The root may then create one or more agents, which, in
turn, may create additional agents, etc. Application tree
structure may change in time, due to new agents being
created but also existing agents being removed in a
dynamic fashion.
The placement of agents onto nodes, however, is, to a
significant extent, hidden from the application
programmer. Thus, the programmer works primarily with
the logical structure of the application.
The communication within application is also
hierarchical. Every micro-agent can communicate only
with its parent or its children. The application structure is reasoned by the fact that
task to be performed by an application is achieved by
decomposing it and assigning the sub-tasks to the micro-
agent’s children.
Such elementary decomposition using only
hypothetical 2-level hierarchical structure for the D/R
application can looks like in the Figure 5.
Generic root agent will create the following agents:
NG agent “Request” placed on an object which is
able to communicate with a utility company and to
receive requests to initiate/terminate consumption reduction period.
NG agent “User” placed on an object used as an
interface to user who has to accept or deny power
reduction request.
NG agents on objects placed on every D/R enabled
power consuming device2. The main task of these
agents is to receive the user accepted D/R requests and perform the necessary tasks to reduce energy
consumption.
Generic root agent provides here many aggregation and
communication tasks. The D/R device we can understand
as an abstraction of a device which consumes energy and
is able to reduce the consumption on demand [2].
Already on this easy decomposition, it is possible to
show an opportunistic behaviour of the application. Let
suppose that there are really nodes which are by their
descriptor denoted as D/R device. The generic root agent
will be implemented so, that it will create the D/R device
NG agent on whatever device with proper description.
The application need not be modified if number of devices will change. (In fact, there have to be either
different types of D/R agents for different types of D/R
devices or within the D/R agent must be a mechanism to
recognize type of device and call proper code branch. But,
it is not important for this easy example.)
IV. COOPERATION WITH OTHER PLATFORMS
Finding of proper ways for cooperation of the
POBICOS platform with legacy systems, including those
based on KNX standards is useful not only for
marketability of the product. It generates also some
interesting technical considerations which could enrich
also KNX itself. To reconsider them let’s go back to the
2 In spite of the fact that mostly there will not be a
compact device with sensing and actuating functionality
which can be denoted as D/R device it will be shown that
specially when cooperating with KNX devices it has also
a real base.
Figure 4. An example of the object taxonomy tree
Gen. agent
Root
D/R
device
NG agent
1
Request
NG agent
User
NG agent
D/R
device
NG agent
2
D/R
device
NG agent
n
Figure 5. Easy decomposition of the D/R application
terms POBICOS enabled object and POBICOS node
(Figure 6). Every POBICOS node uses its internal
resources as microcontroller, RAM, FLASH memory and
software enabling to run POBICOS application program
parts.
Most POBICOS nodes (except of those providing pure computational tasks) provide access to external
resources. It can be resources of the POBICOS object to
which is POBICOS node built in. In the Figure 6, it is
switch and lamp itself. The external resources can be also
much more complex. It can be one module of a legacy
system or even the whole system. Access to this module
or system provides a POBICOS node using a software
communication driver [2].
Most building automation systems like EIB/KNX,
BACnet and LON works create applications as set of
modules interconnected by a kind of bus. It can be a real
wired bus or bus-like wireless communication. There are
the following possibilities for the cooperation of
POBICOS application with those systems:
Using resources of a specific non-POBICOS node
from legacy system as external resources of a
POBICOS node over direct connection (Figure 7a)
To gain access to the bus of the legacy system and to
use all resources of a legacy system to create
POBICOS applications.
For the second of the cases above, we have two
possibilities:
To use all resources of the legacy system as external
resources of one POBICOS “mega node” (Figure
7b). It is similar to standard POBICOS application
deployment using only POBICOS nodes because all
modules of the legacy system are used as external
resources of only one POBICOS node.
Using access to the legacy system bus, e.g.
EIB/KNX, to offer data points from different
modules for using as external resources for different
POBICOS nodes.
POBICOS Node
Application
program
parts
Middleware
Ge
ne
ric
No
n-g
en
eri
c
Resources
Non-
gen.
agent
Inte
rna
lE
xte
rna
l
RAM
Flash
memor
y
Gen.
agent
GE
GI
POBICOS software
Non-
gen.
agent
NGI
NGE
Resource
descriptors
None-
POBICOS
software
IsOn/isOff
SwitchOn/SwitchOff
POBICOS Object - Lamp
Figure 6. Typical POBICOS object with embedded node
Legacy system bus
Legacy
system
node
External
resources
of the
legacy
system
node
Node
Acces
s to
the
exte
rnal
reso
urce
s
Legacy
system
node
Node
External
resources
of the
POBICOS
node
Legacy
system
node
External
resources
of the
legacy
system
node
Node
Acces
s to
the
exte
rnal
reso
urce
s
Node
Legacy
system
node
External
resources
of the
POBICOS
node
Figure 7a. Using of modules of a legacy system as
external resources for POBICOS nodes
External resources
of the POBICOS node
Legacy system bus
Mega-Node
Node
External
resource
s
of the
POBICOS
node
Node
Node
External
resource
s
of the
POBICOS
node
Node
Figure 7b. Using of whole legacy system as one
“POBICOS mega node
Figure 7c. Using of data points from different modules
as external resources for POBICOS nodes
The last case is much more interesting from the point of
view of applications using KNX or other legacy systems
modules for creation of the POBICOS like applications
with opportunistic behaviour.
As can be seen in the Figure 7c, using of data points
from the legacy bus (not directly from EIB/KNX devices), enables us that EIB/KNX devices must not be
always mapped one to one on the POBICOS nodes.
POBICOS platform has been developed primarily for
distributed computing with distinct POBICOS nodes
embedded into the POBICOS objects. But, e.g. KNX
modules are often created so that one module is used for
more objects. For example, one KNX switching module
provides switching of more lamps.
Another example related to our D/R application –
there can be one EIB/KNX device used as temperature
controller and another one used for one or more actuators.
By grouping of data points from those modules, a POBICOS node for the virtual D/R device object can be
created.
V. CENTRALIZED POBICOS RUNTIME
The application software creation methodology for
POBICOS platform based on using of micro-agents
placed on POBICOS nodes was created primarily for
distributed computing systems. But, in terms of used
hardware, it is possible to create centralized computing
system able to run the same code as written for distributed
system. To provide it, we have two possibilities:
To run more instances of the real POBICOS nodes on one computer.
To create compact software application that will be
able to run all functionality of the POBICOS
programming API using virtual POBICOS nodes.
The both mentioned implementations can be called centralized POBICOS runtime (CPR). Both real and
virtual POBICOS nodes used in CPR can be denoted as
POBICOS proxy nodes. It can be used, as shown in the
Figure 8, to provide involving of modules connected to
the EIB/KNX bus over one communication gateway to
the heterogeneous POBICOS application. This application
contains directly controlled objects with embedded
POBICOS nodes as well as centrally controlled objects.
Centrally controlled objects can have virtually embedded either real POBICOS nodes or virtual POBICOS nodes
depending on using of either more instances of the
POBICOS nodes on one computer or the above
mentioned compact software application .
The POBICOS application, although running in
heterogeneous environment, has to have, in terms of
application deployment, automatic placement of micro-
agents on nodes, communication between micro-agents
the same behaviour as application running in
heterogeneous environment without centralised runtime.
VI. USING OF POBICOS APPLICATION FOR THE KNX
A-MODE.
The Automatic Mode (A-Mode) [9] according to the
KNX standard achieves “Plug-and-Play” configuration
aimed primarily at consumer products such as White and
Brown goods. This takes also into account the fact that
some appliances may be moveable. The concerned
appliances are generally part of an application that has its
dedicated Application Controller, usually also being the
Configuration Master for its application.
The considerations about CPR implicate following
hypothesis for implementation of A-mode according to
the KNX standard. There can be special case of the objects set according
to the Figure 8 where only centrally controlled objects
will be used. Using of POBICOS methodology for
creation of software applications with opportunistic
behaviour together with KNX devices controlled over
CPR can enable systematic approach to the creation of A-
mode applications. CPR can be then use as KNX
Application controller. When using compact software
application for implementation of CPR as described
above, such controller can be implemented relatively
easy.
VII. RELATION BETWEEN APPLICATIONS AND SYSTEMS
BASED ON DATAMODEL AND POBICOS
Most applications for building management systems as
well as industrial control systems are based on application
data model. Different hardware and software modules
have their input and output data-points. By the creation of
applications based on data model, as the first step, the
input, output and status data-points, and as the next step,
interconnections between these data-points are defined.
Creating of these interconnections is in KNX based
systems called grouping.
Contrary to that, the POBICOS platform uses functional application model. It can be seen already in the
Figure 6. Instead of using of a data-point (a variable) for
Figure 8. Including centrally controlled objects (e.g.
on the EIB/ KNX bus to the POBICOS application)[4]
connection between switch on the lamp, an POBICOS
instruction isOn() ( C-language function), which enables
to find out if the switch on the lamp is switched on or not,
is used. For the same purpose, the event (with alike name)
can be generated. But, the difference between data-model
and functional model in this case is not as big as seems to be. Within KNX, either weak type control or strong type
control is used, where not only used data types for
different data-points are defined but also their semantics.
In such case, providing of mapping of the data-points
(with defined semantics) to the POBICOS API
programming instructions can be very intuitive.
Providing of KNX-like grouping in POBICOS means
to interconnect two or more POBICOS nodes by defined
way. Principally, we have two possibilities how to solve
it. The first one is connected with using of POBICOS
proxy nodes. Such a proxy node needs not to solve
cooperation with only one KNX – module but also with more modules. The grouping can be then solved directly
in the proxy node like in the Figure 7c.
The second possibility to implement the grouping goes
out from POBICOS application communication structure.
A parent micro-agent can provide communication
gateway between its children micro-agents. Because of
this, we can provide that the parent micro-agent makes a
grouping between its children. But, when providing KNX
like grouping, it is not enough to provide communication
connection between micro-agents but between concrete
POBICOS nodes. It means, it is necessary to provide that the children micro-agents will be after their creation
placed on correct nodes. As already has been explained,
this placing can be done using matching descriptors on
micro-agents and nodes. This principle is explained in the
Figure 9.
To put micro-agents on proper nodes, the special
grouping taxonomy concepts G1 and G2 are used in this
figure. However, in POBICOS platform is supposed to use concepts having semantics. Because of this, we can
use e.g. concepts from the object placement taxonomy for
grouping purposes instead.
For example, we want to use within D/R application
one KNX module with temperature sensor and another
KNX module with heating actuator placed in the same
room. We create POBICOS proxy node for every from
those two KNX modules and put the same descriptor from
placement taxonomy on both proxy nodes. Within application, a generic agent, where heating control
algorithms will be implemented, will be created. The
generic agent creates thereafter NG agents for
temperature sensing and for heating actuator and using the
same descriptor put them on the proper proxy nodes.
VIII. CONNECTING POBICOS TO THE LEGACY BUS
SYSTEM
Using of POBICOS, we aimed to deploy the D/R
application in bioclimatic building in premises of the
Centre for Renewable Energy Sources (CRES) in Athens
Greece, where already a building energy management
system (BEMS) based on EIB/KNX devices is used. Because of this, it was necessary to prepare
implementation of the hybrid POBICOS application with
native microcontroller POBICOS nodes communicating
over ZigBee with centralized POBICOS runtime
providing approach to KNX modules.
We tried to find solution which would enable a
connection of the POBICOS platform not only to the
EIB/KNX bus but to many different legacy systems for
building automation and also for industrial applications.
Such solution enables the broadly used
interoperability standard OPC. There are OPC servers to all mentioned and also many other systems, so
implementing a gateway to the legacy system as OPC
server and having communication layer on POBICOS
modules implemented as OPC client would enable
interoperability of the POBICOS platform with many
different systems.
But, considering the actual implementation and future
portability of the POBICOS platform, there is one
problem – OPC was initially developed for MS
Windows™ platform and uses DCOM technology. It
would be necessary to have DCOM technology also on a
microcontroller or on a PC hardware platform where POBICOS middleware will run. Although there are
various portings of the DCOM technology on other
platforms, this solution seems to be not optimal.
Fortunately, the OPC technology was moved on higher
level of the platform independency with usage of web
services in the OPC XML DA and OPC UA standards.
Using of solution based on web services has also another
advantage - the possibility to debug, run and provide
visualization of the POBICOS application also over
Internet.
To provide high portability on different computer modules and operating systems, we have developed an
OPC XML DA client for POBICOS nodes in the ANSI C
language.
Figure 9. Grouping in POBICOS [2]
We tested two solutions with centralised POBICOS
runtime. The first one used a few instances of the
POBICOS nodes on the PC with operating system
LINUX. POBICOS middleware for native POBICOS
nodes is implemented above operating system used by
more ZigBee enabled microcontroller systems. To be able to use the same middleware also for centralised runtime,
every instance of the POBICOS node has to run over
discrete event simulator for TinyOS –TOSSIM. Every
node (Figure 10) has own web services client (consumer)
which enabled access the OPC items on the EIB/KNX
server wrapped by OPC XML DA Wrapper.
The second solution was based on the centralised
runtime implemented as compact application. As part of
the POBICOS development platform a simulation
application POSIM has been developed. The simulator
POSIM can be used, not only for debugging of the application, but also as a kind of compact POBICOS
centralized runtime (Figure 11) Virtual nodes for POSIM
are implemented as dynamic linked library modules.
Within every such virtual node can be implemented not
only functionality of the simulated node but a
communication with external entities as well. This fact
was used for implementing of the same OPC clients in
every virtual module as in the previous solution.
IX. APPLICATION SIMULATION ENVIRONMENT
It is not possible to debug an application in a really
used building. An application simulation environment is necessary for that. We have used the software
OpcDbGateway™ from the company SAE–Automation,
s.r.o. enabling to offer simulated data points over XML
DA web services alike way as provides KNX OPC server
in the installation in CRES. Transition from simulated
environment to the real EIB/KNX bus has become thus
very easy. It was possible to run D/R application for
CRES on POSIM, and the visualisation (Figure 11), not
only locally, but also remotely over Internet. For the 1st experiments, the principle according to the
Figure 7c - grouping within proxy nodes has been used.
Every virtual D/R device node used data-points from a
few KNX devices. For example, data-points from
temperature regulator device and heating actuator device
have been grouped within one virtual D/R device-node.
In this context, we have to put the following question.
Is it reasonable to speak about ad hoc implementation of
the D/R application (or other applications) when using
devices hardwired to EIB/KNX?
We suppose that yes. By a standard distributed
POBICOS application with POBICOS enabled objects,
when we deploy some new real POBICOS nodes, the
application should recognize this node and be able to use the resources of the node. It is not necessary to enhance
or change the application because it opportunistically
uses the new accessible resources. By analogy, when we
create and parameterize a new virtual POBICOS node
using a set of information about data points accessible on
the legacy system bus, instead of deploying a new node,
the opportunistic application does not need to be changed
to use the resources of the new virtual node as well. The
fact that the application itself need not be changed is
crucial in this consideration.
X. STRUCTURE OF THE D/R APPLICATION IN CRES
Within D/R application, we have counted with next
types of D/R devices: Light, Brightness-adjustable light,
Fan, Temperature control (enabling to switch between
Figure 10. Connecting POBICOS proxy nodes with
a legacy system bus using OPC and web services [2].
Figure 11. Using of POSIM as centralized POBICOS
proxy[2]
heating and cooling according to the season). To reduce
an impact of the D/R application on inhabitants, we have
aggregated different kinds of D/R devices according to
their placement. Changing of the D/R devices
functionality, in case that demand from the utility
company has come, was affected by status of the human presence sensor node (HPS). An intervention in none
occupied placements can be more radical than in the
occupied ones. There were three types of intervention (1)
switching of a D/R device, (2) changing of a functionality
mode and (3) changing of the required value for a
controller.
The application structure was a little more
complicated as in the Figure 5. The new layer of the
aggregating generic agents for different placements has
been added.
Data points from different KNX devices have been
accessible for the POBICOS centralised runtime over OPC items from the KNX OPC server. It was necessary
to map the OPC to different POBICOS programming
primitives – events and instructions.
We can demonstrate it on the functionally easiest
device - the human presence sensor (HPS). OPC items of
one concrete HPS from the room A4 are mapped
following way:
The OPC item \\KNXOPCserv\\192.168.8.2\\11/0/008 with the
denotation (read a value)
can be mapped on the POBICOS instruction -
pongiIsOn( );
The OPC item \\KNXOPCserv \\192.168.8.2\\11/0/008 with the
denotation (the value changed to True)
can be mapped on the POBICOS event
PONGE_HUMAN_ABSENCE_DETECTED_EVENT
and
The OPC item \\NETxKNX\\192.168.8.2\\11/0/008 with the
denotation (the value changed to False)
can be mapped on the POBICOS event -
PONGE_HUMAN_PRESENCE_DETECTED_EVENT.
There is, except of mentioned instruction and events, concept from the location taxonomy:
PONGO_MEETING_ROOM
used for this concrete placement.
XI. HYBRID CONFIGURATION OF THE CENTRALIZED
POBICOS RUNTIME WITH REAL POBICOS NODES
The first experiments with D/R application has been
done also for a hybrid configuration with real POBICOS
nodes (with own microcontroller module Imote 2)
together with centralized POBICOS runtime using group
of real POBICOS proxy nodes as in the Figure 10.
Proxies on the PC communicate with each other over TCP/IP protocol, coordinated by a software hub – the
Portplex application. To support the process of setting up
and testing of the platform a dedicated Proxy Manager
tool was created. It is driven by a simple text script that
defines a list of executables that compose the given
Centralized POBICOS Runtime. When executed, the
Proxy Manager starts all the proxies specified in the script
assigning them unique node identifiers. Each proxy is
started as a separate process of the operating system. When done, the proxies are being interconnected by
attaching to them the Portplex application.
Tests of the hybrid configuration have been done till
now only in small extent - within two rooms. There were
used six objects from on centralized runtime. Two of
them were created for lights, two for HPS, one for the fan
and one for the demand event generator. The demand
event generator is used to send the signal that the demand
event starts and the signal that the demand event ends.
The lights and the fan in one room are switched on-off
accordingly. Except of this, 4 Imote 2- nodes have been
used. One of them plays the role of the gateway to the tool used to monitor the status of the network. Another
one is the ZigBee-gateway for interfacing the Imote-
nodes with the centralized runtime. The remaining two
Imote-nodes are simulating the heating objects in two
rooms. The four Imote-nodes are communicating
wirelessly [3].
XII. CONCLUSIONS
Our initial intention was to find a way for using of the
different legacy home and building automation platforms
modules together with the new pervasive computing middleware platform POBICOS.
It was shown that there are next possibilities - (1) to
use individual modules as external resources of the
individual POBICOS nodes with a proxy functionality,
(2) to connect wired or wireless bus of a building
automation platform to the centralised POBICOS
runtime. The first possibility is mostly not realistic,
because it is not possible to expect that the legacy home
automation platforms modules will have an inbuilt
connection to the both - automation platform bus and to
the communication layer of the POBICOS platform. The
2nd way is easy to implement using of OPC communication standard.
It was shown that centralised POBICOS runtime can
be implemented as (1) a group of POBICOS nodes with
middleware running above simulated native operating
system used in concrete implementation of the POBICOS
platform (the TinyOS simulator - TOSSIM), (2) as a
compact application implementing the POBICOS API
functionality (POSIM) and enabling thus to run the
POBICOS like opportunistic applications.
From the point of view of KNX devices vendors, it
could be interesting that, as the POBICOS is supposed to be usable with different communication layers, it is
possible to use the POBICOS opportunistic application
creation methodology with devices connected to KNX
communication layers and having implemented
POBICOS middleware. Of course at this moment, it is
only hypothesis which need to be proved.
In the paper described using of KNX modules together
with POBICOS centralised platform can be perceived as
an implementation of the KNC configuration A-mode as a consequence of the POBICOS ability to support
deployment of the applications for ad hoc communities of
objects.
REFERENCES
[1] POBICOS project web site. http://www.ict-pobicos.eu/
[2] V. Palacka, J. Prekop, J. Koyš, P. Lajčiak, J. Chabada, Deliverable
of the project FP7-ICT-223984 D5.1.2 Revised application development report
[3] V.Palacka,J. Koyš, J. Prekop, J. Chabada, P. Lajčiak, M.
Taumberger, M. Jaakola, J. Domaszewicz, M. Rój, T. Paczesny, K.Agnostopoulos, Deliverable of the project FP7-ICT-
223984D5.2.1 -Application deployment and testing report
[4] T. Paczesny, J. Domaszewicz, A. Pruszkowski,G. Georgakoudis, N. Tziritas, S. Lalis,M. Ala-Louko, M. Jaakola, I. Mätäsaho
Deliverable of the project FP7-ICT-223984D2.1.2 Revised system architecture report, PART VI: Node architecture and platform
definition
[5] J. Domaszewicz, S. Lalis,A. Pruszkowski, T. Paczesny, P. Lampsas, V. Palacka, Deliverable of the project FP7-ICT-
223984D2.2.2 Revised Programmer’s Guide and API Manual
[6] J. Domaszewicz , M. Roj, A. Pruszkowski, M. Golanski, and K. Kacperski, “ROVERS: Pervasive Computing Platform for
Heterogeneous Sensor-Actuator Networks”, Proc. WoWMoM 2006, pp. 615-620.
[7] A. Pruszkowski, T. Paczesny, and J. Domaszewicz, “From C to
VM-targeted Executables: Techniques for Heterogeneous Sensor/Actuator Networks”, Proc. WISES 2010, in press.
[8] K. Fishkin, “A Taxonomy for and Analysis of Tangible Interfaces”, in Personal and Ubiquitous Computing, 8(5), 2004, pp.
347-358.
[9] Konnex Association KNX The World’s first open STANDARD for Home and Building Control, Julz 2004 p. 28/
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Building Automation and Control
Multi-Technology System
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
R. Martínez1, C. Gómez1, A. Cuevas1, E. Motoya1, I. Galloso1, C. Lastres1,
C. Feijóo1, A.Santamaría1
1Centro de Domótica Integral (CeDInt-UPM)Universidad Politécnica de Madrid
KNX Scientific Conference 2010
Pamplona, 4th and 5th of November 2010
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
2
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
3
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
1. Introduction
Building Automation and Control Systems (BACS):
• Fast-growing market
• Systems based on different BAC technologies
• Control of complex domotic networks
• Energy efficiency in buildings (40% of total savings in energy
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
• Energy efficiency in buildings (40% of total savings in energy consumption)
Problem addressed:
• BAC technologies integration
• Non-intuitive non-user friendly interfaces
• Context awareness
4
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
5
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
2. Objectives
Multidisciplinary approach:
• Enhanced management of energy consumption in buildings
• CeDInt Energy Efficiency Research Facility (CeDInt-EERF)
• Common BAC protocols Integration
• Test lab for commercial BAC devices
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
• Test lab for commercial BAC devices
System features:
• LAN and Internet connection to the BAC Multi-Technology System
• Highly flexibility, versatility and scalability
• BAC technology commutation with KNX
6
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
CeDInt-EERF
2. Objectives
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
7
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
2. Objectives
CeDInt-EERF
Nominee:
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Nominee:
8
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
9
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. System architecture
KNX
Traditional BAC architecture
versus
BAC Multi-Technology System
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Remote Client
INTERNET
LONWORKS
KNX
DALI, BACNET
OTHER
TECHNOLOGIES
UNDER
DEVELOPMENT
CeDInt Gateway
KNX technology
commutation
10
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
11
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. A. Hardware solution
• Building Control Services:
Lighting Blinds Loads HAVC
KNX OK OK OK OK
DALI
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
– Selection of the active technology is done using KNX protocol
• Metering and monitoring :
IP, EnOcean and Zigbee
DALI OK -- -- --
LON OK OK OK --
BACnet -- -- -- OK
12
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. A. Hardware solution
I N P U T
Control Technology
Blind Buttons
Blind Actuator
Appliances Buttons
Switch Actuator
Lighting Buttons and Presence, Light and IR Sensors
LON / DALI
Local Controler
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
13
O U T P U T
Control Technology
Blind Actuator
(KNX)
Actuator (LON)
Blind Servomotors [1] [2] [3] [4]
Switch Actuator
(KNX)
Actuator (LON)
Appliances [1] [2] [3] [4]
DALI Gateway KNX /
DALIGateway Control
Unit DALI
ECGs [1]… [18]
KNX / BACnetGateway
BACnet Gateway
Indoor Units
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. A. Hardware solution
Lighting System:
• Luminaries equipped with
DALI-enabled dimmable
Electronic Control Gear (ECG)
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Electronic Control Gear (ECG)
• Control: KNX/LON/DALI
14
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. A. Hardware solution
Venetian Blinds
• Facade facing South
• Electrically-controlled
motorized blinds
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
motorized blinds
• Controllers configured to
manage four venetian blinds
by pairs
• Control: KNX/LON
15
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. A. Hardware solution
Electric Loads
• Control appliances with high
energy consumption
• On/Off switching
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
• On/Off switching
• Electric loads control is ready
to implement Demand
Response and Dynamic Pricing
services
• Control: KNX/LON/X10
16
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. A. Hardware solution
HVAC
• Heat Recovery Ventilator unit
• Variable Refrigerant Volume
indoor units
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
indoor units
• BACnet-ANSI/ASHRAE 135
protocol
• Control: KNX/BACnet
17
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
18
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. B. Software solution
CeDInt Gateway
Ontology is used to model the different BAC services
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
JAVA EE
OSGi Framework
Bundles
Ontology
Lin
ux O
per
atin
g S
yst
em
Har
dw
are
Dynamic JAVA components interconnected over OSGi
The system architecture is a set of bundles for development
Multi-platform with an open architecture. LINUX
Service-oriented architecture
19
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. B. Software solution
Ontology
• Models the different BAC services, the communication and data
exchange among different systems and entities
State of the devices to be
controlled.
• Discrete value
State
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Control devices
• Individual elements
• General system
Physical space where
devices to be
controlled are placed
Control actions that may be
performed by the devices
connected to the platform
• Discrete value
• Continuous value
BAC protocol
• KNX, LonWorks, X10, DALI,
BACnet, EnOcean
Thing
Building_Thing
Building environment
Functionality
Domotic network
component
Inspired by DOG Ontology
20
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
3. B. Software solution
Functionality: Entity definition
Room Entity
Room Service EE Manager
BACS EE Strategy Manager
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
has
Control Loads Service
Device/s:
• Capabilities
• Functions
Parameters
has
HAVC Service
Lighting Service
21
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Index
1. Introduction
2. Objectives
3. System architecture
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
3. System architecture
A. Hardware solution
B. Software solution
4. Conclusions and future research lines
22
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
4. Conclusions and future
research lines
Project achievements
� Intelligent Multi-Technology System
� Integration of BAC technologies (KNX, Lonworks, DALI and BACnet)
� Selection between different BAC technologies with KNX
� CeDInt Energy Efficiency Research Facility (CeDInt-EERF)
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
� CeDInt Energy Efficiency Research Facility (CeDInt-EERF)
� Showroom for energy efficiency
� Reduction of energy consumption
Future research lines
� IP access via mobile devices
� Future Demand Response and Dynamic Pricing services integration
23
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
mB
uild
ing A
uto
mation a
nd C
ontr
ol M
ulti-Technolo
gy S
yste
m
Contact info
CeDInt-UPM
Center for Smart Environments
Technical University of Madrid
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
Build
ing A
uto
mation a
nd C
ontr
ol M
ulti
www.cedint.upm.es
Rocío Martínez
Antonio Cuevas
Cristina Gómez
24
Abstract- This paper presents the design of a hardware and software platform aimed to test and demonstrate an integrated, multi-technology Building Automation and Control System (BACS). A premise is that all commercial BAC devices should be testable under the platform, therefore the most representative protocols are supported. Internally, the system uses KNX as a “metaprotocol” to commute the communication paths with the devices. A practical implementation of the described platform has been installed in the Show Room for Energy Efficiency in Smart Buildings. This Show Room is a facility located at CeDInt-UPM.
I. INTRODUCTION
Building Automation and Control technologies belong to a fast-growing market, especially in the recent years. Manufacturers search for their own niche in the market, either embracing standard technologies like KNX or Lonworks, or proposing their own proprietary ones. Given such a wide variety of BAC technologies and devices, integration is a necessity. The described platform has a double purpose: it has to work as demonstrator and test lab for all the available commercial BAC devices (supporting the most common BAC protocols) and it must support all the devices installed at CeDInt-UPM Show Room, including multiprotocol communication with them, in order to compare their capabilities and behaviour. This paper is organized as follows: section II presents previous works on BACS integration. Section III presents the description of the platform developed at CeDInt-UPM, including hardware and software architecture. Finally, conclusions are presented in Section IV.
II. RELATED WORK
The development of new BACS for integration of different solutions aimed to improve in-Building Energy Efficiency has been the objective of several research works. Gateways have been proposed to interconnect devices that use different communications protocols. Intelligent software has been required as long as the system’s complexity increases. [1] describes a service-oriented solution framework to get interoperability in home automation. Its proposed solution uses a central server to translate messages between end-devices. This server includes the development of a software based service using a technology abstract service language (DomoML). A prototype has been implemented considering UPnp and KNX.
[2] proposes a solution based on an IP framework that facilitates the integration of any wireless home automation technology, such as ZigBee and Z-Wave. This work is based on service oriented architecture (SOA). [2] [3] presents an open computing system for home services and a dynamic home control gateway that integrates distributed services based on different technologies, such as Jini and DPWS service. The gateway is based on the OSGi standard. [4] Their OSGi-based MyHome is a framework of smart home that provides integrated user interface and an event-driven, multi-threaded service development platform. The system has been tested in an emulated home environment where peripherals are connected through a ZigBee wireless sensor network with a database for data collection. Politecnico di Torino proposes an ontology-powered Domotic OSGi Gateway (DOG) able to manage different Domotic networks as a single, with independency of the BAC technology. DOG allows managing different networks in a light weight manner, exploiting the DogOnt ontology to support complex interoperation, generalization and validations tasks. [5]
III. GENERAL ARCHITECTURE
CeDInt platform aims to achieve the maximum performance of its architecture in a non-intrusive and transparent way. An application to control and to monitor multi-technology devices is proposed. Figure 1 shows the proposed architecture and functional modules. The system intelligence lays in a dedicated device (BAC Gateway), with IP interface, that integrates any Building Automation Control (BAC) device of the following technologies: KNX, LON, DALI and BACNet. CeDInt solution has its practical implementation at CeDInt Show Room for Energy Efficiency in Smart Buildings. In this way, the pilot CeDInt Energy Efficiency Research Facility (CeDInt-EERF) has been built. CeDInt platform has been designed to be highly flexible and versatile, enabling the integration of future technologies and devices, nowadays under development.
Figure 1. Architecture and functional modules
Building Automation and Control Multi-Technology System
R. Martínez1; C. Gómez2; A. Cuevas3; E. Motoya4; I. Galloso5; C. Lastres6; C. Feijoo7; A.Santamaría8 [email protected], [email protected], [email protected], [email protected], [email protected],
[email protected]; [email protected]; [email protected]
Centro de Domótica Integral (CeDInt-UPM) Universidad Politécnica de Madrid
Tel. +34 913364500, Fax. +34 913364501 Edif. CeDInt-UPM. Campus de Montegancedo. 28223 Pozuelo de Alarcón. Spain
A. HARDWARE SOLUTION
CeDInt platform approaches the energy efficiency challenge from a practical perspective. Several building automation technologies have been integrated into a common EERF. According to robustness, technology maturity, market adoption and functional versatility criteria, the following technologies have been selected and integrated in CeDInt Platform: For Building Control Services: KNX, Lonworks, DALI and BACnet. For metering and monitoring tasks: Ethernet, EnOcean and Zigbee. Flexibility and scalability requirements have been considered having into account both the connection of new Home Area Network (HAN) devices and the integration of new BAC technologies. The aim is to integrate any commercially available device/system in order to test their performance and their suitability for energy management purposes. CeDInt Platform controls lighting, blinds, electric loads (appliances) and HVAC systems. Each controllable device can be operated using several technologies (only one technology in a given moment). The selection of the active technology is done using KNX protocol. Table 1 shows the interconnection between different systems and the control technologies implemented at CeDInt- EERF.
Table 1. Control technologies
Following, the controllable systems are listed: Lighting CeDInt-EERF has 36 luminaries, each one equipped with a DALI-enabled dimmable Electronic Control Gear (ECG). All units are connected using a single common bus. ECGs can be accessed only through DALI. The global control system can use one of the following protocols: KNX, LON or DALI. So, when using KNX and LON protocols, control messages must be translated using a specific gateway: LON/DALI or KNX/DALI. Figure 2 shows the intelligent commutation diagram (yellow), which guarantees that only one DALI gateway is activated and connected to the ECG units in a given moment. This commutation scheme is controlled using KNX. So, KNX is the key element of this EERF. Venetian Blinds CeDInt-EERG facade faces South and it is equipped with electrically-controlled venetian blinds. This is an ideal scenario to test the effectiveness of intelligent control strategies in order to graduate natural indoor lighting and heat exchange with the outside. The venetian blinds system consists of a linear 230V AC
servomotor, with a fixed rod sliding along its 200mm body. The controllers can accept both KNX and LON inputs. The intelligent commutation diagram uses KNX to select one of the two possible paths. The controllers have been configured to control four venetian blinds by pairs. The room is divided in two independent areas.
Figure 2. Venetian blinds/Light Control System
Electric Loads The purpose of this subsystem is to control those appliances with high energy consumption. The only action considered in this subsystem is on/off switching. As in the previous subsystems, the KNX-base communication diagram allows the selection of the control technology (see Figure 2). Electric loads control is ready to implement Demand Response and Dynamic Pricing services. These services will reduce energy demand on CeDInt-EERF by a voluntary temporary adjustment of electricity demand as a response to a price signal received from the utility or a reliability based action. HVAC The Heating and Air Conditioning System (HVAC) consists of multiple sets of one Heat Recovery Ventilator unit and several Variable Refrigerant Volume indoor units linked to an outdoor unit and individually commanded by remote manual controllers. These sets are also connected to a BACnet Gateway that provides status information of the HVAC units and receives commands to/from a client supporting BACnet-ANSI/ASHRAE 135 protocol (see Figure 3). The communication between BACnet and the rest of BAC technologies is done using a KNX/BACnet Gateway, chosen for being the most versatile, mature and robust solution.
Lighting Blinds Loads HAVC KNX OK OK OK OK DALI OK -- -- -- LON OK OK OK --
BACnet -- -- -- OK
Figure 3. HAVC / Loads System
B. SOFTWARE SOLUTION
Software design starts considering the platform as a generic BACS, using CeDint-EERF as a real test scenario, aimed to face up the energy efficiency challenge. The solution has been based on a collection of inter-dependent functional modules, to get the desired behavior maximizing the efficiency of CeDInt-EERF. The system software architecture must support dynamic changes in the software functional modules. Functional modules management must be highly flexible: to register new modules, to remove existing ones and to edit active modules. These management operations must be done without interfering with other software elements. CeDInt Platform is a multi-platform with an open architecture. Therefore, Linux has been chosen as the operating system and OSGi as the dynamic module system. OSGi assures coupling minimizing and bundles management. OSGi is also suitable for interoperable applications and services over a wide variety of devices. OSGi technology enables a services-oriented architecture allowing the components to be dynamically discovered for collaboration [6]. Security is a Java property itself, running the components in a shielded environment. At the end, the whole system is a set of dynamic components interconnected over OSGi. The system architecture is a set of bundles for development. An Ontology is used to model the different BAC services and the communication and data exchange among different systems and entities considered in the BAC application. The design focuses on the interoperability between the different home automation protocols available at CeDInt-EERF. The Ontology, inspired by DOG Ontology [5], is considered as a hierarchical tree of 5 branches. Each of these branches is a class used to represent devices. These classes are described below:
The class Building Thing models the control devices. Devices can be individual elements or a general system installed in the building (such as HVAC, security system or the electrical system).
The class Building environment models the physical
space where the devices to be controlled are placed. Each device knows its location, (building and type of room).
The class Functionality models the control actions that may be performed by the devices connected to the platform.
The class State models the state of the devices to be controlled. Different states are considered: discrete value (on, off, up, down, presence detection) or continuous value (humidity, temperature, blinds position, luminance, electric energy/power).
The class Domotic network component models the BAC protocol that controls a device. The following protocols are considered: KNX, LonWorks, X-10 and EnOcean.
In order to define the actions to be performed in a room, some parameters are needed.
The size of the room or the area under consideration. Capabilities/functionalities of devices installed in the
room. Room Energy Efficiency (EE) strategies. Building Energy Efficiency strategy.
These parameters define an entity, and different entities constitute the whole BACS (see figure 4).
Figure 4. Software architecture scheme
The EE strategy applied to a room depend on several factors:
Room parameters: temperature, humidity, luminance values... (outdoor and indoor).
Devices/s installed in the room: capabilities and functionalities according to the room characteristics and the user requirements.
Services: specific functions offered to the user. Room service EE Manager: management of the
cooperation between the room services. BAC EE strategy Manager: integration of a global
EE management. The software solution supports also the following aspects:
HAN & IP networks access. BAC protocols management: specific drivers for each
device.
IV. CONCLUSIONS
A set of BAC technologies (KNX, Lonworks, DALI and BACnet) has been integrated into a common EERF in the Center for Energy Efficiency and Smart Buildings (CeDInt-UPM). The integration of these BAC technologies has been carried out using KNX as the key factor, allowing the selection between different protocols. This facility aims to reduce the energy consumption of lighting by 35% and of HVAC systems by 30%. This partial improvement represents a global reduction of 16,65% in the total consumed energy. CeDInt-EERF is also prepared to test different Demand Response and Dynamic Pricing services. Their integration, will contribute to a further reduction in energy consumption. The main line of future research is the addition of IP access to the system via mobile devices.
V. REFERENCES
[1] V. Miori, L. Tarrini, M. Manca, and G. Tolomei, “An open standard solution for domotic interoperability,” Consumer Electronics, IEEE Transactions on, vol. 52, no. 1, pp. 97–103, 2006. [2] J. Brønsted, P. Madsen, A. Skou, R Torbesen. “The HomePort System”. Proceedings of the 7th IEEE conference on Consumer communications and networking conference, pp 754-758, 2010. [3] J. Bourcier, C. Escoffier, and P. Lalanda, “Implementing home-control applications on service platform,” Consumer Communications and Networking Conference, 2007. CCNC 2007. 2007 4th IEEE, pp. 925–929, 2007. [4] H. Huang, W. Teng, S. Chung. “Smart Home at a Finger Tip: OSGi-base Myhome”. Systems, Man and Cybernetics, 2009. SMC 2009. IEEE International Conference on, 2009. [5] D. Bonino, E. Castellina, F. Corno. “DOG: an Ontology-Powered OSGi Domotic Gateway”. Tools with Artificial Intelligence, 2008. ICTAI '08. 20th IEEE International Conference on, pp 157-160, 2008. [6] OSGi http://www.osgi.org/About/Technology
FIBER OPTIC SENSOR IN A KNX NETWORK AND
REMOTE MONITORING
Universidad Pública de Navarra
Campus de Arrosadia, 31006 Pamplona
Tel.: 948166166
J.A. Nazabal
R. Unzu
G. Vargas-Silva
M. Galarza
R.J. Hernández
C. Fernández-Valdivielso
F. Falcone
M. Lopez-amo
N. Matías
KNX Scientific Conference
Pamplona 2010
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
Location:
� “Trabajos Catastrales S.A.”, “Gamesa Innovation
Technology ” and “OPNATEL” Headquarters.
� Located in front of the Innovation Center and next
to the Eco-city of Sarriguren (Navarra, Spain).
� Disposes of advanced technological solutions that
allow for an efficient use of the energy needs of the
building
LOCATION AND OBJECTIVESLOCATION AND OBJECTIVES
Objectives:
� Use fiber optic sensor for monitoring the temperature and deformation of
the enclosure of the telecommunication tower.
� Integrate the optic sensors in a KNX network
� Real-time remotely monitorize the sensor values
KNX Scientific conference 2010 Pamplona, 4th November 2010
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
ENCLOSURE PANEL’S STRUCTUREENCLOSURE PANEL’S STRUCTURE
KNX Scientific conference 2010 Pamplona, 4th November 2010
The enclosure panel’s skin are of monolithic glass and the core is an alveolar/reticular polycarbonate structure.
Advantages:
� Excellent flexion and compression mechanical properties with very low density. � Excellent outdoor conditions behavior.� Good acoustic behavior. � Transparent to electromagnetic waves.
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
FBG SENSORSFBG SENSORS
KNX Scientific conference 2010 Pamplona, 4th November 2010
� A Bragg grating (FBG) consists in an optical fiber segment with a periodic variation of the
refraction index all over it’s core.
� Many FBG sensors can be multiplexed in the same optical fiber.
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
The used sensor are based in Bragg gratings (FBG)
Advantages:
� Multiplexing possibility � Low attenuation � electromagnetic immunity � Low weight� Corrosion free� Safe
The optical network has 30 sensors, 20 of temperature and 10 of deformation divided in 4 branches connected to the optical interrogator’s optical channels with a sample rate of one sample per second.
An optic accelerator placed in building’s top is connected to the interrogator’s XPI module with a sample rate of 800 samples per second
OPTICAL NETWORKOPTICAL NETWORK
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
KNX NETWORKKNX NETWORK
� Weather station:
� 1 temperature sensor
� 1 twilight sensor
� 3 brightness sensors
� 1 wind sensor
� 1 rain sensor
� IP/KNX Interface:
� 1 network connections (RJ 45)
� 1 bus KNX connections
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
PHYSICAL SYSTEM CONNECTIONPHYSICAL SYSTEM CONNECTION
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
NETWORK PROTOCOLSNETWORK PROTOCOLS
Connection-orientedConnectionless
Not immediate data sendingImmediate data sending
Heavy weightLight weight
ReliableUnreliable
TCPUDP
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
LOGICAL SYSTEM CONNECTIONLOGICAL SYSTEM CONNECTION
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
BRAGGMETER MODULEBRAGGMETER MODULE
� Programmed in LabVIEW
� Acquires optical sensor data
� Has no graphical interface, programmed for working in background
� Shared variables
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
CALIMERODAEMON MODULECALIMERODAEMON MODULE
� Programmed in Java
� Acquires KNX sensor data
� Uses Calimero Library
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
CALIMERO LIBRARYCALIMERO LIBRARY
� Developed by “Vienna University of Technology”
� Is a KNXnet/IP protocol implementation in Java
� Allows communication with a KNX network using IP packets.
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
HUBDAEMON MODULEHUBDAEMON MODULE
� Programmed in Java
� Retrieves sensor data acquired from the other modules
� Stores de sensor data in a MySQL database
� Opens a port for requesting sensor data for monitoring
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
BRAGGSCOPE MODULEBRAGGSCOPE MODULE
� Programmed in labVIEW
� Uses Ni-daq
� Uses data compression
� MySQL Data storage
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
SENSORVIEWER (I)SENSORVIEWER (I)
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
SENSORVIEWER(II)SENSORVIEWER(II)
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
SENSORVIEWER(III)SENSORVIEWER(III)
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
SENSORVIEWER(IV)SENSORVIEWER(IV)
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
CONCLUSIONSCONCLUSIONS
� The higher panels suffers more deformation due thermal conditions and the wind effects.� The possibility of integrating optical and KNX networks has been demonstrated.
Strain measurement including temperature effects Strain measurements excluding temperature effects
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
THANK YOUTHANK YOU
Universidad Pública de Navarra
Campus de Arrosadia, 31006 Pamplona
Tel.: 948166166
Universidad Pública de Navarra
Campus de Arrosadia, 31006 Pamplona
Tel.: 948166166
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
J. A. Nazabal, R.Unzu , G. Vargas-Silva, M. Galarza, R. J. Hernández, C. Fernández-Valdivielso, F. Falcone, M. Lopez-Amo and N. Matías
Departamento de Ingeniería Eléctrica y Electrónica, Universidad Pública de Navarra, Campus de Arrosadia s/n, 31006, Pamplona.
Persona de contacto: Juan Antonio NAZABAL ([email protected]).
Abstract— This paper shows the utilization of a fiber optic sensor system for monitoring the enclosure of a communication tower. Such enclosure is composed by double glass panels filled with an alveolar type structure. The system monitors remotely 31 FBG based sensors and 7 KNX based sensors. The results related to the measurements recorded into the glass alveolar panel has been used for assessing the structural reliability of the panel, under thermal and mechanical working conditions
Index Terms— Fiber optics sensors, new materials, intelligent buildings, multiplexing
1 Introduction
Optical sensors based on Fiber Bragg Gratings (FBGs) have been widely used in monitoring of civil
structures. They show very interesting features and advantages such as, the possibility of wavelength
multiplexing in a fiber optic, their reduced size and lightness, and total immunity to electromagnetic
interferences, among others [1]-[5]. The measured parameters by the FBG sensors are codified in the light
wavelength. This feature avoids the distortion of the information through the sensor network due to external
effects.
In this work, we show and demonstrate the use of FBG sensors to monitor the enclosure of civil buildings.
The aim of the work is to know the performance of the enclosure materials in real time and under service
conditions. Moreover, the system is intended to prevent severe alterations in the enclosure due to external agents
(temperature changes, wind loads, vibrations,…).
2 Application description
In order to evaluate and quantify the behavior of building elements under real service conditions by means
of FBG sensors, a singular building designed by Alonso Hernández & Associates Architects S.L. was chosen.
Moreover, this building makes use of an innovative enclosure system: double glass panels filled with an alveolar
type core.
2.1 Telecomunication tower
The chosen building belongs to the headquarter of TRACASA, a public company of the Government of
Navarra, located in front of the Innovation Center and next to the Eco-city of Sarriguren (Navarra, Spain). The
main building has a built surface of 20.600 m2 and disposes of advanced technological
solutions that allow for an efficient use of the energy needs of the building, reducing the energetic
consumption in a minimum of 35% and a maximum of 60%, in some cases.
Fig. 1. External view of the Telecommunication tower
This building has a singular telecommunication tower that contains the information systems and the
communication antennas. The high level of electromagnetic radiation in such buildings makes the choice of FBG
sensors particularly suitable for this application.Due to this functional exclusivity of the tower, the construction
needed an innovative glass enclosure solution, which is shown in Fig. 1
2.2 Alveolar sandwich structure
A vertical façade of innovative panels was installed in the tower. These panels have a sandwich structure,
composed by two external glass skins filled with a central alveolar core. The two cladding glasses use monolithic
glass and the core has an alveolar/ lattice structure of polycarbonate (see Fig. 2).
The main structural features of the panels are reached by the adhesive union between the glass claddings
and the core, without the need of any other kind of holder in the perimeter of the panel. In addition, the sandwich
configuration provides outstanding mechanical properties to strain and compression.
Fig. 2. : Panel structure
Besides, from an aesthetic point of view there are several new design degrees. The glass skins provide to
the panels with a translucent feeling, whereas the alveolar core allows the use of colored solutions and a variety
of translucent degrees. The translucency reaches it maximum in the perpendicular direction with respect to the
panel plane, and it decreases with increasing angles of observation.
2.3 Optical network
In order to monitor the mentioned tower, both commercial strain and temperature sensors have been
installed. Strain sensors offer information about contraction, dilatation and deformation of the glass panels, and
temperature sensors are necessary to compensate for the deformation effects on strain sensors due to thermal
changes on the glass. Moreover, the information provided by the temperature sensors is required to establish the
current temperature of the panels and it is essential to determine the experimental coefficient of thermal
expansion (CTE) of the glass.
As the glass alveolar panels have a sandwiched structure, some sensor pairs have been placed in both faces
of the panels. The aim of such placement is to record the differences in deformation and temperature in both
faces of each investigated sandwiched glass, and to evaluate their isolation capability.
The experimental setup system of the tower is complemented with a vibration sensor (accelerometer)
located at the upper floor of the building.
The network comprises a total of thirty one FBG sensors [6]-[7] (20 deformation sensors, 10 temperature
sensors and 1 accelerometer) distributed in four branches or arrays that were located on different points of the
tower:
Fig. 3. optical sensor distribution
- Branch 1. Six sensors inside the building, and three sensors outside, located at the first and second floor.
- Branch 2. Six sensors inside the building at the third floor.
- Branch 3. Nine sensors inside the building at the fourth floor.
- Branch 4. Six sensors inside the building at the fourth floor
See the schematic in Fig. 3. All available channels of the interrogator were utilized.
2.4 KNX network
The building possesses a control system based on KNX [8] (European standard for Home and Building
Control), which provides a high degree of flexibility and an important saving in energetic management and
maintenance. This control system can be managed using different software tools, all of them based on the
standard communications protocol KNX. In order to facilitate the future management and maintenance of the
monitoring system, we have developed a unique global management tool which controls both the KNX system
and the sensor system. So, in the tower coexists two kinds of sensor networks, one optical and another KNX.
Making use of the network KNX it was installed a meteorological station (see Fig. 4) in the rooftop of the
tower which will give more information about weather conditions that may affect the enclosure during the
realization of this work. The station can measure in real-time the speed of the wind, the temperature outside and
the luminosity in three directions. Furthermore, it has a twilight sensor and a rain sensor.
Fig. 4. KNX meteorological station model 2224 WH from Jung
For communicating EIB systems with IP networks a hardware IP/KNX interface is needed. In this work,
N148/21 model from Siemens has been used.
Also the Java library “Calimero” [9] developed in the Vienna Technical University has been used. This
library allows a bidirectional access to KNX network through an IP interface using KNXnet/IP protocol.
In the Fig. 5 is shown the scheme used in this work for requesting data to the KNX sensors using Calimero.
Fig. 5. Calimero used scheme
2.5 Network integration
As shown in Fig. 6, each fiber optic sensor branch is connected to a different optical channel with optical
fiber. The optical accelerometer is connected to the interrogator’s PXI module, also with optical fiber.
The KNX/IP interface is connected with an Ethernet UDP cable to one of the two Interrogator’s network
interfaces available and the other is used for connecting with the 3G router, also with an Ethernet UDP cable.
Fig. 6. Physical system connection
The system consists in five separated software modules, intercommunicated with UDP or TCP, depending
of the nature of the data exchange, as shown in Fig. 7.
The BraggMeter module acquires the fiber optic sensor data and the CalimeroDaemon module acquires the
KNX sensor data. They pass the acquired values to the Hub module, where they are processed and stored in a
data base. For data storage we have use a MySQL server, a powerful open source database. Finally this module
has the functionality of connecting remotely with the SensorViewer module via internet for displaying the sensor
networks data in real-time, as well as the displaying values stored in the database for a given time interval. The
BraggScope module acquires the data from the optical accelerometer and also sends it to the SensorViewer
module for viewing.
Fig. 7. Logical system connection
3 Results and conclusions
The network of FBG sensors, the data processing, the data storage and the automatic remote monitoring of
the sensors, is a complete and well defined system with the capability to perform simultaneously multiple sensor
measurements and to provide both local and global information about the behavior of the panel under different
environmental parameters and operating conditions.
Both the data of the sensors and the information of the meteorological station have been saved every fifteen
minutes during a year. The placement of the FBG sensors having different orientations and height positions, and
located inside and outside the tower, allows monitoring the different temperatures and deformations the panels
go through.
Fig. 8. Strain measurement of 3 sensors against temperature
Fig. 8 shows the relationship between the temperature and the deformation for several panels. The
coefficient of determination,R2, between the temperature and the deformation is in all cases, greater than 0.9.
Therefore, we can conclude that there exists a lineal relationship between temperature and deformation [10].
Fig. 9. Strain measurements excluding temperature effects
Moreover, in this graph we can observe that there are other factors that produce deformations to the glass
panels. The deformation of the panels depends on both thermal conditions (changes of temperature) and
mechanical conditions (such as the load of the wind, vibrations, strain due to its own weight or mechanical
supports used to fix the panels). It has not been possible to establish a clear relationship between the load of wind
and the strain in the panels, due to the light wing the panels went through during the measured period. Figures 8
and 9 show that panels placed higher show higher deformation due to more critical thermal and mechanical
conditions (remember that the range of temperature registered for this panels is the largest).
Sensors installed in the outside recorded more unstable measurements compared to sensors in the inner
side. The base packaging was not enough to avoid the hostile environment, such as rain, hailstone, birds, etc.
Therefore, some ranges of measurements have not been considered as reliable
4 References
[1] Hongo, S. Kojima, S.Komatsuzaki, “ Applications of fiber Bragg grating sensors and high-speed interrogation techniques” ,
Structural Control and Health Monitoring, Vol 12, no. 3, 269-282, 2005
[2] D. Kersey, M. A. Davis, H. J. Patrick, M. LeBlane, K. P. Koo, C. G. Askins, M. A. Putnam, and E. J. Friebele, “Fiber grating
sensors” J. Lightwave. Technolog., Vol. 15, no. 8, pp. 1442–1463, Aug. 1997
[3] S. Liu, Y. Yu, J. Zhang X. Chen, “ Real-Time monitoring sensor system for Fiber Bragg Grating array”, IEEE Photonics
Technology letters, Vol. 19, no.19, 1493-1495, Oct. 2007.
[4] J.M. Lopez-Higuera (Ed), “Handbook of Optical Fibre Sensing Technology”, (John Wiley & Sons,2002)
[5 ]Kenneth O. Hill, Gerald Melzt, “Fiber Bragg Grating Technology Fundamentals and Overview”, Journal of Lightwave
Technology, Vol. 15, no. 8, 1263-1276, 1997.
[6] http://www.fibersensing.com
[7] http://www.micronoptics.com
[8] http://www.knx.org
[9] https://www.auto.tuwien.ac.at/a-lab/calimero.html
[10] Draper, N.R. and Smith, H. Applied Regression Analysis. Wiley-Interscience (1998)
INTEGRATION OF WIRELESS SYSTEMS IN INDOOR
INTELLIGENT HOME SYSTEMS
Universidad Pública de Navarra
Campus de Arrosadia, 31006 Pamplona
Tel.: 948166166
J.A. Nazabal
V. Torres
J. Becerra
C. Fernández-Valdivielso
F. Falcone
N. Matías
KNX Scientific Conference
Pamplona 2010
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
Introduction:
� Optical sensors based on Fiber Bragg Gratings (FBGs) have been widely used in monitoring
of civil structures.
� KNX is the worldwide standard called for leading the home and building control market.
� Personal Area Networks (PAN) such as 802.15 are suitable for mass introduction in
residential scenarios due to their low cost, low power consumption and availability.
INTRODUCTION AND OBJECTIVESINTRODUCTION AND OBJECTIVES
Objectives:
� The main objective of this work is to integrate optic, KNX and ZigBee sensors in one
single system.
� A secondary objective consists in remotely monitorize the data of the integrated
sensors.
KNX Scientific conference 2010 Pamplona, 4th November 2010
KNX Scientific conference 2010 Pamplona, 4th November 2010
OPTICAL NETWORKOPTICAL NETWORK
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
� FS6300 :
� 2 Temperature sensor
Serial number Central wavelength Polynomial
� FS5200 :
� Optical interrogator
KNX Scientific conference 2010 Pamplona, 4th November 2010
KNX NETWORKKNX NETWORK
� WS 10H:
� Temperature sensor
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
�N148/21:
� IP/KNX Interface
� 1 network connections (RJ 45)
� 1 bus KNX connections
� WS 10T:
� Brightness sensor
� 2214 REG A:
� 4 Analog Input Module
KNX Scientific conference 2010 Pamplona, 4th November 2010
ZIGBEEZIGBEE
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
IEEE 802.15.4IEEE 802.15.4
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
IEEE 802.15.4 AND IEEE 802.11B INTERFERENCESIEEE 802.15.4 AND IEEE 802.11B INTERFERENCES
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
RF RADIOPROPAGATIONRF RADIOPROPAGATION
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
Free Space Path Loss Multipath
Medium Change Diffraction
KNX Scientific conference 2010 Pamplona, 4th November 2010
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
f = 4.52 GHzFull 3D Ray Tracing algorithm
Ray-Launching TechniqueSolid angle of departureTetrahedral resolution
EM Phenomena considered:ReflectionRefractionFirst Order of Diffraction
Configuration: parameters of systemFrequencyAntenna � power, gain, polarization and directivity diagramSymbol Time (bit rate)
Material properties are consideredMaterial properties are considered
3D RAY LAUNCHING (I)3D RAY LAUNCHING (I)
KNX Scientific conference 2010 Pamplona, 4th November 2010
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
f = 4.52 GHzConfiguration: parameter of simulationAngle incrementTetrahedral sizeNumber of rebounds
Results:
Coverage planesPower Delay ProfileBidimensional Delay planesDispersion planes
Programmed in MatlabTM
Time Vs PrecisionTime Vs Precision
3D RAY LAUNCHING (II)3D RAY LAUNCHING (II)
KNX Scientific conference 2010 Pamplona, 4th November 2010
ZIGBEE NETWORK (I): XBEE CHARACTERISTICSZIGBEE NETWORK (I): XBEE CHARACTERISTICS
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
� Based on EM357 SoC from Ember
� Integrated chip antenna model used
� Working at 2.4 GHz
KNX Scientific conference 2010 Pamplona, 4th November 2010
ZIGBEE NETWORK (II): SENSOR DEVELOPMENTZIGBEE NETWORK (II): SENSOR DEVELOPMENT
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
� XBEE PRO :
� ZigBee module
� LM335 :
� Analog temperature sensor
� LD1117V33 :
� Voltage regulator
KNX Scientific conference 2010 Pamplona, 4th November 2010
ZIGBEE NETWORK (III): X-CTU XBEE PROGRAMMING TOOLZIGBEE NETWORK (III): X-CTU XBEE PROGRAMMING TOOL
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
PHYSICAL SYSTEM CONNECTIONPHYSICAL SYSTEM CONNECTION
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
LOGICAL SYSTEM CONNECTIONLOGICAL SYSTEM CONNECTION
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
CALIMERO LIBRARYCALIMERO LIBRARY
� Developed by “Vienna University of Technology”
� Is a KNXnet/IP protocol implementation in Java
� Allows communication with a KNX network using IP packets.
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
SENSORVIEWER (I)SENSORVIEWER (I)
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
SENSORVIEWER(II)SENSORVIEWER(II)
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
KNX Scientific conference 2010 Pamplona, 4th November 2010
CONCLUSIONSCONCLUSIONS
� The possibility of integrating optical, ZigBee and KNX networks has been demonstrated.
INTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMSINTEGRATION OF WIRELESS IN INDOOR INTELLIGENT HOME SYSTEMS
� For future works, integration with other wireless popular systems like RFID or Bluetooth can be considered.
FIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORINGFIBER OPTIC SENSOR IN A KNX NETWORK AND REMOTE MONITORING
KNX Scientific conference 2010 Pamplona, 4th November 2010
THANK YOUTHANK YOU
Universidad Pública de Navarra
Campus de Arrosadia, 31006 Pamplona
Tel.: 948166166
Universidad Pública de Navarra
Campus de Arrosadia, 31006 Pamplona
Tel.: 948166166
INTEGRATION OF WIRELESS SYSTEMS IN INDOOR INTELLIGENT HOME SYSTEMS
J. A. Nazabal, V. Torres, J. Becerra, F. Falcone, C. Fernández-Valdivielso and I.R. Matías
Departamento de Ingeniería Eléctrica y Electrónica, Universidad Pública de Navarra, Campus de Arrosadia s/n, 31006, Pamplona.
Persona de contacto: Juan Antonio NAZABAL ([email protected]).
Abstract— In this work, we present a ZigBee temperature sensor prototype and the developed system for its integration in a KNX sensor network and a Fiber Optic sensor network. The system also presents a Java Software module allowing the remote monitoring in real time of all the different sensors.
Index Terms— Personal Area Networks, Wireless Sensors, 3D Ray Launching, Integration, ZigBee, new KNX networks, ambient intelligence
1 Introduction
Wireless technologies are playing a key role in defining the way in which business as well as the interaction
with the surrounding environment is made. Great deal of work is now being devoted into cross layer
connection between different networks in order to have full seamless connectivity wherever the user is
present. In this context, Personal Area Networks (PAN), such as 802.15, are suitable for mass introduction
in residential scenarios due to their low cost, low power consumption and availability. In this new scenario,
wireless technologies are very important. On the other hand, KNX is the worldwide standard called for leading
the home and building control market, therefore, both technologies must work together in order to
improve the services for the final users. Also, optical sensors based on Fiber Bragg Gratings (FBGs) have
been widely used in monitoring of civil structures [1]-[3]. In the future, all this technologies (and many more)
will coexist together in the same building.
The upcoming era of so-called Ambient Intelligence fosters the development of smart spaces characterized
by a certain degree of ubiquitous intelligence. As a result the domestic environments evolve towards resident-
aware homes, enabling them to react and adapt to their inhabitants’ context, preferences, tasks, and needs.
2 Application description
In order to demonstrate the integration between fiber optic, KNX and ZigBee sensors, a simple system has
been developed at laboratory level. The system consists in a hardware part and a software part. The optical
interrogator used for acquiring optical sensor data also incorporates an embedded window XP, which will be
used for running part of the software system modules implemented.
2.1 System’s hardware part
As shown in Fig 1, the center of the system of the hadware part is the optical interrogator, a fs5200 model
from FiberSensig.
The KNX network consists in two analogic sensors, one of temperature and another of brightness. The
models used are WS 10 T and WS 10 H, from Jung. Both sensors are connected to a 4 analog input module,
concretely the model 2214 REG A from Jung. This module has been programmed for sensing data on demand
only. For communicating EIB systems with IP networks a hardware IP/KNX interface is needed. In this work,
N148/21 model from Siemens has been used. The KNX/IP interface is connected with an Ethernet UDP cable to
one of the two Interrogator’s network interfaces available.
The Optical network consists in two temperature sensors [4]-[5], each one connected to an interrogator’s
different optical channel by optical fiber.
The ZigBee network consists in two temperature sensors and a network coordinator, plugged in a XBee
Explorer USB device that is connected via USB cable to the optical interrogator.
The ZigBee temperature sensors have been developed for this project and are based in XBee Pro modules
from Digi International. The transmission RF power level can be adjusted with a maximum default value of 18
dBm. There are different XBee modules with different antennas. In this work, an integrated chip antenna module
has been used. This antenna’s gain is quite low, about -1.5 dBi, but the device is more compact, that is important
for integrating it in another systems. For programming XBee modules X-CTU [7] software has been used. It is
an easy to use software with a friendly graphical interface and has the functionality of accessing to all the
configuring parameters of the XBee modules.
The ZigBee temperature sensor developed consists in an analog temperature sensor (a LM335 with TO-92
plastic package) connected to a XBee pin configurated as an analog input. The temperature sensor works with 5
VDC and the XBee module, with 3.3 VDC, so additional circuitry is needed. For obtaining these two different
voltages, two AA batteries with a DC/DC converter that supplies 5 VDC and a LD1117V33 that supplies 3.3
VDC have been used. The module has been programmed for sending a data packet to the coordinator with the
value registered by the analog input every second but this time value can be set easily.
Fig. 1. System’s hardware part
2.2 System’s software part
As shown in Fig 2, the system consists in five separated software modules, intercommunicated with UDP
or TCP, depending of the nature of the data to exchange. For critical data, TCP will be used and for streaming
data, UDP. All modules but the SensorViewer will be executed in the optical interrogator. The SensorViewer
module will be executed in the remote monitoring machine.
Fig. 2. System’s software part
2.2.1 OpticModule
The optical interrogator uses a software tool developed in LabVIEW by the same manufacturer. This tool
contains different shared variables for accessing the sensor parameters, like sensors names, units and measured
values. The OpticModule access to those variables (see Fig. 3) and opens a TCP port for requesting them.
Fig. 3. : Access to shared variables in LabVIEW
2.2.2 KNXModule
This module access to the KNX sensor values and opens a TCP port for requesting them. The Java library
“Calimero” [6] developed in the Vienna Technical University has been used. This library allows a bidirectional
access to KNX network through an IP interface using KNXnet/IP protocol.
In the Fig. 4 is shown the scheme used in this work for requesting data to the KNX sensors using Calimero.
The boxes with green background colour indicates objects and methods already implemented by the
Calimero library and the ones with orange background, interfaces and method that must be implemented by the
user of the library.
The first step is to create a CEMI_Connection object. Then the EICLEventListener interface must be
implemented, putting custom code in both methods. The next step consists in calling addFrameListener method
for setting the interface for listening. Finally, method sendFrame will send a request to a KNX sensor and this
sensor will send a response, activating newFrameReceived method and executing implemented custom code.
Fig. 4. : Calimero used scheme
2.2.3 ZigBeeModule
Each time that the coordinator of the ZigBee network receives a data packet, sends the received information
through its UART, and travels across the USB cable from the coordinator’s serial port to the interrogator’s USB
port. There, the ZigBeeModule retrieves this data and acquires the name of the sensor and the value, source of
the packet. Also opens a TCP port for requesting the received ZigBee sensor data.
2.2.4 Hub
This module sends data requests to the OpticModule, KNXModule and ZigBeeModule for retrieving all
sensor data. Finally this module has the functionality of connecting remotely with the SensorViewer module via
internet for displaying the sensor networks data in real-time.
2.2.5 SensorViewer
This is the module for displaying remotely the sensor data in real-time. Consists in a Tabbed Pane with
three different tabs. The screen capture of the first one is shown in the Fig. 5. On the top-left of the screen there
is a Combo box with all the sensor types available. When one is chosen, on the left of the screen appears all the
sensor of that type available if form of buttons. The border of each sensor will be red if the sensor is selected or
black otherwise, changing from one state to the other by clicking the button. On the center on the screen will
appear a figure with the temporal evolution of the values of the selected sensors, each one with a different colour
and a different legend on the figure.
Fig. 5. Real-time sensor values
The screen capture of the first one is shown in the Fig. 6. It consists in a table with three different columns:
sensor name, sensor units and the sensor value in real-time. The background colour of the sensor name’s cells
will be blue for optical fiber sensors, pink for the KNX sensors and orange for the ZigBee ones.
Fig. 6. Real-time sensor values in table form
The last tab is used for connection with the hub module and for minimizing and/or exiting the application.
3 Results and conclusions
With this work has been demonstrated the possibility of integrating fiber optic and ZigBee sensors in a
KNX network. Theoretically, any kind of sensor technology can be integrated with KNX as long as the data is
accessible by software. In fact, in the future many different technologies will coexist together in the same
building and system.
4 References
[1] Hongo, S. Kojima, S.Komatsuzaki, “ Applications of fiber Bragg grating sensors and high-speed interrogation techniques” ,
Structural Control and Health Monitoring, Vol 12, no. 3, 269-282, 2005
[2] D. Kersey, M. A. Davis, H. J. Patrick, M. LeBlane, K. P. Koo, C. G. Askins, M. A. Putnam, and E. J. Friebele, “Fiber grating
sensors” J. Lightwave. Technolog., Vol. 15, no. 8, pp. 1442–1463, Aug. 1997
[3] S. Liu, Y. Yu, J. Zhang X. Chen, “ Real-Time monitoring sensor system for Fiber Bragg Grating array”, IEEE Photonics
Technology letters, Vol. 19, no.19, 1493-1495, Oct. 2007.
[4] http://www.fibersensing.com
[5] http://www.micronoptics.com
[6] https://www.auto.tuwien.ac.at/a-lab/calimero.html
[7] “X-CTU Configuration & Test Utility Software”, Digi International