An Intelligent System for Smart Tourism Simulation in a Dynamic Environment Mohannad Babli, Jesús Ibáñez, Laura Sebastiá, Antonio Garrido, Eva Onaindia 1,2 Abstract. In this paper, we present a smart tourism system for instance, a museum that closes, a restaurant which is fully that plans a tourist agenda and keeps track of the plan exe- booked, a bus route that is now diverted, etc. This has critical cution. A Recommendation System returns the list of places implications on the way tourists regard their experiences. Ac- that best fit the individual tastes of the tourist and a planner tivities, even pre-designed in advance, must be dynamically creates a personalized agenda or plan with indication of times adapted and personalized in real time. One essential prerequi- and durations of visits. The key component of the system is site for smart technology is real time synchronization, which the simulator in charge of the plan monitoring and execution. implies that information is not limited to a-priori collection The simulator periodically updates its internal state with in- but can be collected and updated in real time [14]. formation from open data platforms and maintains a snapshot Creating an agile and adaptable tourist agenda to the dy- of the real-world scenario through live events that communi- namic environment requires tracing the plan and checking cate sensible environmental changes. The simulator builds a that activities happen as expected. This involves plan moni- new planning problem when an unexpected change affects the toring and possibly finding a new tourist agenda organization plan execution and the planner arranges the tourist agenda in case some particular activity can not be realized. In this by calculating a new plan. paper, we relate our experience with a context-aware smart tourism simulator. From the monitoring and simulation perspective, there 1 INTRODUCTION exist many frameworks for different programming lan- The exponential growth of the Internet of Things (IoT) and guages that support discrete event-based simulators (e.g. the surge of open data platforms provided by city govern- http://jamesii.informatik.uni-rostock.de/jamesii.org, ments worldwide is providing a new foundation for travel- http://desmoj.sourceforge.net/home.html, related mobile products and services. With technology being http://simpy.readthedocs.io/en/latest/). Although embedded on all organizations and entities, the application they can be programmed for very particular scenarios, they of the smartness concept to address travellers’ needs before, fail to take a general domain description and simulate its during and after their trip, destinations could increase their behavior in highly dynamic environments. At this stage, competitiveness level [2]. planning technology can be very valuable. The Planning Smart tourism differs from general e-tourism not only in Domain Definition Language (PDDL) provides a simple way the core technologies of which it takes advantage but also in to define the physics of the domain (a tourism domain in the approaches to creating enhanced at-destination experi- our case, although it is valid for any other scenario) and ences [8]. In the work [14], authors identify the requirements the particular problem that instantiates such a domain. In of smart technology integration in personalized tourism expe- PDDL we can define the activities to be executed similarly to riences including information aggregation, ubiquitous mobile rules, with their preconditions, effects and other interesting connectedness and real time synchronization. features like duration, cost, reward, etc. The result of using Many tourism applications provide a personalized tourist planning in a tourism domain is a plan, represented as the agenda with the list of recommended activities to the user agenda of activities the user will follow. The plan needs to [12, 13, 5, 16, 15]. In many cases, these systems provide a dy- be validated, executed and adapted, if necessary, to new namic interaction that allows the user to interact with such information. VAL is a plan validation tool [9] that can be agenda by adding or removing activities or changing their used to validate and simulate a successful plan execution. order. Additionally, the use of GPS in mobile devices al- However, VAL does not consider the dynamic changes of the lows recommender systems to locate the future user’s location world and, consequently, it cannot react to them. and recommend the most interesting places to visit. However, In this work, we present a smart tourism system that at- most of these applications work with fixed and static infor- tempts to overcome the previous limitations. Particularly, we mation throughout the execution of the activities. In other use a PDDL tourism description that can be easily adapted words, they do not easily react before changes in the world; to many different scenarios with new activities, preconditions, effects and points of interest. We run a planner to obtain a 1 Universitat Politècnica de València, Valencia, Spain, Email: plan and we simulate the plan execution like in a real con- {mobab, jeibrui, lstarin, agarridot, onaindia}@dsic.upv.es text, dynamically simulating changes in the environment. The 2 This work has been partially supported by Spanish Government simulator reacts to the changes by checking whether the real Project MINECO TIN2014-55637-C2-2-R 15 would be also valid, such as OpenStreetMap6 . Third, there exists a snapshot of the environment or real-world scenario where the plan is executed. Since this world is highly dy- namic and can change frequently (e.g. the opening hours of a museum has changed, or a restaurant is fully booked and the duration for having lunch is longer than expected), we get the new information as live events. On the other hand, the planning module takes the user profile and the problem information to create a planning sce- nario in a PDDL format, as described in Section 3. We need to model the user preferences, constraints and the actions that the user can do, such as visit or move. The output of this is a plan, as a sequence of actions the user has to execute. As a proof of concept, in GLASS we actually simulate that execu- tion rather than having a real execution that would require a true group of tourists equipped with sensoring information to their current geographic positions, pending and already satisfied goals, etc. This simulation process, more detailed in Section 4, takes the plan and creates a timeline structure to run a timed events based execution. It simulates and monitors Figure 1. GLASS Architecture the resulting states of the world, according to the changes in the plan, that is the effects that actions provoke and, proba- bly, being also modified by the live events. This simulation is world matches the expected one or not and reformulating the shown in a specially designed Graphical User Interface that PDDL problem if a failure in the plan is detected, while trying shows what is happening at any time. If the expected state is to reuse as many of the original set of recommended activities different to the real state, i.e. a discrepancy has been discov- as possible. ered, because some live events prevent the remaining actions This paper is organized as follows. Next section outlines the in the plan from being executed, a (re)planning module be- architecture of the smart tourism system. Section 3 presents comes necessary. The idea is to reuse the same planning mod- the planning description of the tourism domain and highlights ule, thus closing the loop, with a new PDDL domain+problem the main components of a planning problem. Section 4 de- specification to adapt the plan to the new emerging scenario. scribes the simulator behaviour with a special emphasis on the reformulation of a planning problem. Section 5 presents a case of study of a tourist plan in the city of Valencia in Spain 3 PLANNING MODULE and last section concludes. The main goal of our system is to provide a personalized plan to a given tourist. This resulting plan has to reflect the prefer- 2 GLASS ARCHITECTURE ences of the tourist according to his/her profile (demographic classification, the places visited by the user in former trips and This work is part of the ongoing GLASS3 (Goal-management the current visit preferences). Moreover, in order to build this for Long-term Autonomy in Smart citieS) project applied to plan, the duration of the activities to perform, the opening a tourism domain. The idea here is to apply different strate- hours of the places to visit and the geographical distances be- gies for dividing the set of goals (i.e. tourist recommendations tween places (time to move from one place to another) needs based on previous plans executions by other tourists) for each also to be considered. Thus, solving this problem requires the user by using different utility recommendations systems. The use of a planning system capable of dealing with durative ac- GLASS architecture is shown in Figure 1. As can be seen, tions to represent the duration of visits; temporal constraints the architecture simply consists of a two-process loop: plan- to express the opening hours of places and soft goals for the ning module and simulation+monitoring that share common user preferences. Soft goals will be used to denote the prefer- information. able visits of the user, the non-mandatory goals that we wish On the one hand, the input information is retrieved from to satisfy in order to generate a good plan that satisfies the different data sources. First, we need the user profile with user but that do not have to be achieved in order for the plan the explicit interests of the user, the goals and preferences to be correct. In our case, the goal of visiting a recommended (such as points of interest he/she wants to visit), and tem- place according to the user profile (the list of potential places poral constraints. Second, we need to access a different set that the user can visit is returned by a Recommender Sys- of databases that identify and categorize the points of in- tem), is defined as a soft goal (more details in section 3.2). terest (e.g. museums, restaurants, etc.), their timetable, and Among the few automated planners capable of handling tem- geographic sources to find out routes, distances and times be- poral planning problems with preferences, we opted for OPTIC tween points. Currently, we use standard APIs, such as Google [1] because it handles the version 3.0 of the popular Planning Places4 and Directions5 for this, but other open databases Domain Definition Language (PDDL) [7], including soft goals. 3 More info at http://www.plg.inf.uc3m.es/~glass 4 More info at https://developers.google.com/places/web-service directions 5 More info at https://developers.google.com/maps/documentation/ 6 More info at http://wiki.openstreetmap.org/wiki/API 16 All the information required by OPTIC to build the plan is violation, of these preferences will affect the quality of a plan. compiled into a planning problem encoded in PDDL3.0 lan- The penalties for violation of preferences (costs) will be han- guage, as described in the following sections. dled by the planner in the plan metric to optimize at the time of selecting the best tourist plan; i.e., the plan that satisfies the majority of the tourist preferences and thereby minimizes 3.1 Initial state the penalties for violation. The initial state of a planning problem describes the state The objective is to find a plan that achieves all the hard of the world when the plan starts its execution. The initial goals while minimizing a plan metric to maximize the prefer- state must reflect the opening hours of the places to visit, the ence satisfaction; that is, when a preference is not fulfilled, a distances between them, the initial location of the user, etc. penalty is added to the metric. Specifically, we define penal- Some information is expressed with predicates and functions, ties for non-visited POIs and for travelling times. while other information is represented by Timed Initial Liter- The penalty for non-visited places is aimed to help the plan- als (TILs). TILs, which were first introduced in PDDL2.2, are ner select the activities (tourist visits) with a higher priority a very simple way of expressing a restricted form of exogenous for the user. Given a plan Π, this penalty is calculated as the events that become true or false at given time points [3]. ratio between the priority of the activities not included in Π The predicate (be tourist ?l) is used to represent the and the priority of the whole set of activities recommended location of the user and the pair of TILs (at 0 (active to the user (RA): tourist)) and (at tavailable (not (active tourist))) de- P P ra termine the available time of the user for the tour, where Pnon visited = a∈RA−Π P aPr tavailable is the difference between the time when the tour a∈RA starts and finishes. The time indicated in the TILs is relative For example, if the priority for visiting the Lonja is 290, and to the starting time of the plan; that is, tavailable = 540 refers the sum of the priorities of all the visits is 2530, the penalty to 7pm if the plan starts at 10am. Another pair of TILs is for not visiting the Lonja would be expressed in PDDL as: ( used to define the time window in which the tourist prefers / (* 290 (is-violated v3)) 2530). The priority of the ac- to have lunch. For example, if the preference is between 2pm tivities (P ra ) is calculated by a hybrid Recommender System and 4pm, the TILs are (at 240 (time for eat tourist)) (RS) which returns a value between 0 and 300 according to and (at 360 (not (time for eat tourist))). the estimated degree of interest of the user in activity a. The The duration of a particular visit ?v for a tourist ?t is de- value of P ra is also used by the RS to return a time interval fined through the numeric function (visit time ?v ?t). As- that encompasses the minimum and maximum recommend-  signing a value to a numeric function gives rise to a numeric- able visit duration following a normal distribution N µa , σa2 , valued fluent; for example, (= (visit time Lonja tourist) where µa represents the average visit duration for a typical 80) (details about calculating the duration of the visit are tourist [10]. Thus, the higher the value of P ra , the longer the shown in the following section). The list of available restau- visit duration. rants is given through the predicate (free table ?r); for The penalty for movements enforce a reduction in the time example, (free table ricard camarena). For each restau- spent in travelling from one location to another, so that closer rant, we define the time slot in which it serve meals, which activities are visited consecutively. This penalty is calculated may depend on the type of restaurant, closing time of the as the duration of all move actions of Π (Πm ): kitchen or other factors. Both, places to visit and restau- rants, have an opening hour and a closing hour that are P a∈Πm dur(a) specified by a TIL: (at topen (open a)) and (at tclose (not Pmove = dur(Π) (open a))), to indicate when the place/restaurant is not longer available. For example, (at 0 (open Lonja)), (at The function (total moving time tourist) accumulates 540 (not (open Lonja))). the time spent in transportation actions, so this penalty would The distance between two locations ?a and ?b is defined by be defined in PDDL as: ( / (total moving time tourist) the function (moving time ?a ?b), which returns the time 540). The plan metric to be minimized by the planner is ex- in minutes needed to travel from ?a to ?b by using the pressed as the sum of both penalties: Ptotal = Pnon visited + travel mode preferred by the user. The time to move between Pmove . two places is represented through a numeric fluent (e.g., (= (moving time caro hotel Lonja) 9)), where the value 9 is taken from Google Maps. 3.3 Actions We define three actions in the tourism domain. The action to move from one location to another is defined in Figure 2. It 3.2 Goals and preferences takes as parameters the user ?per, the initial location ?from We handle two types of goals: hard goals, that represent the and the destination ?to. The duration of the action is set to realization of an activity that the user has specified as manda- the estimated/actual time to go from ?from to ?to, which is tory (e.g., the final destination at which the user wants to fin- stored in the database. The preconditions for this action to ish up the tour (be tourist caro hotel)); and soft goals or be applicable are: (1) the user is at location ?from and (2) the preferences, that represent the realization of a desirable but time window for the available time of the user is active during non-compulsory activity (e.g., visiting the Lonja (preference the whole execution of the action. The effects of the action v3 (visited tourist Lonja))). Preferences are expressed assert that (1) the user is not longer at the initial location, (2) in PDDL3.0 so we need to define how the satisfaction, or the user is at the new location at the end of the action and (3) 17 (:durative-action move (:durative-action visit :parameters (?per - person ?from - location :parameters (?per - person ?mon - monument) ?to - location) :duration (= ?duration (visit_time ?mon ?per)) :duration (= ?duration (moving_time ?to ?from) ) :condition :condition (and (and (at start (be ?per ?mon)) (at start (be ?per ?from)) (over all (be ?per ?mon)) (over all (active ?per))) (over all (active ?per)) :effect (over all (open ?mon)) (and :effect (at start (not (be ?per ?from))) (and (at start (walking ?per)) (at end (visited ?per ?mon)))) (at end (be ?per ?to)) (at end (not (walking ?per))) (at end (increase (total_moving_time ?per) (moving_time ?from ?to))))) Figure 3. Action visit of the tourism domain Figure 2. Action move of the tourism domain (:durative-action eat :parameters (?pers - person ?loc - restaurant) :duration (= ?duration (eat_time ?pers ?loc)) :condition the time spent in move actions is modified according to the (and movement duration. In order to indicate the position of the (at start (free_table ?loc)) (at start (be ?pers ?loc)) user during the execution of the action, a walking predicate (over all (be ?pers ?loc)) is asserted at the start of the action and deleted at the end (over all (active ?pers)) of the action. In this paper, we only consider walking as the (over all (open ?loc)) (over all (time_for_eat ?pers))) move action; however, more transportation modes according :effect to the user’s preferences can be included; e.g., cycling, driving, (and and public transport, as in [10] . (at end (eaten ?pers)))) The action to visit a place is defined in Figure 3, whose parameters are the place to visit ?mon and the user ?per. The duration of the action is defined by the function (visit time Figure 4. Action eat of the tourism domain ?mon ?per). The conditions for this action to be applicable are: (1) the user is at ?mon during the whole execution of the action; (2) ?mon is open during the whole execution of the action and (3) the time window for the available time of the 4.1 Timed event simulation: the timeline user is active. The effects of the action assert that the place A timeline is a simple structure that contains a collection is visited. of unique timed events in chronological order that represents The action to perform the activity of eat is defined in Fig- a sequence of world states and that need to be monitored. ure 4, whose parameters are the user ?pers and the restaurant The timeline is generated with the actions of the plan, the ?loc. The duration of the action is defined by the function problem information and the live events, as depicted in Fig- (time for eat ?pers) and specified by the user. To apply ure 1. A timed event is an event that happens at time t and this action, the following conditions must hold: (1) the user is contains the following information: (1) the start, over all or at ?loc during the whole execution of the action; (2) ?loc is end conditions to be checked at t; (2) the start or end ef- open during the whole execution of the action; (3) the restau- fects to be applied at t; (3) TILs that represent exogenous rant has a free table and (4) both the time window for the events but that are defined as part of the problem informa- time to have lunch defined by the user and the available time tion, so they are known at the time of the plan simulation; are active. The effects of the action assert that the user has and (4) live events, that dynamically appear during the exe- had lunch. cuting/monitoring process and so they are unknown a priori. This way, a timeline encapsulates the information about the 4 SIMULATOR plan (irrespective of it is a sequential or parallel one), TILs and live events7 , and the corresponding world states. The time The objective of the simulator is to execute the plan and mon- scale of the timeline will depend on the granularity of the itor that everything works as expected. To accomplish this, we plan and the periodic steps we want to use for monitoring first need to create the structures to perform the simulation. the timed events. In our implementation, live events can be We use a timed event simulation, where events occur at par- manually supplied or they can be retrieved from a datasource ticular times through a timeline, possibly provoking changes that keeps information about the real world. in the world state. During the plan monitoring, we check the Given a plan with two actions (move and visit), of duration predicates and functions and we visually show the plan trace 20 and 60, respectively, and a live event that indicates the in a specially designed GUI. In case a failure that prevents 7 The information about the plan, problem information and an action of the plan from being executed is found during the live events is modeled in PDDL format. We used PDDL4J plan simulation, we activate a replanning mechanism that re- (https://github.com/pellierd/pddl4j), an open source library quires a knowledge-based reformulation of the new planning that facilitates the development of JAVA tools for automated scenario. Next, we describe these tasks in more detail. planning based on the PDDL language 18 0.00 move person1 hotel museum [20.00] 20.01 visit person1 museum [60.00] 90.00 live event (not (open museum1)) Figure 5. An example of a timeline with five timed events. Note the closed interval for the at start/end conditions and effects, and the open interval for the over all conditions museum is closed (not open) at time 90, the resulting timeline is shown in Figure 5. Figure 6. Simulator graphical user interface 4.2 Plan execution simulation The simulation of the plan execution requires to set the size the failure: the action that has failed and the conditions that of the execution step that will be applied along the timeline have been violated. For instance, in the example of Figure 5, explained in section 4.1. We can set the step size to the time let us suppose there is a live event at time 60 that indicates granularity of the planner or choose a larger size. The smaller the museum will no longer be open from 60 onwards. In this the size of the execution step, the more frequently access to case, the overall condition ]20.01,80.01[ (open museum) is external databases (Google APIs) to acquire new information violated, which means the visit action cannot be successfully and update the real-world state. Thus, the execution step size executed. Then, we need to invoke the replanning module as specified by the user determines the update frequency of the described in Section 4.4 internal state of the simulator with respect to the real-world state. If changes frequently occur in the domain, a small ex- 4.3 Graphical User Interface ecution step will result in a more reliable simulation with a proactive behavior. The simulation state is also updated at The graphical user interface (GUI) has been designed to pro- each timed event, checking the conditions of the actions in vide information about the internal state of the simulator dur- the state and applying the effects of the event. Additionally, ing the whole plan execution simulation and provides mech- the simulator also interacts with the real-world through live anisms to control the next step of the simulation. The GUI events, which may in turn modify or create new timed events is specifically designed to offer a smart-city orientation. It in- in the timeline. cludes six distinguishable GUI parts: The simulation of the plan execution starts at time zero, with an initial state equal to the real-world state, and the sim- 1. Figure 6-section 1 shows the current simulation time ulator advances through the timeline in every execution step 2. Problem objects (Figure 6-section 2): it displays the plan- (see Figure 5). The simulator checks that conditions are sat- ning problem objects along with their types. This static isfied, the current state matches the expected state, and then information will not change over the simulation process. updates the current state accordingly — this whole process is 3. Current state (Figure 6-section 3): This graphical section visually shown in our GUI, described below. More specifically, contains the PDDL description of the current state, which every execution step involves two main tasks: can change after an action starts or ends, when a live event arrives or when a user introduces a manual change (TILs). 1. processing the live events for changes and update the re- Propositions and numeric fluents of the current state can spective timed events be separately consulted in two different tabs. 2. for every unprocessed timed event within the current step: 4. Figure 6-section 4 shows the problem goals. In later refine- (1) update the simulation state with the TILs and effects ments, we intend to show the goals that are expectedly to of the live events; (2) check the conditions of the timed be achieved with the plan under execution. event to find differences between the current state and the 5. Figure 6-section 5 shows the dynamic list of plan actions, expected state; and (3) update the state with the effects of their start time, the objects involved in the action execution the actions. and the action duration. In addition, actions are shown with a representative colour: actions currently in execution If a difference between the current state and the expected are shadowed in yellow, past or already executed actions in state is found and this difference leads to a situation where the red, and future actions in white. plan is no longer executable, then a failure has been detected. 6. Representative map (Figure 6-section 6): The map depicts In such a case, the GUI informs the user about the cause of with location icons the relevant places involved in the plan 19 due to an overall or an at end condition violation, we will calculate the new initial state by simply rolling back the at start effects of the failing action (if any). Step 1.2: Update the time of TILs. When the new problem is reformulated, we invoke the OPTIC planner, which resets the time of execution and generates a plan starting from time equal to zero. Consequently, we need to update the occurrence time of the TILs to the result of its original time minus the failure time. Let us assume that a failure occurred at time 100, and that we have the TIL planned at time 235 (at 235 (not (open la paella))), meaning that the restaurant la paella will close at 235. Therefore, in the new initial state formulation, its time will be 135 (235 minus 100); and it will be updated to (at 135 (not (open la paella))). Step 2: Update preferences. When a failure occurs, we come across a situation where we can distinguish two types of preferences or soft goals: 1. Goals that have already been achieved at the time of the failure by the actions that have been successfully executed Figure 7. Reformulation steps before the failure. These preference goals along with their penalties will not be included in the new reformulated prob- lem. 2. Goals that have not been satisfied, and which can in turn (places to visit, restaurant, hotel). These location icons be divided into two sets: change their colour when the corresponding action is ex- ecuted. The map also displays distances between locations. (a) The problem goals that were not included in the original 7. Simulation control buttons (Figure 6-section 7): In the mid- plan; dle of the top menu, the interface displays four buttons to (b) The problem goals included in the original plan that have run the simulator step by step (the step size is defined by not been satisfied yet due to the failure. the user), continue with the simulation, stop the simulation • For the set of goals in (a), the penalties are kept intact and reset the simulation. as they were originally defined in the problem file. • For the set of goals in (b), we want to keep the plan sta- 4.4 Reformulating the planning problem bility metric [4] similar to the concept of minimal per- turbation [11], which is why we increase the penalties Figure 7 shows the steps of the reformulation procedure. of these goals in the new reformulated problem. Par- Step 1: Create the New Initial State. The initial state ticularly, we opt for assigning a relatively high prior- will comprise the information known by the simulator at the ity to these pending goals (twice as much as the max- time of creating the new problem. This includes the infor- imum penalty among all goals), in order to potentially mation of the current simulation state plus the information enforce these goals in the new plan. We have thus opted about future TILs; that is currently known information about for applying a stability strategy that gives more priority some future events. Thereby, the occurrence time of the future to goals that were already included in the original plan TILs must also be updated. than goals that were not. Other strategies such as keep- Step 1.1: Update propositions and fluents. This step ing a higher level of stability with respect to the failed refers to the update of the current state. The propositions prior plan can also be adopted. In the case of a tourism and fluents after the failure are retrieved from the current domain, we think that maintaining the original agenda world state. However, this might not be an accurate state of the tourist as far as possible is more advisable. since we do not have sensing actions that provide us with a precise picture of the real world. This may be particularly For example, let us consider that the preference problematic when an overall or an at end condition of an (preference v2 (sometime (visited tourist action is violated and the action has at end effects. Let us central market))) is one of the soft goals in the take as an example the action (move tourist caro hotel set (b); this preference indicates that sometime during viveros garden), with an at start effect (at start (not the execution of the plan the tourist wishes to visit (be tourist caro hotel))), an at end effect (at end (be the central market. Assuming that the penalty of this tourist viveros garden)), and an overall condition (over preference in the original problem file was 270, and that all (active tourist)). Due to a failure that resulted from the highest among all preferences was 300, the new a live event which violated the previously mentioned overall penalty for preference v2 will be 600. condition, the tourist is neither in caro hotel because the Finally, two points are worth mentioning. First, we learn at start effect were already executed, nor in viveros garden the soft goals that the planner decided to pursue in the because the at end effects were not yet executed due to the original plan by simply executing the plan without any live failure. For simplicity, and because of the lack of sensing ac- events. Second, the pending hard goals of the original prob- tions in our current implementation, when a failure happens lem are kept as hard goals in the new problem file. 20 Step 3: Generate the new PDDL files. The last step set of goals includes two lists: (a) the pending goals of the of the reformulation process consists in generating the new failed plan; that is, have lunch (4. have lunch) and the PDDL files. In principle, the domain file remains unchanged, three remaining monuments that have not been yet visited unless we wish to necessarily include some particular action in by the user (5. Lonja, 6. Central market, 7. Town Hall); the new plan. In this case, we would need to encode a dummy plus (b) the goals of the original problem goals that were effect that triggers the corresponding action. Otherwise, only not included in the first plan. the problem file is generated taking into consideration the Regarding penalties of the goals, the list of goals in (b) modifications discussed in step 1 and step 2. are included in the new planning problem with their original In future implementations of the simulator, we will test a recommended values (see the non-bold values RV’ in column Constraint Programming approach [6] for reformulating the 2 of Table 1). As for the pending goals of (a), the penalty of planning problem, as in [15], and compare the performance these goals is increased with respect to their penalty in the when relying on a scheduler rather than a planner. first plan (see the bold values RV’ in column 2 of Table 1 for the three pending monuments) accordingly to the stability 5 CASES OF STUDY concept explained in section 4.4. The simulator invokes OPTIC and obtains a new plan, dis- played in the middle snapshot of Figure 8. A few things must The aim of this section is to show the behaviour of our be noted in this new plan: simulation system with a representative example. We have a tourist who wishes to make a one-day tour in the city of Va- 1. OPTIC suggests a new restaurant (orange icon labeled with lencia. Initially, the system retrieves a set of recommended number 4) which is rather far away from the prior restau- places according to the user profile (table 1, column 1) and rant. The reason is that we have only included in the plan- a set of restaurants. The list of recommended places is cal- ning problem the 10-top restaurants in Valencia suggested culated by a Recommender System through the user profile. by Trip Advisor, and the closest one to the prior restaurant This list of places comes along with a recommendation value is the one shown in the second map. (Table 1, column RV) according to the interest degree of the 2. The places included in the new plan are marked with green user in the particular place. This value will be used by the location icons as well as the paths between places. We can planning module to obtain a plan that fits the user’s likes. observe that the new plan maintains the visit to Town Hall The tour (plan) for the user calculated by the planner is (now represented with the green icon numbered as 5) and to shown in the left snapshot of Figure 8. The visits included in the Lonja (now indicated with the green icon with number the plan are marked with a red location icon in the snapshot. 6). However, the visit to Central Market has been discarded The tour starts from the origin location of the tourist, i.e., in this new plan. This is likely due to the longer distance the hotel in which the user is staying at (green location icon), to the new restaurant. and includes six visits to monuments (red icons) and one stop at a restaurant (orange icon). The simulation continues. Let us assume that when the The simulator starts the plan execution simulation with tourist is visiting the Town Hall, a new live event announc- the information provided above. Let us assume that at time ing the building closes before the scheduled closing time ((at 1:55 pm, a live event is received, (at 235 (not (free table 140 (not (open town hall)))) is received, the current time el celler del tossal))), indicating that the restaurant cho- being equal to 140 . A new failure is detected in the middle of sen by the planner, el celler del tossal, is completely full the execution of (visit tourist town hall) due to a viola- and has no available table. At the time the live event ar- tion of an overall condition. As we explained in section 4.4, rives, the tourist has already visited the first three monuments the simulator applies a rollback process to obtain the current (1. Viveros garden; 2. Serrano towers; 3. Quart towers), and state before the last visit action but preserving the simulation he is currently at the location of the restaurant el celler del time. Then, in the new reformulated problem, the user is lo- tossal. When the user learns the restaurant is fully booked, the cated at the Town Hall, he has not visited the Town Hall and simulator detects a failure because the action (eat tourist the live event causes the proposition (open town hall) to be el celler del tossal) is not executable. Then, the simula- removed from the initial state. Note that the goal (visited tor reformulates a new planning problem in order to obtain a tourist town hall) will be included as a goal in the new plan that solves the failure: problem to maintain the plan stability but since the Town Hall is no longer open for visits, the planner will not include 1. Initial state: the current location of the tourist is the point this goal in the new plan. The penalties of the goals for this at which the previous plan failed; i.e., the restaurant el third problem are shown in column 3 of Table 1. celler del tossal. Since the new initial state is initialized to The third plan (right snapshot of Figure 8), shown in light time zero (tini = 0), the simulator updates the time of the blue colour, retrieves the visit to the Central market that TILs in the current state, namely, the opening and closing was eliminated from the second plan. The new plan suggests time of places, the time slot for having lunch and the TIL visiting La Lonja (5. la Lonja) and then the Central market (at tavailable (not (active tourist))), where tavailable (6. Central market). Finally, the user returns to the hotel. is set to the new time the tourist must get back to the hotel from tini = 0. Additionally, the fluent (total moving time tourist) is updated with the total time the tourist has 6 CONCLUSIONS AND FURTHER spent in moves around the city. WORK 2. Goals: the places that have already been visited (the first We have presented a context-aware smart tourism simulator three monuments) are removed from the goal list. The new that keeps track of the execution of a tourist agenda. The sim- 21 Figure 8. The three simulated plans. Icons in PLAN1: (0) Caro hotel, (1)Viveros Garden, (2) Serrano towers, (3) Quart towers, (4) El Celler del Tossal (RESTAURANT), (5)Lonja, (6) Central market, (7) Town hall. Icons in PLAN2: 1,2,3 are the same as PLAN1, (4) the Pederniz (RESTAURANT), (5) Town hall, (6)Lonja. Icons in PLAN3: 1,2,3,4 are the same as PLAN2, (5) Lonja, (6) Central market PLACES RV RV’ RV” [5] I. Garcia, L. Sebastia, E. Onaindia, and C. Guzman, ‘E- Cathedral 280 280 280 Tourism: a tourist recommendation and planning applica- Central market 270 600 600 tion’, International Journal on Artificial Intelligence Tools, Lonja 290 600 600 18(5), 717–738, (2009). Serrano towers 250 — — [6] A. Garrido, M. Arangu, and Eva. Onaindia, ‘A constraint City of arts and sciences 280 280 280 programming formulation for planning: from plan scheduling Oceanografic 300 300 300 to plan generation’, Journal of Scheduling, 12(3), 227–256, Bioparc 210 210 210 (2009). Quart towers 200 — — [7] A. Gerevini, P. Haslum, D. Long, A. Saetti, and Y. Dimopou- los, ‘Deterministic planning in the 5th International Plan- Viveros garden 250 — — ning Competition: PDDL3 and experimental evaluation of the Town hall 200 600 600 planners’, Artificial Intelligence, 173(5-6), 619–668, (2009). [8] U. Gretzel, M. Sigala, Z. Xiang, and C. Koo, ‘Smart tourism: Table 1. Recommended places foundations and developments’, Electronic Markets, 25(3), 179–188, (2015). [9] R. Howey, D. Long, and M. Fox, ‘VAL: automatic plan vali- dation, continuous effects and mixed initiative planning using PDDL’, in 16th IEEE ICTAI, pp. 294–301, (2004). ulator periodically updates its internal state with real-world [10] J. Ibañez, L. Sebastia, and E. Onaindia, ‘Planning tourist information and receives sensible environmental changes in agendas for different travel styles’, in ECAI, (2016). the form of live events. Events are processed in the context [11] S. Kambhampati, ‘Mapping and retrieval during plan reuse: A of the plan and in case of failure, a new planning problem is validation structure based approach.’, in AAAI, pp. 170–175, (1990). formulated. This involves creating the new initial state and [12] F. Martı́nez-Santiago, F. J. Ariza-López, A. Montejo-Ráez, updating the time of timed events. In the case of study, we and A. U. López, ‘Geoasis: A knowledge-based geo-referenced have shown how the user can track the plan execution through tourist assistant’, Expert Syst. Appl., 39(14), 11737–11745, a GUI that automatically displays the plan under execution. (2012). [13] I. Mı́nguez, D. Berrueta, and L. Polo, ‘Cruzar: An applica- As for future work, we intend to endow the system with tion of semantic matchmaking to e-tourism’, Cases on Se- a pro-active behaviour, analyzing the incoming of live events mantic Interoperability for Information Systems Integration: that entail a future failure in the plan. Practices and Applications. Information Science Reference, (2009). [14] B. Neuhofer, D. Buhalis, and A. Ladkin, ‘Smart technologies REFERENCES for personalized experiences: a case study in the hospitality domain’, Electronic Markets, 25(3), 243–254, (2015). [1] J. Benton, A. J. Coles, and A.I. Coles, ‘Temporal planning [15] I. Refanidis, C. Emmanouilidis, I. Sakellariou, A. Alexiadis, with preferences and time-dependent continuous costs’, in R.-A. Koutsiamanis, K. Agnantis, A. Tasidou, F. Kokko- ICAPS, (2012). ras, and P. S. Efraimidis, ‘myVisitPlanner gr : Personalized [2] D. Buhalis and A. Amaranggana, ‘Smart tourism destinations Itinerary Planning System for Tourism’, in SETN, pp. 615– enhancing tourism experience through personalisation of ser- 629. Springer, (2014). vices’, in Proc. Int. Confernece on Information and Commu- [16] P. Vansteenwegen, W. Souffriau, G. V. Berghe, and D. V. nication Technologies in Tourism, pp. 553–564, (2013). Oudheusden, ‘The city trip planner: An expert system for [3] S. Edelkamp and J. Hoffmann, ‘PDDL2.2: The language for tourists’, Expert Syst. Appl., 38(6), 6540–6546, (2011). the classical part of the 4th International Planning Competi- tion’, IPC 04, (2004). [4] M. Fox, A. Gerevini, D. Long, and I. Serina, ‘Plan stability: Replanning versus plan repair’, in ICAPS, volume 6, pp. 212– 221, (2006). 22