18
Generation of human computational models with knowledge engineering Francisco Campuzano a,n , Teresa Garcia-Valverde a , Emilio Serrano b , Juan A. Botía a,c a Universidad de Murcia, Facultad de Informática, Campus Universitario de Espinardo, 30100 Murcia, Spain b Universidad Politécnica de Madrid, Escuela Técnica Superior de Ingenieros de Telecomunicación, Ciudad Universitaria, 28040 Madrid, Spain c Visiting Researcher in Middlesex University, London, United Kingdom article info Article history: Received 29 November 2013 Received in revised form 28 May 2014 Accepted 27 June 2014 Keywords: Ambient intelligence systems engineering Smart environments fast prototyping and testing Computational models of humans Knowledge acquisition Agent-based social simulation abstract The Ambient Intelligence (AmI) paradigm envisions systems whose central entity is the user. AmI integrates technologies such as Articial Intelligence, implicit Human Computer Interaction, and Ubiquitous Services. Each capability of AmI systems is oriented towards assistance of humans at work, in the classroom, or even at home. In consequence, the AmI development process usually incorporates the nal user since the rst stages. However, having users available during all this long process is not always possible. Agent-based social simulations where the users' role is played by simulated entities can be used to make the AmI development process faster and more effective. In this scenario, the modelling of CMHBs (Computational Models of Human Behaviour) is a major challenge. To address this issue, this paper proposes a methodology whose main contributions are: (1) the use of domain experts' knowledge to create CMHBs; (2) a common methodological framework to develop CMHBs by combining information obtained from sensors' perceptions and experts' experiences; and, (3) open source tools to support this development paradigm. The paper also presents a full case of study in a hospital which illustrates: the number of recommendations made by the methodology; the techniques proposed (mainly the use of ontologies and temporal reasoning); and, the potential of the methodology to model the personnel in a hospital. & 2014 Elsevier Ltd. All rights reserved. 1. Introduction Ambient Intelligence (AmI) is an emerging discipline in informa- tion technology, in which people are empowered through a digital environment mainly consisting of complex software and devices (sensors and actuators) connected through a network (Cook et al., 2007). AmI is based on technologies from the following areas: Articial Intelligence, Human Computer Interaction, Sensors and Ubiquitous Computing. The main goal of AmI is to offer a digital environment which is possible to support the cooperation of the devices, services and people. By using AmI, it is possible to create sensitive, adaptive and responsive scenarios which interact with users seamlessly by providing them with implicit and unobtrusive interaction paradigms. AmI applications are endless: smart homes (Silva et al., 2012), health monitoring and assistance (Suryadevara et al., 2013), hospitals (Cheng et al., 2013), transportation (García- Nieto et al., 2012), emergency services, education (Kaklauskas et al., 2013), workplaces, and etcetera. In all these applications, the user is the central entity. And the usual tendency is the incorporation of groups of users into the development process of AmI systems. Nonetheless, this comes with an extra cost which sometimes is not affordable. There are mainly three phases of the development process in which users are a must: requirements specication, testing, and validation. In all these phases, agent- based social simulation (ABSS) is a promising technology which can support AmI development (Serrano and Botía, 2013). Regarding the requirements specication, AmI systems are a revolutionary paradigm which changes the vision of IT (Informa- tion Technology) systems. And new paradigm's particularities are hard to grasp by customers when it comes to explain what AmI systems can do for them. This makes requirements specication a hard task. The use of ABSS allows customers to approach to visualizations of different scenarios and to understand quickly and intuitively the concepts behind the system. Moreover, the customer can criticize and propose new ideas which, in turn, are again simulated and visualized. This iterative fashion of working with requirements has proven to be useful not only in AmI but also in general software engineering. Concerning testing and validation phases, the most extended approach for testing AmI systems is by using Living Labs. These laboratories allow users and researchers to work together in real Contents lists available at ScienceDirect journal homepage: www.elsevier.com/locate/engappai Engineering Applications of Articial Intelligence http://dx.doi.org/10.1016/j.engappai.2014.06.027 0952-1976/& 2014 Elsevier Ltd. All rights reserved. n Corresponding author. E-mail addresses: [email protected] (F. Campuzano), [email protected] (T. Garcia-Valverde), [email protected] (E. Serrano), [email protected], [email protected] (J.A. Botía). Engineering Applications of Articial Intelligence 35 (2014) 259276

Generation of human computational models with knowledge engineering

  • Upload
    juan-a

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

Generation of human computational models withknowledge engineering

Francisco Campuzano a,n, Teresa Garcia-Valverde a, Emilio Serrano b, Juan A. Botía a,c

a Universidad de Murcia, Facultad de Informática, Campus Universitario de Espinardo, 30100 Murcia, Spainb Universidad Politécnica de Madrid, Escuela Técnica Superior de Ingenieros de Telecomunicación, Ciudad Universitaria, 28040 Madrid, Spainc Visiting Researcher in Middlesex University, London, United Kingdom

a r t i c l e i n f o

Article history:Received 29 November 2013Received in revised form28 May 2014Accepted 27 June 2014

Keywords:Ambient intelligence systems engineeringSmart environments fast prototyping andtestingComputational models of humansKnowledge acquisitionAgent-based social simulation

a b s t r a c t

The Ambient Intelligence (AmI) paradigm envisions systems whose central entity is the user. AmIintegrates technologies such as Artificial Intelligence, implicit Human Computer Interaction, andUbiquitous Services. Each capability of AmI systems is oriented towards assistance of humans at work,in the classroom, or even at home. In consequence, the AmI development process usually incorporatesthe final user since the first stages. However, having users available during all this long process is notalways possible. Agent-based social simulations where the users' role is played by simulated entities canbe used to make the AmI development process faster and more effective. In this scenario, the modellingof CMHBs (Computational Models of Human Behaviour) is a major challenge. To address this issue, thispaper proposes a methodology whose main contributions are: (1) the use of domain experts' knowledgeto create CMHBs; (2) a common methodological framework to develop CMHBs by combininginformation obtained from sensors' perceptions and experts' experiences; and, (3) open source toolsto support this development paradigm. The paper also presents a full case of study in a hospital whichillustrates: the number of recommendations made by the methodology; the techniques proposed(mainly the use of ontologies and temporal reasoning); and, the potential of the methodology to modelthe personnel in a hospital.

& 2014 Elsevier Ltd. All rights reserved.

1. Introduction

Ambient Intelligence (AmI) is an emerging discipline in informa-tion technology, in which people are empowered through a digitalenvironment mainly consisting of complex software and devices(sensors and actuators) connected through a network (Cook et al.,2007). AmI is based on technologies from the following areas:Artificial Intelligence, Human Computer Interaction, Sensors andUbiquitous Computing. The main goal of AmI is to offer a digitalenvironment which is possible to support the cooperation of thedevices, services and people. By using AmI, it is possible to createsensitive, adaptive and responsive scenarios which interact withusers seamlessly by providing them with implicit and unobtrusiveinteraction paradigms. AmI applications are endless: smart homes(Silva et al., 2012), health monitoring and assistance (Suryadevaraet al., 2013), hospitals (Cheng et al., 2013), transportation (García-Nieto et al., 2012), emergency services, education (Kaklauskaset al., 2013), workplaces, and etcetera. In all these applications,

the user is the central entity. And the usual tendency is theincorporation of groups of users into the development process ofAmI systems. Nonetheless, this comes with an extra cost whichsometimes is not affordable. There are mainly three phases of thedevelopment process in which users are a must: requirementsspecification, testing, and validation. In all these phases, agent-based social simulation (ABSS) is a promising technology which cansupport AmI development (Serrano and Botía, 2013).

Regarding the requirements specification, AmI systems are arevolutionary paradigm which changes the vision of IT (Informa-tion Technology) systems. And new paradigm's particularities arehard to grasp by customers when it comes to explain what AmIsystems can do for them. This makes requirements specification ahard task. The use of ABSS allows customers to approach tovisualizations of different scenarios and to understand quicklyand intuitively the concepts behind the system. Moreover, thecustomer can criticize and propose new ideas which, in turn, areagain simulated and visualized. This iterative fashion of workingwith requirements has proven to be useful not only in AmI but alsoin general software engineering.

Concerning testing and validation phases, the most extendedapproach for testing AmI systems is by using Living Labs. Theselaboratories allow users and researchers to work together in real

Contents lists available at ScienceDirect

journal homepage: www.elsevier.com/locate/engappai

Engineering Applications of Artificial Intelligence

http://dx.doi.org/10.1016/j.engappai.2014.06.0270952-1976/& 2014 Elsevier Ltd. All rights reserved.

n Corresponding author.E-mail addresses: [email protected] (F. Campuzano),

[email protected] (T. Garcia-Valverde), [email protected] (E. Serrano),[email protected], [email protected] (J.A. Botía).

Engineering Applications of Artificial Intelligence 35 (2014) 259–276

life environments to evaluate the quality of the services developed.Although this testing approach is intuitive and ultimately neces-sary, it is possible to anticipate a large number of faults beforesoftware deployment using ABSS techniques (Campillo-Sanchezet al., 2013). This anticipation involves a significant cost reductionin fixing these faults because one of the bases of softwareengineering is that the earlier a fault is found, the cheaper it isto fix it (McConnell, 2004).

As explained, users are the main entity in AmI systems becausethese systems provide users with personalized facilities in a non-intrusive way. Therefore, a major issue when studying AmIsystems by simulations is the realistic modelling of users and itsvalidation (Garcia-Valverde et al., 2012a). To address this challen-ging research problem, the authors introduced a methodologycalled CHROMUBE (CHROnobiology for Modelling hUman BEha-viour) (Campuzano et al., 2012a). Unlike a great number of relatedworks which propose methodologies for the agent based model-ling, CHROMUBE allows developers to model realistic users withthe purpose of helping on various phases of AmI systems' deve-lopment: requirements specification, testing and validation. Themain principles of this methodology are the following: (1) The AmIdevelopment process can be enhanced by modelling realistichuman behaviours and simulating them. (2) Chronobiology(Halberg et al., 1977), which is an area of science which studieshow time affects living organisms, can assist in the characteriza-tion of human behaviours. (3) Knowledge extracted from sensordata allow creating realistic CMHBs (Computational Models ofHuman Behaviour).

CHROMUBE has been successfully employed to test AmI envir-onments where realistic users were simulated from extensive dataretrieved from sensors (Campuzano et al., 2012a; Muñoz et al.,2012). Nonetheless, requiring experiences registered by sensors isan important shortcoming in the methodology. There are a largenumber of cases where this assumption is simply unfeasible:sensors can be seen as an invasive technology by users; sensorsmay not be allowed because of ethical reasons; and, moreimportantly, aspects of users' behaviours may not be accessibleby the imperfect vision of the world that sensors are capable ofoffering, e.g. social interactions.

Due to the aforementioned drawbacks in the methodology, thispaper presents an extension of CHROMUBE which allows it to usean additional information source to generate human models:domain experts. This CHROMUBE extension proposal consists ofobtaining knowledge about human behaviours from these expertsand to model this knowledge with an ontology and timelines.Benjamin et al. (2006) explained that although ontological analysishas been shown to be an effective step in the construction ofrobust knowledge based systems, the modelling and simulationcommunity, in general, has not enjoyed the benefits of ontologymanagement methods and tools such as the one proposed in thisCHROMUBE extension. Due to the ontologies expressivenesslimitations related to temporal reasoning, the ontology model iscombined with timelines, which have been extensively used forrepresenting the order of the events, tasks and human behaviours.These knowledge models ease to developers the implementationof CMHBs and their subsequent validation.

Although the knowledge engineering techniques that thiscontribution relies on are not novel, to the best of the authors'knowledge, this paper is the first work where (1) the domainexperts' knowledge is aimed at reproducing the behaviour ofrunning AmI systems by simulations; (2) a common methodolo-gical framework is given for combining information obtained fromsensors and experts' expertise to create realistic agent-based socialsimulations; and (3) open and free tools are given to allow theinterested reader to follow and evaluate the approach presented.These contributions are illustrated with the modelling of users'

behaviours during a complete morning in the operating theatre ofa Spanish hospital. A number of incorrect assumptions andprogramming faults were detected thanks to the CHROMUBEextension proposed here. Besides, the resulting models (CMHBs)proved to be a powerful tool to test AmI systems in this hospitaland, more specifically, to test indoor location based services.

The paper outline is the following. After revising the relatedworks in Section 2, the CHROMUBE methodology is detailed inSection 3. Section 4 focuses on the last and more challengingphase of the methodology: the validation of the human modelsproduced. Section 5 gives a full case study to illustrate the use ofthe approach presented and, finally, Section 6 concludes.

2. Related works

CHROMUBE proposes using expert knowledge to developrealistic models of human behaviours. There are many examplesof works using the elicitation of knowledge from experts to createrealistic model of human behaviours (Bos et al., 1997; Jones et al.,1999). Moreover, some works combine expert knowledge withother information sources. For example, Hattori et al. (2011)combine log data from trials performed on a simulator with expertknowledge in order to identify and formalize driving behaviourmodels. In the same vein, Murakami et al. (1999, 2005) combinedomain knowledge obtained from interviews with data fromobservations of some simulations for the construction of realisticbehaviour models used in a virtual training system. Although mostproposals consider several sources of information, such assump-tion is not always feasible in real scenarios. In many cases, expertsare the only information source available. In that sense, Garro andRusso (2010) present the easyABMS methodology. This work isoriented to provide domain experts with a methodology for theagent-based modelling and simulation of complex systems. Thismethodology is user-friendly and does not require advancedknowledge or skills. However, the expert is in charge of the wholeprocess in this methodology. This requires the domain experts tomake a special effort and, in some cases, this causes the simula-tions to be incorrectly simplified or modelled.

In order to address these issues, this paper presents anextension of the CHROMUBE methodology, which provides fullassistance in the process of obtaining computational humanmodels from expert knowledge. This extension offers supportfrom the knowledge capture until the validation of the CMHBs.

Regarding the first step, the knowledge capture, there areseveral methods for acquiring data about people's activities intheir daily lives. These methods can be classified in at least threecategories: (1) data collection from sensors, (2) observation-baseddata collection, and (3) data collection based on survey techniques(Monitoring et al., 2009; Tapia et al., 2004).

In the first group, data collection is made by the use of sensorsattached to the body or included in the environment. This methodis a promising and relatively inexpensive technique to acquire dataabout certain human behaviours. Examples of sensors attached tothe body are the accelerometers (Amini et al., 2011; Makikawaet al., 2001), biometric wearable sensors (for measuring heart rate,blood pressure, temperature, etc.) (Pantelopoulos and Bourbakis,2010), sensors integrated into clothes (Pacelli et al., 2006) orsensors integrated into mobile phones or PDAs (Liao et al.,2007). Among the sensors embedded in the environment, typicaldevices are the following: motion sensors, pressure pads, and doorlatch sensors (Beth et al., 2003; Orr and Abowd, 2000).

The main advantage of this kind of data collection techniques isthat sensors are usually not intrusive for people and they can beeasily deployed in actual environments. However, some activitiesthat include complex physical motion and interactions among

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276260

people cannot be correctly differentiated from others (Serranoet al., 2012; Gutiérrez et al., 2013). Another important disadvan-tage is that the use of sensors could not be allowed in somescenarios, therefore data must be extracted from other sources.

The second group of methods is the observation-based datacollection. The observation of human behaviours involves follow-ing the target subjects and recording their movements, actionsand activities. This can be undertaken in a simply manner bywriting-down the activities (i.e. direct observation) or by usingsensors such as microphones and cameras (H.-S. Chen et al., 2006;Hoey et al., 2005; Kern et al., 2003). In the case of directobservation, the problem is that the presence of the observerscould annoy people. In the case of remote observation, an issue isthat sensors can be perceived as invasive and, as in the previouscase, they might be not allowed.

In such situations, the remaining alternative is data collectionbased on survey techniques, where information of behaviours isbased on users' self-assessments or on experts' knowledge. Themost common techniques in that group are interviews (Corbetta,2003) and trip diaries (Thornton et al., 1997).

Trip diaries are usually written in real-time and, therefore, theycan provide very detailed information. Since a great deal of effortis needed, this can cause the subjects to avoid participating.Besides, in some cases, these subjects are unable to participate(e.g. an Alzheimer patient).

Interview techniques involve questioning the experts. They canbe structured, where the questions are standardized, or unstruc-tured, where a freestyle chat with the expert is established.However, the most common method is the semi-structured inter-view, where pre-defined questions are planned and more addi-tional questions are asked according to the answers obtained. Themain advantages of the use of interviews in data collection are thatthey are relatively cheap, easy to develop and allow the collectionand analysis of data taken from comparatively large samples.Furthermore, this kind of technique is the only available in somescenarios where sensors cannot be installed or other sources ofinformation are not available.

When the knowledge has been extracted and analysed, creat-ing the models which represent such knowledge is needed. Thiswork proposes the use of ontologies as part of the knowledgemodelled. Ontologies aim to structure and represent domainknowledge in a generic way which may be reused and sharedacross various applications and groups of people (Razmerita,2011). The use of ontologies for user modelling is not novel andhas been proposed for several scenarios in ubiquitous computingenvironments (Heckmann et al., 2005, 2007), real-time ubiquitousapplications (Hatala et al., 2005), e-learning environments (Dologet al., 2004; Kay and Lum, 2005), and etcetera.

For a general purpose, the work presented in Napierski et al.(2004) and Young and Harper (2005) describes an ontology-basedapproach to develop human behaviour models. This ontologyemerges from the need of a common model where the knowledgeis modelled in a very understandable manner by the model analystsand the users. Authors illustrate how the ontology is used to capturehuman behaviour models and domain specific knowledge in ageneric manner. In this process, authors detect the need of present-ing the chronological order of the behaviours in a clear and intuitivemanner. This problem is solved by the use of timelines as in thepaper presented here. Timelines have been extensively used forrepresenting the order of the events, tasks and human behaviours(Addlesee et al., 2001; Corker and Smith, 1993; Flores and Sepúlveda,2011). Furthermore, they are usually complemented with othertechniques as in the approach this paper presents.

Finally, in order to validate if the CMHBs generated are realisticenough for their purpose, this work proposes the use of produc-tion rules with workflow to validate temporal restrictions.

The validation of computational models is usually conducted bycomparing the model output to real or synthetic data generated bysimulations or statistical methods (Campuzano et al., 2012a; Garcia-Valverde et al., 2012a; Muñoz et al., 2012; Pentland and Liu, 1999;Salvucci et al., 2001). In other works, this kind of validation isimproved using assessments by domain experts or rules thatincorporate the experts' judgements (Collopy and Armstrong, 1992;Moss et al., 1994, 1997). A number of works only use experts'knowledge for the validation, i.e. experts employ their expertiseand intuition to validate the models (Eddy and Schlessinger, 2003).

Other methods of validation are “Evolutionary verification andvalidation” (EVV) (Shervais and Wakeland), which are based onevolutionary techniques to test and exploit unusual combinationsof parameters and models in order to compare their results (Axtellet al., 1996; L.-C. Chen et al., 2006).

When no previous data or models are available, verification andvalidation can be undertaken theoretically by utilizing formalmethods based on defining a previous formal specification(Fitzgerald, 2005; Hinchey, 2003; Weiss, 1999). Formal methodsuse a precise specification which could reveal ambiguities andomissions. Furthermore, these methods can enhance the commu-nication among developers and experts (Yahja, 2006).

Production rules are very adequate to represent formal knowl-edge. In fact, rule-based systems are considered to be the mostappropriate paradigm to capture and refine human expertise, andto automate reasoning for problem solving (Hayes-Roth, 1985; Luand Sadiq, 2007). However, systems with large and complex rulesets are incomprehensible and can lead users to mistrust, misuseor abandon this system (Bellotti et al., 2002; Bellotti and Edwards,2001; Muir, 1994). This case is usual in context-aware systemswhere complex rules and machine learning models (Lim et al.,2009; Serrano et al., 2013) are employed.

Furthermore, rules could be defined to manage the temporalconstraints and relationships among the behaviours. Nonetheless,this could result in a larger and more complex rule set. A usualsolution to this problem is the use of workflows. Even so, usingworkflows to specify complex temporal constraints and relation-ships is not trivial for people with little modelling experience,typically the domain experts (Flores and Sepúlveda, 2011).

To solve the exposed difficulties, this work proposes the use ofontologies with timelines to achieve a more understandableknowledge representation. Nevertheless, the use of productionrules and workflows is also recommended for validation purposes.Therefore, this work employs production rules to validate thatbehaviours are as expected and workflows to validate the timingof these behaviours.

3. Methodology

CHROMUBE addresses the problem of obtaining computationalmodels of human behaviour (CMHBs) which are useful for realisticsimulations. This process starts with information about how thetarget subject (TS) behaves. Up to now, the only informationsource considered in CHROMUBE was sensor data. However, thisinformation source may not be available. In this case, other sourcesmust be considered, e.g. documents, databases, websites, or ITsystems. The main difference between these information sourcesand sensors is that sensors supply raw behaviour data which mustbe interpreted in order to obtain more structured informationabout behaviours. On the other hand, documents, databases orwebsites could contain structured information that can be used forCMHBs. Still, finding human behaviour information encoded intodocuments is not very frequent. According to our experience,the companies interested in the CMHBs creation do not dissemi-nate encoded information about their TSs' behaviour. They often

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 261

have related documentation but which is incomplete to achieverealistic CMHBs.

For that reason, this paper is concerned with considering analternative information source, domain experts. An expert is aperson who has expertised in a certain field or domain. Expertiseis the ability of people to do effective and efficient work and todeal with complex situations. In this case, an expert must knowhow the TSs behave on a daily basis (e.g. the manager of a hospitalmust know their hospital employees). Experts can provide all theirknowledge about the TSs routines, timetables, their interactionswith other people, or their abnormal behaviours. This paperpresents an extension of CHROMUBE that allows developers togenerate CMHBs using expert knowledge.

Knowledge acquisition techniques allow us to obtain knowl-edge from experts and to create a knowledge base. A knowledgebase (Russell et al., 1995) is a special kind of database that storesgeneral knowledge about a particular domain. This knowledgebase can be used to build knowledge models (i.e. formal repre-sentation of knowledge) integrated into the CMHBs. Once theCMHBs are created, and following the usual steps in CHROMUBE,they must be simulated and validated in order to check if theirsynthetic behaviours correspond to the real ones.

Fig. 1 shows how to apply CHROMUBE for both sensor data andexpert knowledge. Step 1 is in charge of selecting the targetsubjects to model. Social simulation research always starts study-ing the “real world” phenomenon that researchers are interested

Target subject

Behaviour data

Basic design information

Behaviour model

Behaviour data

Step 1

Step 2a

Step 4a

Step 5

Step 6

Step 7

Step 3a

Step 3b

Step 4bVisual representations

Basic knowledge elements

Source

Sensors

Experts

of observation

Validate behaviours

Datagathering

Perform datarepresentation

Knowledge capture

Analyse data &representations

Design

behaviours

Knowledge modelling

Knowledge analysis

behaviours

Unstructured knowledge

Sensors

Knowledge base

Step 2b

Is the KB validated by an

expert?

NO

YES

Sensors approach

Experts approach

Common steps

Fig. 1. Outline of the CHROMUBE methodology.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276262

in. This is called the target system or target subject (TS) in ABSSterminology (Gilbert and Troitzsch, 2005). The basic researchguidelines include the following: modelling this target; imple-menting the model in a simulation; and, after verifying andvalidating the implemented model, studying the output of simula-tion executions to gain insights into the TS. As stated in theintroduction, a major issue when studying AmI systems bysimulations is the realistic modelling of users and its validation(Garcia-Valverde et al., 2012a). In CHROMUBE, the TSs are theseusers and the results of a research conducted by the presentedmethodology are computational models of human behaviour(CMHBs). Therefore, the whole process starts with informationabout how the TSs behave.

In the CHROMUBE extension presented in this paper, expertknowledge is captured, analysed and modelled to create andvalidate a CMHB. Therefore, while steps 2–4a of the methodologyare previous contributions (Campuzano et al., 2012a), steps 2–4bhave been added to consider this new kind of information. Theworkflow path to follow is chosen depending on the available datasource. Steps 2–4a, not detailed in this paper, receive sensor datarepresenting facts or events as input. On the other hand, steps2–4b deal with expert knowledge which is a highly structuredform of information. One of the challenges this contributionaddresses is that the knowledge that an expert can give in step2b will be unstructured. Therefore, it needs to be analysed toextract its basic concepts and relations (step 3b) before theknowledge modelling (step 4b). The result is a well highlystructured knowledge model of the TSs' behaviour which is theinput of step 5. Therefore, steps 5–7, which were already includedin previous works (Campuzano et al., 2012a) when sensors datawere employed, have to be reconsidered and extended to dealwith this new possible input. In this context, the validation step(explained in Section 4) is specially challenging since it funda-mentally defines the rigour of an agent-based model (North andMacal, 2007).

As explained above, steps 2–4b represent the application of theexperts' variant of CHROMUBE this paper focuses on. These stepsare inspired by the Knowledge Acquisition methodology by Milton(2007). Milton's work is an excellent survey which offers a widerange of information about processing techniques and methods inthe fields of knowledge acquisition, analysis, and modelling. Thisproposal addresses these three key areas. In the field of KnowledgeAcquisition, it is similar to a number of other methodologies,notably CommonKADS (Schreiber, 2000) and MOKA (Stokes,2001). The main difference between these approaches lies in thetype of knowledge modelling projects they support. Common-KADS is oriented to very specialized knowledge engineers thatneed to create expert systems using specific templates. MOKA ismore focused on the development of computer aided design (CAD)software. The main advantage of Milton's methodology over theothers is its generality. Its knowledge acquisition procedures canbe used virtually on any development project. It is composed of aset of simple techniques whose main goal is capturing knowledgefrom experts and creating computer based models of thisknowledge.

3.1. Step 2b: knowledge capture

A key part of a knowledge acquisition project is concerned withknowledge elicitation. This step is not as easy as asking an expert arather obvious set of questions and obtaining knowledge. Dealingwith different psychological phenomena is also required (such asmemory effects, communication difficulties, lack of understanding,and experts having different opinions). A number of circumstancesmake the problem even harder. Shadbolt (2005) presents a wideset of techniques developed by knowledge engineers to cope with

these issues. Methods based on interviews are the techniquesmost commonly used for knowledge capture. The interviewprocess is an art (Weiss, 2008), not a quantitative methodology.This section offers some guidelines illustrated with an example ofhow to capture knowledge related to the human behaviours topicin the context of the CHROMUBE step 2b.

Let us suppose an example in which an office building managerwants to simulate the behaviour of the office workers during anemergency in order to validate an emergency management appli-cation. There is not any sensor deployed inside the building andthe only information source about the protocols to follow in caseof emergency is the person in charge of the building security. Thisperson, due to his/her experience, knows everything about how toperform the protocols during an emergency, the building struc-ture, the workers' timetables, and typical behaviour patterns theseworkers present. This person can be considered as an expert dueto the great amount of knowledge he/she has about the targetsubjects and the problem itself.

CHROMUBE proposes a semi-structured interview with theexpert as the main technique for obtaining knowledge about humanbehaviour in these cases. In addition to a set of pre-definedquestions, additional questions may arise during the semi-structured interview, making the interview experience richer andallowing it to obtain a higher amount of knowledge. The elaborationof the question set is directly related to the abstraction level thedeveloper needs. The most important topics to focus on are thefollowing: (1) what target subjects need to be modelled?; (2) whatbehaviours do they usually manifest and when?; (3) how do theyinteract with their environment and other subjects? It is advisable todefine a set of questions about these topics and to send it to theexpert at least one day before the interview. Thereby, the expert willhave time to think about them in a deliberate and conscious manner.The question set must help the expert to focus on the requiredknowledge. In the case of our example, the simulation of the officebuilding involves a high number of users. It is important to identifyall the target subjects (i.e. workers and visitors), their timetables, thetasks that all of them should perform during an emergency (i.e.emergency protocols), the interactions and coordination amongpeople, even possible sensory and physical disabilities of some ofthem. The service or application, which is going to be validated withsimulations (i.e. the model specific purpose), guides the developer toconfigure the abstraction level of the knowledge needed.

Some illustrative questions in this case could be the following:

� How many work shifts are there during the day? Please, specifytheir timetables and number of people involved at every one.

� Please, specify the offices or places where the target subjectsusually spend their time during the day.

� According to the protocol, are there different emergencyteams? (e.g. evacuation team and first intervention team)Who are the employees composing each team?

� According to the protocol, what tasks does every personinvolved have to perform during an emergency?

During the interview and depending on the answers given bythe expert, some specific situations will usually arise, e.g. supposethat the expert says that Bob is the employee responsible forevacuating a determined sector of the building. The developercould be interested in obtaining more information about thisperson, such as office, roommates, and timetable.

The interview outcome should be an unstructured knowledgeset consisting of transcriptions or/and audio recordings. The nextstep of the methodology uses this material as input and analyses itto extract the most relevant knowledge concepts.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 263

3.2. Step 3b: knowledge analysis

Step 3b is in charge of the analysis of knowledge extracted by step2b. Knowledge analysis is an activity performed by the knowledgeengineer after the knowledge capture. It is concerned with identify-ing elements of knowledge that will be entered into the knowledgebase to form its structure and basic components. There are four mainelements to consider regarding knowledge structure:

� Concepts: This set will include the following: the differenttarget subjects; the behaviours to simulate; the physical envir-onment, i.e. rooms or zones where the TSs behave; and theobjects they could interact with.

� Attributes: They are crucial to obtain more realistic models, bydescribing the interval when the TS manifests a behaviour, therole and name of the target subject, physical attributes like theweight or height, etc.

� Values: For the attributes, they can be precise or approximate,e.g. the approximate time when the TS is used to go to sleep is9 p.m. or the weight of the TS is 200 lbs.

� Relations: How the concepts are related between them. Thisincludes a behaviour of a TS that produces other behaviour inanother TS, e.g. a TS sends a task to another TS, the behaviourSending a task produces a new behaviour on the latter TS(Accomplishing the task).

Let us illustrate this step following a subcase of the example ofSection 3.1, referring to a concrete worker called Bob. Note that thefull problem complexity is considerably higher but we are focusingon a subcase for illustrative purposes only. Then, suppose that wehave previously obtained the following annotations (i.e. unstruc-tured knowledge) about the worker Bob from the expert:

Bob is a worker responsible of evacuating the people workingat room 23. Every day he enters the room number 23 at 9:00.According to the emergency protocol, what must he do whendetecting a fire at this room? (1) warning to any person who ispresent at the room, (2) making use of the fire alarm located atthe room, (3) fleeing. The rest of workers must start fleeingtowards the main stairs of the building once they have beenadvertised of the emergency.

The first step after capturing this unstructured knowledge isanalysing and decomposing it into concepts, attributes, values andrelations. The most important concept to extract is which TS willbe simulated. In this case explained above, there are two targetsubjects, TS 1 and TS 2. Note that it is possible to use the sameCMHB for different persons if all of them behave similarly. In thiscase, TS 1 represents the worker in charge of evacuation andTS 2 represents the rest of the workers in the building. Then someattributes of these two subjects can be defined: (1) Name and(2) Role during an emergency. The values of the Name attribute forTS 1 is Bob and, with respect to the attribute Role, TS 1 is a Memberof evacuation team while TS 2 is a Common worker.

Once the knowledge about the subjects is extracted, let usanalyse the concepts related to the behaviours. The followingconcepts can be obtained from the text above: Entering a room,Detecting a fire, Warning colleagues, Activating alarm and Fleeing.Some of these behaviours have attributes associated, e.g. the timethey are accomplished. For example, the text says that one possiblevalue of this attribute for Bob and the behaviour Entering the roomis 9:00, i.e. when he enters the room at the beginning of themorning. Other concepts that must be considered, as they have animportant role as part of the physical environment where thebehaviours occur, are the following: Room number 23, Fire alarmand Stairs. Finally, relations among concepts are defined. Detecting

a fire is causally related to Warning and Activating alarm followingthe emergency protocol. Warning is causally related to Fleeing, asevery subject who receives a warning starts fleeing immediately.

The next step deals with creating a knowledge base composedof knowledge models. These models represent the concepts,attributes, values and relations obtained in this step 3b. This isachieved in step 4b of the CHROMUBE methodology.

3.3. Step 4b: how to model knowledge

Knowledge models are useful because, on the one hand, theyallow experts to easily validate them and, on the other hand, theycan be used to create CMHBs either manually or automatically.Thus, step 4b deals with creating simple visual models under-standable by humans and machines.

An ontology (McGuinness et al., 2004) is a (meta) data schemathat gives structure to informal sources of data and information.Ontologies are regularly used to represent knowledge models.Information about the target subjects and their environment canbe stored in an ontology by using the knowledge extracted fromthe previous analysis (step 3b). In CHROMUBE, ontologies are usedfor the specification of both the users and the environment.

It is important to note that although there exists a clearmapping from ontologies to human models, ontologies haveexpressive limitations that make more information necessary. Inthe semantic web literature, these limitations are usually over-come by rule-based knowledge. One of our main research linesattempts to simplify the presented proposal by replacing most ofits modelling techniques and tools (see Fig. 5) with semantic webtechnologies such as SPARQL (Garlik et al., 2011) for queries andSWRL (Horrocks et al., 2004) for rules. Nonetheless, as explainedin Section 2, the rule-based knowledge and semantic reasonersalso have limitations that motivate the inclusion of other model-ling techniques in our approach. For example, because of the open-world assumption, SWRL rules that attempt to enumerate indivi-duals or properties in an ontology are not always possible (http://www.protege.cim3.net/cgi-bin/wiki.pl?SWRLLanguageFAQ).

Despite these limitations, ontologies are still necessary anduseful in the approach presented. The ontology definition allowsobtaining a controlled vocabulary of concepts with explicitly andformally defined semantics to be shared and understood bymachines and humans. Therefore, after the knowledge extractionprocess in the step 3b of the methodology, an ontology buildingprocess is needed in the step 4b to translate experts' requirementsfrom natural language into an ontology language such as OWL(McGuinness et al., 2004). Although, for the sake of brevity, thispaper does not detail the process of creating an ontology, it can bea challenging and time-consuming process which has motivated anumber of methodologies devoted just to this task (Fernández-López and Gómez-Pérez, 2002). This process was undertakenusing the open-source ontology editor Protege (http://www.protege.stanford.edu) although there are plenty of alternatives.As explained, an ontology is not only readable by machines butalso a very intuitive knowledge representation for humans. Thisallows the human-domain experts to validate that the ontologiescover correctly the requirements formerly expressed in naturallanguage. Additionally, as Section 5.5 describes, an ontology readerplug-in for the UbikSim simulator (https://github.com/emilioserra/UbikSim/wiki) has been developed to partially automate theimplementation of CMHBs from ontologies.

In CHROMUBE, the use of ontologies is combined with time-lines for temporal specification of users behaviours and theirinteractions with the environment. Timelines (Harrison et al.,1994) are one of the most recommended kinds of knowledgemodels to represent human behaviour at work. A timeline is agraphical representation of when tasks are executed. Tasks are

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276264

represented as nodes, disposed along an horizontal axis represent-ing time. The width of each node shows when the task starts andfinishes. It is useful to represent the different tasks of a workroutine. Every node of the timeline represents, in this case, abehaviour. The timeline allows declaring behaviours that precedeother behaviours (i.e. a causal relation) and behaviours that occursimultaneously to other behaviours.

Timelines (Smith et al., 2001) can be automatically translated tocomputational models of temporal processes (i.e. those whoserelevant information is when they start and their duration). Thus,they are suitable to represent when behaviours start and end.However, they have not enough expressiveness to represent thewhole picture of behaviours in a simulation. Neither TS roles norenvironment details can be represented by this method. Asexplained above, ontologies are employed to represent this kindof knowledge. Thus, the knowledge base of a CHROMUBE simula-tion specification is composed of two kinds of knowledge models:a timeline for temporal aspects of behaviours and an ontology forthe rest of information related to the TSs (e.g. physical environ-ment, objects, human actors, etcetera).

Fig. 2 presents the timeline and the ontology for the knowledgeanalysed in Section 3.2. How to create these models from theconcepts obtained in step 3b follows:

Firstly, we model the concepts related to users and environ-ment (i.e. objects and physical spaces) by considering the ontologyclasses. Three main entities were created to represent theseconcepts: Person, Object and Space. Two subclasses of Person wereneeded to represent the two target subjects defined in step 3b: TS1 and TS 2. These subclasses have a pair of attributes: Name andRole. These attributes are added to the ontology as string proper-ties. At this modelling stage, the ontology is not instantiated yet.Therefore, the values of these properties are not assigned. Forexample, the CMHB representing Bob will be an instance of TS 1 innext steps.

The rest of the concepts related to Object and Space werecreated in the same way. Note that the property location of theentity Fire Alarm is a reference to an entity Space. This referencemodels the relation existing between the object fire alarm and thelocation where it is allocated, that could be in a room or on thestairs.

Secondly, using the timeline we model the human behavioursand the temporal relations between them. The timeline of Fig. 2models the behaviours of both target subjects: TS 1 and TS 2.Following the knowledge analysis of step 3b, we know that theworking day begins at 9:00, when TS 1 enters the room. At thispoint, we suppose that his/her roommates are working since thishour. At some point of the morning, TS 1 detects a fire and warnsthe rest of the people in the room. Note that there is an arrow from

the behaviour Warning colleagues that provokes a change ofbehaviour in TS 2. This dependence models an interaction betweenTS 1 and TS 2 as the warning that TS 1 makes to TS 2 for startingfleeing. Finally, while the rest of the workers are fleeing, TSactivates the alarm and starts fleeing too.

Both knowledge models combined, ontology and timeline,compose our knowledge base in the approach presented. Thisknowledge base will be needed in the next steps in order to createthe CMHBS and to simulate them.

However, before using the knowledge base as a reference tocreate CMHBs, it is important to ensure that such knowledge isaccurate. Thus, it must be checked by at least the expert whoprovided the knowledge. Unless only one expert is available, cross-validation with alternative experts can help to assure that themodels developed with the primary expert are as correct andcomplete as possible. Cross-validation consists of showing theknowledge models to an alternative expert for review. When somediscrepancy arises, a consensus session can be programmed tosolve it. As Fig. 1 shows, if no consensus can be reached, theknowledge models cannot be validated. Then it is recommendedto return to step 2b and refocus the interviews. Once the knowl-edge models are validated, they can be used to create CMHBs(step 5).

3.4. Step 5: how to generate CMHBs

To achieve the development of CMHBs, it is necessary toidentify four elements in the knowledge base: (1) the targetsubjects to simulate; (2) the behaviours they can manifest;(3) the physical places where they are going to manifest thebehaviours; and (4) the parts of the physical environment thesubjects can affect and/or use (e.g. tools, furniture, mobile devices,etcetera). CHROMUBE includes the following steps to generate theCMHBs starting from the knowledge base constructed in step 4b:

1. Identify all the TSs in the knowledge base and create one CMHBper TS.

2. For all TS in the knowledge base,(a) Identify all the behaviours the TS can manifest.(b) For all these behaviours,

i. Implement the behaviour code considering (1) the phy-sical place, and (2) the elements of the environmentwhich could affect the behaviour.

CHROMUBE already includes from its previous version a rathergeneric abstract machine that can be used to develop CMHBs calledthe hierarchical automaton of behaviours (HAB). The HAB is ahierarchical automaton whose states can be themselves other

9:00

Entering room

Detecting a fire

Warning colleagues

Working

FleeingActivating alarm

Fleeing

TS1

TS2

Simulation end

Fig. 2. Representation of the TSs context and temporal specifications using ontologies and timelines.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 265

automata. States represent behaviours and the current state of theautomaton represents the behaviour the CMHB is having at thetime. It is possible to simulate the transitions between behavioursusing probability distribution functions (pdfs). One of the mainreasons of recommending HABs is that there is an open and freeimplementation as the next step of the methodology covers. How-ever, other alternatives are perfectly feasible. For example, Lacroixet al. (2013) have formalized the construction of populations inmulti-agent simulations and implemented various driving styles inthe traffic (e.g. aggressive, cautious drivers) in a commercialsimulator.

The following subsection is devoted to introduce how to workwith HABs in CHROMUBE.

3.4.1. How to model behaviours with a HABA HAB is a hierarchical automaton of behaviours, whose

transitions between states are generated by a set of randomvariables fXigni ¼ 1. Each Xi follows a probability distribution. Thisabstract machine is very convenient in this context because itallows mapping every behaviour concept from the knowledgebase to a state of the HAB. Thus, given a concrete CMHB to create,let its HAB be denoted as ξ. The HAB is formally defined as a tripleξ¼ fq0;Q ; Tg, where Q is the set of states. State q0 from the triple ξrefers to the single default behaviour that any ξ must have. Thus,the automaton switches to this state when no other transitionremains so far.

Every behaviour qi of the HAB is defined as

qi ¼ ðlabel; tleft ; p; IÞ

where label is the label of the state, the element tleft denotes theaverage time for the subject to stay in this state, and p is a priorityfor this state. Priorities are useful in cases where a number oftransitions must be done at the same time. Ii ¼ fIi;jgmj ¼ 1 is the set ofintervals during the day which modulate how the subject behavesin the state depending on the active interval. In each

Iij ¼ ðtsi;j; tei;j; pdf i;jðθÞÞ;

the tsij is the time of the day in which the j-th interval of the qistate starts, and teij is the time of de day in which the same intervalfor the same state ends. Finally, pdf i;jðθÞ refers to a parametricprobability distribution (pdf) function (e.g. an exponential func-tion) whose parameters are defined by the θ vector of values (e.g. λparameter of the exponential pdf). The last element of the ξ tripleis T. It refers to an interpreter algebraically defined as

T : Q � t24 � t24-fðq; tÞ; ðq0; t0Þ; ðq″; t″Þ;…g:T takes an argument in the set of the automaton states, and twoother parameters in the time domain bounded on the interval½00 : 00;23 : 59�. The q, q0;…AQ and t, t0;… are instants of time inwhich there is a behaviour change. For example, the pair ofconsecutive states ðq; tÞ; ðq0; t0Þ indicates a change from stateq(label) to state q0ðlabelÞ at time t. For a full description of theinterpreter, see Campuzano et al. (2012a).

Once the states qi are defined, the process for creating CMHBswith the HAB component follows:

1. Identify all the TSs in the knowledge base and create one CMHBper TS.

2. For all TS in the knowledge base,(a) Identify all the behaviours the TS can manifest.(b) For all of these behaviours,

i. Associate a descriptive label with the behaviour.ii. Identify the behaviour duration (parameter tleft).iii. Identify the time intervals of the day when the beha-

viour can manifest and assign the values to the

parameter I. Note that for every interval, a start timeand an end time must be defined.

iv. Choose an appropriate probability distribution function(pdf). In the earlier version of CHROMUBE, pdf i;jðθÞ ischosen after a Chronobiology based analysis of thebehaviour data extracted from sensors. In this case,taking into account the absence of sensors, this para-meter must be adjusted in function of the necessitiesexpressed by the expert.

v. Implement the behaviour code considering attributes,values and relations of the knowledge base which canaffect the behaviour, e.g. Does the behaviour modify anyobject of the environment?

(c) Assign priorities to the behaviours taking into account thetime relations between them and their relevance (para-meter p).

(d) Create an automaton structure (i.e. defining its nodes andtransitions) for every TS by parsing the timeline defined instep 4b.

Creating a CMHB is a simple process once the necessary knowl-edge about behaviours is codified in a knowledge model (i.e. atimeline). The pseudocode of Fig. 3 provides the reader with adescription of the automatic translation process of a timeline intoa HAB model. The algorithm keeps track of a set of nodes, a set ofinternal transitions (i.e. those that join two behaviour nodes of thesame target subject) and a set of external transitions (i.e. thosethat join two behaviour nodes of different target subjects). Eachnode of the timeline has an associated state in the resultingautomaton. Fig. 4 shows the automaton which corresponds tothe timeline of Fig. 2. Only one level of hierarchy is required inthis case.

3.5. Step 6: simulation of CMHBs

Step 6 of CHROMUBE is concerned with how to simulate theCMHBs once they are created. CHROMUBE relies on the use ofUbikSim (https://github.com/emilioserra/UbikSim/wiki) for this pur-pose. UbikSim is a social simulator (i.e. it is based on the MASONsocial simulation software) which addresses the simulation of usersrealistically and offers the required software classes to use HABs withlittle effort (Campuzano et al., 2012b). It also eases creating thevirtual world and people with an editor based on Java3D(Campuzano et al., 2011). This editor allows creating virtual worldsby simply dragging and dropping objects from a palette. Moreover,this editor reads the ontology model within the knowledge base andincludes all the relevant concepts in the editor palette. Within thesame editor, the developer can assign a 3D model to each one ofthese objects and introduce them in the simulation scenario. In otherwords, the ontology created in step 4b can be instantiated in this stepusing an ontology reader plugin and the UbikSim editor. Theontology reader parses the OWL file which describes the ontologyand loads all the entities of the ontology on the editor palette (i.e.target subjects, objects and spaces).

The instantiation of these entities is performed by the developer,who is in charge of creating the instances needed for the simulationby adding the entities of the palette to the simulation scenario andgiving them appropriated values. For example, following the exampleof previous sections about the worker Bob, the developer mayinstantiate and add to the 3D environment an instance of the entityTS 1 whose name value is Bob and its role value is evacuation teammember. Moreover, a set of instances of TS 2 must be created torepresent the rest of the workers. The rest of the entities of theontology (i.e. fire alarm, room and stairs) must be instantiated too,paying special attention to attributes and relations, e.g. the propertylocation of the fire alarm must be a reference to the room number 23

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276266

where Bob works. Taking into account that the timeline was used instep 5b to implement the automaton that manages the behaviour ofthe instances of TS1 and TS2, now all the knowledge previouslyacquired and modelled has been successfully employed for creatingthe simulated environment. This approach provides the cooperationbetween simulated persons and their simulated environment (e.g.objects or devices) using the knowledge models of CHROMUBE step4b, the ontology and the timeline.

Then, once the simulation scenario and the artificial behavioursare completely created, the simulation in UbikSim is immediate(Serrano and Botía, 2013). The results of these simulations can beused to validate the CMHBs in step 7 of CHROMUBE.

4. Step 7: Validation

Step 7 of the methodology deserves its own section. Probably itis the most challenging phase of the methodology as it is not easyto validate simulation models of human behaviour. Validation isthe process of evaluating software during or at the end of thedevelopment process to determine whether it satisfies specifiedrequirements (IEEE, 1990). Within the modelling and simulationcommunity, the definition of validation is the process of determin-ing to what extent a computerized model or simulation and theirassociated data are accurate representations of the real world fromthe perspective of the intended use (Schlesinger et al., 1979).

4.1. Validating CMHBs

CMHBs are used for testing AmI services and applications (e.g.an indoor location service, an in-home monitoring service forelders, motion detection services, Huang and Cheng, 2012, energyefficiency measures, Silva et al., 2012, and etcetera) before theirreal deployment. CMHBs represent users of the service or applica-tion. Each simulation run represents a software test. Thus, the keyis to define good software tests (i.e. good simulations in this case).It is important to know, at this point, the service's expectedfunctionality. This functionality is required to test the service bysimulations because it allows us to check if the CMHB behaves asexpected. For further detail of the process proposed by CHRO-MUBE for validating CMHBs created from sensor data, see theprevious work (Campuzano et al., 2012a).

Since no previous sensor data is available in this work,CHROMUBE relies on the knowledge base for comparing it withthe behaviour generated by the CMHBs. Note that, at this point ofthe CHROMUBE application, this knowledge base is already vali-dated by experts. Thus, the only source of errors to be consideredis the CMHB created from the knowledge base. Anomalies ormisunderstandings of the knowledge interpretation during theCMHB creation process can lead to faulty behaviour at run-time(i.e. the CMHB does not behave as the expert said).

At a first stage of the simulation, a visual inspection as validationis advisable. Ideally, the same expert used in the generation of the

Default state

Entering room

Warning colleagues

Activating alarm Fleeing

Default state Working Fleeing

TS2

TS1

Fig. 4. Automata corresponding to the previous timeline.

Fig. 3. Pseudocode for the automatic creation of a behaviour automaton from a timeline.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 267

knowledge base is provided with an animated simulation by usingthe 3D viewer of UbikSim (Garcia-Valverde et al., 2012b). The expertreviews the simulation looking for inexact physical elements, objectsor behaviours. However, visual inspections are usually not enough tovalidate the model when either the virtual world is large or thesimulation takes too much time. An automated validation process isnecessary at a second stage.

4.2. Towards an automatic validation

CHROMUBE focuses on how to create CMHBs whose routinesare performed, during work or leisure time for example, in atimely and realistic manner. Thus, the methodology includesmeans to validate the following issues with respect to CMHBsfor each behaviour: (1) where the CMHB is when manifesting agiven behaviour?; (2) what changes are produced in the environ-ment by the behaviour?; (3) who is manifesting a given beha-viour?; and (4) is it valid the order in which the behaviours fromall the CMHBs were executed?

Note that all these questions may be answered by using theknowledge base (at least to some extent). CMHB uses all thepossible answers as the source information for validation. CHRO-MUBE proposes validating answers for questions (1)–(3) withproduction rules and answers for question (4) by defining abehaviour workflow.

Production rules consist of conditional statement and expressrelationships between parameters and variables. The rule premiseand consequent are series of clauses that can be used to describethe state of characters in the simulation, objects, time, location,etc. Production rules are a very comprehensible form of knowl-edge representation. Defining the answer to questions (1)–(3) inthe form of production rules delivers a natural way of checking ifthe simulation was incorrect: if a rule did not fire during the wholesimulation, a fault is detected.

To automate the creation process of production rules, CHRO-MUBE delivers generic templates for the behaviours involved inthe simulation. These templates are composed of a set of blanksections concerning about the situation before and after theexecution of a concrete behaviour. Thanks to these templates,the production rules can be generated automatically.

A generic behaviour template is given below containing themost important attributes a CMHB usually includes. Developersare free to add any attribute of their interest:

� Behaviour name.� CMHB who manifests the behaviour.� Antecedents:

○ Interval time or concrete time of beginning.○ Physical zone/s where the behaviour begins.○ Previous status of all the resources which the behaviour is

going to alter, including other CMHBs if the behaviour is aninteraction.

� Consequent:○ Interval time or concrete time of ending.○ Physical zone/s where the behaviour ends.○ Status of all the resources which the behaviour alters,

including other CMHBs if the behaviour is an interaction.

After fulfilling the general template with antecedents andconsequents, its implementation in an inference-based rulesengine, such as http://www.jboss.org/drools which is employedin the case study of Section 5, is straightforward. Following theexample introduced in previous sections and whose knowledgebase is shown in Fig. 2, the fulfilled template associated with thebehaviour Activating alarm could be defined as follows:

� Behaviour name: Activating alarm.� CMHB who manifests the behaviour: TS 1.� Antecedents:

○ Interval time or concrete time of beginning: Indifferent (it isnot specified in the experts description).

○ Physical zone/s where the behaviour begins: Roomnumber 23.

○ Previous status of all the resources which the behaviour isgoing to alter, including other CMHBs if the behaviour is aninteraction: Alarm: {Inactive}.

� Consequent:○ Interval time or concrete time of ending: Indifferent

(unspecified).○ Physical zone/s where the behaviour ends: Room 23.○ Status of all the resources which the behaviour alters,

including other CMHBs if the behaviour is an interaction:alarm: {Active}.

The production rule associated with this example is thefollowing: behaviourðTS1; InitActivatingAlarmÞ4 location ðTS1;23Þ4stateðalarm; inactiveÞ-behaviourðTS1; EndActivatingAlarmÞ4locationðTS1;23Þ4stateðalarm; activeÞ.

This rule can detect automatically possible flaws in the simu-lated model such as an alarm which remains inactive after theexecution of the behaviour Activating alarm or the execution ofthis behaviour when the TS is not located at the appropriate room.Moreover, if one or several of the antecedents are not satisfiedwhen the behaviour begins, it could be an indicator of an incorrectimplementation of the previous behaviour as discussed below.

In order to check type of question (4), it could be possible to usetemporal reasoning (Allen, 1983) so as to keep using the productionrules formalism. Nevertheless, this approach makes hard to manage ahigh number of rules. The alternative proposal of CHROMUBE isusing a workflow structure oriented to validate temporal restrictionsbetween behaviours. Defining a workflow allows the developer todescribe the order in which a series of steps must occur. This easesthe description of complex compositions of behaviours.

BPMN 2.0 (Business Process Modelling Notation) is a popularworkflow notation language used for modelling business pro-cesses, and it provides the necessary node types for representinga behaviour workflow such as start/end nodes, split/join nodes,wait states, timers, events, and composite nodes. Coupling theworkflow with the production rules engine improves the valida-tion process making easy to detect behaviours executed in analtered order. Note that behaviours are represented in the knowl-edge base with a timeline. To encode the timeline as a BPMNworkflow we rely on the proposal of Flores and Sepúlveda (2011).This proposal describes the equivalence between a BPMN diagramand timelines, allowing the automation of the conversion process.

Fig. 5 shows a diagram depicting the validation process ofCMHB simulations using a production rule base and a BPMNworkflow. One rule must be created for every behaviour conceptcontained in the knowledge base. The BPMN workflow is createdby mapping the behaviour concepts and their relations from thetimeline. Every node of the workflow represents either a singlebehaviour or a group of behaviours. While the simulation isrunning, the CMHBs produce events that represent the behaviourthey manifest. The rule engine and the workflow check that allconditions of the behaviours are being satisfied on real time.

Two kinds of events can be received from the simulation asseen in Fig. 5: behaviour initiation and behaviour end. When abeginning event arrives, the workflow must be checked in order toassure that the flow is not altered. Then, the next step is to checkthe antecedents of the production rule associated with thebehaviour. If the antecedents are not satisfied, the rule will notbe launched. This could be an indicator of an incorrect

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276268

implementation of the previous behaviour. Note that thesequence, order and inference of the production rules for thespecific behaviour are internally managed by the inference-basedrules engine. This is one of the cornerstones of the declarativeprogramming: the developer specifies “what to do” but not “howto do it”. However, in the approach presented there is just one rulefor each behaviour. The second kind of event indicates that abehaviour ends. In this case, the workflow is updated advancingone node in the flow. Then the consequent of the production ruleassociated with the behaviour has to be checked to ensure that thebehaviour is correctly implemented.

Therefore, as explained at the beginning of this section, boththe production rules and the workflows automatically validate ifthere are requirement violations in the CMHBs simulated. Thedifference is that production rules address aspects of individualbehaviours which can be extracted from the ontologies built basedon experts knowledge, while workflows ensure that the sequenceof behaviours is correct according to the experts specificationsgathered in timelines.

An illustrative example of the process followed to validatebehaviours is detailed in Section 5.6, including a fulfilled templateof production rules (Table 3) and a BPMNworkflow of the case study.Both tools are employed to detect a number of flaws in the CMHBssimulated in an automatic manner.

5. Case study

CHROMUBE is used for the generation and the validation ofCMHBs using the knowledge obtained from domain experts.Depending on the TS to be modelled, different experts could beconsulted. This section presents a case study concerned withgenerating CMHBs that represent the working routine of hospitalworkers. This case study was developed in the scope of the projectCADUCEO.1 CADUCEO is concerned with the introduction of newindoor location technologies in the Hospital of Terrassa (Spain).These location technologies (i.e. Zigbee and RFID) improve theresources control and management of the hospital by usinglocation information of their personnel and surgical equipment.

Before the implantation of the pilot experience, the hospital isinterested in the simulation of these location technologies in asimulated environment. CMHBs produced by applying CHROMUBEare used for testing the functionality of the system avoidingpremature physical deployments in the hospital. Realistic humanmodels of the hospital staff should be created for an effectivevalidation of the system. CHROMUBE uses knowledge from thestaff members considered as experts (i.e. the management team ofthe hospital). For this purpose, the knowledge referred to time-tables, routines, interactions, work teams, etcetera is essential. Thefollowing subsections illustrate the application of the methodol-ogy to the modelling of a complete morning in the operatingtheatre within CADUCEO. The interest lies in the following issues:

� the manner the staff moves along the hospital's floor devotedto surgery (with two different operating theatres and twomaterial storage rooms),

� the manner the equipment is used and shared among surgeries(defibrillators, anesthesia related equipment, health monitors) and

� the manner the material which is consumed during surgeries isdistributed (scalpels, gauzes and similar stuff).

The equipment is very costly and its use must be optimized whenshared across operating theatres. The material used must be availablebefore the different surgeries scheduled start thus the assistantpersonnel can transport it from the storage rooms to the operatingtheatres. Both the equipment and the material are transported withtrolleys. Trolleys and the human staff carry a badge used by the ZigBeelocation system to locate them in real time.

5.1. Step 2b: knowledge capture

Detailed knowledge about workers' daily routines was obtainedafter a semi-structured interview maintained with a member ofthe hospital management team. To model the CMHBs, the follow-ing information is taken into account: their location (i.e. the roomwhere the TS is at every moment), the hour the behavioursmanifest and what surgical equipment they use. Given that thiscase focuses on representing how the staff and equipment move,the question set did not go further than looking for those details.For instance, an extract of the question set is described as follows:

Validation engine

Knowledge Base

Ontology Timeline

Hierarchical automaton of behaviours

Simulation

Production rules (Drools)

B1AntecedentsConsequent

B2AntecedentsConsequent

BNAntecedentsConsequent

Temporal reasoning

B1 BN+

Events (Behaviour init, Behaviour end)

Computational Models of Human Behaviour

Static and temporal properties

Errors

execution output

Fig. 5. Overview of the validation process.

1 http://innovation.logica.com.es/web/caduceo/inicio, last access: March 2014.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 269

� How many workers are involved in the workday routine andwhich are their roles?

� For every worker involved in the workday routine, could youdescribe the routes they usually follow and the material andequipment they carry with them?

� Could you enumerate the rooms where the workers spend theworkday?

� Which equipment is required during an intervention? Where isit stored?

� Who is in charge of collecting the medical equipment beforethe intervention?

In addition to the initial interview, an alternative domainexpert of the management team checked our knowledge modelsand validated them. During this cross-validation stage, the alter-native expert confirmed that the models were correct and alsoadded some more knowledge about abnormal situations whichcan occur during a workday, e.g. a lack of material occurs during asurgery, the nurse goes from the operating theatre to the storageroom number 12 and returns to the operating theatre again.

Table 1 presents a summary of the most important conceptsrelated to the TSs which were obtained after knowledge analysis.

5.2. Step 3b: knowledge analysis

Knowledge analysis generated relevant concepts for thefollowing:

� the roles which every worker must assume during an workday,� the working methods and timetables assigned for each one of

these roles and� the routes they follow when performing their tasks.

Moreover, knowledge about abnormal situations was also gener-ated, e.g. “if a lack of material occurs during a surgery, the nursegoes from the operating theatre to the storage room number 12and returns to the operating theatre again”. Table 1 presents asummary of the most important concepts related to the TSs whichwere obtained after knowledge analysis.

All the CMHBs created must have a role. Depending on this role,the CMHB can manifest a specific behaviour. Table 2, explained in thissection, defines which behaviours correspond to every role. Besides,the rooms and the objects of the table are physical elements that mustbe created in the social simulator environment. They are requiredbecause the CMHBs will interact with them during the simulations.

The knowledge capture, analysis and modelling tasks per-formed in this work took about six man-days (including theontology and timeline definitions which required just two man-days). Although the modelling stage could be much more time-consuming and challenging, the domain experts of the presentedcase study had very clear ideas about the expected human modelsand were able to provide the knowledge base in a very complete(although informal) manner. Based on this description, identifyingthe most important concepts, attributes, values and relations fordefining the ontology and the timeline was straightforward.

5.3. Step 4b: knowledge modelling

An ontology was created using the previous concepts and someothers. The full ontology schema of the hospital including con-cepts, relations and attributes is available online (http://www.ants.inf.um.es/staff/emilioserra/ubiksim/EAAI). This schema is notincluded in the paper due to size reasons. Additionally, the time-line of Fig. 6 represents a fragment of the typical working day. Thisfigure shows a structured knowledge of which behaviour conceptsand relations among them were extracted from the interview. Itrepresents the following course of actions: it starts with the nursegoing to the storage room number 14, the nurse collects the

Table 1Knowledge basic concepts.

Worker roles Rooms Objects

Nurse Operating theatre TrolleySurgeon Storage room TableAssistant Waste zone CabinetAnesthesiologist Sterilization zoneCleaner

8:00 8:30 11:30

B1 B2 B3 B4

B7

B6B5Nurse B3

Simulation end

B3Surgeon and other TSs

Cleaner

Fig. 6. Timeline which includes behaviours that represent a typical surgery morning in the hospital.

Table 2Relation between roles (columns) and behaviours (rows).

Behaviour Nurse Surgeon Assistant Anesthesiologist Cleaner

Collect equipment fromstorage (B1)

Get equipmentfrom storage (B2)

Surgery (B3) ✓ ✓ ✓ ✓

Collect equipmentduring surgery (B4)

Get equipment duringsurgery (B5)

Carry equipment tosterilization room(B6)

Clean operatingtheatre (B7)

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276270

material from a cabinet and puts it in a trolley (B 1 in the timeline).Then, the nurse goes again to the operating theatre and puts thematerial on the table (B 2). Once everything is ready, the surgerybegins (B 3). Surgery is performed by various TSs at the same time:the nurse, a surgeon, an anesthesiologist and an assistant. Thenurse may go again to the storage room to collect more materialduring the intervention (B 4 and B 5). When the surgery finishes,he/she carries the consumed material to the sterilization zone(B 6) while the cleaner comes to the operating theatre and tidiesup (B 7). These last two behaviours occur simultaneously.

The ontology and the timeline knowledge models complementeach other. The ontology contains all the TS concepts and theirrelations with the physical environment (rooms and objects theyuse) while the timeline contains all the timing information related totheir behaviours. Note that the ontology and the timeline presentedcontain CMHB–CMHB interactions (e.g. the surgeon starts the surgeryonce the nurse has brought him/her the required equipment).Therefore, the case study presented in this paper only deals withinteractions between CMHBs–CMHBs (between computational modelsof human behaviours), and CMHBs–environment (interactionsbetween CMHBs and general spaces or objects which are notnecessarily computational devices). These interactions are one of themain concerns of the subsequent steps of the methodology: modellingthem with the HAB, implementing the model in UbikSim, andvalidating these interactions through production rules and timereasoning. On the other hand, interactions among people, servicesand devices are ultimately necessary to assist AmI systems'development by social simulation. One of our ongoing works is thecombination of the HAB with a hierarchical automaton of interactions(HAI) to simplify the modelling and implementation of these complexinteractions (Campuzano et al., 2012b). However, for the sake ofsimplicity, these preliminary results are not discussed in the contribu-tion presented.

5.4. Step 5: creation of CMHBs

To generate the CMHBs, all behaviour of the timeline must berepresented in the hierarchical automata. Due to the use of UbikSim(https://github.com/emilioserra/UbikSim/wiki) as social simulator inthe next step, the HAB architecture is considered. A CMHB for everyTS has to be created. In this case study, there are five TSs: nurse,surgeon, anesthesiologist, assistant and cleaner. Table 2 indicates theset of behaviours of the timeline that must be implemented for everyCMHB. Note that the HAB is an architecture which fosters code reuse.Hence, as some TSs share behaviours, those behaviours must beimplemented only once and be reused in each TS using it.

At this point, the required behaviours are created. Remind fromSection 3.4.1 that a behaviour within the HAB architecture needsthe following parameters: time duration, daytime intervals and aprobability distribution function. Regarding the pdf, the hospitalwas interested in simulating common delays when the behaviouroccurs. According to the management team, delays usually arewithin a range of 0–5 min, but never higher than 10 min. A gammadistribution following this specification was chosen because it canmodel waiting times (Garcia-Valverde et al., 2012a). The completelist of behaviours used in the simulation follows:

� q1 ¼ ð“CollectEquipmentFromStorage”;15;1; Iq1 Þ,Iq1 ¼ fð08 : 00;08 : 10; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

� q2 ¼ ð“GetEquipmentFromStorage”;15;1; Iq2 Þ,Iq2 ¼ fð08 : 15;08 : 25; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

� q3 ¼ ð“Surgery”;10800;1; Iq3 Þ,Iq3 ¼ fð08 : 30;08 : 40; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

� q4 ¼ ð“CollectEquipmentDuringSurgery”;15;1; Iq3 Þ,Iq3 ¼ fð10 : 00;10 : 10; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

q5 ¼ ð“GetEquipmentDuringSurgery”;15;1; Iq4 Þ,Iq4 ¼ fð10 : 15;10 : 25; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

� q6 ¼ ð“CarryEquipmentToSterilizationRoom”;15;1; Iq5 Þ,Iq5 ¼ fð11 : 30;11 : 40; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

� q7 ¼ ð“CleanSurgeryRoom”;15;1; Iq6 Þ,Iq6 ¼ fð11 : 30;11 : 40; gammaðshape¼ 5; scale¼ 1=2ÞÞg.

The workday begins with the nurse collecting surgical equip-ment from a cabinet at the storage room (room 14) and putting iton a trolley (i.e. q1). The nurse goes with the trolley to theoperating theatre (room 17) and puts the equipment on atable (i.e. q2). Then, the surgery begins (i.e. q3). This behaviour isperformed simultaneously by the nurse, the surgeon, the anesthe-siologist and the assistant. Behaviours q4 and q5 model the nursegoing to another storage room (room 12) to collect new equipmentand bring it to the operating theatre table, respectively. Now, q6represents the nurse carrying unused equipment to the steriliza-tion room (room 21). Meanwhile, the cleaner enters the operatingtheatre and removes all the single use equipment (i.e. disposables)from the table (i.e. q7). A priority value of 1 was assigned to all theqi;0r ir6. The resulting set of automata for the timeline of Fig. 6appears in Fig. 7. These automata correspond to a concrete CMHBfor the nurse, which is one of the most interesting CMHBs due toits number of behaviours. The main automaton corresponds tolevel 0, the highest on the hierarchy. The developer has to considerwhether to add new levels to the main automaton depending onthe simplicity of every state. If a state is simple enough, then it isnot necessary to discompose it in a new automaton. In this case,three levels of hierarchical automata have been defined forbehaviour B2. The rest of the behaviours are not shown for thesake of brevity.

5.5. Step 6: simulation

Once the behaviours are implemented with a HAB architecture,the entities of the ontology are instantiated and imported to thesocial simulator (https://github.com/emilioserra/UbikSim/wiki) tosimulate them (step 6 of CHROMUBE). On the one hand, one instancefor every kind of CMHB is required (a nurse, a surgeon, an assistant,an anesthesiologist and a cleaner). On the other hand, instances forevery one of the objects and rooms are needed for simulating theenvironment (a trolley, an operating theatre, etc.). The simulation ofthe CMHBs must be understood as test of the simulation model, andused as an input to Step 7 (see next subsection).

The number of tests needed to validate the behaviour modeldepends of the complexity of the model and the stringency levelrequired for the model. All behaviours have to be tested exhaustivelyin order to detect possible configuration or implementation errors.The developer must take into account that some configurationparameters of a behaviour are static, i.e. the priority, the timeduration and the intervals of a behaviour will not change duringthe simulation. However, the pdf parameter is a random process thatgenerates different values along the simulation and also differentvalues for every simulation. For that reason, a large number ofsimulations are necessary to validate the model. Note that animproper pdf may induce a behaviour to be launched after or beforethan that expected causing abnormal results in the model.

Consequently, it is recommended to continue simulating untilall behaviours have been tested at least σ times, where σ is agoodness parameter defined by the developer. This parameter canbe defined depending on the stringency level required by theexperts. Note that the more the behaviours and alternative flowsthere are, the more the simulations are required. Fig. 8 shows asnapshot of the plug-in developed for UbikSim which reads anontology and allows the developer to instantiate subjects and

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 271

physical objects to the scenario. This snapshot shows the workerroles which were parsed from the ontology.

Fig. 9 shows a snapshot of the simulation through the 3D viewof UbikSim. The medical staff is shown (nurse, surgeon, anesthe-siologist and assistant). At the right of the figure, some relevantphysical concepts of the case study as the table and the trolley aredisplayed. Additional contents including a video and a detailedexplanation of the simulation are available online (http://www.ants.inf.um.es/staff/emilioserra/ubiksim/EAAI).

5.6. Step 7: validation

The methodology CHROMUBE proposes using two differenttools to validate simulation models created with the presentedextension. On the one hand, production rules are employed forautomatically checking that (1) all CMHBs are executed at the rightphysical place; (2) the effects of these are the specified; and (3) allthe CMHBs are executed by the right simulation objects. On theother hand, workflows are needed to validate that CMHBs satisfythe precedence order required. Drools (http://www.jboss.org/drools) is used for production rules and Eclipse BPMN2 Modeler(http://eclipse.org/bpmn2-modeler) for BPMN workflows.

Using the template described in Section 4.2, the resulting produc-tion rules required for each behaviour are shown in Table 3. Note thatthe most important attributes are the same which were previouslydefined in Section 4.2: hour, physical zone (with a granularity of roomlocations), modified resources and the CMHBs who manifest thebehaviour. Note also that not all the entries contain all the attributes,

e.g. B 1 behaviour has the hour attribute in the antecedent but not inthe consequent. The reason is that the behaviour must begin approxi-mately at 8:00 but its end time is not relevant. It is worth noting thatconcrete timestamps are random by nature, i.e. they are generated bya pdf. In line with this, the validation process must check only if theydo not differ in more than 10min of the time specified at the template.These 10 min of difference was obtained from the experts. A similarexample is that of B 7. In this behaviour, the resource Table onlyappears in the consequent. This means that the validation process onlyneeds to check if the behaviour updated the table's state as empty,regardless of its previous state. The production rules resulting fromthese templates were Drools rules, and automatically generated fromthe templates. This process exceeds this paper scope.

The BPMN workflow that corresponds to the timeline of Fig. 6is shown in Fig. 10, remind that it has been created following theapproach presented in Flores and Sepúlveda (2011). A detailedexplanation of the creation process follows. The temporal relation-ship between B 1 and B 2 is a Finish to Start (FS) relationship. Thisrelationship implies that B 2 cannot begin before B 1 ends. In otherwords, the nurse cannot go to the surgery if he/she has not gonepreviously to the storage room. When B 2 ends, a parallel gateway(i.e. the diamond with a cross inside) with three outputs isconsidered. When a parallel gateway has one incoming sequenceflow and more than one outgoing sequence flow, all outgoingsequence flows are produced in parallel.

This parallel gateway has three flow sequences. The upper flowincludes the task B 3. When this behaviour finishes, the flow ishalted in a catch signal event (S 2). Signals are used for sending orreceiving general communication messages within and acrossBPMN processes (i.e. behaviours in this case). Thus, the behaviourshould wait for an event arrival in order to finish. The mainpurpose of this signal is to control that B 3 does not end before B4 and B 5 execution. In other words, the nurse must collectequipment from the storage room before the surgery ends.

An important detail is that a timer event is collocated before B4. It is used to represent a necessary delay in launching thebehaviour. In this case, it assures that B 4 starts after B 3. Thetimer value might be synchronized with the behaviour times, e.g.if B 4 must begin 1 h after the beginning of B 3, the timer valueshould be 1 h. In this case, B 4 begins approximately 90 min afterthe beginning of B 3. B 4 and B 5 have the same FS relationship as B1 and B 2. Once B 5 ends, a throw signal event labelled with S 1 is

Fig. 8. Ontology reader plug-in.

B1 B2 B3 B4 B5

Nurse

B6Default state

Take trolleyMove to operating theatre

B2

Level 0

Level 1

Drop trolley Organize equipment

Pick up equipment from trolley

Move to table

Organize equipment

Level 2

Deposit equipment

in table

Fig. 7. A summarized representation of the automata corresponding to the previous timeline.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276272

generated. That kind of throw signal events generates a signal sentto the corresponding catch signal events that react on arrival. Notethat the same happens with S 2.

Then, the catch signal event labelled with S 1 of the flowsituated in the middle of the workflow will receive this event. Thetimer event between S 1 catch signal event and S 2 throw signalevent assures that B 5 finishes before B 3 finishes. 60 min after theend of B 5, B 3 is ready to be finished so the signal S 2 is thrownand the upper flow ends. The three parallel flows are incomingsequence flows of the following parallel gateway. Thus, unless allof them have finished, the flow cannot continue through thegateway.

When the surgery ends, it is time to carry equipment tothe sterilization room (B 6) and clean the operating theatre(B 7). Both behaviours must be executed at the same time.The gateways after and before B 6 and B 7 are parallel gateways.These gateways assure that both behaviours can be executed at thesame time.

Once the rules of Table 3 are specified in Drools format and theworkflow of Fig. 10 is modelled with the Eclipse BPMN Modeller, abatch of simulation runs can be launched and monitored. Theapplication of the CHROMUBE methodology was found to be veryuseful for this particular case and three kinds of errors weredetected:

Fig. 9. Simulation of the case study in UbikSim.

Table 3Rules definition for the case study.

Behaviour CMHBs Antecedents Consequent

Collect equipment from storage (B1) Nurse Hour: 8:00 Physical zone: room 14Physical zone: room 32 Resources:Resources: Trolley:{new equipment},Trolley:{empty},Cabinet1:{new equipment} Cabinet1:{empty}

Get equipment from storage (B2) Nurse Physical zone: room 14 Physical zone: room 17Resources: Resources:Trolley:{new equipment}, Trolley:{empty},Table:{empty} Table:{new equipment}

Surgery (B3) Nurse, Hour: 8:30 Hour: 11:30Surgeon, Physical zone: room 17 Physical zone: room 17Anesthesiologist, Resources: Resources:Assistant Table:{new equipment} Table:{dirty equipment,disposables}

Collect equipment during surgery (B4) Nurse Physical zone: room 14 Physical zone: room 12Resources: Resources:Trolley:{empty}, Trolley:{new equipment},Cabinet2:{new equipment} Cabinet2:{empty}

Get equipment during surgery (B5) Nurse Physical zone: room 12 Physical zone: room 17Resources: Resources:Trolley:{new equipment}, Trolley:{empty},Table:{empty} Table:{new equipment}

Carry equipment to sterilization room (B6) Nurse Hour: 11:30 Physical zone: room 21Physical zone: room 17 Resources:Resources: Trolley:{dirty equipment}Trolley:{empty}

Clean operating theatre (B7) Cleaner Hour: 11:30 Physical zone: room 17Physical zone: room 32 Resources:

Table:{empty}

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 273

� priority errors: remind that the behaviours composing eachHAB must have a priority. Assigning wrong priorities led tobehaviours executed with an incorrect order.

� incorrectly programmed behaviours: behaviours must have agiven effect on simulated objects. The validation process foundsituations in which this effect was not as expected.

� incorrect duration of behaviours: behaviours duration is checkedin the validation process. Whether a behaviour did not take aslong as expected, this fault was be detected.

Instances of these three kinds of errors for the presented casestudy are presented:

� The states Surgery, CollectEquipmentDuringSurgery and GetE-quipmentDuringSurgery were all implemented with the samepriority. That was an error since CollectEquipmentDuringSurgeryand GetEquipmentDuringSurgery must have a greater prioritythan Surgery. The main reason is that Surgery must be inter-rupted by them. This error was detected because CollectEquip-mentDuringSurgery was launched after the end of Surgery.

� There was an error in the behaviour GetEquipmentFromStorage.The consequent trolley¼{empty} was not satisfied becausethe behaviour implementation was incorrect.

� The duration of Surgery was incorrectly set to zero and the statehad finished before the CollectEquipmentDuringSurgerystate began.

These errors which were detected in the validation step helpedto improve the CMHBs simulated according to the experts' needsand knowledge. However, no flaw was found with respect to theknowledge modelling (step 4b). Consequently, the iterative pro-cess was re-executed from step 7 to step 5 three times (once foreach error detected). The iterations allowed modifying the CMHBconfiguration by fixing the correct parameters. Therefore thevalidation process was worthy and useful to obtain more accuratecomputational models.

In this step, a visual validation was also performed by a groupof over 10 domain experts (i.e. the full management team includ-ing the two experts consulted in step 2b). This validation alloweddeciding if a new iteration was needed after checking that thephysical elements, objects and behaviours involved in the simula-tion were correctly simulated.

6. Conclusion and future works

This paper has proposed an extension of the CHROMUBE(CHROnobiology for Modelling hUman BEhaviour) methodologywhich focuses on the use of domain experts' knowledge. Thismethodology aims at creating CMHBs (Computational Models ofHuman Behaviour) for assisting in several phases of the AmbientIntelligence (AmI) development process: requirements specification,testing, and validation. The employment of experts' knowledge,combined with data from sensors or in an isolated manner, has beenextensively justified by the inherent limitations in the use of sensorstechnologies.

Regarding the knowledge capture, the semi-structured inter-views have been recommended due to their flexibility. At thisstage of the methodology, the conclusion is that the maininformation required from these interviews is the target subjects;their behaviours; and their interactions with the environment orother subjects. Concerning the knowledge analysis, the methodol-ogy concludes that four main elements have to be found andcategorized in the knowledge previously gathered: concepts,attributes, values for the attributes, and relations.

These elements are typically found in the semantic webspecialized literature and, therefore, the modelling step of CHRO-MUBE proposes defining ontologies as primary knowledge model.Moreover, due to the ontologies expressiveness limitations, theontology model is combined with timelines, which have beenextensively used for representing the order of the events, tasksand human behaviours.

With regard to the CMHBs generation, a formal model calledHierarchical Automaton of Behaviours (HAB) has been detailedand implemented in the open and free simulator UbikSim (https://github.com/emilioserra/UbikSim/wiki). The HAB provides devel-opers with a natural transition from the models of the previousstep to the simulation implementation and execution. The inter-ested reader may download UbikSim (https://github.com/emilioserra/UbikSim/wiki), creating environments models usinga drag and drop editor, and simulate the CMHBs implemented inthe context of these environments.

Finally, the most challenging task identified is the validation ofthe CMHBs. For this purpose, CHROMUBE has proposed the use ofproduction rules implemented in Drools and automatically gener-ated from templates. These rules are able to detect automaticallyfaults regarding users' locations, changes produced in the envir-onment, and behaviours assigned. This mechanism is combinedwith temporal reasoning implemented in BPMN 2.0 (Business

Fig. 10. Workflow including behaviours that represent a typical surgery morning in the hospital. Language BPMN.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276274

Process Modelling Notation) to validate the correct time order andcoordination among the simulated events.

A full case study where the CHROMUBE methodology has beeninstantiated and detailed. In the scope of the CADUCEO project,where indoor location based technologies have to be studied, thiscase study hints at the potential of CHROMUBE to model realistichuman models from domain experts' knowledge. Furthermore, thenumber of recommendations and techniques proposed has provedto be effective to detect faults in the human modelling process.These faults have been classified in three main categories: priorityerrors, incorrectly programmed behaviours, and incorrect durationof behaviours.

In spite of the advantages presented in these conclusions, thework still presents some shortcomings which must be addressedon future works.

Firstly, in order to get realistic human behaviours and due tothe difficulty of this task, this work is focused only on themodelling of such behaviours. However, the interactions amonghumans, ubiquitous services and devices are still needed to get awhole AmI system simulation. This fact affects mainly the ontol-ogy which should be completed with more concepts and relationsfrom the ubiquitous domain.

Secondly, regarding the definition of the ontology, morechanges are still necessary. On the one hand, as described above,it should be extended with new concepts. On the other hand, theexisting vocabulary defined is not able to take advantage of all thebenefits that the semantic web technologies can offer. The inclu-sion of more relations, restrictions and rules should be setaccording to the domain to allow detecting inconsistencies andreasoning for discovering facts that have not been explicitlydefined in the knowledge base. In that sense, some of thetechnologies proposed in this paper could be replaced for theontology and semantic web tools, like the inference based onDrools. However, at this moment, the complexity of the presentedontology is limited and the use other formalisms such as timelinesis necessary. Thirdly, one of the main difficulties in following thepresented methodology is the large quantity of technologies andtools involved. Therefore, one of our main research lines involvessimplifying the presented approach to enhance its usability.Finally, we also aim to maximize the diffusion of these researchresults by their inclusion in the open and free simulator used inthis paper to support CHROMUBE, the UbikSim simulator (https://github.com/emilioserra/UbikSim/wiki).

Acknowledgements

This research work is supported by the Spanish Ministry ofEconomy and Competitiveness under the R&D projects SocialAmbient Assisting Living - Methods (SociAAL) (TIN2011-28335-C02-02) and CALISTA (TEC2012-32457).

References

Additional material for this paper. ⟨http://ants.inf.um.es/staff/emilioserra/ubiksim/EAAI/⟩.

Addlesee, M., Curwen, R., Hodges, S., Newman, J., Steggles, P., Ward, A., Hopper, A.,2001. Implementing a sentient computing system. Computer 34 (8), 50–56.

Allen, J.F., 1983. Maintaining knowledge about temporal intervals. Commun. ACM26 (11), 832–843.

Amini, N., Sarrafzadeh, M., Vahdatpour, A., Xu, W., 2011. Accelerometer-based on-body sensor localization for health and medical monitoring applications.Pervasive Mobile Comput. 7 (6), 746–760.

Axtell, R., Axelrod, R., Epstein, J.M., Cohen, M.D., 1996. Aligning simulation models:a case study and results. Comput. Math. Organ. Theory 1 (2), 123–141.

Bellotti, V., Back, M., Edwards, W.K., Grinter, R.E., Henderson, A., Lopes, C., 2002.Making sense of sensing systems: five questions for designers and researchers.In: Proceedings of the SIGCHI Conference on Human Factors in Computing

Systems: Changing our World, Changing Ourselves. ACM, New York, NY, USA,pp. 415–422.

Bellotti, V., Edwards, K., 2001. Intelligibility and accountability: human considera-tions in context-aware systems. Hum. Comput. Interact. 16 (2–4), 193–212.

Benjamin, P., Patki, M., Mayer, R., 2006. Using ontologies for simulation modeling.In: Proceedings of the 38th Conference on Winter Simulation, WSC'06.pp. 1151–1159.

Beth, T., Boesnach, I., Haimerl, M., Moldenhauer, J., Bös, K., Wank, V., 2003.Characteristics in human motion–from acquisition to analysis. In: IEEE Inter-national Conference on Humanoid Robots, pp. 56–75.

Bos, C., Botella, B., Vanheeghe, P., 1997. Modelling and simulating human beha-viours with conceptual graphs. In: Conceptual Structures: Fulfilling Peirce'sDream. Springer, Berlin-Heidelberg, Germany, pp. 275–289.

Botía, J.A., Campillo, P., Campuzano, F., Serrano, E. UbikSim website. ⟨https://github.com/emilioserra/UbikSim/wiki⟩, 2014.

Campillo-Sanchez, P., Serrano, E., Botía, J.A., 2013. Testing context-aware servicesbased on smartphones by agent based social simulation. J. Ambient Intell.Smart Environ. 5 (3), 311–330.

Campuzano, F., Garcia-Valverde, T., Garcia-Sola, A., Botía, J.A., 2011. Flexiblesimulation of ubiquitous computing environments. In: Ambient Intelligence-Software and Applications. Springer, Berlin-Heidelberg, Germany, pp. 189–196.

Campuzano, F., Botía, J.A., Villa, A., 2012a. Chronobiology applied to the develop-ment of human behavior computational models. J. Ambient Intell. SmartEnviron. 4 (4), 369–389.

Campuzano, F., Serrano, E., Botía, J.A., 2012b. Towards socio-chronobiologicalcomputational human models. In: Advances in Artificial Intelligence–IBERAMIA2012. Springer, Berlin-Heidelberg, Germany, pp. 392–401.

Chen, H.-S., Chen, H.-T., Chen, Y.-W., Lee, S.-Y., 2006. Human action recognitionusing star skeleton. In: Proceedings of the Fourth ACM International Workshopon Video Surveillance and Sensor Networks. ACM, New York, NY, USA,pp. 171–178.

Chen, L.-C., Carley, K.M., Fridsma, D., Kaminsky, B., Yahja, A., 2006. Model alignmentof anthrax attack simulations. Dec. Support Syst. 41 (3), 654–668.

Cheng, C.-Y., Lan, T.-H., Chan, C.-H., 2013. An improved localization algorithm withwireless heartbeat monitoring system for patient safety in psychiatric wards.Eng. Appl. Artif. Intell. 26 (2), 905–912.

Collopy, F., Armstrong, J.S., 1992. Rule-based forecasting: development and valida-tion of an expert systems approach to combining time series extrapolations.Manag. Sci. 38 (10), 1394–1414.

Cook, D.J., Augusto, J.C., Jakkula, V.R., 2007. Ambient Intelligence: Technologies,Applications, and Opportunities.

Corbetta, P., 2003. Social Research: Theory, methods and techniques. SAGEPublications Limited, London, UK.

Corker, K.M., Smith, B.R., 1993. An architecture and model for cognitive engineeringsimulation analysis: application to advanced aviation automation. In: Proceed-ings of the AIAA Computing in Aerospace 9 Conference, pp. 1079–1088.

Drools website. ⟨http://www.jboss.org/drools/⟩, 2014.Dolog, P., Henze, N., Nejdl, W., Sintek, M., 2004. Personalization in distributed

e-learning environments. In: Proceedings of the 13th International World WideWeb Conference on Alternate Track Papers & Posters. ACM, New York, NY, USA,pp. 170–179.

Eclipse BPMN2 Modeler website. ⟨http://eclipse.org/bpmn2-modeler/⟩, 2014.Eddy, D.M., Schlessinger, L., 2003. Validation of the archimedes diabetes model.

Diabetes Care 26 (11), 3102–3110.Institute of Electrical and Electronics Engineers (IEEE). IEEE 90: IEEE Standard

Glossary of Software Engineering Terminology.Fernández-López, M., Gómez-Pérez, A., 2002. Overview and analysis of methodol-

ogies for building ontologies. Knowl. Eng. Rev. 17 (June 2), 129–156.Fitzgerald, J., 2005. Validated Designs for Object-Oriented Systems. Springer-Verlag

New York Incorporated, New York, NY, USA.Flores, C., Sepúlveda, M., 2011. Temporal specification of business processes through

project planning tools. In: Business Process Management Workshops. Springer,Berlin-Heidelberg, Germany, pp. 85–96.

García-Nieto, J., Alba, E., Olivera, A.C., 2012. Swarm intelligence for traffic lightscheduling: application to real urban areas. Eng. Appl. Artif. Intell. 25 (2), 274–283.

Garcia-Valverde, T., Campuzano, F., Serrano, E., Villa, A., Botía, J.A., 2012a. Simula-tion of human behaviours for the validation of ambient intelligence services:a methodological approach. J. Ambient Intell. Smart Environ. 4 (3), 163–181.

Garcia-Valverde, T., Serrano, E., Botía, J.A., 2012b. Combining the real world withsimulations for a robust testing of ambient intelligence services. Artif. Intell.Rev., 1–24.

Garlik, S.H., Seaborne, A., Prud'hommeaux, E., 2011. SPARQL 1.1 Query Language.⟨http://www.w3.org/TR/sparql11-query/⟩.

Garro, A., Russo, W., 2010. easyABMS: a domain-expert oriented methodology foragent-based modeling and simulation. Simul. Model. Practice Theory 18 (10),1453–1467.

Gilbert, N., Troitzsch, K.G., February 2005. Simulation for the Social Scientist. OpenUniversity Press, Maidenhead, Berkshire, UK.

Gutiérrez, C., García-Magario, I., Serrano, E., Botía, J.A., 2013. Robust design of multi-agent system interactions: a testing approach based on pattern matching. Eng.Appl. Artif. Intell. 26 (9), 2093–2104.

Halberg, F., Carandente, F., Cornelissen, G., Katinas, G.S., 1977. Glossary of chron-obiology. Chronobiologia 4, 1.

Harrison, B.L., Owen, R., Baecker, R.M., 1994. Timelines: an interactive system forthe collection and visualization of temporal data. In: Graphics Interface.Citeseer, pp. 141–141.

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276 275

Hatala, M., Wakkary, R., Kalantari, L., 2005. Rules and ontologies in support of real-time ubiquitous application. Web Semant.: Sci. Serv. Agents World Wide Web3 (1), 5–22.

Hattori, H., Nakajima, Y., Ishida, T., 2011. Learning from humans: agent modelingwith individual human behaviors. IEEE Trans. Syst. Man Cybern. Part A: Syst.Hum. 41 (1), 1–9.

Hayes-Roth, F., 1985. Rule-based systems. Commun. ACM 28 (9), 921–932.Heckmann, D., Schwartz, T., Brandherm, B., Schmitz, M., von Wilamowitz-

Moellendorff, M., 2005. Gumo—the general user model ontology. In: UserModeling 2005. Springer, Berlin-Heidelberg, Germany, pp. 428–432.

Heckmann, D., Schwarzkopf, E., Mori, J., Dengler, D., Kröoner, A, 2007. The usermodel and context ontology gumo revisited for future web 2.0 extensions. In:Contexts and Ontologies: Representation and Reasoning, pp. 37–46.

Hinchey, M.G., 2003. Formal approaches to agent-based systems. In: SecondInternational Workshop, FAABS 2002, Greenbelt, MD, USA, October 29–31,2002, Revised Papers, vol. 2. Springer-Verlag New York Incorporated, New York,NY, USA.

Hoey, J., Poupart, P., Boutilier, C., Mihailidis, A., 2005. Pomdp models for assistivetechnology. In: Proceedings of the AAAI Fall Symposium on Caring Machines: AIin Eldercare.

Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet, S., Grosof, B., Dean, M., 2004.Swrl: A Semantic Web Rule Language Combining OWL and RuleML. W3CMember Submission, World Wide Web Consortium.

Huang, S.-C., Cheng, F.-C., 2012. Motion detection with pyramid structure ofbackground model for intelligent surveillance systems. Eng. Appl. Artif. Intell.25 (7), 1338–1348.

Jones, R.M., Laird, J.E., Nielsen, P.E., Coulter, K.J., Kenny, P., Koss, F.V., 1999.Automated intelligent pilots for combat flight simulation. AI Mag. 20 (1), 27.

Kaklauskas, A., Vlasenko, A., Raudonis, V., Zavadskas, E.K., Gudauskas, R., Seniut,M., Juozapaitis, A., Jackute, I., Kanapeckiene, L., Rimkuviene, S., Kaklauskas, G.,2013. Student progress assessment with the help of an intelligent pupil analysissystem. Eng. Appl. Artif. Intell. 26 (1), 35–50.

Kay, J., Lum, A., 2005. Ontology-based user modelling for the semantic web. In:Proceedings of the Workshop on Personalisation on the Semantic Web: Per-SWeb05, pp. 15–23.

Kern, N., Schiele, B., Junker, H., Lukowicz, P., Tröster, G., 2003. Wearable sensing toannotate meeting recordings. Pers. Ubiquitous Comput. 7 (5), 263–274.

Lacroix, B., Mathieu, P., Kemeny, A., 2013. Formalizing the construction of popula-tions in multi-agent simulations. Eng. Appl. Artif. Intell. 26 (1), 211–226.

Liao, L., Patterson, D.J., Fox, D., Kautz, H., 2007. Learning and inferring transporta-tion routines. Artif. Intell. 171 (5), 311–331.

Lim, B.Y., Dey, A.K., Avrahami, D., 2009. Why and why not explanations improve theintelligibility of context-aware intelligent systems. In: Proceedings of theSIGCHI Conference on Human Factors in Computing Systems. ACM, New York,NY, USA, pp. 2119–2128.

Lu, R., Sadiq, S., 2007. A survey of comparative business process modelingapproaches. In: Business Information Systems. Springer, Berlin-Heidelberg,Germany, pp. 82–94.

Makikawa, M., Kurata, S., Higa, Y., Araki, Y., Tokue, R., 2001. Ambulatory monitoringof behavior in daily life by accelerometers set at both-near-sides of the joint.Stud. Health Technol. Inform. (1), 840–843.

McConnell, S., 2004. Code Complete, Second Edition Microsoft Press, Redmond, WA,USA.

McGuinness, D., 2004. Van Harmelen, F., et al. OWL Web Ontology LanguageOverview. W3C recommendation, 10:2004-03.

Milton, N.R., 2007. Knowledge Acquisition in Practice: a Step-by-Step Guide.Springer-verlag London Limited, London, UK.

Monitoring, B., Gottfried, I.-B. B., Aghajan. H., 2009. Pedestrian behaviour monitor-ing: methods and experiences. In: Behaviour Monitoring and Interpretation-BMI: Smart Environments, vol. 3, p. 11.

Moss, S., Artis, M., Ormerod, P., 1994. A smart automated macroeconometricforecasting system. J. Forecast. 13 (3), 299–312.

Moss, S., Edmonds, B., Wallis, S., et al., 1997. Validation and Verification ofComputational Models with Multiple Cognitive Agents. CPM Report (97-25),p. 168.

Muñoz, A., Serrano, E., Villa, A., Valdés, M., Botía, J.A., 2012. An approach forrepresenting sensor data to validate alerts in ambient assisted living. Sensors 12(5), 6282–6306.

Muir, B.M., 1994. Trust in automation: Part I. Theoretical issues in the study oftrust and human intervention in automated systems. Ergonomics 37 (11),1905–1922.

Murakami, Y., Sugimoto, Y., Ishida, T., 1999, 2005. Modeling human behavior forvirtual training systems. In: Proceedings of the National Conference on Artificial

Intelligence, vol. 20. AAAI Press; MIT Press; Menlo Park, CA; Cambridge, MA;London, p. 127.

Napierski, D.P., Young, A., Harper, K.A., 2004. Towards a common ontology forimproved traceability of human behavior models. In: 2004 Conference onBehavior Representations in Modeling and Simulation.

North, M.J., Macal, C.M., 2007. Managing Business Complexity: Discovering Strate-gic Solutions with Agent-Based Modeling and Simulation. Oxford UniversityPress, USA.

Orr, R.J., Abowd, G.D., 2000. The smart floor: a mechanism for natural useridentification and tracking. In: CHI'00 Extended Abstracts on Human Factorsin Computing Systems. ACM, New York, NY, USA, pp. 275–276.

Pacelli, M., Loriga, G., Taccini, N., Paradiso, R., 2006. Sensing fabrics for monitoringphysiological and biomechanical variables: E-textile solutions. In: 3rd IEEE/EMBSInternational Summer School on Medical Devices and Biosensors, 2006. IEEE,Cambridge, Massachusetts, USA, pp. 1–4.

Pantelopoulos, A., Bourbakis, N.G., 2010. A survey on wearable sensor-basedsystems for health monitoring and prognosis. IEEE Trans. Syst. Man Cybern.Part C: Appl. Rev. 40 (1), 1–12.

Pentland, A., Liu, A., 1999. Modeling and prediction of human behavior. NeuralComput. 11 (1), 229–242.

Protege website, open-source ontology editor and framework for building intelli-gent systems. ⟨http://protege.stanford.edu/⟩, 2014.

Razmerita, L., 2011. An ontology-based framework for modeling user behavior—acase study in knowledge management. IEEE Trans. Syst. Man Cybern. Part A:Syst. Hum. 41 (4), 772–783.

Russell, S.J., Norvig, P., Canny, J.F., Malik, J.M., Edwards, D.D., 1995. ArtificialIntelligence: a Modern Approach, vol. 74. Prentice Hall Englewood Cliffs, UpperSaddle River, New Jersey, USA.

Salvucci, D.D., Boer, E.R., Liu, A., 2001. Toward an integrated model of driverbehavior in cognitive architecture. Transp. Res. Rec.: J. Transp. Res. Board 1779(1), 9–16.

Schlesinger, S., Crosbie, R.E., Gagne, R.E., Innis, G.S., Lalwani, C., Loch, J., Sylvester,R.J., Wright, R.D., Kheir, N., Bartos, D., 1979. Terminology for model credibility.Simulation 32 (3), 103–104.

Schreiber, G., 2000. Knowledge Engineering and Management: the CommonKADSMethodology. The MIT press, Cambridge, Massachusetts, USA.

Serrano, E., Botía, J.A., 2013. Validating ambient intelligence based ubiquitouscomputing systems by means of artificial societies. Inf. Sci. 222, 3–24.

Serrano, E., Muñoz, A., Botía, J.A., 2012. An approach to debug interactions in multi-agent system software tests. Inf. Sci. 205, 38–57.

Serrano, E., Rovatsos, M., Botía, J.A., 2013. Data mining agent conversations:a qualitative approach to multiagent systems analysis. Inf. Sci. 230, 132–146.

Shadbolt, N., 2005. Eliciting Expertise. Evaluation of Human Work. pp. 185–218.Shervais, S., Wakeland, W. Evolutionary Strategies as a Verification and Validation

Tool. Technical Report, 2003.Silva, L.C.D., Morikawa, C., Petra, I.M., 2012. State of the art of smart homes. Eng.

Appl. Artif. Intell. 25 (7), 1313–1321.Smith, M.H., Holzmann, G.J., Etessami, K., 2001. Events and constraints: A graphical

editor for capturing logic requirements of programs. In: Proceedings of theFifth IEEE International Symposium on Requirements Engineering, 2001. IEEE,Washington, DC, USA, pp. 14–22.

Stokes, M., 2001. Managing Engineering Knowledge: MOKA: Methodology forKnowledge based Engineering Applications, vol. 3. Professional EngineeringPublishing London, London, UK.

Suryadevara, N., Mukhopadhyay, S., Wang, R., Rayudu, R., 2013. Forecasting thebehavior of an elderly using wireless sensors data in a smart home. Eng. Appl.Artif. Intell. 26 (10), 2641–2652.

SWRL Language FAQ website. ⟨http://protege.cim3.net/cgi-bin/wiki.pl?SWRLLanguageFAQ⟩, 2014.

Tapia, E.M., Intille, S.S., Larson, K., 2004. Activity Recognition in the Home usingSimple and Ubiquitous Sensors. Springer, Berlin-Heidelberg, Germany.

Thornton, P., Williams, A., Shaw, G., 1997. Revisiting time-space diaries: anexploratory case study of tourist behaviour in cornwall, england. Environ. Plan.A 29, 1847–1868.

Weiss, G., 1999. Multiagent Systems: a Modern Approach to Distributed Artificialintelligence. The MIT press, Cambridge, Massachusetts, USA.

Weiss, R.S., 2008. Learning from Strangers: The Art and Method of QualitativeInterview Studies. Free Press, New York, NY, USA.

Yahja, A., 2006. Simulation Validation for Societal Systems. Technical report, DTICDocument.

Young, A.S., Harper, K.A., 2005. Trace: An ontology-based approach to generictraceability tools for human behavior models. In: Proceedings of the 14thConference on Behavior Representation in Modeling and Simulation (BRIMS05).

F. Campuzano et al. / Engineering Applications of Artificial Intelligence 35 (2014) 259–276276