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.


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.


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


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).


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


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:


● 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


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.


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


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

http://www.google.com/url?q=http%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5545&sa=D&sntz=1&usg=AFQjCNFPpXxiI95uPXdYSvZ397gxvpyOoQ

http://www.google.com/url?q=http%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5545&sa=D&sntz=1&usg=AFQjCNFPpXxiI95uPXdYSvZ397gxvpyOoQ


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

[email protected]

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

[email protected]


What is the presentation

about

21st year review, Brussels, Belgium1.-2.7.2010


Using of POBICOS and KNX together to create

applications with pre-planned infrastructure and ad hoc

added objects


Application using

different objects with

embedded controllers

Pervasive

distributed

computing

platform

Objects are

added ad hoc

Pre-planned

building/home-

automation

infrastructure


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



POBICOS – what is it



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 objects, nodes, micro-agents, virtual machine


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 application example



POBICOS application example 1/3

Demand/Response application


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




• 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





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


Application programmer tools

supporting creation of applications

with opportunistic behavior in

POBICOS



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


2nd year review, Sophia-Antipolis, France1.-2.7.2010

Abstract access to resources

alert

alertVisually

alertByDisplayingTextalertByBlinking

alertBySirenSound

alertByVoice

alertAurally

alertBySound

provides


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


POBOCOS proxy and

POBICOS centralized runtime



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


17

Typical POBICOS node built

into the POBICOS object

lamp

POBICOS proxy node enabling access to the

non-POBICOS objects


The POBICOS proxy node

18


Using of individual modules of a legacy system as

external resources for POBICOS nodes


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


Using the whole legacy system as one „POBICOS mega

node “


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


Creating of virtual objects using access to different data

points on a legacy system bus


Virtual

POBICOS

object

created

by grouping of

data points from

more EIB/KNX

devices within

one POBICOS

node.


Centralized POBICOS runtime


• 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


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


How can be the POBICOS

application creation

methodology useful for KNX



KNX A-mode


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


Using of POBICOS centralized runtime as KNX

application controller for A-mode


Centralized

POBICOS

runtime


Demand/Response

application – implementation

example



The Bioclimatic building (BEMS) in The Centre for

Renewable Energy Sources and Saving, CRES (Athens,

Greece) where application runs

28



Interfacing POBICOS nodes and EIB/KNX

installation - solution

Centralized

POBICOS

runtime


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


Using of the instruction and event taxonomies in non-generic agents

31

The D/R

devices

agent

types

The

human

presence

sensor

agent


Using of POSIM as centralized POBICOS runtime


One compact

application (able to

work with POBICOS

API) with virtual

POBICOS nodes



Centralized

POBICOS

runtime with

real nodes –

every node

runs over own

instance of

the TinyOS

simulator

TOSSIM


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


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.


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

[email protected]

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

[email protected]

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


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/

http://www.ict-pobicos.eu/

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


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


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

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


Build

ing A

uto

mation a

nd C

ontr

ol M

ulti

Build

ing A

uto

mation a

nd C

ontr

ol M

ulti





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


Build

ing A

uto

mation a

nd C

ontr

ol M

ulti

Build

ing A

uto

mation a

nd C

ontr

ol M

ulti





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


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


Build

ing A

uto

mation a

nd C

ontr

ol M

ulti

Build

ing A

uto

mation a

nd C

ontr

ol M

ulti





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


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


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


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


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


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


Build

ing A

uto

mation a

nd C

ontr

ol M

ulti

Build

ing A

uto

mation a

nd C

ontr

ol M

ulti





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


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


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


Build

ing A

uto

mation a

nd C

ontr

ol M

ulti

Build

ing A

uto

mation a

nd C

ontr

ol M

ulti





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

[email protected]

Antonio Cuevas

[email protected]

Cristina Gómez

[email protected]

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

[email protected]

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


ENCLOSURE PANEL’S STRUCTUREENCLOSURE PANEL’S STRUCTURE


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.


FBG SENSORSFBG SENSORS


� 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.



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



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



PHYSICAL SYSTEM CONNECTIONPHYSICAL SYSTEM CONNECTION



NETWORK PROTOCOLSNETWORK PROTOCOLS

Connection-orientedConnectionless

Not immediate data sendingImmediate data sending

Heavy weightLight weight

ReliableUnreliable

TCPUDP



LOGICAL SYSTEM CONNECTIONLOGICAL SYSTEM CONNECTION



BRAGGMETER MODULEBRAGGMETER MODULE

� Programmed in LabVIEW

� Acquires optical sensor data

� Has no graphical interface, programmed for working in background

� Shared variables



CALIMERODAEMON MODULECALIMERODAEMON MODULE

� Programmed in Java

� Acquires KNX sensor data

� Uses Calimero Library



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.



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



BRAGGSCOPE MODULEBRAGGSCOPE MODULE

� Programmed in labVIEW

� Uses Ni-daq

� Uses data compression

� MySQL Data storage



SENSORVIEWER (I)SENSORVIEWER (I)



SENSORVIEWER(II)SENSORVIEWER(II)



SENSORVIEWER(III)SENSORVIEWER(III)



SENSORVIEWER(IV)SENSORVIEWER(IV)



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



THANK YOUTHANK YOU



Tel.: 948166166

[email protected]



Tel.: 948166166

[email protected]

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



Tel.: 948166166

[email protected]

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.



OPTICAL NETWORKOPTICAL NETWORK


� FS6300 :

� 2 Temperature sensor

Serial number Central wavelength Polynomial

� FS5200 :

� Optical interrogator


KNX NETWORKKNX NETWORK

� WS 10H:

� Temperature sensor


�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


ZIGBEEZIGBEE



IEEE 802.15.4IEEE 802.15.4



IEEE 802.15.4 AND IEEE 802.11B INTERFERENCESIEEE 802.15.4 AND IEEE 802.11B INTERFERENCES



RF RADIOPROPAGATIONRF RADIOPROPAGATION


Free Space Path Loss Multipath

Medium Change Diffraction



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)



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)


ZIGBEE NETWORK (I): XBEE CHARACTERISTICSZIGBEE NETWORK (I): XBEE CHARACTERISTICS


� Based on EM357 SoC from Ember

� Integrated chip antenna model used

� Working at 2.4 GHz


ZIGBEE NETWORK (II): SENSOR DEVELOPMENTZIGBEE NETWORK (II): SENSOR DEVELOPMENT


� XBEE PRO :

� ZigBee module

� LM335 :

� Analog temperature sensor

� LD1117V33 :

� Voltage regulator


ZIGBEE NETWORK (III): X-CTU XBEE PROGRAMMING TOOLZIGBEE NETWORK (III): X-CTU XBEE PROGRAMMING TOOL



PHYSICAL SYSTEM CONNECTIONPHYSICAL SYSTEM CONNECTION



LOGICAL SYSTEM CONNECTIONLOGICAL SYSTEM CONNECTION



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.



SENSORVIEWER (I)SENSORVIEWER (I)



SENSORVIEWER(II)SENSORVIEWER(II)



CONCLUSIONSCONCLUSIONS

� The possibility of integrating optical, ZigBee and KNX networks has been demonstrated.


� For future works, integration with other wireless popular systems like RFID or Bluetooth can be considered.



THANK YOUTHANK YOU



Tel.: 948166166

[email protected]



Tel.: 948166166

[email protected]

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

using the knx model to enhance houses intelligence · 2017. 2. 22. · this paper will show that...

Documents