Your SlideShare is downloading. ×
0
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
MICE: Monitoring and modelIng of Context Evolution
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MICE: Monitoring and modelIng of Context Evolution

241

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
241
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 1. MICE:Monitoring and modelIng the Context Evolution Lyon 10/09/2012Luca Berardinelli Antinisca Di Marco Flavia Di Paololuca.berardinelli@univaq.it antinisca.dimarco@univaq.it Flavia.dipaolo@univaq.itDipartimento 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 MEHAwareness Manager examples for the MeH System……and an excerpt of their combination. At any time, the context of MeH is triple of threevaluesAt design-time all the parameter are the transition probabilities (assumed) and the steadystate 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-timeMICE is a composite and distributed system that includes threemain 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 CardKeep track of your battery information. plugged (1/0) temp ( C) level (%)This app runs in the background collecting you on/off on/offbattery level, voltage, temperature andplugged state and sends this information toyour 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-timeContext Data Repository: Cosm (COTS)Cosm is a RESTful Web service that, through Cosm-enabled device Cosm-enabled device Cosm-enabled devicethe 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 isorganized in feeds. The latter are divided in Repository(typed) datastreams that, in turn, are (Cosm Web Service) HTTPcomposed by datapoints, each representing asingle value of a datastream at a specific point Raw Data (feed)in time.Any feed on Cosm belongs to a registered userthat may decide to keep them private orpublic. https://cosm.com/how_it_works 12
    • 13. MICE: Moving AMs from design- to run-timeContext Data Repository: Cosm (COTS)Battery Level: 35 (%)at Aug 15 20:01:15 Data Not CollectedPlugged: 1 (true)at Aug 15 20:01:15 https://cosm.com/how_it_works 13
    • 14. MICE: Moving AMs from design- to run-timeModeling 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-timeContext Model API has been automatically obtained from a Ecore-based AM Metamodel 15
    • 16. MICE: Moving AMs from design- to run-timeModeling 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 v1The following list summarizes the main steps that have been undertaken to set upthe 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; HighBattery Level: 35 (%) Powerat 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 PowerPlugged: 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
    • 23. 23

    ×