MICE: Monitoring and modelIing the Context Evolution


Published on

Presentation by Luca Berardinelli, Antinisca Di Marco and Flavia Di Paolo at the 2nd Awareness Workshop on Challenges for Achieving Self-awareness in Autonomic Systems @ SASO 2012, Lyon, France

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MICE: Monitoring and modelIing the Context Evolution

  1. 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. 2. OUTLINE  •  Keywords  •  Mo4va4ons  and  Mo4va4ng  Example  •  Background:  our  context  modeling  and  analysis  approach  •  The  MICE  Tool  •  Ongoing  and  Future  Works  •  Conclusions   2  
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. MICE:  Moving  AMs  from  design-­‐  to  run-­‐4me     Context  Model  API  has  been  automa4cally  obtained  from  a  Ecore-­‐based   AM  Metamodel   15  
  16. 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. 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. 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. 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. 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. 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. 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