management of connectedspaces using homewabash graduate students: latest update: january 27, 2002...

Management of ConnectedSpaces using homeWabash

Graduate Students:

Latest Update: January 27, 2002

PI: Aditya P. Mathur

Presentation to:MotorolaJanuary 28, 2002

Undergraduate Students:

Ramkumar NatarajanBaskar Sridharan

Alok Dalal [Handheld Access]Snehal S. Antani [Cerf-Cube Access]Mashrur Nabi [Flash Demo]

January 28, 2002 2Management of Smart Homes

The homeWabash Project [1]

Goal: Develop an infrastructure to support test

and management of applications to manage SmartHomes.

Demonstrate the effectiveness of the infrastructure.

Sponsors: NSF, British Telecom, Telcordia, and Tivoli

(until May 2000)



Staff: Since the beginning: PI, 3 doctoral, 2 MS,

and 4 undergraduate students.

Current: 2 doctoral and 3 undergraduate

students starting in fall 2001.


The homeWabash Project

Prototypes available:

August 1999 TDS 1.1 available to SERC affiliates.

August 2000 Wabash 2.3 available to SERC affiliates.

December 2000 homeWabash prototype available for demonstration.

May 2001 homeWabash 2.0, integrates variety of device standards. One application to demonstrate the utility of the homeWabash

2.0 infrastructure. December 2001

homeWabash 2.1, allows interfacing with handheld devices.


Status

homeWabash 2.0 infrastructure available. Source code, and

user’s manual will be available to SERC affiliates in August

2001.

Support for Telcordia’s Residential Gateway, X10, JINI, and

IEEE 1394 devices.

White Paper “Development of an Infrastructure for the

Management of SmartHomes” made available to British

Telecom and Telcordia. (Copies available for affiliates.)

Baskar Sridharan has joined the VESA working group; made a

presentation, on behalf of Telcordia, to VESA members on May

15 at R 7.4 Indianapolis.


What is a SmartDevice ?

HardwareInterface

PC/Gateway

Local Communication Network

Internet/Intranet

Device


What is a SmartHome ?

SmartDevice SmartDevice SmartDevice

Gateway

Service Provider

Service Provider

Service from within

Local Comm Network

Internet/Intranet

SmartHome boundary

Infrastructureresides in


Why SmartHomes ?

Need to stay connected with people and devices.

Working parent with child. Caretaker with sick person. Manufacturer with device.

Better and safer living Remind of low inventory and scheduled

maintenance. Detect blood clotting during dialysis and

take appropriate action.


Why Manage SmartHomes ?

Improved monitoring, control, and planning For home owners For device manufacturers For service providers

Better and safer living Pre-programming audio/video Security alarms; health alarms; safety alarms.


1D-1A Management Scheme

Manufacturer 1 D1

D2

D3

D4

Gateway

DMA: Device Management ApplicationDMA’: Different version of DMADi: Device i

Computerat Home

DMA 1DMA 2DMA 3DMA 4

Gateway

Internet

Manufacturer 2

Manufacturer 3

Manufacturer 4

Smart Home

DMA 1DMA’ 2

RemoteComputer

is manufactured by

Communicates with


nD-1A Management Scheme

Internet

D1

D2

D3

D4

Gateway

Gateway

Smart Home

ConfiguredInfrastructure

DM 1DM 2DM 3DM 4

Service Provider

DM 1DM 2DM 3DM 4

Infrastructure

Local User

Image

Manufacturer

RemoteUser

DMA

DM: Device Module

DMA

Configure


1D-1A Scheme: Pros

Good for complex management tasks such as climate

control within a building, management of a cruise ship,

and management of a production plant.

Benefits the manufacturer of devices as addition of

functionality, both hardware and software has the

potential for increased revenue.


1D-1A Scheme: Cons

Number of applications to handle increases with the

devices and leads to need for additional training for the

end user. Multiple user interfaces, management terminology,

database subscriptions, etc.

End user must keep track of updates and pay for them

or else risk being outdated.

Devices may not be able to collaborate unless their

manufacturers have planned for it.


nD-1A Scheme: Pros

Uniform device management interface. Variations are specific

to device functionality. Eases training needed to install and

begin using new devices.

End user need not be concerned about software upgrades,

Service Provider does so based on subscription.

New, cross-devices applications easier to construct.

End user deals with only one entity: the Service Provider. This

is similar to the phone subscription mechanism.

Common management and communications infrastructure

provided and maintained by the Service Provider. New

technologies easier to integrate.


nD-1A Scheme: Cons

All manufacturers might not join the end user’s favorite

Service Provider.

Devices might not follow interfacing standards. The end

user might have to subscribe directly to the service

provided by its manufacturer.

Monopoly or oligopoly in the Service Provider market

might harm the interests of the end-user.


Components in home Wabash [1]

Device Communication Multiplexes and de-multiplexes control commands for various types of devices

Proxy Mirrors the interfaces and attributes of a device for management.

(CPM) Configuration andProxy Management

Maintains information about the numberand types of proxies and configuration.

ERNC

Policy Management(Under construction)

Maintains system wide policy information and statistics. Enforces specified policies.

Co-relates event notifications against user-specified Event-Action pairs.



Technology AdapterExports the CPM module for external access

using various protocols.

Proxy Mirrors the interfaces and attributes of a

device for management.

Proxy Persistence

Management

Stores and retrieves state of a proxy using

a persistent store.

User ProfileManagement

Stores and retrieves user profiles and

proxy information from a persistent store.



Presentation Provides information for consumption by different types of users.

Device ModuleGenerator (underConstruction)

Generates Device Modules using Digital Device Manual.


Presentation

TechnologyAdapter

User ProfileManagement

CPMERNC PolicyManagement

ProxyDevice

Communication

Component Interaction [1]

DM Generator


CA

RG

X10

IEEE

1394

Bluetooth

MS EPE-A Notifications (N)

P1

P2

N

N A

A

Actions (A)

Actions (A)

Event-Action Pairs (E-A)

E-A

A

A

A EP: Event ProxyP1: Device ProxyP2: Device ProxyRG: Residential GatewayCA: Communications AdaptorMS: MBean ServerE-A: Event-Action PairsN: NotificationsA: Actions



MS

HA

CA

RA

P1

P2

P3

RG

X10

IEEE

1394

Bluetooth

TCP

UDP

IPC

CORBA

RMI

HTTP

CORBA

RMI

WebServer

WML HTML

DB

RMI

JDBC

JDBC

WebServer

HTTP



• Event proxy• Is an MBean like other device proxies• Maintains the set of event-action pairs specified by user• Each event can be associated with a list of actions• Registers for notification of events from other device

proxies and the residential gateway• Matches notifications against set of event-action pairs and

executes matching actions

• Device proxies• Use the JMX notification architecture for propagating

notifications

• Event-action pairs and notifications are well-formed XML documents

ERNC


Smart Device

Hardware

Interface

Smart Devices and Device Modules [1]

home WabashApplication Generator

Digital Device manual

resides in

Communicationnetwork


Smart Devices and Device Modules [2]

A Device Module (DM) is an automatically generated

application to manage a class of similar devices e.g. VCR, EKG

monitor, Blood Pressure Monitor, Oxygen dispenser, climate

controller, etc.

DM is generated by the Device Module Generator in

homeWabash with assistance from a Digital Device Manual

that resides within the device or at a place known to the DM

generator.


Digital Device Manual (DDM) [1]

A DDM is an active repository of device dependent

information for a specific class D of devices.

Formally, a DDM for a device class D is an 8-tuple: (ID,

S, S0. F, P, , I, A) : ID: Device ID; contains both static and dynamic

identifiers.

S: Finite set of all possible device states

S0 S : Finite set of all possible start states of the

device after it powers on.


Digital Device Manual (DDM) [2]

F: A finite set of all possible functions that all devices in D

can perform.

P: Finite set of applicable safety and security policies.

: S x F x P S x P

I: Finite set of interfaces. This includes functions to

get/set the attributes.

A: Finite set of attributes.


Example Partial DDM: A Home VCR [1]

ID: (Manufacturer: Sony; Model: ES 60; Serial: S3923667;

Owner: APM; Location: 40, 2, N, 86, 5, W; DDM: Here; Type:

Non-critical, home-use.)

S: {Idle-unloaded, Idle-loaded, Rewinding, Playing,

Recording, Paused, Downloading}

S0: {Idle-unloaded, Idle-loaded}

F: {Play, Record, Pause, Set-Type, Download, Load.local}

P: {User: Owner, Manufacturer, Provider; Time: Any;}


Example Partial DDM: A Home VCR [2]

Idle-unloaded, Load.local, null idle-loaded, null

Idle-loaded, Play, null Playing, null

I: Set of function calls to be used for

communications with the VCR. This includes

functions to get/set the attributes.

A: {Volume, Channel, Video-mode}


Policy: Specification,Verification & Enforcement

Services are realized using distributed applications

High-level policies establish the acceptable level of

quality of the service (non-functional behavior)

Goal:

A methodology and mechanisms for managing non-functional behavior of distributed services.


Issues [1]

Use of multiple distributed systems technologies

Service domain partitioned into sub-domains

Domains managed by administrators

Multiple administrators with different rights

Various types of policies


Policies for… Safety

Security

Reliability

Fault Tolerance

Availability

Server Selection

Performance

Data Accuracy

Issues [2]


Relevance of the policy depends on the type of distributed system.

Example:

Performance and Server selection policies

Low relevance in Home Area Networks

High relevance in Telecommunication applications

Issues [3]


Needs [1]

Ability to specify Service domain organization

Administrators and rights

Policies for a group of

domains/sub-domains/components

Various types of policies


Needs [2]

Ability to verify Consistency Completeness Adequacy Minimalist Relative strength of the policies

Ability to notify violations of policies Ability to enforce policies


A Sample Service

Admin1, Policy1

Admin2, Policy2

Admin3, Policy3

CORBA{Policy1+Policy2}

EJB{Policy1+Policy3}

DomainHierarchy

Components


Approach

Step I: Model the distributed system using a component-based abstraction.

Step II: Transform high-level policies into policy constraints using invariants and predicates using system state (state-based approach)

Step III: Translate policy constraints into states and state transitions

Step IV: Capture state transition triggers(events) to monitor possible policy violations

Step V: Perform policy enforcement ahead of state transitions


Example: Safety Policies for SmartHomes

Component specification: Attributes, Methods, State transitions

Components = {TV, AC, Heater, Pulse Monitor, Alarm} High-level policies

STD_VOL: Defined on all types of TVs. Specifies the range of the volume of the TV

SAFE_VOL: Defined for TVs coexisting in domains with emergency alarms. Limits the volume of the TV

ALARM_SAFE: Defined over all types of emergency alarms and TVs. Restricts the TV volume to be within the SAFE_VOL policy

whenever the alarm is on.


Example [Continued]

CO_SAFE: Defined over temperature controller devices. Prohibits the simultaneous operation of the AC and a heater to prevent possible emission of Carbon Monoxide.


Step I: (a) Policy Specification

Policies = {STD_VOL, SAFE_VOL, ALARM_SAFE, CO_SAFE}

STD_VOL={0 < TV.volume < 60} SAFE_VOL={20 < TV.volume < 40} ALARM_SAFE = !(ALARM.state = on & TV not in

SAFE_VOL) CO_SAFE = !(AC.state = on & Heater.state = on)

Note: Policies are specified over component types not instances. Policies are later applied to instances.


(b) Domain Hierarchy Specification

MyHome

First Floor Basement

Kitchen LRoom BRoom

AC H

AC H

ACH TV HAC TV PM AL

AC – Air ConditionerH – HeaterAL – Emergency AlarmPM – Pulse MonitorTV - Television

LRoom – Living RoomBRoom - Bed Room


(c) Policy Application

MyHome{CO_SAFE, STD_VOL}

First Floor Basement

Kitchen LRoom BRoom {SAFE_VOL,ALARM_SAFE}

AC H

AC H

ACH TV HAC TV PM AL

AC – Air ConditionerH – HeaterAL – Emergency AlarmPM – Pulse MonitorTV - Television

LRoom – Living RoomBRoom - Bed Room


(d) Resolving Policy Conflicts

Specify policy ranks

Use rank to resolve conflicts

Example:

Policies = {STD_VOL, SAFE_VOL,ALARM_SAFE, CO_SAFE}

Increasing priority

Parent node, in domain hierarchy, has higher priority

than its children

Children inherit parent’s policies


Step II: Verification

Consistency verification: resolving policy conflicts

Resolve SAFE_VOL & STD_VOL conflict on TV in

“BRoom”

Use SAFE_VOL (higher priority)

Inconsistent if unable to resolve using the

information provided in Step I.


Step III: Translation

Collect invariants and predicates from policies Translate each invariant/predicate into events on

system components. Component-based abstraction

All data required for policy management exposed using get/set interfaces.

Exported data modified ONLY through the respective interfaces

Use request_{in,out}/reply_{in,out} events as state transition triggers


Step IV: Monitoring

Intercept all event triggers

Evaluate new state of the components

Notify in case of possible violations of policy


Step V: Enforcement

Intercept all event triggers Evaluate new state of the components Use technology specific architecture to prevent

movement of the system into illegal state Ex: Policy Management Architecture will use

HomeWabash to enforce policies in SmartHomes Wabash to enforce policies in CORBA-based

enterprise applications


WinAmp Remote Control

RF

Power Line

UDP

X10 Remote

X10 Transceiver

X10 Controller

homeWabash

WinAmp

X10 Remote sends RFCommand to transceiver

Transceiver transmits itOver the power line

Controller detects X10 eventOn power line and informs homeWabash

homeWabash finds matchingActions for the event

homeWabash transmitsControl action to WinAmpUsing the WinAmp Proxy


Assisted Living: An Application

MS

HA

CA

RA

P1

P2

P3 RG

TCP

UDP

RMI

JiniG/W

TCP

UDP

RMI

TS

PM

CH X10

Jini

RMI

TS

PM

CH Chime

Pulse Monitor

Thermostat

Patient Monitoring Application

homeWabashInfrastructure

Gateways Devices


Application Generation

MHAN: Management of Home Area Networks, a language for the development of management applications for Home Area Networks. Used by:

Home Owners Service Providers

Characteristics of MHAN Domain Specific Typed Support for policy and security based operations

on types


MHAN Source for Assisted Living

USE LIB ‘swathi.cs.purdue.edu’CREATE aldomain DOMAIN WITH NAME=“AL DOMAIN”CREATE prmonitor DEVICE WITH

TYPE=“PRX13R” NAME=“PULSE MONITOR”CREATE thermostat DEVICE WITH

TYPE=“TS1000” NAME=“THERMOSTAT”CREATE roomheater DEVICE WITH

TYPE=“STD_HTR” NAME=“ROOM HEATER” TEMP=“65F”

CREATE aladmin USER WITH NAME=“ADMIN” EMAIL=“[email protected]”

WHEN thermostat.TEMP > “80F”INFORM aladminINVOKE roomheater.OFF


Application Generator

ManagementApplication

SCGMPG

MHANSource

MTL IL

JavaSource

MPG MHAN Program GeneratorMTL MHAN Type LibrariesIL SmartHome Infrastructure

LibrariesSCG Source Code Generator

User

Specifies requirements

Generates Generates

is input to

is input to


Future Work [1]

Completion of Policy module.

Completion of MHAN Language Design, library, and

related infrastructure.

Investigation of issues in the design and development of

Digital Device Manuals

Development of HomeWabash Libraries in Java

Develop and deploy an application in the area of

Assisted Living.


Affiliate Contacts

Summer interns at BT Labs and Telcordia.

Collaboration with BT and Telcordia.

Partnership with Telcordia in VESA Working

Group on Home Network Management.

Thanks for your support!



Products delivered:August 1999

TDS 1.1 available to SERC affiliates.

August 2000 Wabash 2.3 available to SERC affiliates.

December 2000 homeWabash prototype available for demonstration.

May 2001 homeWabash 2.0, integrates variety of device

standards. One application to demonstrate the utility of the

homeWabash 2.0 infrastructure.


Publications[1]

1. B.Sridharan et.al. "Flexible Software Architecture for Home Network Management". In Proceedings of the 2nd IEEE International Workshop on Networked Appliances,New Brunswick, NJ, USA, December 2000.

2. B.Sridharan, S.Mundkur and A.P.Mathur. "Non-intrusive Testing, Monitoring and Control of Distributed CORBA Objects", In the Proceedings of International Conference on Technology of Object-Oriented Languages and Systems (TOOLS) , pp 195-206, St. Malo, France, June 2000

3. B.Sridharan, B.Dasarathy and A.P.Mathur. "On Building Non-Intrusive Performance Instrumentation Blocks for CORBA-based Distributed Systems". In Proceedings of the 4th IEEE International Computer Performance and Dependability Symposium, pp 139-143, Schaumburg, IL, USA, March 2000


4. B.Sridharan. "An Extensible Framework for Monitoring and Controlling CORBA-based Distributed Systems". In Proceedings of the 1st ICSE Workshop on Testing Component-Based Distributed Systems, Los Angeles, CA, USA, May, 1999

5. A.P.Mathur, S.Ghosh, P.Govindarajan and B.Sridharan. “A Framework for Assessing Test Adequacy, Architecture Extraction, Metering, Monitoring and Controlling Distributed Component-Based Systems". In Proceedings of the 1st Symposium on Reusable Architecture and Components for Developing Distributed Information Systems, pp 657-660,Orlando, Florida, July, 1999

Publications[1]

management of connectedspaces using homewabash graduate students: latest update: january 27, 2002...

Documents

management of s mart

management of smarthomes

management of connectedspaces

management of applications

infrastructure available

management scheme manufacturer

status homewabash

homewabash graduate