Management of C onnectedSpaces using h omeWabash

1. Management of ConnectedSpaces using homeWabash • Ramkumar Natarajan • Baskar Sridharan Undergraduate Students: • Alok Dalal [Handheld Access] • Snehal S. Antani [Cerf-Cube Access] • Mashrur Nabi [Flash Demo] Graduate Students: PI: Aditya P. Mathur Presentation to: Motorola January 28, 2002 Latest Update: January 27, 2002

2. 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)

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

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

6. What is a SmartDevice ? Device Hardware Interface Local Communication Network PC/Gateway Internet/Intranet

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

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

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

10. DMA 1 DMA’ 2 Computer at Home DMA 1 DMA 2 DMA 3 DMA 4 is manufactured by Communicates with 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

11. Remote User Manufacturer 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

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

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

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

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

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

17. Technology Adapter Proxy Exports the CPM module for external access using various protocols. 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 Profile Management Stores and retrieves user profiles and proxy information from a persistent store. Components in home Wabash [2]

18. Presentation Device Module Generator (under Construction) Provides information for consumption by different types of users. Generates Device Modules using Digital Device Manual. Components in home Wabash [3]

19. Component Interaction [1] Presentation Technology Adapter User Profile Management ERNC CPM Policy Management Proxy DM Generator Device Communication

20. X10 IEEE 1394 Bluetooth Component Interaction [4] P1 RG Actions (A) A N A MS EP E-A Notifications (N) A N P2 A Actions (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

21. X10 HTTP TCP UDP IPC IEEE 1394 CORBA CORBA RMI RMI Bluetooth Web Server Component Interaction [3] RG HA P1 MS CA P2 P3 RA JDBC RMI DB JDBC HTTP WML HTML Web Server

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

23. resides in Digital Device manual Smart Devices and Device Modules [1] Smart Device Hardware Interface Communication network home Wabash Application Generator

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

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

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

27. 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;}

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

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

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

31. Issues [2] • Policies for… • Safety • Security • Reliability • Fault Tolerance • Availability • Server Selection • Performance • Data Accuracy

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

33. Needs [1] • Ability to specify • Service domain organization • Administrators and rights • Policies for a group of domains/sub-domains/components • Various types of policies

34. Needs [2] • Ability to verify • Consistency • Completeness • Adequacy • Minimalist • Relative strength of the policies • Ability to notify violations of policies • Ability to enforce policies

35. A Sample Service Admin1, Policy1 Domain Hierarchy Admin3, Policy3 Admin2, Policy2 CORBA {Policy1+Policy2} Components EJB {Policy1+Policy3}

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

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

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

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

40. (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

41. (c) Policy Application MyHome{CO_SAFE, STD_VOL} First Floor Basement AC H LRoom BRoom {SAFE_VOL,ALARM_SAFE} Kitchen AC H AC H TV AC H TV PM AL AC – Air Conditioner LRoom – Living Room H – Heater BRoom - Bed Room AL – Emergency Alarm PM – Pulse Monitor TV - Television

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

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

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

45. Step IV: Monitoring • Intercept all event triggers • Evaluate new state of the components • Notify in case of possible violations of policy

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

47. RF UDP 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

48. Thermostat TS PM Pulse Monitor CH Chime Assisted Living: An Application TCP UDP TS Jini G/W HA Jini P1 MS RMI PM CA P2 TCP UDP RG X10 CH RMI P3 RA RMI homeWabash Infrastructure Patient Monitoring Application Gateways Devices

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

50. 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=“me@cs.purdue.edu” WHEN thermostat.TEMP > “80F” INFORM aladmin INVOKE roomheater.OFF