View
217
Download
0
Tags:
Embed Size (px)
Citation preview
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)
January 28, 2002 3Management of Smart Homes
The homeWabash Project [2]
Staff: Since the beginning: PI, 3 doctoral, 2 MS,
and 4 undergraduate students.
Current: 2 doctoral and 3 undergraduate
students starting in fall 2001.
January 28, 2002 4Management of Smart Homes
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.
January 28, 2002 5Management of Smart Homes
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.
January 28, 2002 6Management of Smart Homes
What is a SmartDevice ?
HardwareInterface
PC/Gateway
Local Communication Network
Internet/Intranet
Device
January 28, 2002 7Management of Smart Homes
What is a SmartHome ?
SmartDevice SmartDevice SmartDevice
Gateway
Service Provider
Service Provider
Service from within
Local Comm Network
Internet/Intranet
SmartHome boundary
Infrastructureresides in
January 28, 2002 8Management of Smart Homes
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.
January 28, 2002 9Management of Smart Homes
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.
January 28, 2002 10Management of Smart Homes
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
January 28, 2002 11Management of Smart Homes
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
January 28, 2002 12Management of Smart Homes
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.
January 28, 2002 13Management of Smart Homes
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.
January 28, 2002 14Management of Smart Homes
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.
January 28, 2002 15Management of Smart Homes
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.
January 28, 2002 16Management of Smart Homes
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.
January 28, 2002 17Management of Smart Homes
Components in home Wabash [2]
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.
January 28, 2002 18Management of Smart Homes
Components in home Wabash [3]
Presentation Provides information for consumption by different types of users.
Device ModuleGenerator (underConstruction)
Generates Device Modules using Digital Device Manual.
January 28, 2002 19Management of Smart Homes
Presentation
TechnologyAdapter
User ProfileManagement
CPMERNC PolicyManagement
ProxyDevice
Communication
Component Interaction [1]
DM Generator
January 28, 2002 20Management of Smart Homes
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
Component Interaction [4]
January 28, 2002 21Management of Smart Homes
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
Component Interaction [3]
January 28, 2002 22Management of Smart Homes
• 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
January 28, 2002 23Management of Smart Homes
Smart Device
Hardware
Interface
Smart Devices and Device Modules [1]
home WabashApplication Generator
Digital Device manual
resides in
Communicationnetwork
January 28, 2002 24Management of Smart Homes
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.
January 28, 2002 25Management of Smart Homes
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.
January 28, 2002 26Management of Smart Homes
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.
January 28, 2002 27Management of Smart Homes
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;}
January 28, 2002 28Management of Smart Homes
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}
January 28, 2002 29Management of Smart Homes
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.
January 28, 2002 30Management of Smart Homes
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
January 28, 2002 31Management of Smart Homes
Policies for… Safety
Security
Reliability
Fault Tolerance
Availability
Server Selection
Performance
Data Accuracy
Issues [2]
January 28, 2002 32Management of Smart Homes
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]
January 28, 2002 33Management of Smart Homes
Needs [1]
Ability to specify Service domain organization
Administrators and rights
Policies for a group of
domains/sub-domains/components
Various types of policies
January 28, 2002 34Management of Smart Homes
Needs [2]
Ability to verify Consistency Completeness Adequacy Minimalist Relative strength of the policies
Ability to notify violations of policies Ability to enforce policies
January 28, 2002 35Management of Smart Homes
A Sample Service
Admin1, Policy1
Admin2, Policy2
Admin3, Policy3
CORBA{Policy1+Policy2}
EJB{Policy1+Policy3}
DomainHierarchy
Components
January 28, 2002 36Management of Smart Homes
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
January 28, 2002 37Management of Smart Homes
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.
January 28, 2002 38Management of Smart Homes
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.
January 28, 2002 39Management of Smart Homes
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.
January 28, 2002 40Management of Smart Homes
(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
January 28, 2002 41Management of Smart Homes
(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
January 28, 2002 42Management of Smart Homes
(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
January 28, 2002 43Management of Smart Homes
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.
January 28, 2002 44Management of Smart Homes
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
January 28, 2002 45Management of Smart Homes
Step IV: Monitoring
Intercept all event triggers
Evaluate new state of the components
Notify in case of possible violations of policy
January 28, 2002 46Management of Smart Homes
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
January 28, 2002 47Management of Smart Homes
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
January 28, 2002 48Management of Smart Homes
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
January 28, 2002 49Management of Smart Homes
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
January 28, 2002 50Management of Smart Homes
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
January 28, 2002 51Management of Smart Homes
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
January 28, 2002 52Management of Smart Homes
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.
January 28, 2002 53Management of Smart Homes
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!
January 28, 2002 54Management of Smart Homes
The homeWabash Project [3]
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.
January 28, 2002 55Management of Smart Homes
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
January 28, 2002 56Management of Smart Homes
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]