MICE: Monitoring and modelIng of Context Evolution
1. MICE:
Monitoring and modelIng the
Context Evolution
Lyon
10/09/2012
Luca Berardinelli Antinisca Di Marco Flavia Di Paolo
luca.berardinelli@univaq.it antinisca.dimarco@univaq.it Flavia.dipaolo@univaq.it
Dipartimento di Ingegneria e Scienze dell’Informazione e Matematica (DSIM)
University of L’Aquila (ITALY)
2. OUTLINE
• Keywords
• Motivations and Motivating Example
• Background: our context modeling and analysis approach
• The MICE Tool
• Ongoing and Future Works
• Conclusions
2
3. KEYWORDS
Context:
The heterogeneous information that the software 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 software system to sense the context in which it is executing
and to change the behavior in response to changes of the sensed context.
Context Evolution:
The set of changes in the sensed context and their possible (cause-effect)
relationships.
3
4. MOTIVATIONS
• The Goal:
– Validation and refinement of (context) models at run-time, as the
basis for
• Predictive Analysis of QoS: predicting the QoS of a context-aware software
system within ranges of parameters that are not (yet!) experienced in practice;
• Proactive Context Evolution: provinding in advance QoS information so that the
system adaptation is not blindly taken, but it can be QoS-aware
• Our Contribution:
– MICE (Monitoring and modelIng the Context Evolution), a supporting tool for
our context modeling and analysis approach.
4
5. MOTIVATING EXAMPLE
Doctor Mobile eHealth
home
Service Layer
Patient
Send Alarm
Request Patient Info Service Manager
open air
Component Layer
surgery
Doc Client
patient’s home Doc GUI Server App Beeper Client
Platform Layer
PDA
TCP/IP
Wireless
Network
Mobile eHealth (MeH) is a mobile, component-based application for assisting
doctors in their everyday activities through services running on their PDAs.
MeH Context may be (but not limited to) a combination of:
• Physical Location of its users
• Logical Location of its sw components
• Configuration of its hardware resources
5
6. BACKGROUND: CONTEXT MODELING
Luca Berardinelli, Vittorio Cortellessa, Antinisca Di Marco: Performance Modeling
and Analysis of Context-Aware Mobile Software 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
attr1…attri …attrn attri=vb B
DSLs (π probB)
– Based on Awareness MANAGERs, a stochastic extension of Harel’s Statecharts
• can be associated to any modeling element whose attributes contribute to define the
application-specific context where
• each state (partially) represents the actual context as a set of attribute values.
• transitions are triggered by the occurrence of certain event(s) when certain condition(s) are
verified.
• Paramenters : Probabilities are associated to transitions.
• Assumption: Probabilities are exponentially 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 combination. At any time, the context of MeH is triple of three
values
At design-time all the parameter are the transition probabilities (assumed) and the steady
state probabilities (calculated).
7
8. MICE: Moving AMs from design- to run-time
• Problem: collecting contextual data at run-time to
continuously update the AMs
– Req.1: MICE has to support our Context Modeling approach
– Req.2: The implementation 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 after the end of the
exam/thesis).
– Req.4: MICE has to reuse COTS as much as possible (it helps in
satisfying Req.2 and 3).
8
9. MICE: Moving AMs from design- to run-time
MICE is a composite and distributed system that includes three
main components with the following roles:
• Monitor. It is in charge of collecting the heterogeneous data that
are sensed by the context-aware application (e.g., the battery 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 elaborations.
• 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-time
• Monitor: Battery Status (COTS)
• Context Data Repository: Cosm (COTS)
• Modeling Component: Context Model API (in-house)
Monitoring Component
(Battery Status Cosm)
Context Data
Repository
HTTP
(Cosm Web Service)
Modeling Component
Context Model API
(EMF-based API)
MICE
10
11. MICE: Moving AMs from design- to run-time
PDA (Android Device)
Monitor: Battery Status App (COTS)
Battery WiFi Screen
Card
Keep track of your battery information.
plugged (1/0)
temp ( C)
level (%)
This app runs in the background collecting you
on/off
on/off
battery level, voltage, temperature and
plugged state and sends this information to
your Cosm account. Monitoring Component
(Battery Status Cosm)
Additional data is also collected: Context Aware System
- Screen brightness (MeH Client)
- Network status
- Phone Call state
- WiFi on/off
- Bluetooth on/off
- Data transferred
https://play.google.com/store/apps/details?id=nfcf.BatteryStatus&hl=en
11
12. MICE: Moving AMs from design- to run-time
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 publication
(POST) and retrieval (GET) of sensor-derived
feed
contextual data to/from the Web.
The whole heterogeneous contextual data
Context Data Raw Data (feed)
collected from a Cosm-enabled device is
organized in feeds. The latter are divided in Repository
(typed) datastreams that, in turn, are (Cosm Web Service) HTTP
composed by datapoints, each representing a
single value of a datastream at a specific point Raw Data (feed)
in time.
Any feed on Cosm belongs to a registered user
that may decide to keep them private or
public.
https://cosm.com/how_it_works
12
13. MICE: Moving AMs from design- to run-time
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
https://cosm.com/how_it_works
13
14. MICE: Moving AMs from design- to run-time
Modeling Component (in house)
It includes a
Modeling Component
- Parameters Extractor that sets the state-
Context Model API
steady probabilities π 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
http://code.google.com/a/eclipselabs.org/p/context-manager/
14
15. MICE: Moving AMs from design- to run-time
Context Model API has been automatically obtained from a Ecore-based AM
Metamodel
15
16. MICE: Moving AMs from design- to run-time
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)
probabilities π 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
probabilities from the sojourn times in the identified
awareness states.
Thanks to Giovanni Di Santo (Context Editor, Bachelor Thesis)
http://code.google.com/a/eclipselabs.org/p/context-manager/
16
17. MICE: Moving AMs from design- to run-time
PDA (Android Device)
MICE at a glance
Battery 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
Raw Data (feed) (Battery Status Cosm)
Context Data
Thanks to Context Aware System
Repository (MeH Client)
Flavia Di Paolo HTTP
(Cosm Web Service)
(co-author)
Modeling Component
(MICE, Bachelor Raw Data (feed)
Thesis) Context Model API
(EMF-based API)
Manager(s)
MICE
JVM-compatible 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 BatteryStatus application on two Android
devices so that new datapoint were sent by BatteryStatus every 15 minutes;
• We retrieved from Cosm the up-to-date collection 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, respectively;
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 times in the high and low power states by
counting the number of couples, each corresponding to a time 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 time spent
in high and low power (i) during the latest monitored day at the time of
writing 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 notation to suitably
combine ( ◦ ) two or more Awareness Managers, including remote firings
(i.e. AM dependencies), into a multi-attribute Context Manager that still
remains a valid Markov Model.
• We are combining Context, Design and Analysis Models at run-time. We
already combine these different kind of models but at design-time
(NFPinDSML@Models 2009)
21
22. CONCLUSIONS
• We presented MICE, a distributed tool for monitoring and
modeling the context evolution;
• It is meant to support an existing Context Modeling and
Analysis Approach presented at FASE 2010;
• MICE exploits existing COTS to reduce its implementation and
maintenance efforts so making it suitable for undergraduate
and graduate students
• MICE is an ongoing work available at
http://code.google.com/a/eclipselabs.org/p/context-manager/
Thanks for your attention.
Questions and suggestions are very welcome
22
Thetopicofthispresentationis the performance modeling and analysisofcontext-aware mobile software systems
Thisis the outlineofthis talk. I detail a UML-basedframeworkformodeling system services and theirusers, the software architecture, the component-basedbehaviors, the hardware platform. The UML modelisthensuitablyextendedusingprofilesto annotate performance parametersneededby a model-based performance analysismethodology[click]Wewillseehowcontext and context-awareness are cross-cuttingconcerns in the modelContextinducesmobilityaspects in users and software architecture,Weconsiderbehaviorsadaptabletocontext and a configurable hardware platform.also the performance parametersbecomecontext-related and consequently the performance analysiscarried out usingsuchparametersI will end the presentationwithconclusions and future work
whatwemeanforcontext, a combinationof informationaboutphysical location of system userssuchasthisroom or our homelogical location of software componentsthatiswhere the components are deployedconfigurationof hardware resourcessupporting the executionof the software. Forexample the actualchargelevelof the battery, the cpu frequency[click]The contextmayrapidlychange. Followingourdefinitionofcontextwe deal withphysicalmobilitycorrespondingtochangesofphysicallocationsof the users. He can move or the placeschangesaround in termsofavailable hardware resourceslogicalmobilitycorrespondingtoredeploymentof software componentsover the hardware platform hardware configurationchange: forexample the amountof a certainresourcedecreasessuchas the chargelevelof a battery
So PLASTIC. I willexplainitwith a leadingexample in the ehealth domain.A doctortakes care ofhispatientswhilemoving in differentphysicalplaces. PLASTIC introduces a twolayersapproach at software level: the service and componentlayers. Services are implemented in termsofcomponents. Forbothlayersweneed a structural and behavioraldescription. Thenwe a platformlayercomposedbyresourceconstraineddevices and heterogeneousnetworks, namely B3G networks. In fact PLASTIC aims at realizingservicesover B3G networks.Finallywehavetodescribe the context: itcorrespondto a set ofheterogeneous information thatinfluences the system behavior. In particularweconsider information relatedto the network and hardware devices.
Nowweneedto introduce contextinformationswithin a UML modeldescribed so far.In ourframeworkwechoose a distinctAwarenessManagersforeachcontextdimensionconsidered.Itis a stochasticstatechartassociatedtothosemodelingelementsrelatedtocontextwhere state models the set ofattributesassociatedto the modelingelement,transitionsmodels the eventstriggeringchanges in attribute’s valuesprobabilities are associatedtotransitions. They are constrained so thatprobabilities on outgoingtransitionsfromeach state sum up to 1finallyvariables are usedacross the modelforexampleto indicate the current state