Management of Smart Homes using homeWabash

1
Management of Smart Homes using homeWabash

• Sambhrama Mundkur
• Ramkumar Natarajan

Aditya P. Mathur Baskar Sridharan
Software Engineering Research Center Department
of Computer Sciences Purdue University, West
Lafayette, Indiana, USA
Presentation at British Telecom, Martlesham
Heath, UK July 23, 2001
Latest Update July 19, 2001
2
The homeWabash Project 1

• Goal
• Develop an infrastructure to support test and
  management of applications to support
  SmartHomes.
• Demonstrate the effectiveness of the
  infrastructure.
• Sponsors
• NSF, British Telecom, Telcordia, and Tivoli
  (until May 2000)

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

4
Status

• Move from homeWabash 1.0 to homeWabash 2.0
• homeWabash 2.0 infrastructure available. Source
  code, and users manual will be available to SERC
  affiliates in August 2001.
• Support for Telcordias 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.

5
What is a SmartDevice ?
Device
Hardware Interface
Local Communication Network
PC/Gateway
Internet/Intranet
6
What is a SmartHome ?
SmartDevice
SmartDevice
SmartDevice
Local Comm Network
Infrastructure resides in
SmartHome boundary
Gateway
Service from within
Internet/Intranet
Service Provider
Service Provider
7
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.

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

9
1D-1A Management Scheme
Smart Home
Internet
Manufacturer 1
D1
Gateway
Remote Computer
Manufacturer 2
D2
Manufacturer 3
D3
Gateway
Manufacturer 4
D4
DMA Device Management Application DMA
Different version of DMA Di Device i
10
nD-1A Management Scheme
Internet
Smart Home
Service Provider
DMA
Local User
D1
DM 1 DM 2 DM 3 DM 4
Gateway
DMA
Image
D2
DM 1 DM 2 DM 3 DM 4
Infrastructure
D3
Gateway
Configure
Configured Infrastructure
D4
DM Device Module
11
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.

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

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

14
nD-1A Scheme Cons

• All manufacturers might not join the end users
  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.

15
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 and Proxy Management
Maintains information about the number and types
of proxies and configuration.
Co-relates event notifications against
user- specified Event-Action pairs.
ERNC
Policy Management (Under construction)
Maintains system wide policy information and
statistics. Enforces specified policies.
16
Components in home Wabash 2
17
Components in home Wabash 3
18
Component Interaction 1
Presentation
Technology Adapter
User Profile Management
CPM
ERNC
Policy Management
Proxy
Device Communication
DM Generator
19
Component Interaction 4
RG
P1
Actions (A)
N
A
A
MS
EP
E-A
Notifications (N)
A
N
P2
Actions (A)
A
E-A
CA
Event-Action Pairs (E-A)
EP Event Proxy P1 Device Proxy P2 Device
Proxy RG Residential Gateway CA Communications
Adaptor MS MBean Server E-A Event-Action
Pairs N Notifications A Actions
A
20
Component Interaction 3
HA
RG
P1
MS
CA
P2
P3
RA
JDBC
RMI
DB
JDBC
HTTP
WML
HTML
Web Server
21
ERNC

• 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

22
Smart Devices and Device Modules 1
Smart Device
Hardware
Interface
Communication network
home Wabash Application Generator
23
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.

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

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

26
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

27
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

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

29
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

30
Issues 2

• Policies for
• Safety
• Security
• Reliability
• Fault Tolerance
• Availability
• Server Selection
• Performance
• Data Accuracy

31
Issues 3

• 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

32
Needs 1

• Ability to specify
• Service domain organization
• Administrators and rights
• Policies for a group of domains/sub-domains/compon
  ents
• Various types of policies

33
Needs 2

• Ability to verify
• Consistency
• Completeness
• Adequacy
• Minimalist
• Relative strength of the policies
• Ability to notify violations of policies
• Ability to enforce policies

34
A Sample Service
Admin1, Policy1
Domain Hierarchy
Admin3, Policy3
Admin2, Policy2
CORBA Policy1Policy2
Components
EJB Policy1Policy3
35
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

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

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

38
Step I (a) Policy Specification

• Policies STD_VOL, SAFE_VOL, ALARM_SAFE,
  CO_SAFE
• STD_VOL0 lt TV.volume lt 60
• SAFE_VOL20 lt TV.volume lt 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.

39
(b) Domain Hierarchy Specification
MyHome
First Floor
Basement
AC
H
LRoom
BRoom
Kitchen
AC
H
H
H
PM
AL
AC
TV
AC
TV
AC Air Conditioner
LRoom Living Room
H Heater
BRoom - Bed Room
AL Emergency Alarm
PM Pulse Monitor
TV - Television
40
(c) Policy Application
MyHomeCO_SAFE, STD_VOL
First Floor
Basement
AC
H
LRoom
BRoom SAFE_VOL,ALARM_SAFE
Kitchen
AC
H
AC
H
TV
H
AC
TV
PM
AL
AC Air Conditioner
LRoom Living Room
H Heater
BRoom - Bed Room
AL Emergency Alarm
PM Pulse Monitor
TV - Television
41
(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 parents policies

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

43
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

44
Step IV Monitoring

• Intercept all event triggers
• Evaluate new state of the components
• Notify in case of possible violations of policy

45
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

46
WinAmp Remote Control
X10 Controller
Power Line
homeWabash
X10 Transceiver
Controller detects X10 event On power line and
informs homeWabash
Transceiver transmits it Over the power line
homeWabash finds matching Actions for the event
X10 Remote sends RF Command to transceiver
homeWabash transmits Control action to
WinAmp Using the WinAmp Proxy
X10 Remote
WinAmp
47
Assisted Living An Application
TCP UDP
Jini G/W
TS
HA
Jini
P1
MS
RMI
PM
CA
P2
TCP UDP
RG
X10
CH
RMI
P3
RA
RMI
homeWabash Infrastructure
Patient Monitoring Application
Gateways
Devices
48
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

49
MHAN Source for Assisted Living

• USE LIB swathi.cs.purdue.edu
• CREATE aldomain DOMAIN WITH NAMEAL DOMAIN
• CREATE prmonitor DEVICE WITH
• TYPEPRX13R NAMEPULSE MONITOR
• CREATE thermostat DEVICE WITH
• TYPETS1000 NAMETHERMOSTAT
• CREATE roomheater DEVICE WITH
• TYPESTD_HTR NAMEROOM HEATER TEMP65F
• CREATE aladmin USER WITH NAMEADMIN
  EMAILme_at_cs.purdue.edu
• WHEN thermostat.TEMP gt 80F
• INFORM aladmin
• INVOKE roomheater.OFF

50
Application Generator
Generates
Specifies requirements
Generates
Management Application SCG
MPG
MHAN Source
Java Source
User
is input to
is input to
MTL
IL
51
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.

52
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!
53
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.

54
Publications1

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

55
Publications1

• 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