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

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

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

Ubicomp Systems 4

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

 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

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

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

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.

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

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

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

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

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

 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

 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

 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

 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

Activate policies 19

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

 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

 Overview The reconfiguration framework 22

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

 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

 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

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

 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

ThankS