Smart buildings - architectures and technologies

Politecnico di Torino
Dipartimento di Automatica e Informatica
e-Lite Research Group
http://elite.polito.it

Smart Buildings
architectures and technologies

Fulvio Corno – fulvio.corno@polito.it

Outline
 Conclusions
 Happy hour

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

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


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
Home Automation
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

Available Well-defined
technologies applications

Problem
solved
… or
not?

Outline (the real one…)
 Problem definition
 Proposed architecture
 Application examples
 Q&A


Starting points

• Environmental sensors (temperature,
Application 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

D D D D
Devices


Starting points

• Dashboards (observing, monitoring, …)
Application • 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, …)
D D D D • Integration with information systems
Devices


Closing the loop

Application • Sensor technologies
• Communication protocols
• Scale (local, geographic)
• Number of devices
• Sampling frequencies
Infrastructure • Security / authentication
• Type of data
• Unidirectional vs bidirectional
• Data encoding
• Polling / Pushing
D D D D
Devices


Easy to say «device»
Field bus Wireless

Powerline Computer-derived

RS-485


Easy to say «device»
Field bus Wireless

Note 1: this is just a small sample of
currently used protocols

Note 2: we don’t list all other solutions,
Powerline more or less «custom» Computer-derived

RS-485
Note 3:   


Network Technology
 Bus  Powerline
 MyOpen  Echelon
 KNX  X10
 Modbus  Insteon
 Echelon  Wireless
 Dali  ZigBee
 CAN  Z-Wave
 MBus  EnOcean


Application Area
 Automation  Entertainment
 Real-time Control  UPnP
 CAN  DLNA
 KNX, MyHome, Insteon,  General purpose
Echelon, Modbus, X10, ZigBee,
 Bluetooth
Z-Wave, EnOcean
 WiFi
 Lighting
 Dali
 (all Automation)
 Metering
 Mbus
 RS-485
 KNX, Modbus, Echelon,
ZigBee, Z-Wave,…


Meanwhile, in the real world, …
 Different suppliers  Diverse technologies in
 Different the same system
sub-systems  Never designed for
 Different installation times interoperation (even
 Legacy worse…)
 Different needs and
D D D D
requirements

D D D D

D D D D


Meanwhile, in the real world, …
 Needs are growing  Different applications on
 Opportunities the same physical system
are growing  Sharing sensors, data and
 Developing new interfaces actuation commands
 New application areas
 Scale integration
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
The «My gateway is way too
«All you can eat» application
clever» case

Application Application

Infrastructure
Infrastructure

D

D D D D D D D D
Devices Devices


And now?
Application Application Application Application

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


A lingua franca

Neutral representation



Open and Horizontal Architectures

Rules and Application
Real time computation
scenarios service
API

Basic/core functionalities Data exchange


Protocol interface drivers



Applications consume data and services

scenarios service
API






Applications command and control

scenarios service
API






An abstract model
Application ApplicationAbstract w.r.t. technology
• Application Application
• Expandable w.r.t.
• Tecnologies
RulesDevices
• and Application
scenarios
• Application domains service
Standard languages and representations (W3C
•API
Semantic Web): RDF & OWL
• We propose: DogOnt ontology





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

DogOnt
DogOnt - Ontology Modeling for Intelligent Domotic Environments, D. Bonino, F. Corno
7th International Semantic Web Conference, 2008, Springer-Verlag, pp. 790-803

Building
Thing IsIn / contains

Building
Environment
Controllable

House Building Apartment
Plant

Electric
System Lamp hasState
Room

OnOff
hasFunctionality State
Control
Functionality
Discrete
OnOff State
Functionality

State
Functionality


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

OffNotification

OnNotification hasNotification
hasNotification
OnOffNotification
Functionality

OnOffState hasFunctionality

generatesCmd hasState Switch
hasState
Lamp
hasFunctionality isIn
isIn OnOffState
OnOffFunctionality
hasCommand Sample Room
hasCommand
OffCommand generatesCmd
OnCommand


Home / Building Gateway
Application Application Application configuration
• System Application
• Sending commands
• Monitoring states
Rules and • Getting data from sensors
Application
scenarios • Asynchronous (event-driven)
service
API programming model
• Application independent
Basic/core functionalities • Standard-based interfaces (http,
Data exchange
XML, JSON, …)


We propose: D • Open and expandable architecture
D D D D D D D D D D D
Dog 2.x • Acceptable development times
• Application independent

Dog 2.x http://domoticdog.sourceforge.net

 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


Intelligent Domotic Environments


DOG - Domotic OSGi Gateway
http://domoticdog.sourceforge.net/


System Architecture
User Mobile, Web, Home Display,
User Multi Touch, Accessibility,
Interface
User Natural language, …
Interface
Interface
Data ERP, Web services, Stream
processors, Datawarehouse
analysis
Device abstraction, Event
Dog abstraction, State abstraction,
Bundles Rules engine, …

Ethernet, Wi-Fi, USB

Bus-to-IP gateway
GW GW Bus-to-serial gateway

Domotic bus (wired, wireless)

Smart D D D D D D D D Domotic devices (switches,
buttons, relays, sensors, meters,
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


Core

DogXMLEndPoint DogRESTEndPoint

DogStateMonitor DogScheduler DogExecutor DogDeviceManager DogNotificationManager
DogAutoStart

DogDeviceFactory DogSimpleHouseModel
DogSemanticHouseModel
DogOntLibrary DogDeviceModel

DogConfigurator DogLogger

Dog2Library DogJaxBLibrary DogSemanticLibrary MeasureLibrary org.rxtx


Dog REST EndPoint

Dog REST EndPoint
DogStateMonitor DogScheduler
DogExecutor DogDeviceManager DogNotificationManager
Provides REST access to Dog

 Based on JSON or XML messages
DogAutoStart


 Under development




Dog XML EndPoint


Dog XML EndPoint
DogStateMonitor
DogScheduler DogExecutor DogDeviceManager DogNotificationManager
 Provides XML-RPC access to Dog
DogAutoStart

DogSimpleHouseModel
 Based on XML messages
DogDeviceFactory
DogOntLibrary Two Way Connection
 DogDeviceModel
Client  to send notifications
 Server  to listen application requests



DogStateMonitor


DogStateMonitor
DogAutoStart

Keeps a snapshot
 DogDeviceFactory of the state of all devices DogSimpleHouseModel
 Allows for state change listener registration
 Supports state querying
 Typically asynchronous
 Synchronous through a different interface (API)


DogScheduler


DogScheduler
DogAutoStart

Allows to schedule
 DogDeviceFactory recurring tasks involving DogSimpleHouseModel
 Command execution (done through the command
handling bundles)
 State requests (done by reading the currentDogLogger
DogConfigurator device
state in dog – not on the network)
 Notification…?(for what?)


DogExecutor


DogExecutor
DogAutoStart

Dispatches a command to relative device object
 DogDeviceFactory DogSimpleHouseModel
 Performs command validation
 Supports message priority
 No pre-defined priority levels
 Higher priority  Higher Priority Value in the
corresponding DogMessage


DogDeviceManager


DogDeviceManager
DogAutoStart

Implements the OSGi device manager (device
 DogDeviceFactory DogSimpleHouseModel

access specification)DogSemanticHouseModel
 Manages device/driver attachment in Dog
 When device/driver are added/modified/removed



DogNotificationManager


DogNotificationManager
DogAutoStart

 DogDeviceFactory the
Implements Event Admin Service Specification
DogSimpleHouseModel
Version 1.2 DogSemanticHouseModel
 It is based on a event publish and subscribe model
 Filters inner state change notifications from DogLogger
DogConfigurator outer
ones (visible to applications)
 Dispatches Notification and State Change MeasureLibrary
Dog2Library DogJaxBLibrary DogSemanticLibrary org.rxtx

Notifications only


DogDeviceFactory


DogAutoStart

DogDeviceFactory DogSemanticHouseModel
 Creates device istances according to the runtime home

configuration
 Either provided by the SimpleHouseModel or by the Semantic
House Model


DogOntLibrary


DogAutoStart

DogOntLibrary  State classes
DogConfigurator  StateDogLogger
value classes
 All possible
Programmatically

 Devices DogJaxBLibrary
(interfaces)
Dog2Library generated from
DogSemanticLibrary MeasureLibrary org.rxtx
 Functionalities classes DogOnt


DogDeviceModel


DogAutoStart

DogDeviceModel
 All possible
 Device implementationsDogSemanticLibrary
Dog2Library DogJaxBLibrary MeasureLibrary org.rxtx




DogAutoStart

 Manages the home description in form of DogOnt instances
 Supports configuration requests
 Supports model merging
DogConfigurator
 Implements classification and basic reasoning DogLogger
 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


DogSimpleHouseModel


DogAutoStart

DogSimpleHouseModel
 Manages the home description in XML
 Used for Dog instances running on devices with low computational
power
DogConfigurator
 No model-merge capabilities DogLogger

 No reasoning support
Dog2LibrarySemanticHouseModel is present, this bundle automatically shuts
 If a DogJaxBLibrary DogSemanticLibrary MeasureLibrary org.rxtx
down


DogConfigurator


DogAutoStart

DogConfigurator DogSemanticHouseModel
 Manages bundle-specific
DogOntLibrary DogDeviceModel configurations
 Property files
 XML files
 Additional files (ontology, images, etc.)
 Provides configurations to all bundles implementing the
ManagedService interface


DogLogger


DogAutoStart

DogLogger DogSemanticHouseModel
 Provides logging facilities to all Core bundles
 CanDogConfigurator
log on console or file DogLogger

 Can apply different handlers (file, console) to different
logging levels


Dog2Library


DogAutoStart

Dog2Library DogSemanticHouseModel
 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


DogJaxBLibrary


DogAutoStart

DogJaxBLibrary DogSemanticHouseModel
 Provides XML serialization / de-serialiazion for
Inner messages
 Outer messages
 Configurations
 Etc.


DogSemanticLibrary


DogAutoStart

DogSemanticLibrary DogSemanticHouseModel
 Encapsulates and makes available all semantics-related
libraries
Jena
Dog2Library
 Pellet DogJaxBLibrary DogSemanticLibrary MeasureLibrary org.rxtx

 SPARQL query facilitator


MeasureLibrary


DogAutoStart

MeasureLibrary DogSemanticHouseModel
 Exports the JScience library to all Dog bundles
 WillDogConfigurator
define un-supported JScience unit of measures
DogLogger



Org.rxtx


DogAutoStart

Org.rxtx DogSemanticHouseModel
 Exports the serial port API library (rxtx) to all Dog
bundles



Drivers

KNXNetIP Elite
EIBLibIP

Texas
OpenWebNet Instruments
ZWave

Modbus Echelon


Driver structure

Network
Driver
Driver
Driver
Device Driver
Gateway
Driver


Network Driver

Network Driver
 Handles network-level communication
 Protocol
 Connection Driver
 Polling (when needed) Driver
Device Driver
 Defines the network access APIs for all driver
Gateway the same technology
bundles, for
Driver


Gateway driver

Gateway Driver
 Supports multi-gateway operation for a given
network technology
 Driver
Handles the association between devices and gateways
 Permits to install device driver bundles Driver
only if the
Device Driver
corresponding network gateway is present (in the
Gateway
configuration)
Driver


Device Driver

Device Driver
 Implements the DogOnt device features for a given
class of devices
Driver
 Translates ontology-defined commands,
Driver
functionalities and states into network level
messages Device Driver
Gateway
 One device driver per each DogOnt device class
Driver the same driver can serve multiple device
Sometimes
classes but this should be avoided


The KNX demo box

D

GW


The Z-Wave demo box

GW

D


Device access (OSGi)
DogDeviceModel

DeviceDriver

DogDeviceCategory

DogDeviceManager


Add-on

DogRulesBundle

DogPowerModelBundle

DogPowerBundle


DogRulesBundle

DogRulesBundle
 Provides a rule-engine runtime for
 Defining automation scenarios
 Interoperation
 Complex device behaviors

DogPowerModelBundle
Programmable through dedicated DogMessages
 XML-based rule definitions
DogPowerBundle
 Uses notifications as triggers, states as
constraints and commands as rule consequent
 Supports time-driven triggers


Add-on

DogPowerModelBundle
 Handles the power
DogRulesBundle extension of DogOnt
 Plug in the main Semantic House Model
 Provides power-specific query functionalities on
the model

DogPowerModelBundle

DogPowerBundle


Add-on

DogPowerBundle
 DogRulesBundle
Exploits the DogPowerModelBundle
 Provides power consumption estimation based on
 Actual measures
 Typical/Nominal values defined in the DogOnt power
extension
 DogPowerModelBundle
Disaggregates actual measures when needed
 Keeps an updated snapshot of the current home
power consumption
DogPowerBundle


Command handling (1)

Application

Command

Dog


Command handling (2)
Command

DogAutoStart




KNX Modbus Echelon OpenWebNet ZWave

Network Message


Notification handling (1)

Application

Notification

Dog


Notification handling

DogXMLEndPoint DogRESTEndPoint Rules

DogState Dog Dog DogDevice DogNotification
Monitor Scheduler Executor Manager Manager
DogAutoStart

DogDeviceFactory DogSimpleHouseModel PowerBundle
DogOnt DogDevice PowerModel
Library Model Bundle


DogSemantic
Dog2Library DogJaxBLibrary MeasureLibrary org.rxtx
Library

KNX Modbus Echelon OpenWebNet ZWave


Open and Horizontal Architectures

scenarios service
API






Computing near to the field
• Multi-point and
Application Application Application geographic-scale systems
Application
• Data publication
• Integrating external data
• (Open) Linked Data
scenarios service
API

• Data Decimation and Aggregation
• Over time
• Over space
• Computing derivative quantities over recent
data Protocol interface drivers
• Virtual sensors
• Alarms and notifications
• High performance stream processing
• High level functional specification D D D
D D D D D D D D D
• 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  Custom programming
 Good for storage  Perfect fit with application
 Not efficient for requirements
computations  Very expensive to
 Rely on central servers customize
 NoSQL approaches  Stream Processing
 Great for storage  No storage
 May do computations,  Excellent for computations
require custom  Requires custom expertise
programming and expertise
 Rely on central (or cloud)
servers


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
insert into RealEvent(src, streamName, value,
 Defines a set of (fixed) queries
unitOfMeasure) select ‘‘Average’’,
‘‘Average-out’’, avg(value) as value,
 Event streams are analyzed in real(streamName=’’M1’’). in-
unitOfMeasure from realEvent time (often with
memorywin:time_batch(‘‘1h’’) to the programmed queries
processing) according
group by src, streamName, unitOfMeasure;
 Guarantees fast and scalable processing
insert into BooleanEvent(src, streamName,
booleanValue) select ‘‘Threshold’’,
 Increasingly adopted in different domains: Business Process
‘‘Threshold-out’’ as streamName, true as value from pattern
[every (oldSample=RealEvent(
Management, Recommender Systems, Financial Services, Time
streamName=‘‘Average-out’’,
Series, …MeasureEventComparator.compareToMeasure(oldSample,‘‘1kW’’,
EventComparisonEnum.LESS_THAN_OR_EQUAL)) ->
 Several tools available (commercial and open source)
newSample=RealEvent(streamName=oldSample.streamName,
MeasureEventComparator.compareToMeasure(newSample,‘‘1kW’’,
 Specific skills needed to write efficient queries, in tool-
EventComparisonEnum.GREATER_THAN)))].win:length(2);
dependent languages

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
<spXML:blocks> insert into RealEvent(src, streamName, value,
unitOfMeasure) select ‘‘Average’’,
<spXML:block id="Avg1“ ‘‘Average-out’’, avg(value) as value,
function="AVERAGE"> unitOfMeasure from realEvent
<spXML:param name="window" value="1“ (streamName=’’M1’’).
win:time_batch(‘‘1h’’)
unitOfMeasure="h"/> group by src, streamName, unitOfMeasure;
<spXML:param name="mode“ insert into BooleanEvent(src, streamName,
value="batch"/> booleanValue) select ‘‘Threshold’’,
‘‘Threshold-out’’ as streamName, true as value
</spXML:block> from pattern [every (oldSample=RealEvent(
streamName=‘‘Average-out’’,
<spXML:block id="Th1“ MeasureEventComparator.compareToMeasure(oldSamp
le,‘‘1kW’’,
function="THRESHOLD"> EventComparisonEnum.LESS_THAN_OR_EQUAL)) ->
<spXML:param name="threshold“ newSample=RealEvent(streamName=oldSample.stream
value="1" unitOfMeasure="kW"/> Name,
MeasureEventComparator.compareToMeasure(newSamp
</spXML:block> le,‘‘1kW’’,
EventComparisonEnum.GREATER_THAN)))].win:length
</spXML:blocks> (2);

spChains Framework

spBlocks

Stream Pattern Match / Alerts
Processing
Block

Pervasive
Event Sources
application

Event Drains
Environmental Stream Aggregate / Computed (s) Final Users
Data Processing Measures
Chains

Pervasive/Ubiquitous Communication
Infrastructure

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 http://elite.polito.it/spchains
 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


Computing near to the field
• Multi-point and
Application Application Application geographic-scale systems
Application
• Data publication
• Integrating external data
• (Open) Linked Data
scenarios service
API

• Data Decimation and Aggregation
• Over time
• Over space
• Computing derivative quantities over recent
data Protocol interface drivers
• Virtual sensors
• Alarms and notifications
• High performance stream processing
• High level functional specification D D D
D D D D D D D D D
• We propose: spChains

Motivation
 Applications need to
Application Application
access information from
multiple environments
 Standard way to publish
Environ Environ Environ
and consume information
ment ment ment  About accessible
environments
Applian Applian Applian  About available applicances,
ces ces ces sensors and their
characteristics
 About the actual data
sensors sensors sensors
measured by sensors


Approach
 Applications need to
Adopt Semantic Web access information from
«Linked Open Data
(LOD)» approach multiple environments
 Standard way to publish
and consume information
Static information:
Can be encoded in RDF  About accessible
according to a public environments
Ontology  About available applicances,
sensors and their
Dynamic information:
characteristics
New approach to represent  About the actual data
streams of RDF events measured by sensors


General LO(D)D Architecture
Smart
Environment Static
Producer publishes
information
Application about sensor
E
streams

G monitors
F


Smart
Environment Static
Producer publishes
information
E Application about sensor
E F
G streams
E

G monitors describes
F
E Sensor
G E
data
F channel
G Sensor
updates F
data
channel
G
Sensor
data
channel


Smart subscribes
Environment Static
Producer publishes information
E Application about sensor Consumer
E F Application
G streams E
E

G monitors describes
F Consumer
E
E
E Sensor Application
G E E
data
F channel
G Sensor G
Consumer
updates F Application
data F
channel receives
G G
Sensor
data
channel


Proposed solutions
Producer  Open source libraries and API to enable
Application
Consumer application to interact with LO(D)D data
Application
 RDF document with meta-data (PID)
Static  Publisher information
information
about sensor
 List of channels, their source data, their
streams datatypes, and subscription URI/key
 RDF «fragments» representing each event
E  Contains: event#, sensor id, timestamp, value,
F unit of measure
G
E
 Uses publish-subscribe pattern as
transport mechanism for distributing RDF
Sensor
data fragments
channel


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 <RDF:Description RDF:about="&Publisher;energymtr">
publisher API <publisher:Location RDF:datatype="&xsd;string">
Torino, Italia</publisher:Location>
 Published over
<publisher:subscribekey>sub-xxxxxx-42904d46dEEEEE
http </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 <rdf:Description RDF:about = "&publisher;emergymtrChan1">
<publisher:MeterNumber RDF:datatype="&xsd;int">
encodings 231 </publisher:MeterNumber>
available <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>
101 e-lite - Smart Buildings
</RDF:Description> 2012-09-11

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

...and others
pubsubhubbub

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 Speak2Home Politecnico

Elaborazione real time Regole e scenari Servizio
applicativo
API
• Energy
monitoring
• Energy as an Funzionalità di base Scambio dati
asset
• ERP Rappresentazione neutrale
integration
• DogOnt + Driver di interfacciamento ai protocolli
Dog +
spChains



Energy management


Jeerp (Proxima Centauri)


Detailed Jeerp Architecture
Oratio (ERP)

Administrative
staff

Time scale
CMDBuild (Asset
~ 1h
manager)
# Assets
~ 100
Energy Manager

Aggregate Measures
Alerts
by asset / asset group

Collector

Stream
Stream processing
Time scale processing
~ 1s
# Sensors
~ 1000 Dog Events

Dog2.1

historic
Field Data data

Real applications

• System applicativo
Producer API
(wind turbine)
+ Consumer
Funzionalità di base Scambio dati
(cheese
factory)
Rappresentazione neutrale
• Exchange data
across
Driver di interfacciamento ai protocolli
subystems
• DogOnt +
LinkedOpen(D
D D D D ynamic)Data D D D D D D D D


Progetto SMILE-O


Real applications

• Advanced applicativo
API control • Energy
• Natural monitoring
Funzionalità di base language inputScambio dati
• Detective
(spoken, analysis
Rappresentazione written)
neutrale • Integrating
• Language with existing
analysis and
Driver di interfacciamento ai protocolli systems
command • Defining a
exeucution building-level
• DogOnt + architecture
D D D D D D D Dog D D D D D


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?
 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


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


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 No
wanted
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


Visual rule builder


Accessibility / Disability


Testing Dog in a Real Home


Credits

Ideas, Design, Development Projects & Sponsors

 Dario Bonino, Ph.D.  CE FP6 ICT COGAIN
 Emiliano Castellina, Ph.D.  Polo ICT (STORIES,
 Luigi De Russis SMILE-O)
 Faisal Razzak  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
 fulvio.corno@polito.it
 +39 011 090 7053


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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Smart buildings - architectures and technologies

Ähnlich wie Smart buildings - architectures and technologies (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Smart buildings - architectures and technologies