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.

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