Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

TOWARDS SOCIO-CHRONOBIOLOGICAL COMPUTATIONAL HUMAN MODELS

2.872 visualizaciones

Publicado el

Testing and validating Ambient Intelligence (AmI) services by living labs is not always feasible. The costs involved, specially when considering a large number of users, may be prohibitive. In these cases, an artificial society is required to test the AmI software in a simulated environment. Numerous methodologies deal with the modeling of agents, but this paper contributes with a methodology capable of modeling human beings by using agents, CHROMUBE. This methodology is extended in this paper to include social interactions in its models. This extension of the methodology employs an architecture which maximizes code reuse and allows developers to model numerous kind of interactions (p.e.: voice, e-mail conversations, light panels ads, phone calls, etcetera). An implementation of the architecture is also given with UbikSim and a case study illustrates its use and potential.

Publicado en: Ciencias
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

TOWARDS SOCIO-CHRONOBIOLOGICAL COMPUTATIONAL HUMAN MODELS

  1. 1. TOWARDS SOCIO-CHRONOBIOLOGICAL COMPUTATIONAL HUMAN MODELS University of Murcia Francisco Campuzano, Emilio Serrano and Juan A. Botía Contact: {fjcampuzano,emilioserra,juanbot}@um.es 1
  2. 2. CONTENT  Motivation  CHROMUBE  HAB  HAI  HAI, protocols  HAI, channels  HAI, conversations and interactions handler  Case study  Conclusion, where is the contribution?  Future works 2
  3. 3. MOTIVATION  Ambient Intelligence (AmI) main goal is to augment live quality of people  These services need to be tested and validated  The use of living labs is the hegemonic approach  Real users involved → very realistic  But  Faults cannot be detected before deploying system  Tests may be expensive / infeasible 3
  4. 4. MOTIVATION II  Simulation approaches solve these limitations  By modelling an environment, AmI devices, and a users society  Social Simulation  (Although real tests are also desirable)  There are plenty of methodologies and frameworks to develop agent based social simulations  Repast, MASON, NetLogo, etc  ...even simulators designed specifically for AmI  Ubiwise, TATUS, UbiREAL, etc  …but there is a huge gap  when these are employ to model a realistic society of users (in an AmI system) 4
  5. 5. CHROMUBE  This paper extends CHROMUBE  CHROnobiology for Modelling hUman BEhaviour  The essentials of CHROMUBE philosophy:  (1) It is possible to create realistic human behaviours and simulate them for the validation of AmI environment's services or applications.  (2) Chronobiology, an area of science which studies how time affects living organisms, can help in the characterization of human behaviours  (3) Sensor data gathered from the AmI environment allow CMHBs (Computational Models of Human Behaviour) to be created. 5
  6. 6. CHROMUBE II 6
  7. 7. CHROMUBE III  CHROMUBE has been successfully employed to validate AmI environments with isolated users1  Step 5, design of artificial behaviours, is significantly extended here with:  more details in the modelling of users  mechanisms to model and validate social interactions in the CMHBs  an implementation to facilitate this task  Under UbikSim framework http://ants.dif.um.es/staff/emilioserra/ubiksim/ 7 1. “Chronobiology Applied to the Development of Human Behavior Computational Models”, to appear in Journal of Ambient Intelligence and Smart Environments
  8. 8. HAB  Hierarchical automaton of behaviors, HAB  Formalism recommended in CHROMUBE to design behaviours  Hierarchical automaton means that each state is itself another automaton  a HAB is composed of:  a list of pending transitions ordered by priority  a method for creating new transitions  (adding them to the list),  a current state  (state with the control)  and a default state  (state that takes control of the automaton when the list of pending transitions is empty).  An interpreter makes the automaton advance every step of the simulation transparently for the developer  Source code of interpreter available online: http://ants.dif.um.es/staff/emilioserra/ubiksim/IBERAMIA/ 8
  9. 9. HAB II  What decisions must be made to implement a HAB?  (1) creating new transitions,  (2) getting the default state,  and (3) including an ending condition for the automaton if needed.  There are states at the bottom of the hierarchy  These are the simple behaviours (with no subordinate automata)  (1), (2), and (3), are not needed  Only an atomic action must be implemented  Before the model, CHROMUBE should have gathered information to make these decisions in a realistic manner  E.g., after studying elderly people at home, we stated that the moments to create new transitions (decision (1)) for some behaviours such as having meal fit a particular probability distribution function 9
  10. 10. HAI  Hierarchical automaton of interactions, HAI  Formalism recommended in CHROMUBE to design interacting behaviours  Interactions among agents whose behaviours are implemented using a HAB  Hierarchical automaton in three levels  InteractionsHandler, Conversations and Protocols. 10
  11. 11. HAI, PROTOCOLS  Protocols have three different levels of abstraction.  Level 1 is responsible for performing tasks that are implemented for a protocol regardless of the semantics exchanged. Its objectives are:  (1) providing the set of performatives  i.e. communicative acts, that can follow a given performative in the protocol;  (2) determining if the protocol is finished for a given message and if this end has been successful or not;  (3) verifying, given a conversation that has followed this protocol, if the protocol has been followed correctly.  Level 2 is in charge of deciding the semantics or content for the following message.  (4) the semantics of a received message must be studied in addition to its performative to select the next message to be sent.  (5) selecting a set of participants for the conversation,  and (6) reacting once the protocol has been completed  i.e. changing the behaviour of the participants based on the results of a conversation.  Level 3 allows different preferences to be fulfilled in a protocol,  so there are as many instances of this as preferences needed. 11
  12. 12. HAI, CHANNELS  Messages must not always reach their destination.  The requisites to decide whether a message is received or not are implemented in the Channel module of the HAI which is responsible for five different tasks:  (1) Initialize participants reserves the use of the channel when necessary  (e.g for a phone call)  (2) Channel free to send decides if the person modelled is available to send a message through the channel in a conversation  (e.g. having a cell phone and not being already calling)  (3) Channel free to receive is also necessary because in some channels the proper sending does not imply that the recipient receives the message  (e.g modelling a interaction by e-mail)  (4) Discard message when a message does not reach its destination at once  (e.g. voice is ruled out, but a e-mail is not)  (5) Finish participants undertakes tasks after the end of a conversation on the channel  (e.g. releasing a channel reservation if it was made in (1)). 12
  13. 13. HAI, CONVERSATIONS AND INTERACTIONS HANDLER  Conversation uses a channel, a protocol of level 1 and 2, and, if necessary, specific protocols of the participants (level 3) to generate messages.  The conversations are registered by the HAB in the InteractionsHandler which manages the different conversations.  These interpreters acts in a transparent manner without requiring additional code  Source code of interpreters available online  http://ants.dif.um.es/staff/emilioserra/ubiksim/IBERAMIA/ 13
  14. 14. CASE STUDY  It models an emergency evacuation in our department to illustrate the construction of a HAB and a HAI in a particular case.  Several cases modelled:  (1) one of the professors start fleeing to the stairs and loudly warning of an emergence on her way  (2) she is forced to pass through several corridors to warn the remaining people  (3) several organizers are assigned with the offices which must be visited to scale the escape  This is the real strategy provided by the occupational risk prevention department at our institution  Watch online:  http://www.youtube.com/watch?v=-y1F-j5i_AE 14
  15. 15. CONCLUSION, WHERE IS THE CONTRIBUTION?  Any agent platform implementing FIPA protocols can be used to replace the HAB and the HAI  But, there is the aforementioned gap between modelling general agents and modelling agents representing AmI users  Concepts such as channel or protocols of level 2 are not present in FIPA implementations  Our framework attempts to cover this gap:  Offering a methodological framework, CHROMUBE, which includes the main decisions in modelling behaviours and social interactions  And an implementation with several cases: UbikSim  HAB cases: SimpleMove, Move, DoNothing, MoveAndStay...  Protocol cases: FipaRequest, FipaContractNet, SimpleMessage...  Channel cases: channelVoice, channelPhone, channelEmail...  The case study is implemented in few minutes by extending these basic cases 15
  16. 16. FUTURE WORKS  The case study presented is based on fire safety and security policies of a department without considering sensors data  The use of sociometers will allow us to register physical movements, capture vocal inflections and face to face interactions  Therefore, modelling realistic interactions in more complex scenarios such as hospitals or geriatrics will be feasible  We are also studying the use of graphical notations to design HABs and HAIs  Ideally, these notations will allow developers to generate automatically the user simulated in UbikSim 16
  17. 17. THANK YOU VERY MUCH FOR YOUR ATTENTION {fjcampuzano,emilioserra,juanbot}@um.es 17

×