The document describes MICE (Monitoring and modelIng the Context Evolu4on), a tool that supports moving context awareness managers (AMs) from design time to run time. MICE is a composite, distributed system with three main components: a Monitor that collects heterogeneous contextual data sensed by the application, an Analyzer that updates the AMs based on the monitored data, and a Predictor that performs predictive analysis based on the updated AMs. MICE aims to enable validation and refinement of context models at run time to support predictive quality of service analysis and proactive context evolution awareness.

1. MICE:
Monitoring
and
modelIng
the
Context
Evolu4on
Lyon
10/09/2012
Luca
Berardinelli
An3nisca
Di
Marco
Flavia
Di
Paolo
luca.berardinelli@univaq.it
an4nisca.dimarco@univaq.it
Flavia.dipaolo@univaq.it
Dipar4mento
di
Ingegneria
e
Scienze
dell’Informazione
e
Matema4ca
(DISIM)
University
of
L’Aquila
(ITALY)

2. OUTLINE
• Keywords
• Mo4va4ons
and
Mo4va4ng
Example
• Background:
our
context
modeling
and
analysis
approach
• The
MICE
Tool
• Ongoing
and
Future
Works
• Conclusions
2

3. KEYWORDS
Context:
The
heterogeneous
informa3on
that
the
soXware
system
is
capable
to
sense
from
itself
or
from
the
external
environment
that
can
influence
the
behavior
of
the
services
it
provides.
Context
Awareness:
The
ability
of
the
soXware
system
to
sense
the
context
in
which
it
is
execu4ng
and
to
change
the
behavior
in
response
to
changes
of
the
sensed
context.
Context
Evolu3on:
The
set
of
changes
in
the
sensed
context
and
their
possible
(cause-­‐effect)
rela4onships.
3

4. MOTIVATIONS
• The
Goal:
– Valida,on
and
refinement
of
(context)
models
at
run-­‐,me,
as
the
basis
for
• Predic/ve
Analysis
of
QoS:
predic4ng
the
QoS
of
a
context-­‐aware
soXware
system
within
ranges
of
parameters
that
are
not
(yet!)
experienced
in
prac4ce;
• Proac/ve
Context
Evolu/on:
provinding
in
advance
QoS
informa4on
so
that
the
system
adapta4on
is
not
blindly
taken,
but
it
can
be
QoS-­‐aware
• Our
Contribu,on:
– MICE
(Monitoring
and
modelIng
the
Context
Evolu4on),
a
suppor4ng
tool
for
our
context
modeling
and
analysis
approach.
4

5. MOTIVATING
EXAMPLE
Mobile
eHealth
home
Doctor
Service
Layer
Pa3ent
Send
Alarm
Request
Pa3ent
Info
Service
Manager
open
air
Component
Layer
surgery
Doc
Client
pa3ent’s
home
Doc
GUI
Server
App
Beeper
Client
PlaBorm
Layer
PDA
TCP/IP
Wireless
Network
Mobile
eHealth
(MeH)
is
a
mobile,
component-­‐based
applica4on
for
assis4ng
doctors
in
their
everyday
ac4vi4es
through
services
running
on
their
PDAs.
MeH
Context
may
be
(but
not
limited
to)
a
combina3on
of:
•
Physical
Loca4on
of
its
users
•
Logical
Loca4on
of
its
sw
components
•
Configura4on
of
its
hardware
resources
5

6. BACKGROUND:
CONTEXT
MODELING
Luca
Berardinelli,
Vijorio
Cortellessa,
An4nisca
Di
Marco:
Performance
Modeling
and
Analysis
of
Context-­‐Aware
Mobile
SoXware
Systems.
FASE
2010
– An
approach
presented
at
FASE
2010
Best
Paper
Award
System
Design
Model
ELEMENT::Awareness Manager
Context-­‐related
tr. prob “,” event “/” [condition] “/” action
or
ELEMENT
Aattri=va
a@r1…aCri
…a@rn
attri=vb B
DSLs
(π probB)
– Based
on
Awareness
MANAGERs,
a
stochas4c
extension
of
Harel’s
Statecharts
• can
be
associated
to
any
modeling
element
whose
aCributes
contribute
to
define
the
applica4on-­‐specific
context
where
• each
state
(par4ally)
represents
the
actual
context
as
a
set
of
ajribute
values.
• transi,ons
are
triggered
by
the
occurrence
of
certain
event(s)
when
certain
condi4on(s)
are
verified.
• Paramenters
:
Probabili3es
are
associated
to
transi4ons.
• Assump3on:
Probabili3es
are
exponen3ally
distributed
à
Markov
Model
(CTMC)
à
Steady
State
probability
vector
may
be
associated
to
the
state
space
(π
probB)
6

7. BACKGROUND:
CONTEXT
MODELING
IN
MEH
Awareness
Manager
examples
for
the
MeH
System…
…and
an
excerpt
of
their
combina4on.
At
any
4me,
the
context
of
MeH
is
triple
of
three
values
At
design-­‐4me
all
the
parameter
are
the
transi4on
probabili4es
(assumed)
and
the
steady
state
probabili4es
(calculated).
7

8. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
• Problem:
collec4ng
contextual
data
at
run-­‐4me
to
con4nuously
update
the
AMs
– Req.1:
MICE
has
to
support
our
Context
Modeling
approach
– Req.2:
The
implementa4on
effort
should
be
appropriate
w.r.t.
the
availability
of
human
resources
and
their
skills
(few
undergraduate/graduate
students)
– Req.3:
The
maintenance
effort
should
be
as
lower
as
possible
(students
usually
leave
the
project
aXer
the
end
of
the
exam/
thesis).
– Req.4:
MICE
has
to
reuse
COTS
as
much
as
possible
(it
helps
in
sa4sfying
Req.2
and
3).
8

9. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
MICE
is
a
composite
and
distributed
system
that
includes
three
main
components
with
the
following
roles:
•
Monitor.
It
is
in
charge
of
collec4ng
the
heterogeneous
data
that
are
sensed
by
the
context-­‐aware
applica4on
(e.g.,
the
bajery
level
or
the
CPU
frequency).
The
raw
data
are
then
sent
to
a
remote
Context
Data
Repository.
•
Context
Data
Repository.
It
collects
the
contextual
data
sent
by
any
Monitor
and
makes
them
available
for
further
elabora4ons.
•
Modeling
Component.
It
retrieves
data
from
a
Context
Data
Repository
and
elaborates
them
to
generate
context
models
(i.e.
AMs).
9

10. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
•
Monitor:
Bajery
Status
(COTS)
•
Context
Data
Repository:
Cosm
(COTS)
•
Modeling
Component:
Context
Model
API
(in-­‐house)
Monitoring
Component
(Ba@ery
Status
Cosm)
Context
Data
Repository
(Cosm
Web
Service)
HTTP
Modeling
Component
Context
Model
API
(EMF-­‐based
API)
MICE
10

11. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
PDA
(Android
Device)
Monitor:
Bajery
Status
App
(COTS)
BaYery
WiFi
Screen
Card
Keep
track
of
your
bajery
informa4on.
ßplugged
(1/0)
ßtemp
(°C)
ßlevel
(%)
This
app
runs
in
the
background
collec4ng
you
ßon/off
ßon/off
bajery
level,
voltage,
temperature
and
plugged
state
and
sends
this
informa3on
to
your
Cosm
account.
Monitoring
Component
(Ba@ery
Status
Cosm)
Addi4onal
data
is
also
collected:
Context
Aware
System
-­‐
Screen
brightness
(MeH
Client)
-­‐
Network
status
-­‐
Phone
Call
state
-­‐
WiFi
on/off
-­‐
Bluetooth
on/off
-­‐
Data
transferred
hjps://play.google.com/store/apps/details?id=nfcf.BajeryStatus&hl=en
11

12. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
Context
Data
Repository:
Cosm
(COTS)
Cosm
is
a
RESTful
Web
service
that,
through
Cosm-­‐enabled
device
Cosm-­‐enabled
device
Cosm-­‐enabled
device
the
HTTP
protocol,
allows
the
publica4on
(POST)
and
retrieval
(GET)
of
sensor-­‐derived
feedà
contextual
data
to/from
the
Web.
The
whole
heterogeneous
contextual
data
collected
from
a
Cosm-­‐enabled
device
is
Context
Data
ßRaw
Data
(feed)
organized
in
feeds.
The
lajer
are
divided
in
Repository
(typed)
datastreams
that,
in
turn,
are
(Cosm
Web
Service)
HTTP
composed
by
datapoints,
each
represen4ng
a
single
value
of
a
datastream
at
a
specific
point
Raw
Data
(feed)à
in
4me.
Any
feed
on
Cosm
belongs
to
a
registered
user
that
may
decide
to
keep
them
private
or
public.
hjps://cosm.com/how_it_works
12

13. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
Context
Data
Repository:
Cosm
(COTS)
Battery Level: 35 (%)
at Aug 15 20:01:15
Data
Not
Collected
Plugged: 1 (true)
at Aug 15 20:01:15
hjps://cosm.com/how_it_works
13

14. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
Modeling
Component
(in
house)
It
includes
a
Modeling
Component
-­‐ Parameters
Extractor
that
sets
the
state-­‐
Context
Model
API
steady
probabili4es
π
of
the
modeled
(EMF-­‐based
API)
Manager
by
processing
the
real
data
Manager(s)à
collected
by
the
Monitoring
Component.
-­‐ Context
Manager
Editor
that
allows
the
modeling
of
the
Managers
They
are
both
based
on
a
Context
Model
API
hjp://code.google.com/a/eclipselabs.org/p/context-­‐manager/
14

15. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
Context
Model
API
has
been
automa4cally
obtained
from
a
Ecore-­‐based
AM
Metamodel
15

16. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
Modeling
Component:
Context
Model
API
(in-­‐house)
The
Modeling
Component
has
been
implemented
from
scratch
in
Java.
Modeling
Component
It
is
composed
by
a
Context
Manager
Editor
that
allows
the
modeling
of
the
Managers,
plus
a
Context
Model
API
Parameters
Extractor
that
sets
the
state-­‐steady
(EMF-­‐based
API)
probabili3es
π
of
the
modeled
Manager
by
processing
the
real
data
collected
by
the
Monitoring
Component.
The
Parameter
Extractor
retrieves
the
raw
monitored
data
stored
in
the
Context
Repository
COTS
and
then
calculates
the
state-­‐steady
probabili4es
from
the
sojourn
4mes
in
the
iden4fied
awareness
states.
Thanks
to
Giovanni
Di
Santo
(Context
Editor,
Bachelor
Thesis)
hjp://code.google.com/a/eclipselabs.org/p/context-­‐manager/
16

17. MICE:
Moving
AMs
from
design-­‐
to
run-­‐4me
PDA
(Android
Device)
MICE
at
a
glance
BaYery
WiFi
Screen
Card
ßplugged
(1/0)
Cosm-­‐enabled
device
Cosm-­‐enabled
device
Cosm-­‐enabled
device
ßtemp
(°C)
ßlevel
(%)
ßon/off
ßon/off
feedà
Monitoring
Component
(BaCery
Status
Cosm)
Context
Data
ßRaw
Data
(feed)
Thanks
to
Context
Aware
System
Repository
(MeH
Client)
Flavia
Di
Paolo
(Cosm
Web
Service)
HTTP
(co-­‐author)
(MICE,
Bachelor
Modeling
Component
Raw
Data
(feed)à
Thesis)
Context
Model
API
(EMF-­‐based
API)
MICE
Manager(s)à
JVM-­‐compa4ble
Device
17

18. MICE@WORK:
MeH
Running
Example
MICE
v1
The
following
list
summarizes
the
main
steps
that
have
been
undertaken
to
set
up
the
running
example
(Mice
v.1):
• We
created
a
Cosm
account;
• We
installed,
set
up
and
started
the
BaYeryStatus
applica4on
on
two
Android
devices
so
that
new
datapoint
were
sent
by
BajeryStatus
every
15
minutes;
• We
retrieved
from
Cosm
the
up-­‐to-­‐date
collec4on
of
level
datapoints
of
the
latest
30
calendar
days
(as
a
CSV
file).
• We
set
a
user-­‐defined
percentage
threshold,
for
example
strictly
greater
than
25%,
and
coupled
each
level
datapoint
with
the
high
power
or
the
low
power
awareness
states,
respec4vely;
High
Battery Level: 35 (%) Power
at Aug 15 20:01:15
25%
threshold
Data
Not
Collected
Low
Power
18

19. MICE@WORK:
MeH
Running
Example
MICE
v1
• We
calculated
the
sojourn
3mes
in
the
high
and
low
power
states
by
coun4ng
the
number
of
couples,
each
corresponding
to
a
4me
slot
of
15
minutes,
assigned
to
the
high
and
low
power
awareness
states.
• Given
the
total
amount
of
minutes
in
a
single
day
(1440)
and
in
a
month
of
31
days
(46400)
we
calculated
the
percentage
of
3me
spent
in
high
and
low
power
(i)
during
the
latest
monitored
day
at
the
4me
of
wri4ng
and
(ii)
in
the
latest
monitored
month.
19

20. ONGOING
AND
FUTURE
WORKS
MICE
v2
• We
are
combining
different
datastreams
(e.g.,
level
and
plugged)
to
create
more
complex
Awareness
Managers.
Under
Charge
Battery Level: 35 (%)
at Aug 15 20:01:15 High
Power
25%
Low
Data
Not
Collected
Power
Plugged: 1 (true)
at Aug 15 20:01:15
20

21. ONGOING
AND
FUTURE
WORKS
• We
are
formalizing
the
proposed
context
modeling
nota3on
to
suitably
combine
(
◦
)
two
or
more
Awareness
Managers,
including
remote
firings
(i.e.
AM
dependencies),
into
a
mul4-­‐ajribute
Context
Manager
that
s4ll
remains
a
valid
Markov
Model.
• We
are
combining
Context,
Design
and
Analysis
Models
at
run-­‐3me.
We
already
combine
these
different
kind
of
models
but
at
design-­‐4me
(NFPinDSML@Models
2009)
21

22. CONCLUSIONS
• We
presented
MICE,
a
distributed
tool
for
monitoring
and
modeling
the
context
evolu4on;
• It
is
meant
to
support
an
exis4ng
Context
Modeling
and
Analysis
Approach
presented
at
FASE
2010;
• MICE
exploits
exis4ng
COTS
to
reduce
its
implementa4on
and
maintenance
efforts
so
making
it
suitable
for
undergraduate
and
graduate
students
• MICE
is
an
ongoing
work
available
at
hjp://code.google.com/a/eclipselabs.org/p/context-­‐manager/
Thanks
for
your
a@en/on.
Ques/ons
and
sugges/ons
are
very
welcome
22