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.
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.
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.
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.
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.
CHROMUBE II
6

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
THANK YOU VERY MUCH FOR YOUR
ATTENTION
{fjcampuzano,emilioserra,juanbot}@um.es
17