1. A Framework for the Reconfiguration of Ubicomp Systems Pau Giner, Carlos Cetina, Joan Fons, Vicente Pelechano

2.  Introduction  Background  The proposal  The reconfiguration framework  Conclusions and further work Agenda 2

3.  Introduction  Background  The proposal  The reconfiguration framework  Conclusions and further work Agenda 3

4. Ubicomp Systems 4

5.  Invisibility means to cope with different…  …environments  …users  …devices  …to provide a natural interaction. Some words regarding invisibility 5

6.  Many different devices and user preferences involve many configuration options  Services can be combined in different ways  Users have different demands regarding the system behavior The need for configuration 6

7. Simplicity 7  To achieve invisibility for the system, operation and configuration should be simple  We propose the autonomous reconfiguration of the system

8.  Introduction  Background  The proposal  The reconfiguration framework  Conclusions and further work Agenda 8

9. Background: PervML 9 9 > Presence Simulation > Presence Detection > Alarm > Random Simulation Starter > Presence Detected > Perimeter Detector > Infrared Detector > Visual/Acoustic Alarm > Security > Silent Alarm > Automated Lighting > Volumetric Detector > Blink Lighting > Buzzer > Automated Lighting Main concepts: Service coordinates the interaction among providers (hardware or software). Binding provider (BP) technology adapters. Interaction sequence of invocations between services. Trigger changes in the environment. A Domain Specific Language for the specification of Pervasive Systems.

10. PervML Example 10 Security Service in a Smart Home 10 Security Service Presence Detected Trigger Motion Detector Contact Sensor Alarm Technical details: European Installation Bus (EIB) devices Presence Detection Service

11. Code generation capabilities 11 Abstraction Level - + EIBBlueToothUPnP... OSGi Framework PervML models Generated Code Model  Generate  Deploy  Change Model

12.  Introduction  Background  The proposal  The reconfiguration framework  Conclusions and further work Agenda 12

13. The idea 13 Options for service composition Behavior desired by users Feature modeling Policy definition

14. The idea 14 Feature modeling Policy definition I offer a compact representation of information Since I access the system using my mobile phone, I need a compact representation of information General properties are used to connect both aspects

15.  Capture system variability  Using Feature Modeling  Define properties of interest  Indicate which system components fulfill them  Create Policies  Indicate which properties are required  Activate Policies (in run-time)  The system is reconfigured to better fulfill the demanded properties Proposal Overview 15

16.  Feature modeling Capture system variability 16 Smart Home Presence Detection Perimeter DetectionIn home Detection Infrared 160 degree Detection Volumetric 360 degree Detection Presence Simulation Alarm Silent Alarm Visual/Acoustic Alarm Security Siren Automated Illumination Description of a system and its variants. Relationships: Optional Mandatory Or-relationship Alternative

17.  Relevant properties are defined  E.g., compact interaction, activity simulation, house emptiness  Features are qualified according to their fulfillment  Complete, partial or none Define properties of interest 17

18.  A policy defines a set of assertions  Each assertions requires, prefers, discourages, forbids some property  Can be created by designers or end-users Create Policies 18

19. Activate policies 19

20.  Introduction  Background  The proposal  The reconfiguration framework  Conclusions and further work Agenda 20

21.  The reconfiguration framework extends the PrvML framework  Based on OSGi for dynamicity ▪Using Equinox implementation ▪The variability model is kept and queried at runtime  Providing new components: ▪Characterization ▪Analyzer ▪Reconfigurator The reconfiguration framework 21

22.  Overview The reconfiguration framework 22

23.  Characterization component  Collects al the assertions from the active policies ▪Serialized as XML  Inconsistencies are managed ▪Restrictive assertions are prioritized The reconfiguration framework 23

24.  Analyzer component  Decides which features to activate to fulfill the properties ▪OCL is used to query models at runtime  A conservative approach ▪A change is produced only when the system improves the property coverage The reconfiguration framework 24

25.  Reconfigurator component  Once a feature is (de)activated, the corresponding services and resources must be (dis)connected ▪The code for these has been generated by PervML  OSGi Wire class is used ▪To support publish/subscribe pattern The reconfiguration framework 25 Presence detection Service Motion detector Contact sensor

26.  Introduction  Background  The proposal  The reconfiguration framework  Conclusions and further work Agenda 26

27.  The main goal was to provide PervML systems with reconfiguration capabilities  The obtained framework can be used out of the method  The application to more case studies  Better management of policy scope and definition Conclusions and further work 27

28. ThankS