A Framework for the Reconfiguration of
Ubicomp Systems
Pau Giner, Carlos Cetina, Joan Fons, Vicente
Pelechano
Agenda





Introduction
Background
The proposal
The reconfiguration framework
Conclusions and further work
2
Agenda





Introduction
Background
The proposal
The reconfiguration framework
Conclusions and further work
3
Ubicomp Systems
4
Some words regarding invisibility

Invisibility means to cope with different…
 …environments
 …users
 …devices

…to provide a natural interaction.
5
The need for configuration

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
6
Simplicity

To achieve invisibility for the system,
operation and configuration should be
simple
 We propose the autonomous reconfiguration of
the system
7
Agenda





Introduction
Background
The proposal
The reconfiguration framework
Conclusions and further work
8
Background: PervML
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.
<<Service>>
Presence
Simulation
<<Service>>
Presence
Detection
<<Trigger>>
Random
Simulation Starter
<< BP>>
Automated
Lighting
<< BP>>
Infrared
Detector
<< Service>>
Alarm
<< Trigger>>
Presence
Detected
<< BP>>
Volumetric
Detector
<< BP>>
Silent
Alarm
<< Service>>
Automated
Lighting
<< Interaction>>
Security
<< BP>>
Perimeter
Detector
9
<< BP>>
Visual/Acoustic
Alarm
9
<< BP>>
Blink
Lighting
<< BP>>
Buzzer
PervML Example
Security Service in a Smart Home
Technical details:
European Installation Bus (EIB) devices
Security
Service
Presence
Detected
Trigger
Presence Detection
Service
Motion
Detector
Contact
Sensor
10
Alarm
Code generation capabilities
+
Abstraction Level
PervML models
-
Generated Code
Framework
OSGi
EIB
BlueTooth
UPnP
...
Model  Generate  Deploy Change Model
11
Agenda





Introduction
Background
The proposal
The reconfiguration framework
Conclusions and further work
12
The idea
Options for service
composition
Feature modeling
Behavior
desired by users
Policy definition
13
The idea
I offer a compact
representation of
information
Feature modeling
General properties are used to
connect both aspects
Since I access the
system using my mobile
phone, I need a
compact representation
of information
Policy definition
14
Proposal Overview

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
15
Capture system variability

Feature modeling
Description of a system and its variants.
Smart Home
Relationships:
Optional
Mandatory
Or-relationship
Alternative
Security
Presence Simulation
Automated Illumination
Presence Detection
Perimeter Detection
Alarm
In home Detection
Infrared 160 degree Detection
Silent
Alarm
Siren
Volumetric 360 degree
Detection
16
Visual/Acoustic
Alarm
Define properties of interest

Relevant properties are defined
 E.g., compact interaction, activity simulation, house
emptiness

Features are qualified according to their
fulfillment
 Complete, partial or none
17
Create Policies



A policy defines a set of assertions
Each assertions requires, prefers,
discourages, forbids some property
Can be created by designers or end-users
18
Activate policies
19
Agenda





Introduction
Background
The proposal
The reconfiguration framework
Conclusions and further work
20
The reconfiguration framework

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
21
The reconfiguration framework

Overview
22
The reconfiguration framework

Characterization component
 Collects al the assertions from the active
policies
▪ Serialized as XML
 Inconsistencies are managed
▪ Restrictive assertions are prioritized
23
The reconfiguration framework

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
24
The reconfiguration framework

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
Presence detection
Service
Motion detector
Contact sensor
25
Agenda





Introduction
Background
The proposal
The reconfiguration framework
Conclusions and further work
26
Conclusions and further work

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
27
ThankS