1. A Pervasive Reminder System for Smart Homes Sylvain GIROUX and Simon GUERTIN Département d’informatique, Université de Sherbrooke 2500 boul. Université, Sherbrooke, Canada J1K 2R1 {Sylvain.Giroux, Simon.Guertin,}@USherbrooke.ca http://www.dmi.usherb.ca/~sgiroux/domus/

2. Plan  Context  Issues and Goals  Architecture  Scenario 1: –Localization and identification of the user –Towards personalization of the home according to the user  Scenario 2: –Pervasiveness –Moving applications seamlessly across devices  Scenario 3: –Sending information specific to the user that is in the room –Preserving the integrity of the distributed system  Conclusion  Future works

3. Context The DOMUS laboratory investigates pervasive and mobile computing  In a smart home environment, –Technology must be:  Seamlessly incorporated, distributed and available in the environment  Inter operate with other technological system (hardware, networks, software)  Personalized according to the user

4. Goals of the prototype  Identification of a user  Localization of a user  Transitory coalition of devices  Pervasiveness: –Integration in a real living environment –Fluid usage –Transparent user friendly migration of sessions –Zero-configuration  Spontaneous networking and service discovery  To cope with heterogeneity of devices and hardware, networks  Keeping the system in a clean state

5. Hardware Architecture

6. Software Architecture  Operating systems –Windows –Linux  Software –Java { J2ME, RMI, JINI}  Networks –Bluetooth –X10 –WiFi –LAN

7. Architecture  Jini Federation are used to structure services and communication –Rooms  for instance, to support location-awareness  living room, kitchen, etc. –Logically related services and devices  Identification services ( user log, sécurity, etc.)  Lighting control system  Heating, Ventilation and Air Conditioning systems (HVAC) –Example  A lamp using X10 could be part of the federations “Kitchen”, “X10 Devices” and “Electrical Devices”  Federations are used to: –locate and use other services –search for and select relevant services –discard or use a service

8. General Description  Pervasive messaging system  First steps towards a more sophisticated pervasive cognitive assistance system

9. Initial configuration  Basic Jini setup –HTTP Server for file distribution –Reggie  lookup service to allow registration to service discovery  Domus Server –Provide basic Domus architecture info and services –Provides a shared HTTP server to distribute source files  Security Server –Provide a database of user names and passwords

10. Scenario 1  Goals –Enable user detection and localization –Integration of heterogeneous networks  X10 and LAN  When someone enters the room, –Motion detectors gets triggered –The login screen is displayed (pervasive)

11. Scenario 1: Motion detector User goes through the door in a normal motion Motion detectors gets triggered X10 messages are received by the X10 Server X10 Server X10

12. Domus Room A Agenda Server Domus Server Security Server X10 Server Agenda Client Motion Detector Sensor A Sensor B Someone is in the room The agenda client prepares the login screen The user enters his password Authentication of the user X10 Server transform codes from electrical to computer format X10 server feeds new X10 codes to motion detector application Motion Detector establish that someone has entered the room And notify the interested applications The session begins

13. Scenario 2: Pervasiveness  Goals –Seamlessly changing device –Use a device with more appropriate capabilities  display  wireless  Location –Continue working in the application  The session is restored where it was left off  Case A - User switches directly to another device  Case B – User transfers his session to the server for later use

14. Scenario 2 A Domus Kitchen Room A Agenda Server Domus Server Security Server Agenda Client Agenda Client Session The user choose the appropriate device The user logs on The session is transferred The server authenticates The session is restored

15. Scenario 2B Domus Federation Room A Federation Agenda Server Domus Server Security Server Agenda Client Agenda Client Session Same as scenario 2A But session moves through the server

16. Scenario 3  Goals –Spontaneous networking and service discovery –Keeping the distributed system in a “clean” state –No messages are delivered twice –Towards transitory coalition of devices  The agenda tries to notify a user of an upcoming appointment

17. Scenario 3: Feedback Domus Kitchen Agenda Server Domus Server Security Server Feedback Server Room A Agenda Client Message Client Agenda Client Message Client Appointment An appointment is soon Server needs to notify the user A And Send message to feedback server Locate and send message to clients A The user is authenticated Confirmation sent back to the feedback server Remaining messages are removed Confirmation is sent back to agenda server The appointment has been acknowledged by the user

18. Properties of the distributed architecture  Decentralized  No main computer  No need for a super fast or powerful computer  Robust  Some services still remain available in case of partial crash or failure  Spontaneous networking  Integration of heterogeneous networks  Service discovery  Flexible

19. Conclusion  This system has been used to: –Integrate sensing and information devices –Deliver information to the user  Dynamic cooperation of –heterogeneous devices –heterogeneous networks (WiFi Bluetooth LAN X10)  Pervasiveness –Localization of the user –Session migration –Keeping the distributed system in a clean state  Low cost of hardware and software development

20. Future Works  Physical Identification of a user –Automatic login –Smart tags  Networks –Integrating Bluetooth –Choosing the right network protocol to deliver a message (Luc Bergevin)  Enhancing security (software and Java)  Improving and adding features to the messaging system

21. Scenario 2B Domus Federation Room A Federation Agenda Server Domus Server Security Server Agenda Client Agenda Client Session No clients are available to switch to The session is sent to the server A client becomes available The user logs in The server authenticates The session is restored