smart buildings - architectures and technologies

Smart Buildings architectures and technologies

Fulvio Corno – [email protected]

Politecnico di Torino Dipartimento di Automatica e Informatica

e-Lite Research Group

http://elite.polito.it

Outline

2012-09-11 e-lite - Smart Buildings 2

Conclusions

Happy hour

Conclusions


Smart Homes, Buildings, Factories

Technology is available!

Sensors, actuators, communication networks and infrastructure

Domotics

Field bus protocols and systems

Home Automation System (HAS)


Home automation Automation of the home, housework or

household activity.

(remote) control of: lighting

HVAC (Heating, Ventilation and Air Conditioning)

appliances

and other systems

Home automation system An integrated system (computer-based)

offering home automation functionalities

Integrates electrical devices in a house Through a communication network

Possibly includes devices using different communication protocols

Home Automation System (HAS)


Building Automation System (BAS)


Building Automation System (BAS)


Building automation

The advanced functionality provided

by the control system of a building

E.g., security & access control, fire

detection & alarms, HVAC, lighting

control, air quality, smoke detection,

intrusion detection, environmental

control, asset location/management

Building Automation System(BAS)

A computerized, intelligent network

of electronic devices designed to

monitor and control the mechanical,

electronic, and lighting systems in a

building

Home vs. Building Automation


Building

Automation Home

Automation

Home Automation is almost a subset of

Building Automation

Most functionalities are shared

Different protocols and technologies

Pot-pourri of devices…


Conclusions


Smart Homes, Buildings, Factories

Technology is available!

Sensors, actuators, communication networks and infrastructure

Domotics

Field bus protocols and systems

Applications are well-defines

Energy monitoring

Security, Surveillance

Remote control

Pot-pourri of applications…


Conclusions


Problem solved

Available technologies

Well-defined applications

… or

not?

Outline (the real one…)


Problem definition

Proposed architecture

Application examples

Q&A

Starting points


D D D D

Application

Devices

• Environmental sensors (temperature,

humidity, CO2, pollutants, illumination, wind,

…)

• User sensors (presence, movement, access,

…)

• Energy meters (electric energy and

power, gas and water consumption, …)

• Actuators (relays, motor valves, motor

doors, lights and signs, …)

• Automation systems

• Interconnection systems

Starting points


• Dashboards (observing, monitoring, …)

• Historical data (storage, consolidation,

query, …)

• Alerts (anomaly, threshold detection, …)

• Remote control (commanding actuators,

de/activate actions, set-point, …)

• Trends (historical data analysis, analysis on

real time data)

• Real time elaborations (computing derived

quantities, virtual sensors, …)

• Ambient intelligence (comfort, energy

saving, scenarios, dynamic adaptation, …)

• Integration with information systems D D D D

Application

Devices

Closing the loop


D D D D

Application

Devices

• Sensor technologies

• Communication protocols

• Scale (local, geographic)

• Number of devices

• Sampling frequencies

• Security / authentication

• Type of data

• Unidirectional vs bidirectional

• Data encoding

• Polling / Pushing

Infrastructure

Easy to say «device»


Powerline Computer-derived

Field bus Wireless

RS-485

Easy to say «device»


Powerline Computer-derived

Field bus Wireless

RS-485

Note 1: this is just a small sample of

currently used protocols

Note 2: we don’t list all other solutions,

more or less «custom»

Note 3:

Network Technology


Bus

MyOpen

KNX

Modbus

Echelon

Dali

CAN

MBus

Powerline

Echelon

X10

Insteon

Wireless

ZigBee

Z-Wave

EnOcean

Application Area


Automation

Real-time Control

CAN

KNX, MyHome, Insteon, Echelon, Modbus, X10, ZigBee, Z-Wave, EnOcean

Lighting

Dali

(all Automation)

Metering

Mbus

RS-485

KNX, Modbus, Echelon, ZigBee, Z-Wave,…

Entertainment

UPnP

DLNA

General purpose

Bluetooth

WiFi

Meanwhile, in the real world, …


Different suppliers

Different

sub-systems

Different installation times

Legacy

Different needs and

requirements

Diverse technologies in

the same system

Never designed for

interoperation (even

worse…)

D D D D

D D D D

D D D D

Meanwhile, in the real world, …


Needs are growing

Opportunities

are growing

Developing new interfaces

New application areas

Scale integration

Different applications on

the same physical system

Sharing sensors, data and

actuation commands

Application

Application

Application

Application

Application

Challenges


Integration

Different electrical requirements

Different interaction modalities

Different behaviors (temporal, etc.)

Interoperation

Different protocols

Different interaction modalities

Master/slave

Peer-to-peer

Etc.

Modeling

Different technologies & assumptions

A single shared, common description

Errors to avoid


D D D D

Application

Devices

Infrastructure

D D

D

D

Application

Devices

Infrastructure

D

«All you can eat» application The «My gateway is way too

clever» case

And now?


D D D D D D D D D D D D

Application Application Application Application

A lingua franca




Neutral representation

Open and Horizontal Architectures





Basic/core functionalities

API

Protocol interface drivers

Data exchange

Real time computation Rules and

scenarios Application

service





API


Data exchange



service

Applications consume data and services






API


Data exchange



service

Applications command and control






API


Data exchange



service

An abstract model


• Abstract w.r.t. technology

• Expandable w.r.t.

• Tecnologies

• Devices

• Application domains

• Standard languages and representations (W3C

Semantic Web): RDF & OWL

• We propose: DogOnt ontology

DogOnt


Lamp

House

Plant

Electric

System

Controllable

Building

Thing

Building

Environment

Building Apartment

Room

IsIn / contains

OnOff

Functionality

Control

Functionality

Functionality

hasFunctionality

Discrete

State

OnOff

State

State

hasState

http://elite.polito.it/dogont-tools-80

DogOnt - Ontology Modeling for Intelligent Domotic Environments, D. Bonino, F. Corno

7th International Semantic Web Conference, 2008, Springer-Verlag, pp. 790-803






Semantic Modeling (DogOnt)


RDF

OWL

XML

XSD

In Practice (Protégé & OWL)


<owl:Class rdf:about="#SimpleLamp">

<rdfs:comment

rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>Simple lamp that can be just turn on or turn off</rdfs:comment>

<owl:disjointWith>

<owl:Class rdf:about="#DimmerLamp"/>

</owl:disjointWith>

<rdfs:label

rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>SimpleLamp</rdfs:label>

<rdfs:subClassOf>

<owl:Restriction>

<owl:someValuesFrom rdf:resource="#QueryFunctionality"/>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#hasFunctionality"/>

</owl:onProperty>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf rdf:resource="#Lamp"/>

</owl:Class>

Sample Room Model in DogOnt


Sample Room

Lamp

Switch

OnOffFunctionality

OnNotification

OffCommand

OnOffNotification

Functionality

OffNotification

OnOffState

OnOffState

hasState

OnCommand

hasFunctionality

hasCommand hasCommand

isIn isIn

hasState

hasFunctionality

hasNotification

hasNotification

generatesCmd

generatesCmd

Home / Building Gateway






API


Data exchange



service

• Open and expandable architecture

• Acceptable development times

• Application independent

• System configuration

• Sending commands

• Monitoring states

• Getting data from sensors

• Asynchronous (event-driven)

programming model

• Application independent

• Standard-based interfaces (http,

XML, JSON, …)

We propose:

Dog 2.x

Dog 2.x


Intelligent Gateway: Dog 2.x

Open Source (Apache 2.0)

Modular (OSGi framework)

Multi-protocol

Based on semantic computing and DogOnt

Suitable for embedded-PC hardware

http://domoticdog.sourceforge.net

http://domoticdog.sourceforge.net/

Intelligent Domotic Environments


DOG - Domotic OSGi Gateway



System Architecture


D D D D D D D D Domotic devices (switches,

buttons, relays, sensors, meters,

…)

Domotic bus (wired, wireless)

GW Bus-to-IP gateway

Bus-to-serial gateway GW

Ethernet, Wi-Fi, USB

User

Interface

Mobile, Web, Home Display,

Multi Touch, Accessibility,

Natural language, …

Data

analysis

ERP, Web services, Stream

processors, Datawarehouse

Dog

Bundles

Device abstraction, Event

abstraction, State abstraction,

Rules engine, …

User

Interface User

Interface

Smart

Appliance

In Ontology We Trust


Devices and networks exposed by means of a formal,

unique, representation

DogOnt (Ontology)

Applications only see DogOnt-based device descriptions

Functionalities

Notifications

Commands

States

State values

Internal representations and drivers must be ontology-

aware, at different degrees

High-Level Architecture


OSGi - based

2 main layers

3 main bundle groups

Core

Drivers

Add-ons

DogXMLEndPoint DogRESTEndPoint

DogStateMonitor DogScheduler DogExecutor DogDeviceManager DogNotificationManager

DogLogger DogConfigurator

DogDeviceFactory

DogOntLibrary DogDeviceModel

DogSemanticHouseModel

DogSimpleHouseModel

Dog2Library DogJaxBLibrary DogSemanticLibrary MeasureLibrary org.rxtx

Do

gAuto

Sta

rt

Core





DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

Dog REST EndPoint


Dog REST EndPoint

Provides REST access to Dog

Based on JSON or XML messages

Under development




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

Dog XML EndPoint


Dog XML EndPoint

Provides XML-RPC access to Dog

Based on XML messages

Two Way Connection

Client to send notifications

Server to listen application requests




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogStateMonitor


DogStateMonitor

Keeps a snapshot of the state of all devices

Allows for state change listener registration

Supports state querying

Typically asynchronous

Synchronous through a different interface (API)




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogScheduler


DogScheduler

Allows to schedule recurring tasks involving

Command execution (done through the command

handling bundles)

State requests (done by reading the current device

state in dog – not on the network)

Notification…?(for what?)




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogExecutor


DogExecutor

Dispatches a command to relative device object

Performs command validation

Supports message priority

No pre-defined priority levels

Higher priority Higher Priority Value in the

corresponding DogMessage




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogDeviceManager


DogDeviceManager

Implements the OSGi device manager (device

access specification)

Manages device/driver attachment in Dog

When device/driver are added/modified/removed




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogNotificationManager


DogNotificationManager

Implements the Event Admin Service Specification

Version 1.2

It is based on a event publish and subscribe model

Filters inner state change notifications from outer

ones (visible to applications)

Dispatches Notification and State Change

Notifications only




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogDeviceFactory


DogDeviceFactory

Creates device istances according to the runtime home

configuration

Either provided by the SimpleHouseModel or by the Semantic

House Model




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogOntLibrary


DogOntLibrary

All possible

Devices (interfaces)

Functionalities classes

State classes

State value classes

Programmatically generated from DogOnt




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogDeviceModel


DogDeviceModel

All possible

Device implementations




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt




Manages the home description in form of DogOnt instances

Supports configuration requests

Supports model merging

Implements classification and basic reasoning

Supports interoperation rules extraction

Potentially provides access to all properties/features defined in DogOnt

Can generate XML home configuration to be used by the SimpleHouseModel




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogSimpleHouseModel


DogSimpleHouseModel Manages the home description in XML

Used for Dog instances running on devices with low computational power

No model-merge capabilities

No reasoning support

If a SemanticHouseModel is present, this bundle automatically shuts down




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogConfigurator


DogConfigurator

Manages bundle-specific configurations

Property files

XML files

Additional files (ontology, images, etc.)

Provides configurations to all bundles implementing the ManagedService interface




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogLogger


DogLogger

Provides logging facilities to all Core bundles

Can log on console or file

Can apply different handlers (file, console) to different

logging levels




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

Dog2Library


Dog2Library

Defines all the Message Types used for inter-bundle

communication

Defines all the bundle service interfaces

Defines core-level notifications (not defined in DogOnt)

Provides utility classes to other bundles




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogJaxBLibrary


DogJaxBLibrary

Provides XML serialization / de-serialiazion for

Inner messages

Outer messages

Configurations

Etc.




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

DogSemanticLibrary


DogSemanticLibrary

Encapsulates and makes available all semantics-related

libraries

Jena

Pellet

SPARQL query facilitator




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

MeasureLibrary


MeasureLibrary

Exports the JScience library to all Dog bundles

Will define un-supported JScience unit of measures




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

Org.rxtx


Org.rxtx

Exports the serial port API library (rxtx) to all Dog

bundles

Drivers


KNXNetIP

EIBLibIP

OpenWebNet

Modbus

Elite

Echelon

ZWave

Texas

Instruments

Driver structure


Network

Driver

Gateway

Driver

Driver Driver

Device Driver

Network Driver


Gateway

Driver

Driver Driver

Device Driver

Network Driver

Handles network-level communication

Protocol

Connection

Polling (when needed)

Defines the network access APIs for all driver

bundles, for the same technology

Gateway driver


Gateway

Driver

Driver Driver

Device Driver

Gateway Driver

Supports multi-gateway operation for a given

network technology

Handles the association between devices and gateways

Permits to install device driver bundles only if the

corresponding network gateway is present (in the

configuration)

Device Driver


Gateway

Driver

Driver Driver

Device Driver

Device Driver

Implements the DogOnt device features for a given

class of devices

Translates ontology-defined commands,

functionalities and states into network level

messages

One device driver per each DogOnt device class

Sometimes the same driver can serve multiple device

classes but this should be avoided

The KNX demo box


GW

D

The Z-Wave demo box


GW

D

Device access (OSGi)


DogDeviceManager

DeviceDriver

DogDeviceModel

DogDeviceCategory

Add-on


DogRulesBundle

DogPowerModelBundle

DogPowerBundle

DogRulesBundle


DogPowerModelBundle

DogPowerBundle

DogRulesBundle

Provides a rule-engine runtime for

Defining automation scenarios

Interoperation

Complex device behaviors

Programmable through dedicated DogMessages

XML-based rule definitions

Uses notifications as triggers, states as constraints and commands as rule consequent

Supports time-driven triggers

Add-on


DogRulesBundle

DogPowerModelBundle

DogPowerBundle

DogPowerModelBundle

Handles the power extension of DogOnt

Plug in the main Semantic House Model

Provides power-specific query functionalities on

the model

Add-on


DogRulesBundle

DogPowerModelBundle

DogPowerBundle

DogPowerBundle

Exploits the DogPowerModelBundle

Provides power consumption estimation based on

Actual measures

Typical/Nominal values defined in the DogOnt power extension

Disaggregates actual measures when needed

Keeps an updated snapshot of the current home power consumption

Command handling (1)


Application

Dog

Command




DogDeviceFactory



DogSimpleHouseModel


Do

gAuto

Sta

rt

KNX Modbus Echelon OpenWebNet ZWave

Command handling (2)


Command

Network Message

Notification handling (1)


Application

Dog

Notification


DogState

Monitor

Dog

Scheduler

Dog

Executor

DogDevice

Manager

DogNotification

Manager


DogDeviceFactory

DogOnt

Library

DogDevice

Model


DogSimpleHouseModel

Dog2Library DogJaxBLibrary DogSemantic

Library MeasureLibrary org.rxtx

Do

gAuto

Sta

rt

KNX Modbus Echelon OpenWebNet ZWave

Rules

PowerModel

Bundle

PowerBundle

Notification handling


Open and Horizontal Architectures






API


Data exchange



service

Computing near to the field






API


Data exchange



service

• Multi-point and

geographic-scale systems

• Data publication

• Integrating external data

• (Open) Linked Data

• Data Decimation and Aggregation

• Over time

• Over space

• Computing derivative quantities over recent

data

• Virtual sensors

• Alarms and notifications

• High performance stream processing

• High level functional specification

• We propose: spChains

Motivation

Ambient Intelligence Systems

100’s or 1,000’s of sensors

Different physical quantities (ºC, %H2O, kW, kWh, …)

Sampling frequencies from seconds to minutes

Huge stream of data being generated

Storage and retrieval

On-line processing

Off-line processing

Analytics


On-line processing: Applications

Data Decimation (from kHz to mHz)

Aggregation (over time, over space, over sensor types)

Averaging

Feeding User Displays and Dashboards

Computing up-to-date and user-meaningful information

Monitoring and Alerting

Checking Thresholds

Generating Alert messages

Virtual Sensors

Computing derivative quantities


Requirements

Input: up to 10,000-100,000 events/second

Data: real-valued quantities, explicit units of measure

Output: real-valued or Boolean, often at much lower

frequency

Computation: custom-defined depending on the

application requirements

Operators: reusable standard temporal operations

applicable to data streams

Usability: should not require database expert to define

computations, domain experts must be autonomous


Technology scouting

Standard Relational DBMS

Good for storage

Not efficient for

computations

Rely on central servers

NoSQL approaches

Great for storage

May do computations,

require custom

programming and expertise

Rely on central (or cloud)

servers

Custom programming

Perfect fit with application

requirements

Very expensive to

customize

Stream Processing

No storage

Excellent for computations

Requires custom expertise


Stream Processing

(or Complex Event Processing, CEP)

Event processing: tracking and analyzing streams of data

«events», and deriving a conclusion from them

Defines a set of (fixed) queries

Event streams are analyzed in real time (often with in-

memory processing) according to the programmed queries

Guarantees fast and scalable processing

Increasingly adopted in different domains: Business Process

Management, Recommender Systems, Financial Services, Time

Series, …

Several tools available (commercial and open source)

Specific skills needed to write efficient queries, in tool-

dependent languages


Stream Processing

(or Complex Event Processing, CEP)

Event processing: tracking and analyzing streams of data

«events», and deriving a conclusion from them

Defines a set of (fixed) queries

Event streams are analyzed in real time (often with in-

memory processing) according to the programmed queries

Guarantees fast and scalable processing

Increasingly adopted in different domains: Business Process

Management, Recommender Systems, Financial Services, Time

Series, …

Several tools available (commercial and open source)

Specific skills needed to write efficient queries, in tool-

dependent languages


insert into RealEvent(src, streamName, value, unitOfMeasure) select ‘‘Average’’, ‘‘Average-out’’, avg(value) as value, unitOfMeasure from realEvent (streamName=’’M1’’). win:time\_batch(‘‘1h’’) group by src, streamName, unitOfMeasure; insert into BooleanEvent(src, streamName, booleanValue) select ‘‘Threshold’’, ‘‘Threshold-out’’ as streamName, true as value from pattern [every (oldSample=RealEvent( streamName=‘‘Average-out’’, MeasureEventComparator.compareToMeasure(oldSample,‘‘1kW’’, EventComparisonEnum.LESS_THAN_OR_EQUAL)) -> newSample=RealEvent(streamName=oldSample.streamName, MeasureEventComparator.compareToMeasure(newSample,‘‘1kW’’, EventComparisonEnum.GREATER_THAN)))].win:length(2);

Proposed approach (1)

Stream Processing for event data processing in real time

(Extensible) Library of predefined operators (spBlocks)

Declarative framework (spChains) to express the

required computations

Each Computation = Stream Processing Chain

Chain = Sequence of Stream Processing Blocks

Block = predefined operator, configured with parameters


Proposed approach (2)

The set of spChains is described as a simple XML file

All chains are automatically mapped to Stream

Processing queries


insert into RealEvent(src, streamName, value, unitOfMeasure) select ‘‘Average’’, ‘‘Average-out’’, avg(value) as value, unitOfMeasure from realEvent (streamName=’’M1’’). win:time\_batch(‘‘1h’’) group by src, streamName, unitOfMeasure; insert into BooleanEvent(src, streamName, booleanValue) select ‘‘Threshold’’, ‘‘Threshold-out’’ as streamName, true as value from pattern [every (oldSample=RealEvent( streamName=‘‘Average-out’’, MeasureEventComparator.compareToMeasure(oldSample,‘‘1kW’’, EventComparisonEnum.LESS_THAN_OR_EQUAL)) -> newSample=RealEvent(streamName=oldSample.streamName, MeasureEventComparator.compareToMeasure(newSample,‘‘1kW’’, EventComparisonEnum.GREATER_THAN)))].win:length(2);

<spXML:blocks> <spXML:block id="Avg1“ function="AVERAGE"> <spXML:param name="window" value="1“ unitOfMeasure="h"/> <spXML:param name="mode“ value="batch"/> </spXML:block> <spXML:block id="Th1“ function="THRESHOLD"> <spXML:param name="threshold“ value="1" unitOfMeasure="kW"/> </spXML:block> </spXML:blocks>

spChains Framework


Stream Processing

Chains

Stream Processing

Block

Event D

rains

Event So

urce

s

spBlocks

Pervasive/Ubiquitous Communication Infrastructure

Aggregate / Computed Measures

Pattern Match / Alerts

Environmental Data

Pervasive application

(s) Final Users

Chain Definition

Basic spBlock Library


Examples of spChains


Examples of spChains


<spXML:blockid = "Avg1" function = "AVERAGE"> <spXML:param name = "window" value = "1" unitOfMeasure = "h" / > <spXML:param name = "mode" value = "batch" /> </spXML:block>

Implementation

Java spChains library (Apache v2.0 license)

Core library

Esper bindings

Basic spBlock library

Scales up to 200 k events/sec

Already in use

3 different data centers, running on embedded PCs

Monitoring environment, electrical power consumption, thermal flows (heating and cooling), polled by means of the Dog2.x multiprotocol gateway

Computed quantity are “pushed” to Web Service collectors

Over 3 months of uptime, no issues found


http://elite.polito.it/spchains

Computing near to the field






API


Data exchange



service

• Multi-point and

geographic-scale systems

• Data publication

• Integrating external data

• (Open) Linked Data

• Data Decimation and Aggregation

• Over time

• Over space

• Computing derivative quantities over recent

data

• Virtual sensors

• Alarms and notifications

• High performance stream processing

• High level functional specification

• We propose: spChains

Motivation

Applications need to

access information from

multiple environments

Standard way to publish

and consume information

About accessible

environments

About available applicances,

sensors and their

characteristics

About the actual data

measured by sensors


Environ

ment

Applian

ces

sensors

Environ

ment

Applian

ces

sensors

Environ

ment

Applian

ces

sensors

Application Application

Approach

Applications need to

access information from

multiple environments

Standard way to publish

and consume information

About accessible

environments

About available applicances,

sensors and their

characteristics

About the actual data

measured by sensors


Adopt Semantic Web

«Linked Open Data

(LOD)» approach

Static information:

Can be encoded in RDF

according to a public

Ontology

Dynamic information:

New approach to represent

streams of RDF events

General LO(D)D Architecture


Producer

Application

Smart

Environment Static

information

about sensor

streams

publishes

E

G F

monitors



Producer

Application

Smart

Environment Static

information

about sensor

streams

Sensor

data

channel

Sensor

data

channel

Sensor

data

channel

describes

updates

publishes

E

G

E

E

G

G

G

G

E

E

F

F

F

F

monitors



Producer

Application Consumer

Application

Smart

Environment

Consumer

Application

Static

information

about sensor

streams

Consumer

Application Sensor

data

channel

Sensor

data

channel

Sensor

data

channel

describes

updates

publishes

receives

subscribes

E

G

E

E

G

G

G

G G

G

E

E E

E

E

E

F

F

F

F F

monitors

Proposed solutions

Open source libraries and API to enable application to interact with LO(D)D data

RDF document with meta-data (PID)

Publisher information

List of channels, their source data, their datatypes, and subscription URI/key

RDF «fragments» representing each event

Contains: event#, sensor id, timestamp, value, unit of measure

Uses publish-subscribe pattern as transport mechanism for distributing RDF fragments


Producer

Application Consumer

Application

Static

information

about sensor

streams

Sensor

data

channel

E

E

G F

Publisher Information Document (PID)

According to lightweight «Publisher» ontology

Contains declarations of all channels handled by this

publisher – all needed static information

Gives information to subscribe to channels

Created by

publisher API

Published over

http


<RDF:Description RDF:about="&Publisher;energymtr"> <publisher:Location RDF:datatype="&xsd;string"> Torino, Italia</publisher:Location> <publisher:subscribekey>sub-xxxxxx-42904d46dEEEEE </publisher:subscribekey> <publisher:channelName>Energy Meters </publisher:channelName> <RDF:type RDF:resource="&Publisher;Channel"/> </RDF:Description>

Event data fragments

Indivudual data points encoded in RDF

Self-consistent information (e.g. Unit of measure)

Standard syntax and semantics

Application-independent representation

Compact

encodings

available


<rdf:Description RDF:about = "&publisher;emergymtrChan1"> <publisher:MeterNumber RDF:datatype="&xsd;int"> 231 </publisher:MeterNumber> <publisher:Unit RDF:datatype="&xsd;string" > http://purl.oclc.org/NET/muo/ucum/unit/power-level/ bel-kilowatt</publisher:Unit> <publisher:hasTimeStamp RDF:datatype="&xsd;dateTime"> 2012-02-02T13:06:41.056Z </publisher:hasTimeStamp> <publisher:hasCurrentValue RDF:datatype ="&xsd;double"> 0.3 </publisher:hasCurrentValue> </RDF:Description>

Cloud based Transport mechanism

Provides the updates to subscribers whenever publishers

update data

New RDF fragments are sent to the cloud service

Maintains list of subscribers

Handles logic to provide transport from Publisher to

many Subscriber in real time

It makes the Publisher a “light-weight component”

Publisher is independent from the number of connected

subscribers


pubsubhubbub ...and others

Publisher and Consumer APIs

Publisher Library

Creates PID file an offers it on http

Creates channels onto cloud service

Sends updates to channel, encoding it in RDF

Consumer Library

Parses PID file and provides channel information

Subscribes to one or more channels

Notifies application whenr new data is available, decoding it from RDF

Same application may be producer and consumer at the same time

Applications need not manage RDF explicitly


Real applications



JEERP SMILE-O Politecnico Speak2Home

Rappresentazione neutrale

Funzionalità di base

API

Driver di interfacciamento ai protocolli

Scambio dati

Elaborazione real time Regole e scenari Servizio

applicativo

• Energy

monitoring

• Energy as an

asset

• ERP

integration

• DogOnt +

Dog +

spChains

Energy management


Jeerp (Proxima Centauri)


Detailed Jeerp Architecture

2012-09-11 e-lite - Smart Buildings 108 Field Data

Collector

Dog2.1

Aggregate Measures by asset / asset group

Alerts

Dog Events

Stream processing

historic data

Stream processing

Energy Manager

CMDBuild (Asset manager)

Oratio (ERP)

Administrative staff

Time scale

~ 1s

# Sensors

~ 1000

Time scale

~ 1h

# Assets

~ 100

Real applications






API


Scambio dati


applicativo • System

Producer

(wind turbine)

+ Consumer

(cheese

factory)

• Exchange data

across

subystems

• DogOnt +

LinkedOpen(D

ynamic)Data

Progetto SMILE-O


Real applications






API


Scambio dati


applicativo • Advanced

control

• Natural

language input

(spoken,

written)

• Language

analysis and

command

exeucution

• DogOnt +

Dog

• Energy

monitoring

• Detective

analysis

• Integrating

with existing

systems

• Defining a

building-level

architecture

DogEye user interface


Texas Intruments eZ430-Chronos


Motivations


Human-Home Interaction

traditional (buttons, switches, etc.)

computer-based (apps, UIs, etc.)

Needs to find a suitable trade-off

unobstrusive

instantly viewed or operated

feature-rich and personalizable

portable

Wearable computing could be a solution

Why a wrist-watch?

e-lite - Smart Buildings 116

a large fraction of population is already accustomed to

wearing watches

watches are less likely to be misplaced with respect to

phones, tablets or other mobile platforms

watches are more accessible than other devices one may

carry

the wrist is ideally located for body sensors and wearable

displays

2012-09-11

Requirements


Context sensors on board Required

Body sensors on board Optional

Sound emitter and haptics Optional

Localization Optional

Wireless communication Required

Long-lasting battery life Required

Display Required

Touch-access (button) Required

Touch-access (touch screen) Optional

Aspect customization Optional, but typically wanted

Function customization Optional

2012-09-11

eZ430-Chronos capabilities


Context sensors on board Required 3-axis accelerometer,

pressure and temperature

Body sensors on board Optional It supports external heart

rate monitors

Sound emitter and haptics Optional Buzzer

Localization Optional No

Wireless communication Required It supports the SimpliciTI

and the BlueRobin protocols

Long-lasting battery life Required Multiple days, depending on

the usage

Display Required 96-Segment LCD display

Touch-access (button) Required 4 buttons

Touch-access (touch screen) Optional No

Aspect customization Optional, but typically

wanted

No

Function customization Optional Yes

Wrist-watch implementation (I)


A new firmware, in the C language, has been developed

http://elite.polito.it/files/releases/dWatch_RFBSL.txt

Client-server paradigm

due to battery saving concerns, interactions take place either

on a sporadic basis (every 30, 60 or 180 seconds) or manually

2012-09-11

http://elite.polito.it/files/releases/dWatch_RFBSL.txt

Visual rule builder


Accessibility / Disability


Testing Dog in a Real Home


Credits

Ideas, Design, Development Projects & Sponsors


Dario Bonino, Ph.D.

Emiliano Castellina, Ph.D.

Luigi De Russis

Faisal Razzak

CE FP6 ICT COGAIN

Polo ICT (STORIES,

SMILE-O)

Proxima Centauri

Eudata

ISMB

Progetto Lagrange

Get involved!


User interfaces / User experience

Artificial intelligence / Semantic modeling

Wireless [sensor] networks

Ambient Assisted Living applications

Stream data processing

Extension to Buildings and Industrial settings

Energy savings / Energy management

Linked-data information exchange

Device modeling / Environment modeling

…

Thank you!


Questions? Comments?

For further information


Research group

http://elite.polito.it

Dog2 gateway

http://domoticdog.sourceforge.net

Publications

http://elite.polito.it/publications-mainmenu-81

Contact

[email protected]

+39 011 090 7053

http://elite.polito.it/







mailto:[email protected]

Licenza d’uso


Questa presentazione è rilasciate con la licenza Creative

Commons “Attribuzione-Non commerciale-Condividi allo

stesso modo 2.5 Italia”

Siete liberi di riprodurre e modificare quest’opera, per

scopi non commerciali, e citando la fonte. Eventuali

versioni modificate dovranno essere rilasciate con la

stessa licenza

Testo completo della licenza:

http://creativecommons.org/licenses/by-nc-sa/2.5/it/

smart buildings - architectures and technologies

Technology

abuilding7 elite

devices9 elite

smart buildings2012

home automation automation

smart buildingsarchitectures

automation system bas6elite

d ddd devices16 elite

systems home automation