SCUOLA DI INGEGNERIA INDUSTRIALE E DELL’INFORMAZIONE Laurea Magistrale In Ingegneria Meccanica

Simulation of Healthcare Facilities with Unity game engine

Advisor: Prof. Andrea Matta

Paolo LUZZANA 876387

Academic Year 2017/2018

3

Table of Contents

Sommario ...... 6 Abstract ...... 7 Introduction ...... 9 The clinical-hospital world ...... 11 The use of simulation ...... 11 The different available types of simulation ...... 13 A fourth way: an object-oriented approach ...... 14 Application ...... 15 Components of the model ...... 15 Software implementation ...... 16 Chapter 1: Foundations ...... 17 1.1 The model of the Israel Institute of Technology ...... 18 1.1.1 Space ...... 18 1.1.2 Actors ...... 19 1.1.3 The activities ...... 22 1.1.4 The narratives ...... 22 1.1.5 The scheduler ...... 23 1.2 Navigation System ...... 24 1.2.1 Walkable areas ...... 24 1.2.2 Search for a route ...... 25 1.2.3 Obstacles ...... 26 1.2.4 Local and global navigation ...... 27 1.2.5 Model of the NavMesh Agent ...... 28 1.3 A* Algorithm ...... 31 1.3.1 First iteration: Breadth First Search – BFS ...... 32 1.3.2 Movement costs - Dijkstra's algorithm ...... 34 1.3.3 Heuristic research ...... 36 1.3.4 The A * algorithm ...... 37 1.4 Behaviour Tree ...... 39 1.4.1 Basic concepts ...... 39 1.4.2 Execution ...... 40 1.4.3 Typologies of nodes ...... 42 4 Simulation of Healthcare Facilities with Unity game engine

1.4.4 Data Context ...... 46 1.4.5 Stacks ...... 47 Chapter 2: The Central Scheduler and the Pop-Ups ...... 49 2.1 Central Scheduler ...... 50 2.1.1 Active elements ...... 50 2.1.2 Functionalities ...... 52 2.1.3 Behaviour tree ...... 55 2.2 Pop-Up Elements ...... 57 2.2.1 Advantages ...... 57 2.2.2 Disadvantages and compromises ...... 59 2.3 Chairs ...... 61 2.3.1 Active elements ...... 61 2.3.2 Functionalities ...... 62 2.3.3 Interfacing from outside ...... 64 2.4 Group movement ...... 67 2.4.1 Active elements ...... 67 2.4.2 Functionalities ...... 68 2.5 Single line ...... 73 2.5.1 Active elements ...... 73 2.5.2 Functionalities ...... 74 2.6 Dispenser ...... 79 2.6.1 Active elements ...... 79 2.6.2 Functionalities ...... 80 2.7 Toilets ...... 83 2.7.1 Active elements ...... 83 2.7.2 Functionalities ...... 83 Chapter 3: The Professionals ...... 87 3.1 Triage ...... 88 3.1.1 Active elements ...... 88 3.1.2 Functionalities ...... 89 3.1.3 Behaviour tree ...... 90 3.2 Vitalist ...... 93 3.2.1 Active elements ...... 93 3.2.2 Functionalities ...... 94 5

3.2.3 Behaviour Tree ...... 96 3.3 Ward ...... 100 3.3.1 Active elements ...... 100 3.3.2 Functionalities ...... 102 3.3.3 Behaviour tree ...... 103 Chapter 4: Patient ...... 107 Active elements ...... 108 4.2 Functionalities ...... 111 4.3 Behaviour Tree ...... 114 4.4 Sound Management ...... 120 4.5 Light Management ...... 124 Chapter 5: Application & Outcomes ...... 133 5.1 San Raffaele Hospital – HSR ...... 134 5.1.1 Internship ...... 134 5.1.2 Obtained Data ...... 135 5.1.3 Emergency room blueprint ...... 136 5.1.4 Creation of the physical model ...... 137 5.1.5 Importation ...... 137 5.2 Outcomes...... 142 5.2.1 Ordinary situations ...... 142 5.2.2 Problematic situations ...... 146 Chapter 6: Conclusions ...... 153 6.1 Results ...... 154 6.2 Limitations ...... 155 6.3 Future Developments ...... 156 Appendix ...... 157 References ...... 185 List of Figures ...... 187 Ringraziamenti ...... 191 6 Simulation of Healthcare Facilities with Unity game engine

Sommario

All’interno di questo lavoro di tesi viene affrontata la realizzazione di un modello di simulazione che possa essere applicato a situazioni ad alta densità di persone. Per la realizzazione della simulazione è stato sviluppato un approccio nuovo basato sull’utilizzo di elementi Pop-Up. Queste sono strutture virtuali che racchiudono oggetti, spazi e le funzionalità necessarie ad utilizzarli. Grazie a delle interfacce, gli agenti sono in grado di usufruire di questi oggetti con dinamiche più semplici rispetto ad altre modalità di simulazione perché parte del potere decisionale che dovrebbe essere svolto dagli agenti viene distribuito ai pop-up. Essi possono essere utilizzati per la rappresentazione di comportamenti collaborativi e competitivi tra persone. Il principale vantaggio di una logica a pop-up risiede nella loro semplicità di implementazione e nel conseguente risparmio computazionale.

Il modello realizzato è stato poi applicato alla simulazione della sala d’attesa del pronto soccorso dell’ospedale San Raffaele di Milano. La simulazione è basata sui dati reali di accesso al pronto soccorso da parte dei pazienti, sulla planimetria della struttura e su osservazioni dirette in loco. 7

Abstract

Within this thesis work the realization of a simulation model that can be applied to situations with high density of people is addressed. For the realization of the simulation a new approach based on the use of Pop-Up elements was developed. These are virtual structures that contain objects, spaces and the functionalities necessary to use them. Thanks to interfaces, agents are able to take advantage of these objects with simpler dynamics than other typologies of simulation because a fraction of the decision power that should be carried out by the agents is shared with the Pop-Ups.

Pop-Ups can be used for the representation of collaborative and competitive behaviours between people. The main advantage of a Pop-up logic lies in their simplicity of implementation and consequent computational savings.

The realized model has been then applied to the simulation of the waiting room of the emergency room of the San Raffaele Hospital in Milan. The simulation is based on the real data of access to the emergency room by the patients, the layout of the structure and direct observations during daily operations.

9

Introduction

The problem that we are dealing with by this master thesis work is the design of buildings through the simulation’s techniques. Some examples of buildings of interest are hospitals, airports, stations, museums, cinemas, shops, shopping malls, zoos, runway shows and inaugurations.

These buildings contain people, animals, objects, spaces, furniture and services. They are buildings that envelop large spaces composed by many connected rooms or large open spaces. People inside these buildings can perform different functions and play different roles. These can be collaborative or antagonistic. Sometimes there are hierarchical relationships between them. There are important flows that cross these spaces: people, objects, resources, information, substances. The actions take place simultaneously and therefore the different subjects can compete for space, objects and resources.

The main task of a building is the carrying out of the function for which it is designed. The duration of this function can be from a few hours up to decades. Each specific situation entails different requirements. Generally, the building welcomes a person, a customer, who needs a service or a product. The person goes to the building under examination just to get his need satisfied. Another person, or alternatively an equipment, provides the service or the object of interest to the client. Once the client receives what is wanted or does not find a way to satisfy his need, he leaves the building. When more than one customer needs the same thing or more things in some way connected to each other, then a parallelization of the service or a place to wait for your turn are needed.

Together with the delivery of the main service, all a series of other needs that affect the customer (e.g. a toilet, entertainment, privacy, the possibility of socializing, food and water) must be met. The building must then guarantee certain levels of temperature, ventilation, light, noise and general comfort. 10 Simulation of Healthcare Facilities with Unity game engine

The pillars on which the design is based are laws and regulations, trends and experience of professional in action. It starts from qualitative indications up to go to more detailed and quantitative indications.

Implementing a design that can take into account all the needs and problems in an organic way is something enormously complex. Starting from the same list of requirements equally good and satisfactory alternative projects can be formulated, at least on paper.

The element of greater uncertainty in the design of buildings is surely the man or groups of humans who are the users of the space itself, both as service providers and as consumers. By analysing the complex relationship between man, environment and object, fundamental requirements can be defined on the basis of the following aspects:

• Thermohygrometric wellbeing: intended as thermal neutrality due to the combination of various environmental factors such as relative humidity, radiant heat, speed and temperature of air. • Air quality and absence of risk factors guaranteed by the identification of environmental causes (chemical, physical and biological agents) or causes related to the presence of man (metabolic processes and presence of bacteria). • Acoustic wellbeing, characterized by the absence of emission sources above certain sound intensities for the protection of users and for the benefit of the focus of operators. • Visual wellbeing given by the quality, the nature, and the power of light used and by the correct integration between natural and artificial light. • Psychological wellbeing: it concerns all the elements of different nature that can influence the subjective sensations of the users: the spatial configuration of the elements, the choice of materials, finishes and furnishings, privacy and comfort, the relationship between interior and exterior, the relationship between user, building, service and provider. • Social wellbeing: this is given by the complexity of the services that characterize the building as a whole, from the relationship with the territorial and urban context where the professional, management and environmental aspects intersect. Introduction 11

The clinical-hospital world

Among the large buildings, the hospital is perhaps the most complex and complicated declination. The elements that characterize this particular type of architectural expression are:

• Important dimensions in terms of surface area and cubature. • Presence of very different areas in relation to the function performed and the different professionals involved. • Strong specialization of places and equipment. • Personnel divided into hierarchical roles. • Strong differences in the composition of users in terms of age, movement capacity, social and ethnic affiliation, social skills. • Unique fragility of users from a physical and psychological point of view. • Need to provide ancillary services for the sustenance of people within the structure for all the duration of the year. • Danger due to the presence of pathologies and people in continuous movement within the structure. • Extensive economic expense both as an initial investment of the start-up but also as a continuous operating cost of personnel, equipment, consumables and maintenance of the building itself. The wide spectrum of problems related to the design of a hospital or part of it represents an important and substantial challenge. A gain of perspective, even if small, could represent an effective gain in economic terms, human satisfaction and integration with the existing society.

The use of simulation

The building intended as construction is something predominantly static but the activities that take place inside it are tipically dynamic. The common practice leads to the use of common sense and average values recorded in specific situations and difficult to replicate or otherwise generalizable. The extreme diversity of roles and individualities involved leads to an extremely dynamic social situations that need the simulation to be understood, synthesized and then exploited to predict the use of an environment. The interactions 12 Simulation of Healthcare Facilities with Unity game engine

between people concern both predicted events and unthinkable situations with slight or potentially fatal consequences that give rise to emergencies and events of rare probability.

Thanks to BIM (Building Information Modeling), information is available to analyze a certain configuration in terms of acoustic performance, energy efficiency, ability to exploit sunlight and other physical aspects of the building. Despite the great advances from this point of view, less has been done regarding the understanding and synthesis of how people use buildings.

Simulating how people use buildings is something challenging for several reasons:

1. People are complex entities that are difficult to model in their intricacy and fullness. 2. The environment in which people work continuously changes in ways that are often unpredictable. 3. Information contained in BIMs and databases is rarely used to model how people move in space. 4. People do not always behave as individuals but can behave like a group.

The desire to use the simulation arises from the need to verify and virtually recreate a series of situations of interaction between people who then condition their well-being and the state of the environment in which they are located. The presence of minimum norm values (such as door width, average illumination, air temperature) cannot and should not be sufficient as input for the definition of an environment. The use of the simulation allows then to consider stochastic and not only deterministic timing, objects which works far from the nominal value designed for them.

The simulation allows to test the functioning of a building, or part of its operations, evaluating different configurations and parameters. Being the simulation performed by computer the process of selection and creation of configurations can be possibly automated. This allows to explore a wide range of solutions by removing part of the burden from the designer's work. Introduction 13

The different available types of simulation

DES - Discrete Event Simulation

This type of simulation uses the concepts of entities, servers, resources, buffers. The Des can be used as a preliminary sizing but it does not allow to model the spatial dimension that would be reduced to a consumable resource or a slot inside a queue. The definition of interactions between entities would be extremely complex and limited to extremely simple conditional loops.

Agent Based Simulation

Agent simulation is based around the definition of autonomous agents equipped with a system of behavior and relationship with the environment around them. This allows to gather important information and analyze in depth the consequences of the different actions. However, there is a strong limitation due to the fact that decision-making power resides within the individual actors. This implies that there is a limit relatively close to the complexity of behavior that can be represented by this simulation. It is then extremely difficult to implement group behaviors (collaborative or antagonist).

Narratives

The narratives’ approach was developed by Israeli researchers at the Technion Institute of Technology. It is a hybrid approach that seeks to exploit the advantages of DES (Discrete Event Simulation) and those of ABS (Agent Based Simulation). The actions performed by the agents are included in particular simulation elements called "narratives". Narratives contain a list of people, actions, places and resources and are characterized by a value of priority that varies over time. A specific component of the simulation, the Central Scheduler, is responsible for continuously evaluating the order of development of the narratives, on the basis of the priority value. According to the researchers this approach ensures greater efficiency in carrying out collaborative, complex and intertwined actions. The narrative’s approach represents the starting point of this thesis work and will be analysed in the chapter reserved to the state of the art. 14 Simulation of Healthcare Facilities with Unity game engine

A fourth way: an object-oriented approach

The simulation approach created by the Technion researchers is certainly an excellent starting point for the realization of human-intensive simulations. Thanks to the published articles, they present an important framework on which to structure the various elements of the simulation. The use of the narratives seems to be the turning point in order to realize a complete simulation that is at the same time sustainable from the computational point of view. They allow to create many packages that, once "mixed" within a single simulation, should allow to easily obtain the results despite the large amount of staff, spaces and resources involved.

In the practice of wanting to realize a real simulation, and therefore not only the description of a theoretical approach, I clashed with the difficulty of actually implementing a functioning system based on narratives. This difficulty arises from the fact that we need to assign a priority value so that the simulation can autonomously give rise to a chain of events that we normally expect in reality. It is therefore necessary to intervene at the central scheduler level by implementing complex logics of evaluation of the narratives and ordering of the same. This however leads to the loss of easy scalability of the model when we find ourselves making changes or assigning it to another phenomenon to be investigated.

From these difficulties with the narratives’ methodology I decided to develop my own approach. My idea is based on the innovations of the Technion’s researchers but wants to create a simpler model of instruction and reading.

I decided to use a set of procedural instructions embedded within the agents themselves. We won’t have a complex Central Scheduler that has to command the single agents but the agents will possess a predetermined series of actions to be performed within the environment. In this way, the Central Scheduler is unloaded of the "decision-making power", simplifying it. There is therefore the risk of moving the problem on agents, thus approaching a pure agent approach which, however, has difficulties in managing the reproduction of complicated situations. This need pushed me to shift some of the decisional power towards the objects themselves. Introduction 15

In this way the active elements present in the simulation are increased but their respective complexity decreases. The Pop-up elements are born, particular structures that enclose within the objects the functions necessary to use them and the interfaces necessary for the actors to request particular services to the objects. The Pop-Ups are manifestations of objects in object-oriented programming.

Application

The desire to create a real simulation system and to apply it to a real situation made me choose the study of some of the processes involved in the management of the emergency room, particularly the waiting room. The motivations fall primarily on following the choice of Technion researchers in order to work on the same type of problem even if their approach is not explicitly applied to the emergency room but more generally to the hospital environment. Other reasons are the complexity of the situations involved with this large environment, a large number of people passing through and a differentiation of the roles of the employees.

The reproduced processes concern the treatment of patients who transit inside the emergency room, from the entrance to the exit. Given the extreme complexity of the processes, only some of the them have been reproduced. Essentially, in my model, each patient will pass through the acceptance / triage phase in which the degree of emergency of the situation is defined, subsequently through the phase of collecting vital signs and finally inside the specific examination room for the treatment of the specific complication. During their transit, patients find themselves having to deal with resources that are not always available and therefore will have to face waiting phases during their stay. Another considered element is the distances and movements made by patients to reach the different treatment areas.

Components of the model

The resulting simulation is based around four fundamental elements. Although these elements are actually used for this type of analysis, they must be considered as blocks that can be extended to other situations, even different from the emergency room, thanks to the simplicity of use they are characterized by. The four fundamental elements are: 16 Simulation of Healthcare Facilities with Unity game engine

• Central scheduler. • Pop-Up. • Professionals. • Patient. The realization of each of these components is described in the core chapters of this work. The central scheduler will be responsible for gathering patient and resource information during the simulation. Pop-up elements are used for queue management, using single lines and chairs, resources for patients such as toilets and dispensers. They are also used to manage collaborative actions between agents like group movements. The professionals mime the staff of the emergency room that deals with the triage, the vital parameters and the actual visit. The patient represents the subject of interest on which the environment layout is to be evaluated.

Software implementation

For the effective realization of the simulation it was decided to use the Unity 3D development environment. This is a software for creating video games and more generally virtual applications that take place in three-dimensional environments. The great advantage of Unity lies in its gratuitousness for research projects and for the great diffusion within commercial and academic environments. The compatibility with external 3D models and the presence of integrated components for the management of actors’ movement and light have made the choice fall on this software. 17

Chapter 1

Foundations

Within this chapter the theoretical and technical foundations of this thesis work are examined in depth. In the first section the model dictated by Technion researchers is analysed in detail. It formed an important basis on which the thesis work was built. In the following sections are instead described the methodologies and technologies foundation of my simulation: the Navigation System, A * algorithm for the pathfinding and the Behaviour Tree. They represent the distinctive point of Unity 3D technology that allowed the realization of a complete simulation in a three-dimensional environment. 18 Simulation of Healthcare Facilities with Unity game engine

1.1 The model of the Israel Institute of Technology

Technion researchers have formalized an approach that aims to create simulation systems that can solve some of the limitations typical of other ways of simulating. This would allow to deal with complex problems such as effective simulation and sizing of hospitals.

The innovative core concept of the whole work is the narratives, a set of activities, able to shift part of the decisional power and intelligence from the single actors to a higher level system. This can reduce the computational burden and thus allow to use the resources for a more in-depth analysis of the environment and of the relationships of collaboration between the different actors. This section is based on references [1], [2], [3], [4], [5], [6], [7], [8] and [9]

1.1.1 Space

Space is intended as the internal layout of the building, the subdivision into rooms of different sizes and types placed in various positions. The space contains furniture and interfaces such as windows and doors. Then we find lights, air vents, emergency sensors. It therefore contains everything that can be used by users and allows to take advantage of the features of different environments. Every single space is characterized by parameters divided into two groups: static attributes and dynamic attributes.

The static attributes remain fixed during the simulation but still condition the dynamics of people and objects:

• Name: it can be the real name that distinguishes the space in reality or an identification code. • Type: it indicates the main role by which it can be identified by customers / users. • Feasible actions: all the actions that can be carried out in the place. This does not imply that these actions can be carried out by anyone within the space (role compatibility) and that they can be carried out at any time (some conditions must be satisfied as well as the availability of resources, objects and personnel).

Dynamic attributes, on the other hand, vary continuously during the simulation. These can be updated more or less frequently depending on the instantaneous need for Foundations 19

information and the calculation cost required. The variations of the parameters can be preset (a store has an opening time) or will be caused by conditions that occur inside the space itself or outside of it (a fire outside the building implies closing the space itself).

The dynamic attributes are:

• Current use: state in which the space is (open, closed, emergency, exit only, ...). • List of people: individuals currently present on the surface of the space and list of people authorized to be present there. • Equipment: a list of the objects and resources available and not available but which should however be here if they were not used elsewhere. • Density: information on space crowding. It can be singular, a single value for the whole space, or it can be a distribution that more or less finely characterizes the different zones that make up the space. • Temperature: average value or value recorded near virtual sensors. These virtual sensors can replicate any real thermometers in real space or be fictitious but useful during the design of the space. • Light: lighting value due to the sum of solar contribution and artificial light. Useful information can be found if we consider the shadows caused by the movements inside the spaces. Connected to light there are shadows that also depend on the particular arrangement of objects during time. • Smell: complex implementation that can be simplified considering the cleaning levels of different users, presence of food and proximity to possible sources of smell (services, baskets) or perfume (dispensers and flowers). • Noise: it is possible to characterize the attribute by means of a single synthetic value or virtual sensors (replicating or not any real microphones) to detect noises and warning sounds useful to users. Noises can originate from people (talking, moving, walking) or from objects (vending machines, doors and slamming windows, loudspeakers).

1.1.2 Actors

The actors are the people who occupy the space at a given time. Depending on their role they can belong to this space or temporarily cross it to see their own needs fulfilled. 20 Simulation of Healthcare Facilities with Unity game engine

Compared to an agent based simulation, in this way of simulating the person has a limited cognitive ability. Actors are in fact commanded by the narratives that instruct them about which activities to perform and where to do them. These actors are thus seen as a sort of walking sensors and triggers that are activated if instructed by the narrative or in relation to certain values found in the environment.

As for the environment, actors also have two categories of attributes: static and dynamic.

Static attributes remain constant during the simulation. They are:

• Name: identifier intended as the proper name of the person or identifier useful for identification in the environment. • Type: it defines the belonging to an environment. In the case of hospitals, the type distinguishes the staff working in the hospital from outside, patients or their visitors. • Role: it clarifies the position within the hierarchy of the type of membership. So in the case of hospital staff it makes explicit if it is a nurse, a doctor, administrative staff and so on. In the case of outsiders, it defines whether it is a patient, a relative, a friend or a worker from a third-party company that provides services to the hospital. • Age: the actor's age is useful because it distinguishes his behaviour in facing certain situations that occur. A child in a waiting area may cry or play, or otherwise move continuously unlike an elderly person who will generally have lower tolerance values than a young person in terms of noise, air currents, visibility. • Gender: people of different genders tend to have different tastes regarding food, drinks, magazines. They may attend different departments within the hospital. Other differences concern more prosaic things like the toilets and the time needed. • Experience: defines the degree of knowledge of the job performed. In the case of personnel, it will be possible to carry out tasks more quickly and to be able to support emergencies or simple accidents with greater safety. In the case of externals, it will allow them a faster identification of the access routes and the available services. Foundations 21

• Thresholds: show the values tolerated by the individual actors under certain conditions. Despite the fixed value during the simulation these thresholds push to different behaviours in different conditions and therefore have a strong influence on the dynamics of the simulation. Examples of thresholds are:

o Density of people. o Noise. o Smell. • Politeness: parameter that influences the behaviour of the actor in the proximity of other actors who want to use the same service or who are in difficulty in a particular situation close to the considered actor.

The dynamic attributes can vary during the simulation. They are:

• Stress: it indicates the state of nervous solicitation. It starts from an initial value typical of the involved person and then evolves during the simulation depending on the situations that occur and also on the personality of the actor himself. • Tiredness: this value varies depending on the movements and on the basis of the conditions of heat and humidity characterizing the space. The extent of the variation is conditioned by other parameters such as stress and age. • Knowledge: degree of knowledge of the environment. A greater degree of knowledge will ensure greater accuracy in actions. The actor will also require a smaller number of interactions and a shorter duration of the same because he already has information on where to go and which are the most efficient ways. • Social relations: as the actor acts in the environment, he increases his level of belonging with the people present there. This regards the staff but also the other patients. This will change group behaviours and actions related to them. • Travelled distance: synthetic value continuously updated of the distance travelled during movement from one location to another. • Physiological need: in the case of long waits there will be the need to go to the toilet to meet physiological needs. This changes according to the type of subject, differentiating an elderly person, an adult, a child. 22 Simulation of Healthcare Facilities with Unity game engine

These two large families of attributes are inserted into 5 blocks that manage the behaviour of the actors:

1. Characteristics: static attributes that distinguish the actor. 2. Preferences: set of preferred wills in specific situations. 3. Status: role assumed within a temporary situation. 4. Knowledge: set of information collected and manipulated based on accumulated experience. 5. Skills: possibility of exploiting or not the situations in which the actor is participating. Characteristics and preferences collect static attributes while state, knowledge and skills start from an initial condition and then evolve during the simulation.

1.1.3 The activities

The activities represent the basic actions performed by the actors. They are the bricks that will then be used by the narratives. Some activities require an object. Often an actor must simultaneously perform several actions such as walking, carrying a document or following a person who precedes him. The possibility and needs to carry out actions at the same time is managed by the narratives so as not to insert an overly complex network of conditions to be verified by the single actor.

1.1.4 The narratives

Narratives are the heart of the model created by Technion’s researchers. They are sequences of activities, basically events. They concern one or more people and may need objects, resources and conditions to make them feasible. The primary objective of the narratives is to ensure that the tasks are carried out by the involved actors in an efficient way for the simulator. Here lies the artificial intelligence that manages behaviours. The choices made by the actors in conjunction with certain conditions are carried out by the actors but they are actually decided by the narratives. If we imagine a situation that involves five people who must cooperate, with the need to collect resources, information and objects, it is extremely complex to implement a logic of behavior within the individual actors so that they can really cooperate in the situation. To simplify the whole Foundations 23

thing the narrative will send commands to make the cooperation appear real if observed from the outside.

Narratives are conditioned by parameters and conditions. On the basis of the values of these, a narrative may be unable to take place at a certain moment but can then be released later.

In the moment in which a narrative is feasible in a specific time it can be associated with a priority, that is a value that specifies the urgency and the relative importance with respect to the other feasible narratives at that time. The competition of narratives is tipically about people, places or resources. Establishing priority is an incredibly important step in the operation of the whole model because it will guarantee the truthfulness and consistency of the simulation.

1.1.5 The scheduler

The scheduler is the component that practically deals with programming the order of the narratives based on the priority values and also manages the clashes due to identical values of priority.

The action of the scheduler is organized around three phases. The first one sees the list of all the feasible narratives in a given moment. The second phase is concerned with giving priority to the narratives that are actually performable, trying to enter the extreme detail of the evaluation only when there are value overlaps. The last phase sees the selection of a narrative or non-competitive narratives that can be simultaneously run.

During the simulation the scheduler must continually keep track of the working narratives in order to check that the feasibility conditions are still valid and operating. The resources necessary for a narrative to work are not fixed and therefore even if a narrative is not finished it could make available something that is a requirement for another narrative that then becomes feasible. 24 Simulation of Healthcare Facilities with Unity game engine

1.2 Navigation System

The modelling of real people leads to the creation of the concept of agent in the framework of Artificial Intelligence (AI). The movement of agents within the environment involves two objectives / problems that are closely linked but built on two different points of view:

• Search for the suitable route. Finding which path allows the agent to reach the goal in a plausible manner. “Plausible” understood as the best, shortest route: it is assumed that a real person chooses the path that minimizes fatigue (crossing time). This route is calculated only once per destination. • Reaching the destination. Defining how the agent must move in every frame. It takes into account the instantaneous direction of movement to reach the destination without colliding with obstacles and other moving agents. It has a local and dynamic character. This section is based on references [13] and [14].

1.2.1 Walkable areas

The walkable areas are the portions of the environment actually practicable by the agent. The navigation system takes into consideration the physical model of the building and associates it with new information necessary for the movement of the agents. The walkable area appears as a level perfectly overlapped with the floor but reduced because it considers only the surface where the agent can actually stand and move. The agents are modeled as cylinders. The limiting algorithm of the surface tests where the cylindrical agent can stand. The surface that unites all the acceptable locations is called Navigation Mesh (or NavMesh). The Mesh consists of convex polygons adjacent to each other. Convex polygons are chosen because they are easier to define than concave ones and because they guarantee that by connecting two points of the single polygon to each other, no point is found outside the polygon itself. Foundations 25

Figure 1: Main components of the Navigation System

1.2.2 Search for a route

In order to define a route that allows the agent to reach the prefixed destination, it is first of all necessary to bring the departure and the arrival of the path back to the respective polygons. The chosen pathfinding algorithm finds a way to connect the starting polygon with that associated with the arrival. The A* algorithm is used to find the path.

Figure 2: Two alternative corridors for the destination

The set of polygons containing the chosen path is called Corridor. The agent reaches the destination by steering towards the next visible corner of the corridor, repeatedly until he reaches the destination. 26 Simulation of Healthcare Facilities with Unity game engine

Figure 3: Approaching the visible corner

1.2.3 Obstacles

In an unobstructed situation, the "steering logic" considers the position of the next corner to define the direction and speed necessary to reach it. “Steering logic” means the procedure implemented by the agent to connect straight sections of the route between them. This procedure is however based on the static analysis of an empty environment, where there is only one agent at a time, without moving objects. When several agents are present on the mesh, the steering system has to face unexpected obstacles. Thus, the need to define an obstacle avoidance logic arises. Obstacle avoidance is the logic followed by the agent that allows him to avoid obstacles. The movement logic must therefore calculate a new direction-speed couple that balances on one side the need to move towards the destination and on the other the need to avoid collisions. The RVO method, "Reciprocal Velocity Obstacles”, allows to predict the position of moving objects or agents in time and then recreate a realistic interaction situation. By carrying out both the steering and the obstacle avoidance phases, we arrive at the definition of a definitive speed that must be imposed on the agent, taking into account acceleration, steering radius and braking distance.

Figure 4: Obstacle avoidance by RVO method Foundations 27

1.2.4 Local and global navigation

Figure 5: Outline of the Navigation procedure

Separating global and local navigation allows to produce a simulation that can be efficiently managed by the computer. Global navigation finds the corridor that connects departure and destination, analysing the mesh in its entirety. This operation is performed only once per destination and is relatively expensive in terms of power and memory. The result is a first list of polygons that should ideally be visited. Local navigation considers the list as a dynamically updatable structure. In this way we can implement the logic of obstacles avoidance without considering the map as a whole: it would be unsustainable to recalculate the global corridor at high frequency. Only polygons adjacent to those that were already part of the global list are taken into consideration.

During the simulation there can be situations in which large obstacles are positioned on the mesh, covering totally or largely the corridor. Given the exceptional nature of these situations we can evaluate the use of global pathfinding as an alternative to local obstacles avoidance. In the case of relatively large obstacles, in fact, local navigation has the limit of considering only immediately successive obstacles without considering the overview. The result is a movement that could even overcome the obstacle but which would generate an unlikely situation where the agent runs through the perimeter of the obstacle. If the obstacle actually occupies the whole section of the corridor, an infinite loop could be generated where the agent stagnates in a portion of the environment. 28 Simulation of Healthcare Facilities with Unity game engine

Instead, by using global navigation, a process called "carving" is created, which creates holes inside the mesh where the obstacle intersects the mesh itself. At this point the global navigation will perform a recalculation of the route taking as start the current position and as arrival the original destination. This operation is very expensive but allows avoiding these extremely rare but potentially catastrophic situations.

Figure 6: Carving procedure by Global Navigation

1.2.5 Model of the NavMesh Agent

Each agent is associated with an internal movement model that effectively allows the agent to travel the NavMesh associated with the physical environment. This internal model has to take into account the inputs coming from the search for the optimal path and the obstacle avoidance system, continuously generating speed and acceleration values.

The characteristic parameters are:

• Speed: maximum speed reachable by the agent. • Angular speed: maximum value of the angular velocity when making a curve or a steering. • Acceleration: value necessary to make the transition from a standoff to a movement situation natural. Foundations 29

• Stopping distance: quantification of the distance along which the deceleration phase must extend. The necessary deceleration that cancels the speed at the destination will be accordingly calculated. • Radius: synthetic parameter of the agent's "personal space"; the horizontal dimension used in obstacle avoidance. • Height: dimension used to avoid collisions with possible obstacles in the direction perpendicular to the motion. • Priority: the lower the value, the greater the importance of the agent in question, which will consequently enjoy precedence in the movement with respect to agents of lower priority. • AutoRepath: option that allows the agent to request a new path to reach the goal when the original one is no longer practicable. It can sometimes happen that the destination itself is no longer reachable and therefore the agent can request a new route that allows him to reach the place nearest to the original destination.

The listed parameters characterize the person category but may have different values from agent to agent. As a consequence, the values can be adapted to the type of patient under examination to give a more realistic representation of the patient mix. For example, an elderly person will move slower than a young person, will have lower acceleration values and will probably occupy more space (larger radius) due to the use of walking aids such as walking sticks or walkers. Given its delicacy, he could be associated with a higher priority (lower priority parameter) so that other agents have to avoid him.

The previous parameters are called NavMesh Agent Properties and, as already mentioned, define each individual person. At the same time there are NavMesh Bake Settings which are unique values that are used by the navigation mesh construction system for the definition of walkable areas. This new pair of values, radius and height, is unique to limit the number of calculations made by the system: alternatively, a number of navigation meshes equal to the number of agents should be calculated and this would represent an unsustainable calculation burden. Naturally, it will be necessary to make the right choice of "settings" parameters in such a way that it is compatible with the properties values of the agents moving on the mesh. 30 Simulation of Healthcare Facilities with Unity game engine

Figure 7: NavMesh Agent Properties

Figure 8: NavMesh Bake Settings Foundations 31

1.3 A* Algorithm

A* is a pathfinding algorithm. It is the most used pathfinding algorithm. In the case of an obstacle with a complex shape, or even with a concave shape, the A * offers a considerable advantage because it scans the entire area and then immediately provides an optimal path. A motion algorithm (MA), on the other hand, finds the obstacle only when it comes into conflict because it does not implement an early planning but calculates the route frames per frame. The advantage of A * is the prediction of critical situations. It is however slow and less useful when the arrangement of obstacles changes continuously. The motion algorithm is faster and less energivorous because it performs the calculations only when it has to and is able to adapt quickly to situations of extreme dynamism. The ideal would be to use both approaches, A * for an overview and long distances, MA for short journeys in local areas at great rates of change.

In the information technology field, pathfinding algorithms are tools for finding paths that minimize the total travelled distance or an overall cost measure. These algorithms can also be used to find the sequence of events and actions that maximize a profit function. Pathfinding algorithms tend to use graphs, structures that can be graphically represented by edges and nodes. Graphs can be used to model and study physical locations and particularly to find optimal and realistic paths for agents moving in the space. The surfaces that constitute the floor of the environment are divided into tiles that are seen by the algorithm as adjacent nodes connected to each other with edges.

Figure 9: Virtual floor divided into edges and nodes 32 Simulation of Healthcare Facilities with Unity game engine

Unlike other graph types, maps are 2D grids that can show information about distances, directions, and symmetries. This information, if properly exploited within the pathfinding activity, represents a computational advantage.

The input of the pathfinding algorithms is represented by the graphs, understood as the set of the locations (the nodes or vertices) and the mutual connections (the edges). The output consists of a subset of the graph consisting of the nodes and the respective edges that connect the starting point (origin) with the destination (goal).

There are many algorithms for finding paths. The main ones are:

Breadth First Search. Basic algorithm, foundation of all the other algorithms. It explores equally the space in all the directions.

Dijkstra's Algorithm. Also called "Uniform Cost Search". It explores the space giving priority to routes that minimize the cost of crossing. It search for routes for all possible locations.

A * Algorithm. It optimizes the search for a particular arrival point. Compromise between efficiency (calculations made) and effectiveness (optimal solution obtained).

This section is based on references [11] and [12]. All the figures within this Section 1.3 are taken form this two references.

1.3.1 First iteration: Breadth First Search – BFS

This algorithm consists of an expansion loop called “frontier” that evolves from the start up to progressively exploring the whole map. Each node of the frontier is progressively replaced by its adjacent points not yet been visited. Each point added to the border is progressively numbered. Foundations 33

Figure 10: Progressive numbering of the frontier

Later the algorithm adds further information to each tile: an arrow indicating from where the tile has been reached. Once defined the destination, the algorithm retraces from the destination to the start, following the directions of the arrows.

Figure 11: Retracing from destination to start

The concept of "early exit" allows to calculate the extension of the border until the destination has been reached, without going further, thus saving useless calculations. 34 Simulation of Healthcare Facilities with Unity game engine

Figure 12: Saving in calculations thanks to early exit strategy

1.3.2 Movement costs - Dijkstra's algorithm

For a more complete characterization of the simulation environment, zones with different crossing costs can be defined. Some areas can be more difficult to travel or in any case less likely to be chosen by users (stairs versus escalators, passage to the outside to reach another building or to travel a longer but covered road). By linking a different cost to each tile, the algorithm must take into account a new variable to evaluate a path. To reach a location there is therefore a differentiation between the number of steps touched and total cost spent (simply called Distance). By “number of steps” we mean the number of tiles touched, regardless of the cost necessary to cross them. In Figure [13] the green areas are characterized by a crossing cost equal to 5 units while the grey areas have a cost of 1 unit. Foundations 35

Figure 13: Progress quantification with steps (left) and distance (right)

Dijkstra's algorithm extends Breadth First Search by adding the cost component. It is also called Uniform Cost Search because it makes a comparison between routes that have the same total cost of crossing. Each point can however be reached with different paths and therefore it will be necessary to select among the routes the one that guarantees the lowest cost of achievement. Points that belong to the border are placed in a priority list instead of a FIFO queue as in the Breadth First Search. The numbering will evolve from the higher priority points, i.e. those at lower cost.

In Figure [14] we can see how Dijkstra's algorithm tends to avoid crossing the higher cost area (in green). The blue tiles represent the nodes that constitute the frontier at that moment.

Figure 14: Frontier propagation by BFS (left) and Dijkstra (right) 36 Simulation of Healthcare Facilities with Unity game engine

1.3.3 Heuristic research

Breadth First Search and Dijkstra’s algorithms expand the frontier in all the directions. This is great if you really want to evaluate all directions or anyway to analyse a large number of destinations. However, if you want to study a single location, then it becomes evident that a large number of calculations are carried out without any need. As a matter of fact, these algorithms use only the distance actually travelled from the origin to reach the addressed intermediate point.

We introduce an estimator, sometimes defined “heuristic”, to obtain an evaluation of the remaining distance to be covered. A new algorithm, Greedy Best First Search (GBFS) uses only the distance remaining from the target without considering the distance travelled up to that point.

Figure 15: Comparison between BFS (left) and GBFS (right) in exploration without obstacles

In Figure [15] it is clear how, with the same number of iterations, the GBFS approaches the destination much earlier than the Breadth First Search. However, critical issues arise when the map becomes more complex, for example with the presence of obstacles. In fact, the GBFS loses its advantage over BFS. Foundations 37

Figure 16: Comparison between BFS (left) and GBFS (right) in exploration with obstacles

1.3.4 The A * algorithm

Dijkstra's algorithm works well in terms of effectiveness because it is able to find the best, shortest route. However, it is not very efficient because it explores all areas of the map. The Greedy Best First Search instead is efficient because it explores only the most promising paths but does not guarantee to find the best solution.

The A * algorithm is born with the intent to join the advantages of both trying to eliminate the disadvantages. A* uses both the actual distance travelled up to that moment and the estimated distance to reach the destination. A * is as efficient as a GBFS in simple situations and effective such as the Dijkstra’s in complex ones, while sparing iterations.

Figure 17: A* seen as composition of Dijkstra wiht GBFS

The cost function used by A * appears in the form: 38 Simulation of Healthcare Facilities with Unity game engine

( ) = ( ) + ( )

Where: 𝑓𝑓 𝑛𝑛 𝑔𝑔 𝑛𝑛 ℎ� 𝑛𝑛

• ( ) is the cost to reach the current node from the starting point. It is a true cost

𝑔𝑔because𝑛𝑛 it is actually spent to reach the node. • ( ) is the cost to reach the destination. It is an estimate and depends on the choice

ℎwithin� 𝑛𝑛 the specific implementation of the A * algorithm. A * therefore appears as a family of algorithms that differ according to the ( ) chosen

function. Hart, Nilsson and Raphael [10], the authors of the original algorithm,ℎ� 𝑛𝑛 define an acceptance interval for the estimator ( ):

ℎ� 𝑛𝑛 0 ( ) + 2 2 � If ( ) 0 then ≤ ℎ because𝑛𝑛 ≤ � ∆no𝑥𝑥 account∆𝑦𝑦 of the remaining distance is ∗ taken.ℎ� 𝑛𝑛 If →( ) 𝐴𝐴 →+𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 then′ 𝑠𝑠 because the remaining distance assumes 2 2 ∗ the maximumℎ� 𝑛𝑛 →contribution.�∆𝑥𝑥 ∆ 𝑦𝑦 𝐴𝐴 → 𝐺𝐺𝐺𝐺𝐺𝐺𝐺𝐺

The A * algorithm is the most widespread algorithm in the pathfinding because it works well in a range of different situations. However, in more specific situations other algorithms could be chosen.

To search for multiple destinations, it is suggested to use the Breadth First Search in the presence of a single cost or the Dijsktra’s in areas with different costs. To search for a single destination, better using the GBFS or A * if the map is complex.

As for the certainty of finding the optimal path, the Breadth First Search and the Dijkstra’s guarantee to find the shortest route. Greed Best First Search and A *, on the other hand, do not offer this security.

The A* algorithm, despite showing excellent performance, does not eliminate all the limitations that afflict the pathfinding algorithms: no consideration of cooperative movements, evaluation of moving objects or taking charge of the radii of curvature (set of fragmented lines).

The use of the ( ) estimator involves extra calculations. It is necessary to evaluate if

these calculationsℎ� 𝑛𝑛are balanced by the saving of steps in the search for the optimal path. Foundations 39

1.4 Behaviour Tree

The Behaviour Tree, henceforth summarized with "BT", is a formal language of graphic modelling used in computer science, systems engineering, robotics and in the videogame industry. It allows an unambiguous and well-defined description of a system and of the articulation of an execution plan. At the base it consists of simple tasks that are combined in order to represent complex chains. There are strong parallels with state machines where, however, states are replaced by tasks.

It was initially developed in the videogame field for the control of agents not played by the user. The BT allows the control of the decision making flow of an agent equipped with artificial intelligence (AI). Given the power and scalability it is capable of, the BT has been extended to other applications such as multi-mission control framework for UAVs, robotic manipulation and multi-robot systems.

This Section 1.4 is based on references [15] and [16].

1.4.1 Basic concepts

The BT graphically appears as an oriented tree whose nodes can be:

• Root nodes. • Control Flow nodes: composite and decorator. • Task or Leaf nodes.

The task nodes are the actual commands that control the AI and allow it to express itself while the control flow nodes are structures that influence the behaviour, and therefore the choice, of task nodes depending on the particular situation in play. The role of control flow nodes is similar to the function performed by loops in a normal programming language (if, while and for). 40 Simulation of Healthcare Facilities with Unity game engine

Figure 18: Example of a Behaviour tree

Given any pair of nodes and the arrow that joins them, the node from which the arrow starts is called Parent while the node to which the arrow arrives is called Child. The Root node has no parent and has only one child; the Control Flow node has a parent and at least one child; the execution node has one parent and no children.

The hierarchy of nodes is graphically expressed. In descending order of importance and in progressive order of execution the nodes are arranged from top to bottom and from left to right. The resulting trees are often very deep with nodes that call whole sub-trees. The development is however modular and iterable, being able to start from basic "self- sufficient" behaviours that can be combined to describe more complex situations.

1.4.2 Execution

The execution of the BT starts from the root node which, once activated, sends an activation signal called "tick" to its only child node. The frequency with which the ticks are released depends on the specific implementation but they are usually synchronized with the graphic engine’s frames. During the execution of the BT, the ticks propagates within the tree passing from the parents to the children.

Once asked, the child returns a message about his status:

• Ready: the node has not been activated yet but can be if it is fired by its parent. Foundations 41

• Running: the execution of the specific task has not yet finished. • Success: the goal has been achieved. • Failure: the child has failed the goal.

If the node is still in a running state then its execution will be continued for at least one other tick and this allows the expression of actions that have a certain duration of time. A "walk" node, for example, will require several ticks to calculate the path to follow and other ticks to follow the path itself; if the action is successful then the node will eventually return a success status while if the path is interrupted or even the route cannot be calculated, then a state of failure will be returned.

The status obtained by the child then propagates in reverse order with respect to the representation of the tree, i.e. from the bottom to the top. The status of a child propagates depending on the specific model of the parent node. The flow of the tree is thus determined. The execution of a particular path of the BT gives the resulting behaviour of the AI.

It is important to underline that the failure status does not represent an error but only a negative evaluation which then pushes the structure to look for an alternative way of execution.

Figure 19: Arrangement of the different types of nodes

42 Simulation of Healthcare Facilities with Unity game engine

1.4.3 Typologies of nodes

1.4.3.1 Composite

The composite type node can have one or more children and, depending on its version, can execute them one at a time or all together. The execution order can be pre-established, based on the writing order of the children, or follow a random sequence. The success or failure of the composite node depends on a particular combination of the children status.

1.4.3.1.1 Sequences

Sequences are the simplest form of composite. In fact, a sequence visits the children according to the pre-established writing order, from left to right. It is successful if all the children succeed and fail at the first child who fails.

The simplest use is to emulate a sequence of tasks that must be performed in its entirety or a sequence that loses its meaning when even one child task fails.

Figure 20: Example of a sequence composed by actions There are also more complex applications such as lists of conditions followed by a final action so that all conditions must be met before actual actions are carried out. The resulting function is "conditional checking" with a behaviour similar to a nested IF chain or an AND logic gate. Foundations 43

Figure 21: Example of a conditional checking sequence

1.4.3.1.2 Selector or Fallback

The selector node visits the children in the order in which they are written, from left to right or from top to bottom. It succeeds at his first successful son and it fails if all his children fail.

The great power lies in the possibility of representing the different alternative ways in which a task can be performed. The different possibilities are sorted according to preference or priority. Only one of the alternatives will be carried out and you will always get the best one among the available ones, the one written as soon as possible. The selector allows to emulate an OR logic gate.

Figure 22: Example of a selector node used for alternative ways to perform an action 44 Simulation of Healthcare Facilities with Unity game engine

The example in Figure [22] represents the interaction of a person with a door. The preferred action would be to simply open the door. When this road is not viable then the AI will attempt to unlock the door and then open it. Only as a last way, the least desired or plausible, the user will break through the door. The structure is streamlined compared to a classic conditional control because the prioritization is implicitly expressed by the writing order.

1.4.3.1.3 Parallel

The parallel node performs all its own children at the same time. It reacts to the status of the children in the same way as the sequence: it is successful if all the children are successful and fail at the first child who fails.

1.4.3.1.4 Race

Like the parallel node, the race node launches all its children at the same time. However, it processes the results of the children nodes as if it were a fallback node: it succeeds at the first child who succeeds and fails if all the children fail.

1.4.3.1.5 Random

This type of node is actually a middle ground between a composite and a decorator because it has more than one child but acts only on one of them. The chosen child is randomly selected among the children. There is the possibility of assigning different probability weights to the children. Once selected the random node will simply return the status of the child node.

1.4.3.1.6 While

The while node has two children. The first child is still a task but represents the condition that must be respected in order to launch the second child that is called action. Unlike what the name suggests, it actually behaves like an IF but, coupled with an infinite repeat, it can behave like a real WHILE loop. It is successful if both the condition and the action are successful while it fails if the condition fails or if the action fails after the condition has been successful. Foundations 45

1.4.3.2 Decorator

Decorator nodes have a single child node. The decorator transforms the status of the child node and can terminate or repeat its execution.

1.4.3.2.1 Inverter

This node denies (i.e. reverses) the resulting status of the child node. It is the equivalent of the logical NOT gate. It is useful because it allows to have the opposite version of any task, action or condition, without having to actually implement it again.

1.4.3.2.2 Succeeder or Mute

The succeeder node always returns success whether the child node actually succeeds or fails. During the running of the child also the succeeder will result in a running state. It is mainly used when a failure is expected from the child node but we still want a success status to continue executing a particular sequence in a branch of the tree.

1.4.3.2.3 Repeater

The repeater node replays the child node as soon as it returns a positive status. It is characterized by a parameter “n” that specifies how many times it should be repeated. It succeeds after its son's n-successes and fails the first time its son fails.

It is usually used on top of a tree to continuously reproduce it in its entirety or associated with a leaf node to repeat a single task.

There is a sort of "denied" version called "repeat until fail" where the repeat node returns a success when the child node fails. It is used when resources or patients are to be processed and this allows to report when the buffer is empty and therefore when all are satisfied.

1.4.3.3 Leaf

The leafs are the nodes of the lowest level and in fact they do not have any child node. However, they are the most important nodes because they effectively perform an action. 46 Simulation of Healthcare Facilities with Unity game engine

They are not generic nodes but they are specifically implemented for the desired application.

Each leaf node contains two functions:

• INIT. It is a function called the first time a node is visited by its parent. It initializes the node and allows the action / control to start. • PROCESS. It is a function called at each tick when the leaf is in the running status. The actions performed by the task are implemented at this point. This function ends when the leaf is able to return a status or when its running status is interrupted by its parent node.

1.4.4 Data Context

During the execution of the tree some variable are read and modified. They can be private, therefore visible only from the tree itself, or global variables that belong to the gameobject to which the BT is associated. The possibility of interacting with the variables allows the BT to deeply influence the dynamics of the simulation. The variables can be used as parameters / inputs for the task’s execution that gains flexibility and reusability.

: ( , )

The use of two input parameters𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 slightly𝑊𝑊𝑊𝑊𝑊𝑊𝑊𝑊 𝑐𝑐 increasesℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑒𝑒𝑒𝑒 the𝑑𝑑𝑑𝑑 complexity𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 of the implementation but with a single task I can express the action of moving any agent to any destination. It allows the execution of advanced commands, apparently improbable, where an agent can order the movement of another agent, as happens at the line of a counter where the employee calls people forward. This streamlines the writing of the model and increases its efficiency of execution. Foundations 47

1.4.5 Stacks

Stacks are intended as lists of items, people or actions. They are used with repeat nodes and they have the ability to iterate on similar objects. Essential in situations where buffers and queues are expected.

Figure 23: Generic structure of a stack element

49

Chapter 2

The Central Scheduler and the Pop-Ups

This chapter analyses in detail the first two components of the simulation model developed, namely Central Scheduler and Pop-Ups element. The central scheduler appears as a simplification compared to the Technion Scheduler and is the source of global knowledge that extends throughout the duration of the simulation. Pop-ups, on the other hand, are structures associated with objects and particular portions of space that allow to share part of the decision-making power within the objects. 50 Simulation of Healthcare Facilities with Unity game engine

2.1 Central Scheduler

The central scheduler is an element of the simulation that does not have a physical equivalent in the simulation environment and it is not associated with an object or a person. The name can imply that it manages the organization and planning of events but it does not. In a system with pop-up elements, in fact, the decision-making power is divided between the different elements and thus the central scheduler loses most of its active role.

Although it is a rather simple simulation element, it still retains some important functions for the success of the simulation. First, the scheduler remains active from the beginning to the end of the simulation, unlike pop-up elements or agents that have a limited life. Because of this the scheduler can be used as a tool of knowledge and global mapping. As a box it can gather information about what is being created in the scene so that the pop- up elements can request the scheduler about useful data for their execution.

The scheduler mainly plays only one active role, the creation and initialization of the actors. Having an infinite life inside the simulation makes this operation simple, without complications in the implementation. The central scheduler is also responsible for the creation and management of groups. As we will see later, a group is represented by a devoted pop-up which therefore includes all the functions useful for its operation. The decision to create or delete a group must come from outside: either from individual agents who "decide" to join the group or from the central scheduler. In most cases the central scheduler takes care of it because it makes implementation and reading of the simulation easier.

2.1.1 Active elements

The information created by the scheduler must be kept within specific variables and parameters. The chosen type of simulation and its consequent implementation allow the addition of modules and functionalities, and therefore variables, without problems. The following are the elements used in the current implementation of the simulation:

• “List of patients”: list of patient-type agents or more generally of people who need to receive a service. Currently only one category of patients is used. The Central Scheduler and the Pop-Ups 51

• “Patient Prefab”: a generic patient or person that can be created by the central scheduler. It is a rough model that then the scheduler completes with information randomly generated or read from outside. • “Offices”: list of Transforms (therefore a set of positions and rotation around the Cartesian axes) that represent the positions of the offices, or other places of interest, participating in the simulation. Only the transform is stored in this variable because it can be used to impose the destination within the agents' navigation systems. It does not contain information about the distances and the route to follow to reach these offices. This will be addressed by the individual movement system and leaves the data structure of the central scheduler as lean as possible. • “Chair Scheduler”: reference to all the "chair" type pop-ups and then to the information regarding the position and functionality of the chairs. • “Line Scheduler”: reference to all "single line" pop-ups and therefore to the related functionalities. Together with "chair" type pop-ups they allow the definition of all the waiting areas within the simulation. • “Dispenser list”: a list of all the “dispenser” type pop-ups within the simulation. This allows to define the quantity of a given resource and to understand how it is distributed within the physical environment. As will be later discussed, the agents are able to actively react to their need for resources and therefore the distribution and availability of the same will have an influence on the result of the simulation and on the degree of patients’ satisfaction. Without a centralized mapping of these resources, the pop-up elements would continue to function correctly, but the overall view, useful for synthetic considerations of the environment, would be lost. • “Groups List”: list of all the groups participating in the simulation. They are all basically created by the scheduler, but any group independently generated by the agents is also collected. By accessing the group, the scheduler also inherits the functions and the variables within it. • “Group prefab”: a generic sample of the “group” pop-up. At the creation time, the central scheduler can modify the internal arbitrary rules for the management of 52 Simulation of Healthcare Facilities with Unity game engine

the reciprocal positions, of the departure and of the destination as will be explained later in the dedicated paragraph. • “Timer management”: values from stochastic distributions or from files that allow organising the duration of events. • “Data from files”. The performed simulation is "trace driven", so most of the data and durations are read from external files and not randomly generated. To do this we need a data writing system by a third program (in this case Matlab) and a reading routine contained within the central scheduler's operating engine. Pay attention to the fact that some data are read at the beginning of the simulation but will only be used later (such as the “treatment time”). If the simulation were not trace driven these values would be derived from an arbitrary stochastic distribution.

2.1.2 Functionalities

2.1.2.1 Initialization

The initialization phase deals with the gathering and mapping of the data of the simulation environment. It is organized around three sub-phases:

1. Research within the simulation environment of all “patient”, “office” and “group” elements thanks to their identification through tags. The patient lists, office lists and group lists are thus created. This will give access the scheduler (and all the elements with explicit access) to data, parameters and functions of each patient, group or office. 2. Mapping of all the pop-ups within the simulation at the beginning of the same. Naturally with the evolution of the simulation new pop-ups will be added and others deleted. The central scheduler does not provide a continuous update of the pop-ups not to unnecessarily burden the task of the computing unit. This does not prohibit the controlled update of pop-ups when you decide to access them, if you generate a new one or delete an old one. The pop-ups collected by the central scheduler are "chairs", "single line" and "dispenser". The Central Scheduler and the Pop-Ups 53

3. Reading information from file. Inside files that the central scheduler has access to, we find all the information needed to characterize each individual person, that is, the values of the variables that differentiate each person / patient from the other. Other information may be kept the same or independently changed by the patient's internal engine. The information read from file regards: a. Time at which entry into the simulation environment takes place. b. Gender (male or female). c. Age. d. Emergency code (which will be applied by the triage during the simulation). e. Treatment room. f. Place of exit from the building. g. Duration of service or performance to which the patient will be subjected.

2.1.2.2 Functionality 1: Generation of patients

The central scheduler is the solely responsible for creating patients (or other types of people, depending on the application). The subsequent evolution and also the exit of the scene by the patient will instead be managed by the patient's own system. The creation phase is organized around the following elementary sub-phases:

1. Creation of a "patient" type instance. The scheduler considers the patient model entrusted to him by the designer and replicates it within the simulation. 2. Assigning data read from files. In this way the patient becomes the unique counterpart of a person actually transited (or likely to transit) across the emergency room. 3. Assignment of a name and therefore of a unique identifier so that all the elements of the simulation can refer to this element in a univocal way without overlapping or ambiguity. 4. Final admission of the patient within the simulation environment. The designer defines a portion of the environment from which patients can access the emergency room and the scheduler will place the patient randomly within that area. 54 Simulation of Healthcare Facilities with Unity game engine

2.1.2.3 Functionality 2: Management of groups

As noted above, the central scheduler is almost the only responsible for the creation and termination of groups. Because of this we find within it a functionality for their management. However, it should be emphasized that the central scheduler does not directly perform the actions connected to the groups but it exploits the interface with the "group" pop-up that represents each group. The real actions performed by the scheduler are only that of creating, deleting and tracking the pop-up. The life cycle consists of these phases:

1. Group generation. As for the patient, an instance is replicated based on the "group" model entrusted by the designer to the scheduler. In this pop-up the position of the creation does not matter because it will depend on the position of the members of the group, as explained in the dedicated paragraph. 2. Adding a person to the group. By exploiting the functionality of the pop-up, a specific person is added to the group. 3. Removal of a person. Pay attention to the fact that the person is not eliminated from the simulation but he simply will no longer belong to that particular group. 4. Group recollection. The group is collected within a starting position dependent on the mutual position of the members of the group based on a rule chosen by the designer. 5. Sending the group. After gathering around a starting position, each element of the group will be assigned a destination to reach. Each person will have a slightly different position that will be achieved autonomously. 6. Elimination of the group. Once each element of the group has reached its destination, the goal of the group has been satisfied and then the central scheduler provides for the elimination of the group itself, with the possible registration of information about the life of the group

2.1.2.4 Functionality 3: Time management

Since the scheduler takes care of patient creation, we need a timer system for cadenced creation. We must pay attention to the fact that the Δtimes are not all the same, but they depend on the amount of calculations that the physical engine has to support in a given The Central Scheduler and the Pop-Ups 55

frame and on the particular time multiplier chosen for the simulation. Timer management steps can be simplified like:

1. Timer initialization at zero. 2. Extraction of the time value from file or from a distribution. 3. Continuous updating of the cumulative time (+Δtime) by calling the clock of the physical engine. 4. Comparison between the cumulative value of the Δtime and the value read from file. When the value of the accumulated Δtime is at least equal to the value read from file, then the timer can finish and the action will be ended. These calculations are continuously done and inserted into the Behavior Tree that will be discussed in the next paragraph.

2.1.3 Behaviour tree

The central scheduler has a simple behaviour tree (BT) used to schedule patient creation based on interarrival time read from file. The BT does not use its own features but only regulates the activation of those already present in the scheduler. The resulting structure is as follows:

• Timer initialization. Initialization of the time by reading the value to be reached from the relative file. Since the time read is an interarrival time and not a cumulative time the timer must always be reset. 56 Simulation of Healthcare Facilities with Unity game engine

• Waiting. Stage in which the timer is incremented by a fraction of Δtime until it assumes the time value read from file. • Patience generation. In this task, functionality 1 of the central scheduler ("Generation of Patients") is activated thus creating a new patient.

Once the BT is complete this will continue to repeat itself for the whole duration of the simulation. Each reproduction of the BT will be different from the others because the value related to the arrival time will be different.

The Central Scheduler and the Pop-Ups 57

2.2 Pop-Up Elements

The pop-up elements are artificial constructions that distinguish the type of simulation faced by this thesis work in respect to the other main methodologies, pure event simulation and agent based simulation. Compared to the methodology carried out by the researchers of Technion University, it differs in the way the narrative is realized but it maintains the same goal of making the simulation more complete from the point of view of the rendering of collaborative situations between agents.

Pop-ups can be thought of as containers that collect part of the physical environment and some of the objects inside. In addition, pop-ups also contain information and functions necessary to use the objects. In this way it is no longer necessary to instruct every single agent or person to use an object but the logic of utilization of an object is implemented in the object itself. In this way the agent has to "only" make a request for a service and sacrifice part of its internal decision-making power so that the pop-up can intervene and manage from the outside the agent or part of its functionality.

The situations in which the pop-up elements show the greatest advantages are collaborative or competitive actions among agents. Consider, for example, a waiting room where more people access at the same time and where there are a limited number of free chairs: each agent must simultaneously observe the environment and the behaviour of other agents to decide how to behave. This clarifies the limitation of agent based systems without narratives where the logic of the individual behaviour becomes complex even to handle very simple situations. Such logics must be reproduced for each of the actors and then it becomes clear that requesting the intervention of an external agent, the pop-up, brings great advantages.

2.2.1 Advantages

The main advantages of pop-up based simulation are:

• Performance. The heaviest workload in a high-density agent simulation manifests itself in the execution of the agents' decision-making logic. By almost completely sharing this decision-making power on a limited number of pop-ups, it makes computing not only lighter but above all sustainable and feasible. This has a 58 Simulation of Healthcare Facilities with Unity game engine

consequence on the speed in obtaining results and on the completeness of the simulation which allows to simulate many more aspects which, alternatively, should be dealt with separately, losing the reciprocal dependencies. • Ease of implementation. The effort to create the logic is manifested only in the object, not in the agent who will only have to access a request interface. If the logic of use of objects and resources were implemented within the agent we should also consider all the reciprocal relationships between the various objects. With pop-ups, on the other hand, the services are compartments that are autonomously managed by their own internal logic. The ease of implementation arises precisely from the ability to reason, test and realize one logic at a time, reducing complexity as much as possible. Linked to this is the ease of editing an existing object or service: it will be enough to modify only the pop-up of interest without going to consider the relationship with other pop-ups and only rarely change the logic of access to the service for the agent. • Modularity. This aspect is certainly linked to the mutual independence between the objects and services that make up the simulation. If a new pop-up does not overlap with others then it can be added to the simulation without creating conflicts or complications. It will be the behavior tree of the agent to notice the addition of the new pop-up, seen as a useful additional service. Another advantage is the consequent portability of the services implemented within the pop-ups that can be transferred to other simulations also very different from the original thanks to the ability to read and scan the physical environment in which they operate. • Multiplicity. Once a simulation designer has created a pop-up, it will become a sort of progenitor of a family. In fact, it contains parameters that influence its behaviour. In a simulation it is possible to insert multiple instances of the same pop-up both maintaining the same constitutive parameters and intervening on some of them to modify the behaviour of that particular instance. In this way we use the same object for many similar but different applications. These different instances can simultaneously exist within the same simulation. If the logics were implemented at the agent level, we would need to exactly know the number of instances of a service at the beginning of the simulation. For example, we can have two waiting rooms with the advantage of using a single pop-up simply The Central Scheduler and the Pop-Ups 59

copied within the physical environment. The two instances could appear very different as number of chairs and spatial extension and can be associated with different services without a profound change by the designer. • Decision replacement. When the agent interfaces with the pop-up, part of the agent's decision-making power is passed into the hands of the pop-up. In most cases this submission concerns the handling system and the setting of the destination. The pop-up modifies parameters related to the resources, acquired or consumed, inverts Boolean values and adjusts comfort indicators (for example the hydration level). The relationship established between the agent and the pop-up is hierarchical: in this way there can’t be a decision ambiguity between the agent's or the pop-ups. The pop-up can manage multiple agents at the same time preventing the existence of ambiguity among the agents. This replacement will be limited to only one part of the operating logic of the person who continues to calculate a series of internal values. The temporal extension of the intervention will be limited because the pop-up covers only one of the services or resources that an agent needs during a simulation. If the pop-up covered more services its complexity would jeopardize the possibility of obtaining the advantages we are discussing.

2.2.2 Disadvantages and compromises

The comparison with the two other main types of simulation makes clear some of the limitations of the pop-up approach and the compromises that have been accepted to get the consequent advantages.

The main criticisms that can be moved towards this new type of simulation are:

• Incompatibility with the real reasoning of people. The logic of pop-ups is rarely similar or even comparable with that implemented by a person in his choices. The two are incompatible because the pop-up has to impose a hierarchy to manage overlapping situations concerning not one but many people. The main intent of these simulations (applied to situations with high human density) is not the specific simulation of the decisional processes but the analysis of the reciprocal 60 Simulation of Healthcare Facilities with Unity game engine

relationship between environment and people. With the pop-up approach, the situations that can be observed within a simulation are plausible and therefore they represent a relatively good benchmark for the study of environments and their performance. The consequent situations that can be managed at the software level are substantially wider than those achievable with only agents. Naturally, if the object of the simulation were to study the decisional processes within the human logic, a pure agent simulation would have been better. • Performance disadvantage against a pure event simulation. Although a pop-up simulation ensures relatively efficient performance, it is undeniable that the use of the central scheduler of a DES simulation can guarantee larger speed. The efficiency of the latter entails less depth of investigation. The DES loses the particularistic description of the individual and the possibility of collecting statistics of the person-environment interaction, typical of the agents. With a central scheduler it is difficult to make corrections of the actions of groups by statistical values recorded at the level of a leading individual. For example, the removal of a group of people from a simulation area because one of the individuals in the group perceived a suspicious smell or noise. Trying to implement this reasoning within DES would create an absurdly complicated system. The Central Scheduler and the Pop-Ups 61

2.3 Chairs

The pop-up “chairs” is very important because it has a very large spatial extension. In fact, it manages a large number of agents simultaneously, arranged on a surface that usually covers a very high percentage of the total. As well as the "single line" pop-up, it is used in situations where a wait for a service has to be modelled. A particularity of "chairs" is the fact that concurrent waits related to different services can be covered at the same time. It often happens that a person, during his use of space, passes several times from the waiting area, each time for a different service. The area where the chairs are placed inside the environment often represents specific real rooms, such as waiting rooms.

In most of the applications, the call of the functionalities of this pop-up will be carried out by single persons without the intervention of the central scheduler.

2.3.1 Active elements

The pop-up chairs can represent very complex and complicated situations. Its internal structure, however, is very simple and uses only few elements. Naturally, the size of these elements depends on the simulation model: we can have a minimum of one chair up to a maximum of hundreds without the system weighing too much. The elements are:

• “Chairs’ List”: list of chairs that make up the environment. They appear as position indices (x, y and z) and rotation (around x, y and z). Associated with the chair there is a physical part, usually a backrest, which takes into account the dimensions of the chair itself and influences the creation of the mesh that can be walked by the agents. • “Booking”: each chair is associated with this feature that manages the occupation of the chair as if it were booked. In fact, it happens that when a person is instructed to reach a chair this actually turns out not yet occupied and then it could happen that a second person who asks to sit on the chair after the first person but who is closer to the chair goes to occupy it, creating an error in the system. Thanks to this logic the chair will be destined (even if not yet occupied) and it therefore cannot be assigned to other agents. This dynamic does not exactly correspond to reality because if a person sees a chair this does not prevent someone else from occupying 62 Simulation of Healthcare Facilities with Unity game engine

it. The resulting simplicity at the implementation level and the likelihood of the relative simulation led to ignoring this discrepancy. • “Assignment”: this logic is used to mark the chair as occupied. The two logics, booking and assignment, are distinct because the latter uses a different logic exploiting the potentialities of the software environment. Each chair is in fact associated with a component called "collider" that detects the presence and exit of an agent from his space. It is therefore enough that a person is on the chair so that it is occupied without the need to intervene with an agent-chair interaction at the Boolean level. • “Standing position”: position on the surface of the simulation not really covered by a chair but still relevant to the “chairs” pop-up. If all the chairs are occupied it may happen that a person decides to wait for a service but, not being able to sit, chooses to stand. This certainly represents a situation of discomfort even if sometimes it may happen that a person decides not to sit down because of the characteristics of the people sitting at that time, not for the lack of chairs. The resulting simulation will certainly appear visually realistic as well as the complications in terms of movements caused by people standing in areas not designed for that.

2.3.2 Functionalities

2.3.2.1 Initialization

In this first phase, which is performed only once for simulation, the position and the number of chairs in the whole simulation or in a waiting area are determined. This collection allows to determine “chairs’ list”. Thanks to the information on the position, special chairs, curves or sparse chairs can be managed without problems, without any change in the operation logic of the pop-up. The management of any complications in the movement of people will be managed by the agent movement system with the NavMesh tools. The Central Scheduler and the Pop-Ups 63

2.3.2.1 Functionality 1: Free chair count

This feature allows to determine, several times during a simulation, the state of the chairs and therefore to know which ones are occupied or booked. The pop-up has complete access to the information it needs thanks to the "submission logic" not only of the agents but also of the objects: it accesses the single chair as a spatial entity and can also read and modify the operating sub-works related to occupation and booking.

2.3.2.3 Functionality 2: Tell the person where to sit

This second functionality requires the former in order to instantly update the occupational situation of the chairs.

We must then check that there are enough free chairs. If so, the choosing logic of the pop- up “chairs” is implemented, the heart of its operation, which is an arbitrary logic decided by the simulation designer. It can vary in complexity with the danger, however, of creating very realistic situations with too negative consequences on performance. The most powerful version of logic is based on the study of some proxemics researchers, a discipline that studies the interaction between people and space. These researches have dealt with collecting data and statistically analysing them with regard to the choices made by real people about where to sit inside waiting rooms. The results showed differences based on the gender and age group of the people. Since the simulation system is particularly rich in information, it is also possible to take into account the age and gender data in order to narrow down the field of choices actually practicable by that particular person on which we are iterating.

If instead the number of free chairs is null, it will be necessary to proceed with the implementation of the "standing" logic in which a waiting position will be assigned near the chairs. If this happens, the simulation must record this anomalous situation and take it into account to determine the degree of discomfort. The implementation of the "standing" logic can take place even when there are free chairs, but the research logic of the chair has not found a solution according to the chosen statistical model. The agent will thus stand up despite the presence of free chairs but this should not be surprising because it is a situation that frequently occurs in reality. Also as regards "standing", it will 64 Simulation of Healthcare Facilities with Unity game engine

be possible to implement more or less complex logics that depend both on the types of people involved and on the articulation of the waiting room in space.

2.3.3 Interfacing from outside

As previously stated, the pop-up “chairs” is recalled by individuals whose behaviour tree orders to sit, waiting for a performance or a service. When the agent asks the pop-up, he will receive a destination location that will be inserted into the person's movement system.

Statistics can be collected regarding the timing both for the individual person and for the system of chairs in general. Since each chair is a physical entity distinct from the others, statistics can also be collected on the individual chairs, determining the preferences in terms of gender and age, as well as a favourite position within the environment.

Figure 24: Pop-Up totally empty The Central Scheduler and the Pop-Ups 65

Figure 25: Intermediate filling with no standing people

Figure 26: Intermediate filling with standing people

Figure 27: full sitting slots with no standing people 66 Simulation of Healthcare Facilities with Unity game engine

Figure 28: full sitting slots with standing people

The Central Scheduler and the Pop-Ups 67

2.4 Group movement

“Group movement” is a very clear application of the pop-up element system. In fact, there can be several groups at the same time, very different in number and action to be carried out. The group has a finite life within the simulation because it is born to satisfy a collaborative need and then it is eliminated once the goal is reached or when the initial conditions no longer exist.

The group intended as a pop-up physically exists in the simulation environment but its position does not matter: it is like a "club" to which different people belong but then abandon. The physical value of the “group movement” will be given by the movement and position of the elements that are part of it during the group's life window.

2.4.1 Active elements

To exploit the potential of the "group movement" pop-up we need another element to call it from outside. Groups are usually activated and controlled by a central scheduler that has all the information about people, spaces and objects. Sometimes, however, it can happen that individual people activate the functionality of the pop-up. Thus, both single and multiple calls are possible. The elements that make up the “group movement” are:

• “Destination”: position to be reached by the group. Only one of the elements of the group will actually reach it, usually who leads the group. • “Departure”: position where the group meets before leaving to reach the destination. It will actually be the position held by the group leader. • “Direction”: unit vector indicating the direction joining the departure with the destination. It is a straight and ideal direction because it has to deal with the real physical disposition of the environment in which the group operates. • “People in the group”: list of people who belong to the group. This is a dynamic list in the sense that during the simulation some people are added and others deleted and there are "extreme" situations in which the list is empty or where all the members of the simulation belong to the same group. 68 Simulation of Healthcare Facilities with Unity game engine

• “Patience’s logic”: reference to the functioning mechanism of each person belonging to the group that allows the pop-up “group” to relieve, managing movement and adjustment of any parameters.

2.4.2 Functionalities

2.4.2.1 Functionality 1: Adding a Person

Simple functionality that allows to add a person from outside. This decision can be taken by the central scheduler that "knows" all the agents of the simulation or from particular agents that can autonomously add themselves to the group.

2.4.2.2 Functionality 2: Removal of a Person

This feature is called by another element with the purpose of searching, identifying and deleting a person from the list. This action is usually launched when a person has arrived at the destination, however it could happen that the person no longer needs to be in the group and therefore he is excluded. This does not involve a physical elimination but only an exclusion from the operation logic of the pop-up. The management of the excluded person will be taken over by the person's control system or by the central scheduler.

2.4.2.3 Functionality 3: Collect at the Start

Before moving and reaching the destination, the members of the group must gather around a defined starting position.

We try to get realism using an arbitrary rule for the choice of departure. Some examples of starting position are:

• Position of the first element of the group list. • Position of the list element closest to the destination. • Predetermined location such as a bus shelter. • Position of a useful resource for the group action such as a car or a wheelchair. The Central Scheduler and the Pop-Ups 69

Once the departure has been chosen, the direction is determined in detail. As a first choice the direction is imposed as the versor that unites the departure with the destination. In this case, the direction is used to arrange the elements at the start in an equivalent manner.

When choosing the starting position according to a first arbitrary rule then a second arbitrary rule must be chosen to determine how the elements of the group are arranged with respect to this position. There may be a single line, a circle recollection or a random arrangement around the start which will then turn out to be a sort of center of gravity.

At the end of this phase, each element of the group will be assigned the position and direction to be reached before actually leaving to reach the destination. This information will in fact be transferred to each of the handling systems and some time is needed before all the elements will be physically grouped at the start. The central scheduler that calls the group movement functionality from outside must therefore verify the success of the first phase before moving on to the second.

2.4.2.4 Functionality 4: Send to Destination

The first phase of this functionality requires that a sort of leader is chosen among the members of the group. He is associated with the actual destination of the group. The choice of the leader depends on the application, in many situations it can effectively express a hierarchical relationship among the members of the group or in any case a degree of greater knowledge of the environment in which the group operates. The movement of the leader from the starting position to the arrival one will determine the overall aspect of the movement of the whole group. However, the designer of the simulation must choose an additional arbitrary rule that each element of the group must follow. He will have to decide a specific destination for each element and a specific distance either from the leader or from an element of the group that precedes him. In the case of movement in single line, the distance from the person before must be established and maintained during the movement. Upon arrival at destination there may be a different arrangement with respect to movement, such as in a museum where people arrange a semicircle around the opera to be observed.

The target positions are passed to the movement system of each actor for the effective movement within the physical environment. 70 Simulation of Healthcare Facilities with Unity game engine

2.4.2.5 Functionality 5: Arrived at the destination?

This functionality asks the movement systems of the individual elements to understand if all the elements have reached their destination and then returns the decision power to the people that become independent again from the pop-up.

Figure 29: Adding people phase

Figure 30: Collecting at the start The Central Scheduler and the Pop-Ups 71

Figure 31: Collecting phase completed

Figure 32: Actual group movement

Figure 33: Approach of the destination

72 Simulation of Healthcare Facilities with Unity game engine

Figure 34: Procedure completed and elimination of the Pop-Up The Central Scheduler and the Pop-Ups 73

2.5 Single line

The “single line” pop-up is born for the three-dimensional reproduction of queues. The addition of this spatial component is fundamental because it gives a physical extension to the wait and therefore allows to better analyse, in comparison to a simple virtual list, the stress state of people. The “single line” expresses a first-in-first-out logic with the possibility, however, of eliminating agents from the line even from intermediate positions, without satisfying the request for which the agent had lined up. The “single line” allows to express the limit of slots of a queue as a physical limit of the environment in which a certain queue operates. Since the space is occupied by agents in a row, situations of high discomfort such as exits and blocked passages can be better analysed.

2.5.1 Active elements

The pop-up does not have a physical appearance, it will be the addition of agents to give it shape. In most cases this pop-up will be called by individual agents.

The elements that make it possible to manage the operation of the single line and its interface with the outside are:

• “People in line”: list of people who are in line at any given time. It is a dynamic structure. • “Basic position”: it is a set of the position (in Cartesian coordinates x, y and z) and of the rotation (around x, y and z) of the beginning of the “single line” in space. • “Distance”: it is the distance at which people stay in line from each other. It can be a fixed value, a random value within a range or a value depending on the characteristics of the person in front of us: if, for example, we are facing a tall person we move sideways to control the progress of the situation. • “Place in the line”: Transform associated with each element of the row that represents the position and rotation that the particular person will have to cover inside the line. • “Temporary destination”: position in space that each person in line must reach each time there will be an exit from the line by another agent. 74 Simulation of Healthcare Facilities with Unity game engine

• “Person Logic”: reference to the internal operation engine of the agents that allow to update the parameter values and manage the movement. You can then keep track of the time each person passes in a row and thus determine a value of satisfaction. • “Timer”: time counter for the waiting times of the agents that pass within the row. It is used to calculate the average waiting time and the statistics related to it.

2.5.2 Functionalities

2.5.2.1 Initialization

Determination of the basic position asking for it from the central scheduler. The scheduler will not have an active decision role within this pop-up but will still be required to communicate information to agents. The single line is placed by the simulation designer who also labels it based on which particular waiting area it represents. The agent who needs a certain service asks the central scheduler which line to insert in and then he can directly communicate with the line.

2.5.2.2 Functionality 1: Give a slot

This functionality is required when a person needs the service that the single line anticipates. The engine inside the single line has to check that there are actually places available to satisfy the request. If not, the person has to decide how to behave according to the service he can not access. The line manages instead the case of positive availability going to change the parameters of the person related to the actual state of waiting for the service.

The pop-up determines the slot that must be covered, at least for the moment, by the agent. This position depends on the position held in the line and on the position of the line in space. The agent movement system reasons in terms of global coordinates therefore:

= ( ) ( )

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 (𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 − 𝑓𝑓𝑓𝑓𝑓𝑓 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓) 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑜𝑜𝑜𝑜 𝑡𝑡ℎ𝑒𝑒 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 ∗ 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑒𝑒 ∗ 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑜𝑜𝑜𝑜 𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 The Central Scheduler and the Pop-Ups 75

In this way, later a person accesses the line, farther away from the beginning of the line will be. “Slot position” is then imposed within the person's movement system (assigning a destination) that will provide his physical movement on the surface of the simulation.

The pop-up will update its internal parameters like the list of people in line and the available slots.

2.5.2.3 Functionality 2: Free the first place

This feature is activated when the service is delivered and then the person who is in the first position in the row sees his need satisfied and can move to the next occupation. The pop-up has to adjust the internal parameters of the person, freeing him and marking the service as done. With the modification of a Boolean the person will no longer consider himself in line. The agent’s pop-up’s timer will be adjusted accordingly. Only after having updated all the parameters the person can be removed from the list. This is a delicate step because, once removed, the agent remains in the same physical position where he was. However, the decision-making power returns to the person and to his behaviour tree, which foresees a subsequent phase that implies the movement towards a different place. As we will see, the BT of the person provides a continuous control of the parameter related to the service received and therefore is able to intervene at the right time.

The pop-up manages instead all the other people that make up the line, to simulate the progress that is observed in reality. An iterative process is created in which the position to be reached is recalculated for each person in the line, using the previous formula. The distance between people can be varied, for example to highlight a certain impatience by someone who will come closer to the person in front of him. The new position is then inserted into the movement system of the agent who deals with the real physical movement on the navigation mesh.

2.5.2.4 Functionality 3: Free any Person

This feature allows to replicate a typical behaviour of the real life where some people leave the queue because of a prolonged wait. The operating mechanism is the same as the functionality of the first person on the list. Naturally, only the people in line behind this person will see their position adjusted. 76 Simulation of Healthcare Facilities with Unity game engine

In the adjustment phase of the agent's parameters, the Boolean related to the service connected to the line remains false. This is because the person leaves the line before he can be served. The consequence of this is recorded both at the single agent level (satisfaction) and as a statistic relative to the percentage of service.

Figure 35: Beginning of the line with only three people

Figure 36: Adding of two people The Central Scheduler and the Pop-Ups 77

Figure 37: Completion of the adding procedure

Figure 38: Exit of the first agent of the line

Figure 39: Reorganization of the remaining agents 78 Simulation of Healthcare Facilities with Unity game engine

Figure 40: Exit of one of the intermediate actors

Figure 41: Reorganization of the line after an intermediate departure

The Central Scheduler and the Pop-Ups 79

2.6 Dispenser

The pop-up “dispenser” performs a particularly important function in a simulation that has the intent of ensuring likelihood. This is because it allows to simulate, together with the person, mechanisms of adjustment of some vital parameters of the person himself. The “dispenser” can also be considered as a storage room. Among the pop-up elements, the dispenser is undoubtedly the slimmer one, but it performs some distinctive functionalities.

2.6.1 Active elements

Having to provide the management, transfer and consumption of resources, the dispenser must have some parameters able to track quantities over time.

The main elements that manage its operations are:

• “Resource supply”: initial value of a resource contained in the dispenser. This value will be continuously modified during the simulation, increasing or decreasing. However, its value will always be either positive or null. • “Actual size”: value that represents the quantity of resource that the person can actually take from the dispenser. • “Freedom”: Boolean that simply determines if the dispenser is available and therefore can be used by actors. This value must be read by the agent's internal operating engine to decide the subsequent actions. • “Withdrawal dimension”: number that expresses the amount of resource that a person needs. Because of the internal functioning mechanisms of the dispenser, it may happen that this request does not correspond to the quantity actually collected by the person. • “List of resources”: list of names and characteristics relating to the withdrawable quantities of all the resources stored in the dispenser. With a vending machine in mind it is clear how many types of resources can be there. 80 Simulation of Healthcare Facilities with Unity game engine

2.6.2 Functionalities

2.6.2.1 Functionality 1: Withdrawal of a resource

When an agent chooses the type of resource and the quantity, the dispenser will activate this function to adjust the quantities between the dispenser and the person. If the Withdrawal dimension is lower than the Resource supply this means that the request from the person can be fully satisfied and the resource supply will lower its level accordingly.

However, when the request by the person is higher than the “resource supply” level in the dispenser, the logic of the pop-up must decide whether to supply a quantity of product even if not complete or cancel the operation and return a message of fail. If you choose to dispense part of the quantity anyway, the “actual size” will be equal to the “resource supply” that will be subsequently zeroed. You can then decide to intervene at the level of the internal system of the person to go and record this state of discomfort as a result of an unmet need.

When there is the passage of a resource whose physical presence is important the pop-up will generate the corresponding 3D model of the resource that will be associated with the person who took it. This not only for aesthetics but for a functional reason. If a person takes a wheelchair from a storage, his behaviour in the environment will be deeply affected.

2.6.2.2 Functionality 2: Increase of resources

This is the antithetical functionality to the previous one. In principle it will be an easier phase from the point of view of the checks because if resources are returned to the dispenser it is difficult that it is due to an illicit or non-compliance of the accesses. However, it will be necessary to pay attention when the size of the increase is excessive with respect to the maximum quantity that the dispenser is able to contain.

2.6.2.3 Interfacing with the outside

The pop-up “dispenser” will be mainly asked by single agents and not by the central scheduler. The agent's behaviour tree must therefore provide a threshold control system (on hydration) so that the call to the dispenser can take place. The Central Scheduler and the Pop-Ups 81

Figure 42: Blue agent is under the Hydration Threshold

Figure 43: Withdrawal procedure to reintegrate the hydration level

Figure 44: Completion of the procedure with a total reintegration 82 Simulation of Healthcare Facilities with Unity game engine

Figure 45: Withdrawal procedure for the red agent with incomplete reintegration

Figure 46: Emptying of the dispenser The Central Scheduler and the Pop-Ups 83

2.7 Toilets

This pop-up is used to manage the access to the toilets by patients and, more generally, by people belonging to the simulation. As for other pop-ups, it must be activated by the agents and it has not problems interacting with people of different types (patients and professionals). It handles both female and male access. In the current implementation there is a room for men and one for women. It could be expected the presence of multiple rooms for each gender.

2.7.1 Active elements

For the interaction with the elements of the simulation this pop-up needs the following active elements:

• “Men Free” and “Women Free”. These are two Booleans that, independently, report if the toilets are free or not. • “Men WC” and “Women WC”. These are the transforms of the two toilets, their position and orientation with respect to the Cartesian axes. The use of rotation makes it possible to more accurately represent the movement of interaction with the toilet. From this structure it is easy to understand how the bathroom is composed of two distinct sub-entities, kept together because they share the same functionalities. If they were put in two different pop-ups we would need a third element for managing access based on gender. This is a representation of a situation that could also be repeated for other elements of the simulation. Better putting something integrated at the price of a slightly greater complexity.

2.7.2 Functionalities

2.7.2.1 Initialization

When the pop-up is activated, the toilets are free and therefore they are immediately ready to interact with people. 84 Simulation of Healthcare Facilities with Unity game engine

2.7.2.2 Functionality 1: Is the Toilet Free?

This feature allows an agent to know if the bathroom corresponding to his gender is currently busy or not. The answer will then be evaluated within the patient's BT, without the "bathroom" pop-up having to provide an alternative action.

2.7.2.3 Functionality 2: Give Destination to Gender

This feature is once again called directly by the person and provides for the pop-up to return the bathroom position corresponding to the gender of the person who asked the service.

2.7.2.4 Functionality 3: Seize and Free

The two features allow to reserve the bathroom. When the person occupies the bathroom, it will be occupied even before the patient actually reaches the toilet because this allows to avoid situations in which two people try to access the toilet at the same time. To avoid implementing a logic to manage the unexpected, which would increase the complexity of the system, we chose to implement alternative measures such as this to leave everything as lean as possible. The result is something plausible from the outside, even if in reality not everything coincides with the thought mechanisms that are part of the human decision. It is the normal compromise of modelling.

Figure 47: Empty Pop-up The Central Scheduler and the Pop-Ups 85

Figure 48: Seizing of the female WC

Figure 49: Satisfying of the physiological need

Figure 50: Seizing of the male WC

86 Simulation of Healthcare Facilities with Unity game engine

Figure 51: Saturation of Pop-Up capacity

Figure 52: Freeing of the female WC

Figure 53: Freeing of the male WC 87

Chapter 3

The Professionals

Professional is one of the categories of active elements that appear within the simulation. They are used for modelling those people who actually provide the service required by patients. From the point of view of functioning they appear as a middle ground between pop-ups and patient. The main difference with pop-ups is that professionals have their own behaviour tree that manages their actions and therefore they are not just an aggregate of variables and functions called from outside. The autonomy of decision given by the BT allows to implement actions for the collection of resources or satisfaction of needs that bring them very close to the "patient". However, compared to the "patient" they have a simpler structure and a reduced decision-making mechanism.

The professional contains within them the system that manages the timing. They can collect statistics on the services and people subject of the service. It is thus possible to obtain aggregated synthetic parameters, unlike the "patient" which instead collects only his own information. Very often the professionals are associated with a pop-up like "chairs" or "single line" for the management of waiting.

Professionals can contain an agent who represents the staff who exercises the actual service in the reality. The functioning of the activity can take place only when the responsible agent is actually at his desk. There is therefore a feature associated with the professional that allows the agent to reach the location that uses the NavMesh movement system. Once achieved professional is actually active and ready to perform the service. Each staff is associated with a "home" location. 88 Simulation of Healthcare Facilities with Unity game engine

3.1 Triage

Triage is the professional that takes care of the reception and the determination of the emergency code when a patient enters the emergency room. It is a function performed by a nurse. In the current implementation of the simulation there is only one location for triage. For the management of waiting, a "single line" pop-up has been chosen because it is the typical solution used in real emergency rooms.

3.1.1 Active elements

Triage professional includes both the staff and the waiting area where patients wait. The structure is rather streamlined compared to that of a "patient" type element. This is partly due to the lack of communication with the central scheduler, at least in a direct way. Information about patients is directly "communicated" by the patients themselves when they interact with this professional. The triage consists of the following elements:

• “Line Scheduler”. The triage is associated with a "single line" pop-up. This variable is used to guarantee complete access to the functions of the pop-up that will be exclusively used by the triage and not shared with other professionals. • “Timers” + “Times”. These arrays are necessary for the management of the time progress, whether it is indirectly read from a file through the patient or it is completely managed within the professional’s sphere. • “Local Timer”. Variable used to keep track of time spent since this professional has been activated. • “Distribution array”. This array is necessary for the calculation of the values extracted from stochastic or arbitrary distributions, such as the Beta distribution. They are used when we do not have the actual duration of the performance but only an estimate of the average and we must somehow decide the values. • “Waiting Times” + “Net Waiting Times”. Arrays in which the performance times are recorded, travel time included and not included. Although these variables are contained within the “triage”, actually they are progressively compiled by individual patients when they leave the simulation. • "Waiting Time Statistics". Variables in which all the synthetic indicators necessary for a rapid evaluation of the performance of the “triage” are calculated, The Professionals 89

already during the simulation. Basically, they consist of mean and standard deviation.

3.1.2 Functionalities

3.1.2.1 Initialization

When the triage is activated, the preliminary actions necessary for the functioning of the professional are carried out:

1. The first phase coincides with the research of the "single line" pop-up within the simulation which will then be associated with the "Line Scheduler" element. 2. The second phase simply consists of starting the “Local Timer”. 3. With the third phase all the arrays necessary for the use of stochastic or arbitrary distributions are obtained.

3.1.2.2 Update

Although the professionals are provided with a behaviour tree, there is still a mechanism of continuous updating. The latter could be integrated into the BT, however, it would make its functioning less clear, so the two have been splitted. The resulting “update” is very basic and includes:

1. A first phase of Local Timer updating based on the actual duration of the frame, depending on the load of the physical engine. The resulting expression is: = +

2.𝑛𝑛𝑛𝑛𝑛𝑛The𝑇𝑇𝑇𝑇 𝑇𝑇𝑇𝑇𝑇𝑇second𝑉𝑉𝑉𝑉 𝑉𝑉𝑉𝑉𝑉𝑉phase𝑜𝑜𝑜𝑜 is𝑜𝑜 𝑇𝑇activated𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑉𝑉𝑉𝑉𝑉𝑉 only𝑢𝑢𝑢𝑢 when𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 at𝑒𝑒 𝑒𝑒least𝑑𝑑𝑑𝑑𝑑𝑑 𝑑𝑑𝑑𝑑𝑑𝑑one𝑑𝑑 𝑑𝑑patient𝑜𝑜𝑜𝑜 𝑡𝑡ℎ 𝑒𝑒has𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 left the simulation. The values relating to the performances are in fact saved only when the patient has left the emergency room. In this way, mean and standard deviation values stored in "Waiting Time Statistics" are calculated.

3.1.2.3 Function: Colour Updating

When the nurse associated with the triage examines a patient, she determines the degree of emergency. Within the simulation the degree of emergency is read from files by the 90 Simulation of Healthcare Facilities with Unity game engine

central scheduler, saved inside the patient and finally read by “triage”. When the triage’s examination ends, the emergency code begins to acquire value and meaning.

We have implemented a functionality that can change the patient's appearance inside the physical environment of the simulation, changing the colour of the "capsule" shape that represents the agent. The colour exactly corresponds to the colours used as emergency codes in real emergency rooms, in decreasing order of gravity: red, yellow, green and white.

This feature has been developed not only to make the aesthetics of the scene more appealing, but also as a debugging tool of the model and for a faster and easier evaluation of the simulation. The target of the simulation, in fact, is not only engineering. There are also other stakeholders such as nurses, doctors and architects and all those who can play an active role in the creation or use of the emergency room.

3.1.3 Behaviour tree

As for the other professionals, the triage’s BT does not contain real decision-making processes. Basically the tasks’ path is always the same, but the durations and the patients change at each tick of the BT. In this implementation we chose to model conditional control with the WHILE loop, the most natural choice in this situation. In other implementations we chose to perform the same function with a SEQUENCE. The Professionals 91

3.1.3.1 Task: Is There Someone To Serve (?)

This task consults the "single line" pop-up associated with “triage”. The chain of accesses that allows the execution of the task appears as: triage -> "single line" pop-up "-> " people in line" list -> first element of the list -> movement system -> distance from the objective. It is clear how much communication between the elements of the simulation is necessary. If we did not have separate elements but agents of greater complexity, the result would be unmanageable from the point of view of the implementation of the behaviour logics.

The task is successful when two conditions are verified:

1. There must be at least one person waiting to receive the triage. 2. The first person in the line, if any, must have already physically reached the position reserved for the first element of the line.

92 Simulation of Healthcare Facilities with Unity game engine

3.1.3.2 Task: Initialize Stochastic and Wait Stochastic

These tasks are used by all the behaviour trees in the simulation. They manage the treatment times of the triage and the possible extraction of them starting from arbitrary distributions.

3.1.3.3 Task: I Served The First

As a first step, the "Colour Updating" function is applied to the patient currently being treated. The chosen simulation is "trace driven" and therefore the emergency code is read from outside and it is now made public. If instead a simulation with autonomous generation of data was chosen, at this point the degree of emergency would be determined by random generation from a weighted array.

The patient is accessed in order to record the achieved service. The last phase of the task sees access to the "single line” pop-up to activate the "Free First Place" function in order to definitively release the patient just examined by the triage and thus allowing him to continue with his BT. The Professionals 93

3.2 Vitalist

The “vitalist” professional takes care of patients who have already undergone the triage phase. Its function is to collect vital signs of patients who are waiting to be sent to their respective departments. From the simulation point of view this professional does not change the patients but deals with their order, considering both the arrival order and the severity of their situation. As well as for triage we need a waiting type pop-up. Given the habitual practice and the structure of emergency rooms, the use of a “chairs” pop-up was chosen, which, unlike the "single line" pop-up, could also be shared with other phases of the treatment.

3.2.1 Active elements

Unlike the triage, the vitalist needs a direct communication with the central scheduler. The necessary elements needed are:

• “Chairs Link” pop-up and related features. The waiting room composed of chairs is usually close to the area where the patient's vital signs are taken. By accessing the pop-up you can of course take advantage of all the associated features. The use of the waiting area by the vitalist clearly shows the advantage in using the pop-up logic: the same waiting area, and so the same “chairs” pop-up, is used as waiting room for each of the visiting rooms. The delegation of the decisional power by the patients to the pop-up prevents situations of overlapping and ambiguity between people during the various operational phases of the emergency room. • “Central Scheduler”. A direct connection is created with the central simulation scheduler. Its global knowledge is used to determine the patients’ arrival order. • “Local Timer”. Variable used for the time tracking of the vitalist’s operation. It is started when the professional is activated. • “Timers” + “Times”. These arrays are necessary for the management of time progress, whether it is indirectly read from a file through the patient or it is completely managed inside the professional’s sphere. 94 Simulation of Healthcare Facilities with Unity game engine

• “List of patients”. List of people in which all patients are waiting to receive the vitalist's service. This list is then divided into four "Colour List” (white, green, yellow and red) which each contain the patients of the respective emergency code. • “Waiting Times” + “Net Waiting Times”. In these lists are saved the waiting times actually sustained by patients, inclusive or not of the movement times between the waiting chair and the vitalist’s position. As already discussed, time are recorded only when the patient leaves the emergency room. • “Waiting Time Statistics”. Synthetic statistics relating to waiting times are stored. They are already available during the simulation and are used to determine patient’s comfort level. From a future perspective of horizontal expansion of the simulation, a second vitalist could be activated when the average waiting times exceed a certain threshold which gives rise to dissatisfaction. • “Distribution Array”. Variable used to sample treatment times from stochastic or arbitrary distributions. Unlike other phases of the simulation here the extraction from a distribution will be particularly important because we do not have specific data regarding this treatment. • “Current”. Patient taken into consideration and then served by the professional at a given time.

3.2.2 Functionalities

3.2.2.1 Initialization

When the vitalist is activated, the preliminary actions necessary for the functioning of the professional are carried out:

1. The first phase coincides with the research of the “chairs” pop-up within the simulation which will then be associated with the “Chairs Link” element. 2. The second phase simply consists of starting the “Local Timer”. 3. With the third phase all the arrays necessary for the use of stochastic or arbitrary distributions are obtained. The Professionals 95

3.2.2.2 Update

As for other professionals, it was decided to perform during the updating phase some of the functions that could be included in the behaviour tree. In this way we have two separate, simpler and easily modifiable structures. The update phase consists of some sub- phases, in particular:

1. A first phase sees the usual update of “Local Timer” in accordance to the actual duration of the frame: = +

2.𝑛𝑛𝑛𝑛𝑛𝑛 Execution𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑉𝑉 of𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 the “List𝑜𝑜𝑜𝑜𝑜𝑜 Creation”𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑉𝑉𝑉𝑉 function𝑉𝑉𝑉𝑉𝑉𝑉 𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 to define𝑒𝑒𝑒𝑒 𝑑𝑑“List𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 of𝑑𝑑 patients”.𝑑𝑑 𝑜𝑜𝑓𝑓 𝑡𝑡ℎ𝑒𝑒 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 3. Calculation of “Waiting Time Statistics”, only if at least one of the patients has left the simulation. 4. All the members of the "Colour List" are scanned to determine their global position waiting for the vitalist. The parameter “Vitalist Position” inside each patient will be assigned. The determination of the position depends both on the "Colour List" in which the patient is located and also on the specific position inside the list itself, accordingly to the following rules: a. Red code: position in the Red list. b. Yellow code: Red List length + position in Yellow List. c. Green code: Red List length + Yellow List length + position in Green List. d. White code: Red List length + Yellow List length + Green List length + position in White List.

3.2.2.3 Function: List Creation

This function empties all the "Colour List" that may already exist from the previous frame. This action may seem useless and extremely burdensome. This continuous reinsertion of patients to each frame, however, allows to eliminate the error that may occur when a patient leaves and another one enters the queue, since these two actions are managed by two different elements of the simulation, the patient (entering) and the vitalist himself (leaving). 96 Simulation of Healthcare Facilities with Unity game engine

The recreation of the lists is possible thanks to an iteration along all the patients participating in the simulation. This information is available because of the link with the Central Scheduler which provides the “List of Patients”. For each of the elements of this list three checks must be implemented:

1. Has the patient passed through the triage? This equals to check if the “triage made” Boolean inside the patient is TRUE. 2. Hasn’t the patient already passed through the vitalist? This equals to check if the “vitalist made” Boolean inside the patient is FALSE. 3. The vitalist can access the “Emergency Code” of the current patient deciding if he is of the right “Colour List”.

3.2.3 Behaviour Tree

The vitalist's behaviour tree partially shares the functioning of the triage’s one but with some differences. A first difference concerns the choice of using a SEQUENCE node instead of the WHILE node. The result does not change thanks to the rules of success / failure that distinguish the behaviour tree. However, it is necessary to specify the return to the first sequence starting from the end of the second sequence so that all the tasks are repeated for each of the patients who will use the vitalist's service. The second difference concerns the first part of the "Service" tree that contains more tasks due to the use of the "chairs" pop-up instead of the "single line" one. The Professionals 97

Figure 54: BT of the Vitalist

3.2.3.1 Task: Is There Someone To Serve (?)

The number of people waiting for the vitalist is determined by adding the lengths of the "Colour List". When at least one of the lists contains at least one element, the task will succeed while if all the lists are empty then the task will fail. In this way, the operating logic of the SEQUENCE node inside the BT is exploited, which fails at the first node that fails, thus starting again from the beginning. The restart coincides with a continuous condition checking and that is why a similar process in the triage professional is carried out by a WHILE.

3.2.3.2 Task: Call him

All the "Colour List" lists are listed in descending order of gravity, then from "Red" to "White". As soon as one of the lists contains at least one element, the "current" patient is impersonated with the first agent of that first non-empty list. By the way the “Colour List” were created, it might appear that within a list of a particular Emergency Code the elements are ordered without a particular degree of priority. But, being equal the emergency, the order of arrival is followed because the patients have a progressive name 98 Simulation of Healthcare Facilities with Unity game engine

for which they are ordered within the "List of Patients" contained in the Central Scheduler.

Once the "current" patient is chosen, the Central Scheduler is asked to know the spatial position that the patient must cover in front of the vitalist, for example on a chair. This position is then set as the destination of the "current" internal movement system.

The last operation of this task sees the value of "Vitalist Duration" initialized inside the “current” patient component with a particular formula:

=

In this way, at the end of𝑉𝑉 the𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 service,𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 adding𝐷𝐷𝐷𝐷 the− 𝐿𝐿updated𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 value of Local Timer will be enough to get the examination’s effective duration.

3.2.3.3 Task: Did he Arrive (?)

This task is a conditional check where the "current" movement system is asked if it has reached the vitalist's examinationg position. In other words, the remaining distance to reach the destination is compared to a certain threshold of precision (in the order of centimetres).

3.2.3.4 Task: Initialize Stochastic + Wait Stochastic

With this task, a duration is extracted by the simulation’s designer from a chosen distribution. The task is successful when Local Timer has reached a value at least equal to that extracted from the distribution.

3.2.3.5 Task: I Served The First

The task accesses the internal system of the "current" patient modifying some of the variables:

• A value of TRUE is assigned to the Boolean "Vital Signs Taken", specifying that the patient has passed the vital signs’ collection phase. • The assignment of "Vitalist Duration" is completed by summing up the value reached at that moment by "Local Timer". In practice, the delta time of that particular performance is determined. The Professionals 99

Once this task is done, the patient can proceed to the next phase. The Vitalist temporarily finds "current" value equal to "empty" waiting for the BT’s cycle to start again, as indicated by the continuous arrow connecting the two SEQUENCEs. 100 Simulation of Healthcare Facilities with Unity game engine

3.3 Ward

Once the patient has passed through the vitalist, he can proceed to the right examination room inside the emergency room. The destination is actually decided during the triage but since the simulation is set as trace driven, the Central Scheduler reads the information about the examination room from files at the beginning of the simulation and writes it inside the patient. This information is used during this phase when the patient is called by the “ward” professional.

In the simulation there are one instance of the “triage” and one of the “vitalist”. The professional “ward”, on the other hand, appears in multiple expressions, scattered throughout the emergency room. Luckily the power of the approach used in this type of simulation also arises with the professionals that, like pop-ups, can be inserted into the simulation to represent multiple independent blocks with the same basic structure. With the presence of ten different wards, only one “ward” professional is used, simply copied ten times with different names.

3.3.1 Active elements

The professional “ward” exploits a direct connection with the Central Scheduler to take advantage of its extensive knowledge of the elements partecipating in the simulation. This professional also requires the annexation of a pop-up capable of managing waiting in case the requested room is occupied. Vitalist’s “chairs” pop-up has been chosen, shared between the two professionals. This reflects the reality where the same waiting area is simultaneously exploited by several phases in the emergency room. Thanks to the pop- up structure, there is no problem about access because only the pop-up takes decisions regarding the waiting area.

The active elements participating in the "ward" professional are:

• “Central Scheduler”. Access to the central scheduler is created in order to get global information. • “Current”. Reference to the patient taken care of by the specific ward at a given moment of the simulation. The Professionals 101

• “Ward List”. List of patients currently waiting for that particular ward. It guarantees complete access to the patient's internal system. • “Ward Dimension”. Number of patients currently waiting for the ward. • “Local Timer”. Array necessary to manage durations of services provided by the ward. • “Waiting Time” + “Net Waiting Time”. Arrays in which the waiting times sustained by the various patients passed through the ward are recorded. They may include or not include the movement times. Unlike other professionals, routes are longer and therefore a greater difference between the values of these two arrays is expected. As usual, to ensure an exact overlap with the times of other professionals, the recording of performance times takes place only when the patient actually leaves the emergency room. • “Waiting Time Statistics”. Set of statistics that summarize and represent the duration of treatment in the ward. They can be important during the simulation because they give an indication of the level of service and therefore can push to implement alternative manoeuvres such as the deviation to other rooms, other hospitals or the activation of additional staff within the ward that is temporarily under-efficient. • “Distribution Array”. Array in which the data related to a stochastic or arbitrary distribution are saved and from which the durations necessary for the simulation can be extracted. • “Duration from file”. Time duration spent by the patient in the ward. It is included in the patient himself thanks to the Central Scheduler. It is actually used in the current implementation of the simulation. • “Ward’s Name”. A string that identifies the specific ward. It is used for clarity and because it specifically characterizes the relationship between patient and ward. Without this name the individual patient could not be called by the right instance of the “ward” professional. 102 Simulation of Healthcare Facilities with Unity game engine

3.3.2 Functionalities

3.3.2.1 Initialization

When the “ward” is activated, the preliminary actions necessary for the functioning of the professional are carried out. The steps to be addressed are:

1. Obtaining access to the "chairs" pop-up of the waiting area associated with the ward. 2. Obtaining the connection with the Central Scheduler and therefore to the information it contains. 3. Initialization of the Local Timer. 4. Calculation of the arrays for extraction from stochastic distributions.

3.3.2.2 Updating

As for other professionals, it was decided to perform during the updating phase some of the functions that could be included in the behaviour tree. In this way we have two separate, simpler and easily modifiable structures. The update phase consists of some sub- phases, in particular:

1. A first phase sees the usual update of the Local Timer in accordance to the actual duration of the frame: = +

2.𝑛𝑛𝑛𝑛𝑛𝑛Execution𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑉𝑉 of𝑉𝑉𝑉𝑉 𝑉𝑉the𝑒𝑒 “Ward𝑜𝑜𝑜𝑜𝑜𝑜 𝑇𝑇 List𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 Creation”𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 function𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑒𝑒in𝑒𝑒 order𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 to 𝑑𝑑get𝑑𝑑 𝑜𝑜𝑜𝑜 the𝑡𝑡 ℎ“Ward𝑒𝑒 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 List”. 3. Calculation of “Waiting Time Statistics” (only if at least one of the patients has left the simulation). 4. For each of the pending patients the value "Ward Position" is accessed, updating the position to the value in which he is located at that particular frame. The Professionals 103

3.3.2.3 Function: Ward List Creation

As for the “vitalist”, ”Ward List” is emptied to avoid mistakes. The Central Scheduler allows to access “List of Patients” which contains all the patients of the simulation. For each of the elements of this list four checks must be implemented:

1. Has the patient passed through the triage? This equals to check if the “triage made” Boolean inside the patient is TRUE. 2. Has the patient already passed through the vitalist? This equals to check if the “vitalist made” Boolean inside the patient is TRUE. 3. Hasn’t the patient passed through the ward? This equals to check if the “Ward visited” Boolean is FALSE. 4. The “ward” can access the “Ward to be visited” of the current patient deciding if it equals the ward’s name of the current “ward” professional. The first three checks identify a patient that has already passed through triage and vitalist but not through the ward. The fourth check is used by the pop-up itself to call only the patients of its pertinence. “Ward List” is then reordered depending on the emergency code so that the most serious patient can be visited early.

3.3.3 Behaviour tree

The structure of the behaviour tree of the “ward” is identical to that of the “vitalist”. The differences exist in the implementation of the individual tasks because the waiting lists between the two professionals work differently. 104 Simulation of Healthcare Facilities with Unity game engine

Figure 55: BT of the Ward

3.3.3.1 Task: Is There Someone To Serve (?)

The function “Ward List Creation” shows the most up-to-date version of the specific waiting list for the ward. “Ward Dimension" is then obtained based on the number of waiting patients. When “Ward Dimension” is strictly positive then the task will succeed. On the contrary, it will fail if there are no queued patients. Exploiting the logic of the SEQUENCE the task will be continuously repeated until there will be someone to serve.

3.3.3.2 Task: Call him

When a waiting patient exists, this is "called" by the ward so that the patient can move from the waiting area to the ward location. This patient, the first of the “Ward List”, is associated with "current". By accessing the "current" movement system, the position of the ward in the physical environment of the simulation can be imposed as a destination. In "current", the value of "Ward Duration" is modified, initializing it with “–timerLocale” in order to subsequently complete the difference of the Δtime of the performance. The Professionals 105

3.3.3.3 Task: Did he Arrive (?)

"Current" movement system is asked to know if the distance from the destination is below a certain threshold. In practice, the task is successful when the patient reaches the position of the ward.

3.3.3.4 Task: Initialize Stochastic + Wait Stochastic

This task deals with the extraction of the duration value from a stochastic distribution if the duration is not read from file. In this professional, however, a timer limit value is imposed equal to the value contained inside the patient. Naturally, a complete equality is expected between the value read and that actually used by the patient treatment system. The task will be successful only when a fraction of time at least equal to the time read from file has passed.

3.3.3.5 Task: I Served The First

The internal system of "current" is accessed by modifying the value of the Boolean "Ward visited" by imposing it to TRUE. In this way, the professional itself can no longer consider him a patient to be visit during the creation of the “Ward List”. The "Ward Duration" of "current" is increased by an amount equal to the new value of "Local Timer". In this way the duration of the performance is recorded as the difference between the exit time and the entry time. The "current" element is finally "emptied" waiting to be reassigned with a new execution of the BT.

107

Chapter 4

Patient

Among the elements of the simulation the “patient” is certainly the most important. Both because it is the most complicated and complex element and because it is the virtual representative of that real component that the simulation wants to study. The goal of the research is indeed to evaluate the goodness of an environment in satisfying the requests and needs of a specific category of people, patients. The patient is therefore the entity for which the level of comfort is assessed. 108 Simulation of Healthcare Facilities with Unity game engine

Active elements

The greater complexity of the tasks performed by the patient also manifests in a greater number of variables and parameters within his system. The elements necessary for its operation and its interaction with the other elements of the simulation are:

• “agent”. Reference to the navigation system of the single patient. As seen, it will be asked by the different pop-ups and by the professionals. • “Chairs Link”. Reference to the "chairs" pop-up. Within this simulation there is only one because it is shared between more professionals (services). The patient could still manage more than one. • “Single Line Link”. Reference to the "single line" pop-up used in the triage stage. • “Central Scheduler Link”. Reference to the only central scheduler available. It allows to know information related to any element participating in the simulation, like locations and data on other patients. • “Toilets Link”. Representative of the "toilets" pop-up that allows the patient to fulfil his physiological needs. This pop-up already provides, inside itself, a differentiation and the corresponding management of services of both genders. • “Dispenser Link”. Connection to the “dispenser” pop-up. There could be different types of dispensers depending on the room where they are and the resources that they deliver. • “Triage Link”. Reference to the professional that deals with the reception of patients who has just entered the emergency room and with the classification of the degree of emergency by providing a representative code. • “Vitalist Link”. Connection to the professional that deals with the collection of the vital signs after the triage stage. • “Ward Link”. Reference to the professional that carries out the specialistic examination. The connection is not unique because there are multiple wards inside the emergency room, each with a different specialization. They are all contained within this variable because the performed function is the same, with different locations and times in which the performance takes place. Patient 109

• “Destination”. Position indicating the current destination of the internal navigation system. It can be set to start the movement towards the goal or be read to determine the remaining space from the destination. • “Freedom”. Boolean that defines the patient's occupation status. When presenting the value TRUE the patient can start a new activity. • “In Single Line”. Boolean that characterizes the patient when he is in a state of waiting related to a “single line” pop-up. • “Triage Made”. A Boolean value that shows whether the triage has already been addressed by the patient. • “Vital Signs Taken”. Indicator related to the patient’s visit at the vitalist for the collection of vital signs. • “Ward Visited”. Value that enshrines the last phase of treatment at the emergency room, the medical examination at one of the visiting rooms. • “Entry order”. Integer progressive value that allows to determine the patient's entry position. Of course, this position will not give us information about the exit position because the order is continuously compromised due to the different levels of emergency. • “Emergency code”. Integer defined by the triage and it is related to the patient condition in accordance to an objective scale shared between all emergency rooms. It ranks the patients accordingly to a colour, in descending order of severity: red, yellow, green and white. • “Light Level”. Value related to the luminous stress to which the patient is subjected. Everything is detailed in the dedicated paragraph. • “Hydration Level”. Indicator of the level of hydration of the patient. • “Physiological Level”. Indicator related to the patient's need to use the toilet’s facilities. • “Hydration Threshold”. Value under which the level of hydration becomes problematic and requires the patient to implement a mechanism to re-integrate the liquids and then bring the level of hydration back to an acceptable value. • “Physiological Threshold”. Value above which the physiological level constitutes a problem and therefore pushes the patient to implement corrective actions, 110 Simulation of Healthcare Facilities with Unity game engine

essentially going to the toilets compatibly with their availability and time availability of the patient himself. • “Thirst Rate”. Speed of decreasing in the level of hydration over time. It allows to adjust the influence of time on the patient's internal state. • “Physiological Rate”. This is analogous to the “Thirst Rate” but acts on the physiological level and regulates the increase. • “Local Timer”. This variable is used to record time since the patient enters the simulation. • “Triage Duration” + “Vitalist Duration” + “Ward Duration”. Collection of the times related to the services received during the three phases of treatment in the emergency room. They can be read from file or generated from a chosen distribution. Depending on the convention, travel time could be removed. • “Gender” + “Numeric Gender”. Values and strings related to the gender of the patient. The value is read from file in a numerical form and used in string form during simulation for immediate reading. It will influence the patient's behaviour during the simulation, regarding access to certain areas. • “Age”. Expression of the age of the person. It will influence its behaviour. • “Vitalist position” + “Ward position”. Position indexes related to the considered stage. It allows the patient to make considerations to fill the empty time. • “Average Vitalist Duration” + “Average Ward Duration”. They refer to the average waiting time for the specific service considered. It can be corrected during the simulation with the effective average time of the recorded performance up to that moment. • “Estimated Time To Vitalist” + “Estimated Time to Ward”. Depending on the position in queue and the average performance time, patient’s internal system stores here the estimated time to receive the performance for which he is in queue. The greater the Parameter or Department Position, the larger the estimated time will be. • “Vitalist Threshold Time” + “Ward Threshold Time”. If the Estimated Time exceeds the Threshold Time value then the patient can decide to do something in the meanwhile because he thinks he can finish before his turn. In this simulation he can decide to go to the toilets or to the dispenser. The Threshold Time depends Patient 111

on the person’s characteristics as age and gender but also on the distinctly personal preferences, randomly chosen. • “Total Distance” + “Temporary Distance” + “Temporary Position”. These variables are used to determine the total distance travelled by the patient since he accesses the emergency room until he leaves it. It is an indicative value of the goodness according to which the layout was decided. The lower the value, the less the patient's effort to receive the treatment. It can be calculated thanks to a continuous interaction with the internal movement system. • “Ward to be visited”. Indications about the ward that the patient has to visit after the vital signs have been taken. The professional “Ward” will use this string to call and then guide the patient through the building. • “Contacts with people”. This counter is continuously updated by the physical engine taking into account the invasion of the mutual personal space. It can be done by exploiting the colliders and related functions already implemented in the physical engine Unity. • “Array of Exits” + “Index of Exit”. References of the locations through which the patient can leave the building, to be released or to be admitted to the hospital

4.2 Functionalities

4.2.1 Initialization

The initialization phase is started when the individual patient is activated, i.e. when the Central Scheduler creates it. This stage is used for the creation of the connections with the other elements of the simulation and for the initialization of values used by the patient for his operations. The following actions are expected:

1. Activation of the NavMesh internal movement system and therefore obtaining of the “agent” reference. 2. Connections with “chairs”, “single line”, “dispenser”, “toilets” pop-up and with the “Central Scheduler”. They stored in the previously declared variables. 3. Obtaining the connection and access to the professionals “triage”, “vitalist” and “ward”. 112 Simulation of Healthcare Facilities with Unity game engine

4. Initialization of “Hydration Level” to 100% and of “Physiological Level” to 0%. 5. Starting the patient's Local Timer. 6. Determination of the first value of "Temporary position": = ′ 7. Definition𝑇𝑇𝑇𝑇 of𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 the speed𝑃𝑃𝑃𝑃𝑃𝑃 of𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 the agent𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 associated𝑡𝑡 𝑠𝑠 𝑐𝑐𝑐𝑐𝐸𝐸𝐷𝐷𝐷𝐷𝐷𝐷𝑑𝑑𝑛𝑛 to the𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 patient𝑖𝑖𝑜𝑜𝑜𝑜 through a linear interpolation based on age. This value is overwritten by the default value in the physical engine. 1 = 3 1.75 100 1 ′ ′ 𝐴𝐴𝐴𝐴𝐴𝐴 − 𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑈𝑦𝑦 𝑠𝑠 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑎𝑎𝑙𝑙 𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑡𝑡 𝑠𝑠 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 − ∗ � � − 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 4.2.2 Function: Times Evaluation

This function calculates the estimated waiting time of the patient who is waiting for a performance. It uses the Average Performance Time and the position of the patient in the queue. Each patient in the queue will obviously have a different value for the time estimation. In the current implementation of the simulation, it has been decided to apply the time evaluation only to the vitalist and to the wards because they are characterized by longer waitings, with respect to triage which usually happens much more quickly. The expression that estimates the time is given by:

𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇= 𝑡𝑡𝑡𝑡 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 ∗ 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 4.2.3 Updating

This function is launched in each frame of the physical engine so to update the values of those variables that continuously change their value over time. It is important to underline how the time interval that characterizes each frame is variable accordingly to the workload sustained by the physical engine at that particular frame. Access to the built-in "Time.deltaTime" variable allows to know the duration value of the frame and therefore to maintain a coherence between the variation of the variables.

The first action of the Updating function is to update the value of Local Timer inside the patient with the addition of the frame duration. The value of the "Freedom" Boolean is then determined. This is possible by consulting the movement system in relation to the Patient 113

presence of an active destination. However, this value can also be manipulated by the professionals so that the patient is busy even when he is waiting and therefore without an active destination.

The update of the physiological parameters is done thanks to the moderation of the rates based on the duration of the frame:

= +

𝑛𝑛𝑛𝑛𝑛𝑛 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝐿𝐿𝐿𝐿𝐿𝐿 𝐿𝐿𝐿𝐿 𝑜𝑜𝑜𝑜𝑜𝑜 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 𝑇𝑇ℎ𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 ∗ ∆𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡

𝑛𝑛𝑛𝑛𝑛𝑛 𝑃𝑃ℎ𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑔𝑔=𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 𝐿𝐿 𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿

The call of the “Times 𝑜𝑜𝑜𝑜Evaluation”𝑜𝑜 𝑃𝑃ℎ𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 function𝐿𝐿 𝐿𝐿𝐿𝐿allows𝐿𝐿𝐿𝐿 − to 𝑃𝑃ℎ update𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 the value𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 of ∗the ∆𝑡𝑡 Estimated𝑡𝑡𝑡𝑡𝑡𝑡 Time variables.

Within the movement system there is no function that keeps track of the total distance travelled by the agent. This is perhaps due to the fact that an exact value can not be provided. In fact, the agent does not follow a path made of exactly curved lines but rather follows a broken line. This broken line consists of all the segments that join the position of the registered at each frame. The linearity of the line depends on the duration of the frame so if the physical engine can guarantee a high FPS value (frames per second) then the agent's movement will be realistic and the measurement of the total distance will be accurate. The total distance will be increased at each update by a value equal to the distance between the current position of the agent and that of the previous frame, saved in the "Temporary Position" variable.

4.2.4 Function: On Trigger Enter (Collider)

This function is called by the physical engine every time a "collision" occurs between the patient's capsule collider and the collider of any other object participating in the simulation. This is neither an updating call, nor a call from any of the agents of the simulation. When the collider with whom the patient bumps into is another patient, the value of "Contacts with people" counter is increased by one. In order that a contact is recorded, there must not necessarily be a clash between people, it is enough that there is a mutual invasion of what is considered the person’s intimate space. This is allowed at the implementation level thanks to the independence of the collider dimension compared 114 Simulation of Healthcare Facilities with Unity game engine

to that of the object to which it is associated. A capsule collider that represents a patient of 1m diameter can have a 1.2m diameter so that the contact is recorded for approaches under 10cm from the person's actual surface.

4.3 Behaviour Tree

With the patient the BT performs a descriptive function that allows to capture in one image the features involved and manages the decisions about actions to be performed. The use of BT with patient is necessary and not only recommended. Alternatively, different mechanisms such as state machines should be used, but they seem not being too suitable for this application.

Figure 56: BT of the patient Patient 115

Figure 57: MAIN tree

Figure 58: TOILETS tree 116 Simulation of Healthcare Facilities with Unity game engine

Figure 59: DISPENSER tree

4.3.1 Task: Go in Line

The patient accesses the "Single Line" pop-up using the " Single Line Link" previously created and launches the "Give a Slot" function of the pop-up. In this way the patient will submit himself to the pop-up which consequently directs him to the exact position of the single line in which he has to wait his turn. The subsequent progress movements in the queue are autonomously managed by the pop-up.

4.3.2 Task: Did I finish the Triage (?)

The patient must check that he has already gone through the triage phase by accessing his "Triage Made" element. Basically the task will succeed if “Triage Made” is equal to TRUE.

4.3.3 Task: Did they took the Vital Vigns (?)

Through this task the behaviour tree checks if the patient has already passed the vitalist's stage by checking that "Vital Signs Taken" has value TRUE. Otherwise the task will fail.

4.3.4 Task: Have I been to the Ward (?)

This task takes care of verifying that the Boolean "Ward Visited" assumes the value TRUE. Again, in the affirmative case, the task will succeed and proceed with a change of the variable value "Ward Position". Patient 117

4.3.5 Task: Leave ED

The exit indicated by the value of "Index of Exit" is set as the destination of the navigation system. The patient will then proceed to the selected exit, that could be outside the hospital or a ward inside the hospital.

4.3.6 Task: Self-destruction

This task has the goal of eliminating the patient from the simulation because he has covered all the steps necessary for its treatment. This task shows great power since the BT can eliminate the object to which it belongs and therefore also itself.

In order for the task to be successful and to perform its functions, the patient must have already reached the exit to which he has been addressed. The task will then write the "Performance Duration" sustained by patient during the simulation in the respective pop- ups: “triage”, “vitalist” and “ward” (only the one visited by the patient).

Once the previous actions have been carried out, the patient will lose its importance within the simulation and can therefore be definitively eliminated not to steal useful power for the simulation. Eliminating the patient will also eliminate all the features associated with it.

4.3.7 Task: Sit down

The patient activates the "Give A Chair" function of the "chairs" pop-up which he has access to thanks to the "Chairs Link" reference. The patient receives a location but, unlike what happens with “single line”, he has to personally set the location as destination of his internal handling system.

4.3.8 Task: Check Thresholds Times

The task is responsible for checking that at least one of the two “Estimated Time to Performance” (vitalist or ward) is greater than the respective “Performance Threshold Time” value. The task is therefore successful when the person has enough waiting time to do something else, regardless of what it is.

118 Simulation of Healthcare Facilities with Unity game engine

4.3.9 Task: Check Toilets

If the patient's BT is evaluating this condition, it means that the patient has enough time to visit the bathroom. The task will then have to check whether the patient is in a state of physiological stress for which he has to go to the toilet and whether the bathroom of the respective gender is free. To do this, the task checks that “Physiological Level” is greater than “Physiological Threshold” and that, at the same time, the result of the “Is the Toilet Free” function of “toilets” pop-up gives a positive response.

4.3.10 Task: Send to the Toilets

The patients calls the "toilets" pop-up by launching its function “Give Destination To Gender” with as object the gender of the patient. In this way, the toilet’s location of the right type is returned to the patient. This location is then set as the destination of the patient movement system. The toilet physically occupied by the patient is also reported as occupied by exploiting the “Seize” function that is always dependent on patient's gender.

4.3.11 Task: Arrived at the Toilet (?)

By contacting the movement system it is checked that the agent has definitively reached the toilet destination previously assigned to him.

4.3.12 Task: I Finished At The Toilet

Through the “Free” function of the “toilets” pop-up, the occupied toilet is freed by inverting the relative Boolean inside the pop-up. The patient's "Physiological Level" value is reset to zero because through the previous tasks the patient has actually satisfied his physiological need.

4.3.13 Task: Check Dispenser

Through this task the patient checks if he is in a situation where he needs to go to the dispenser because of the thirst and if the dispenser is free to use it. It is checked that the “Hydration Level” is below the “Hydration Threshold”, meaning that the patient is thirsty. Then there is access to the "dispenser" pop-up to know the value of the Boolean Patient 119

"Freedom", which describes the availability status of the dispenser. Both conditions must be valid at the same time for the task to be successful and then the patient can proceed with the subsequent tasks.

4.3.14 Task: Send to the Dispenser

At the beginning the dispenser is occupied even if the patient has not physically reached it so that it is impossible for other patients to start the approach procedure that would create a problem in the simulation. The position that the patient has to reach in order to interact with the dispenser is then determined, thus accessing the position of the dispenser and adding a distance in the front direction (thanks to the knowledge of rotation as well as position). This position is then set as the destination of the patient movement system.

4.3.15 Task: Did I Arrive at the Dispenser (?)

The task addresses the patient movement system to understand when the patient is in the right position to use the dispenser. When this is achieved the task will be successful.

4.3.16 Task: I Finished At The Dispenser

The patient accesses the "dispenser" pop-up and he resets the value of "Freedom" to TRUE so that other needy patients can now access it. Having the patient taken advantage of the dispenser he has satiated the thirst and therefore “Hydration Level” can be replenished up to 100% or only increased by a limited value depending on the designer’s choice.

120 Simulation of Healthcare Facilities with Unity game engine

4.4 Sound Management

This analyser serves to determine the level of sound stress to which an agent is subjected during the simulation. Two components are needed, one to model the noise source and one for the agent that perceives and evaluates the sound. From the point of view of implementation, Unity offers a fairly advanced system of sound reproduction that allows to import real sounds from the outside and play them in the simulation. There is also a "listener" capable of perceiving sounds as if it were a virtual microphone. There is only one virtual microphone because it was born with the intent to capture the sounds that will then be reproduced by the speakers of the videogame’s player who is approaching the application. In our simulation, however, we need a system in which each of the agents can pick up the sound to give it a subjective and time-dependent evaluation accordingly to the mutual position between the sounds and the agent. It is therefore necessary to sacrifice the possibility of actually hearing the sounds during the simulation because, in that case, only one virtual microphone could be chosen. The desire to capture sounds from many points led not to use the sound system embedded in Unity but to develop a special component of the simulation that exploits colliders and the physical law of sound perception.

4.4.1 First Component: Noise Source

This first component is associated with all sound / noise sources. It has its own spatial dimension and it is positioned by the designer superimposing it on the physical elements that produce a noise such as loudspeakers, dispensers and people. It uses the "sphere collider" of the physical engine, an invisible sphere used to record contacts or approaches between elements of the simulation.

4.4.1.2 Active elements

Although this is an important tool in terms of obtainable results, the component structure remains fairly simple. The employed elements are:

• “Intensity”. Value of intensity of the noise source. Each source has its own characteristic value. It is to be understood as the maximum value that will then be Patient 121

conditioned by the distance and by the characteristic time profile of the considered sound source. Its counterpart in the physical world is the Sound Power. • “Frequency”. Indicator of the variation of intensity over time. It characterizes the temporal profile through single trigonometric curves or their composition. By default it is set to zero because we consider constant values of intensity. However, the perceived intensity continues to vary according to the distance between the source and the agent that perceives the sound.

4.4.1.3 Function: On Trigger Enter

The “On Trigger Enter” function is automatically activated by the physical engine when the sphere-type collider associated with the noise source comes into contact with another collider in the scene. If the collider with which the intersection occurs is recognized to be of the "patient" type, then the noise source is added to that patient's “List of Noises” through an access to the patient's sound management component.

4.4.1.4 Function: On Trigger Exit

The “On Trigger Exit” function is activated when the noise source collider leaves the "patient" collider. When this occurs, the noise source is eliminated from the patient's "List of Noises" so that it is no longer taken into account when calculating the patient's sound stress.

4.4.2 Second Component: Hearing of the Patient

The "hearing" component acts as a virtual microphone and it is able to perceive sounds and to quantify the distance from them. It is attached to the patient in order to evaluate the sound stress to which he is subjected. It is actually a separate component from the patient's main system and has a rather general structure. This allows it to be applied also to other elements of person type (such as professional) or to physical objects of the simulation in order to evaluate the trend of sound intensity in a particular area of the environment. 122 Simulation of Healthcare Facilities with Unity game engine

4.4.2.1 Active elements

For this hearing part, as well as for noise’s sources, the structure remains very simple and streamlined thanks to the simulation system that provides important tools for the three- dimensional analysis of the environment. The elements necessary to the virtual microphone for the evaluation of sounds are:

• “Noise Level”. Index that summarizes with a single value the stress state of the patient at a given instant of the simulation. • “List of Noises”. List in which the auditory sources that are interacting with the patient at a given time are collected. It is therefore a dynamic list that depends on the relative position of the patient in relation to the environment.

4.4.2.2 Updating

With the update function the value of “Noise Level” is continually recalculated so as to adapt it to:

• any addition or departure of sounds of the “List of Noises”. • new values of the distance between sounds and the virtual microphone of the patient. The value of "Noise Level" is initially reset to zero. Then an iteration is performed along all the components of the "List of Noises". For each of them the value of "Noise Level" is increased by a quantity equal to:

1 = + 10 log 4 𝐿𝐿𝐿𝐿𝑖𝑖 𝐼𝐼𝐼𝐼𝐼𝐼𝐸𝐸𝑛𝑛𝐷𝐷𝐷𝐷𝐷𝐷𝑦𝑦𝑖𝑖 ∗ 10 � 2� ∗ 𝜋𝜋 ∗ 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝑖𝑖 = 10 log 10 𝐿𝐿𝐿𝐿𝑖𝑖 10 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 ∗ 10 �� � 𝑖𝑖 where is the distance between the person perceiving the sound and the sound itself in𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 that particular𝐷𝐷𝐷𝐷𝐷𝐷𝑖𝑖 frame in which Updating takes place [9]. The formulation used for the Noise Level is given by the expression of the Sound Pressure. The use of the logarithmic form finds a counterpart in the Sound Pressure Level Patient 123

(SPL), normally used in common practice to guarantee an easier comparison of the sound data with each other.

In the Figures [60] and [61] the dynamics of the sound hearing is shown without considering the distance but only the sound’s intensities.

Figure 60: Agent outside of any noise

Figure 61: Agent under the influence of Sound 1

124 Simulation of Healthcare Facilities with Unity game engine

Figure 62: Exit from Sound 1 and entrance into Sound 4 sphere

Figure 63: Agent under the simultaneous influence of Sound 2 and Sound 3

4.5 Light Management

The Unity development environment has the intent to reproduce scenes that may appear credible and appealing to an external observer. To do this it contains a system of light rendering. Unity, however, does not include a method that allows a user to know the value of light to which a point of the three-dimensional environment is subjected. To get it you have to take advantage of other tools of the environment in a way that they have not been designed for.

The trick is to use a virtual camera in addition to the one used to display the scene on the screen. This new camera will not record on screen but on a "Render Texture". Thanks to the functions already implemented in Unity it will be possible to read the values of the Patient 125

pixels that make up the texture, trying to extrapolate a luminous stress value for each of the patients.

From the structure point of view, each patient has a value related to the light stress but it is not obtained from the internal system of the patient but from a single external component, the "Light Check Component". This one, thanks to the access to every single patient guaranteed by the Central Scheduler, is able to overwrite the stress value of each patient. This is different from the Sound Management Analyzer where there is an external component but the calculations are made by the patient itself.

4.5.1 Functionalities

4.5.1.1 Active elements

On an intuitive level, the analysis system is quite simple: from an image (the texture) portions around the patients are cut out, the pixels of the portion give information on the light whose sum determines the “Light Level”.

However, being this analyser not provided by the physical engine we had to implement different elements that allow the transition from the three-dimensional physical environment to the flat 2D dimension of the texture. The elements participating in this conversion are:

• “Light Check Texture”. Reference to the texture on which the camera image is recorded. The auxiliary camera frames the scene from above. The resulting image continuously varies, depending on the movement of the characters within the scene. • “Overall Light Level”. Synthetic value that defines the overall lighting level for the whole scene at a given moment of the simulation. • “Height” + “Width”. Dimensions of the pixel window that surrounds the selected person. [number of pixels] • “ ” + “ ”. Height and width of the entire texture. [number of pixels]

• “𝐻𝐻𝑝𝑝” + “𝑊𝑊𝑝𝑝”. Height and width of the entire texture. [length units] • “𝐻𝐻𝑢𝑢” + “ 𝑊𝑊”.𝑢𝑢 Coordinates of the position of the camera. They are the same of those of𝑋𝑋 𝑐𝑐the centre𝑌𝑌𝑐𝑐 of the plane on which the simulation is running. [length units] 126 Simulation of Healthcare Facilities with Unity game engine

• “ ” + “ ”. Coordinates of the texture reference system (bottom left corner) with

respect𝑋𝑋𝑅𝑅 to𝑌𝑌 𝑅𝑅the plane’s axis system. [length units] • “ ” + “ ”. Coordinates of the position of the considered actor with respect

to𝑋𝑋 the𝑎𝑎𝑎𝑎𝑎𝑎 axis 𝑌𝑌system𝑎𝑎𝑎𝑎𝑎𝑎 of the simulation plane. [length unit] • “ ” + “ ”. Coordinates of the position of the considered actor with respect ′ ′ to𝑋𝑋 the𝑎𝑎𝑎𝑎𝑎𝑎 origin𝑌𝑌 of𝑎𝑎𝑎𝑎 the𝑎𝑎 texture reference system. [length units] • “ ” + “ ”. With these two coordinates we identify a specific point inside the

window𝑋𝑋𝑡𝑡 that𝑌𝑌𝑡𝑡 surrounds the agent. [number of pixels] • “m”. Angular coefficient of the straight line used to exclude a share of the points of the window that surrounds the agent. These excluded points are in fact behind the agent and therefore cannot be used to evaluate the light stress. • “Central Scheduler Link”. Reference to the Central Scheduler that allows the Light Management Analyser to access the patient's position and variables. •

Figure 64: Representation of the texture conversion

4.5.1.2 Initialization

First of all, the XR and YR coordinates are determined, which make it possible to relate the simulation texture to the plan reference systems: Patient 127

= 2 𝑊𝑊𝑢𝑢 𝑋𝑋𝑅𝑅 𝑋𝑋𝑐𝑐 − = 2 𝐻𝐻𝑢𝑢 𝑌𝑌𝑅𝑅 𝑌𝑌𝑐𝑐 − Subsequently, the connection “Central Scheduler Link”, that allows access to the Patients list, is created.

4.5.1.3 Task: Update Lighting Data

This task has the goal of updating the level of light stress perceived by each patient starting from the only texture that records the scene frame by frame. In the frame in which the task is carried out, the texture is copied into a dummy texture that will be substantially converted into a 32-bit deep pixel array from which it will later be possible to deduce “Overall Light Level”.

The task obtains access to the “List of Patients” of the Central Scheduler and then starts an iteration on all the elements of the list. The position of the agent is first determined ( and coordinates). These coordinates are then converted into the window refe𝑋𝑋𝐴𝐴𝐴𝐴𝐴𝐴rence system:𝑌𝑌𝐴𝐴𝐴𝐴𝐴𝐴

=

𝐴𝐴𝐴𝐴𝐴𝐴 𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅 𝑋𝑋′ = 𝑋𝑋 − 𝑋𝑋

𝐴𝐴𝐴𝐴𝐴𝐴 𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅 A portion around the agent on which𝑌𝑌′ we are𝑌𝑌 iterating− 𝑌𝑌 is cut from the whole texture, a subwindow. Any value of "Light Level" already existent from a previous launch of the task is zeroed waiting to be progressively integrated. The angular coefficient "m" of the straight line is then determined. It divides the rectangular portion around the patient into two areas, one in front and one behind the patient.

Within the original iteration there are two other nested iterations: with counter "i" for the vertical direction of the sub-window and with counter "k" for the horizontal points. Basically all the points of the sub-window are considered. The coordinates of each point are expressed as:

= + 2 𝑊𝑊𝑝𝑝 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑋𝑋𝑡𝑡 𝑋𝑋′𝐴𝐴𝐴𝐴𝐴𝐴 ∗ − 𝑘𝑘 𝑊𝑊𝑢𝑢 128 Simulation of Healthcare Facilities with Unity game engine

= + 2 𝑊𝑊𝑝𝑝 𝑎𝑎𝑎𝑎𝑎𝑎 𝑌𝑌𝑡𝑡 𝑌𝑌′𝐴𝐴𝐴𝐴𝐴𝐴 ∗ − 𝑖𝑖 𝑊𝑊𝑢𝑢

Since the texture has been converted into a pixel array, we need to find the index that identifies the point within the array:

= +

It is necessary to check that the poi𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖nt we are𝑖𝑖 ∗ analyzing𝑤𝑤𝑤𝑤𝑤𝑤𝑤𝑤ℎ 𝑘𝑘actually belongs to the part of the sub-window in front of the patient. The check that the point must overcome is:

= + 𝑝𝑝 𝑝𝑝 𝑡𝑡 𝑡𝑡 𝐴𝐴𝐴𝐴𝐴𝐴 𝑊𝑊 𝐴𝐴𝐴𝐴𝐴𝐴 𝑊𝑊 𝑌𝑌 −𝑚𝑚 ∗ �𝑋𝑋 − 𝑋𝑋′ ∗ 𝑢𝑢� 𝑌𝑌′ ∗ 𝑢𝑢 If the check is exceeded then the stress level can𝑊𝑊 be calculated as:𝑊𝑊

= 0.2126 [ ].

𝐿𝐿𝐿𝐿𝐿𝐿ℎ𝑡𝑡+0.𝐿𝐿𝐿𝐿𝐿𝐿7152𝐿𝐿𝐿𝐿 ∗ 𝐿𝐿𝐿𝐿𝐿𝐿ℎ[𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑦𝑦]. 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 𝑟𝑟𝑟𝑟𝑟𝑟

+0.0722∗ 𝐿𝐿𝐿𝐿𝐿𝐿ℎ𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑖𝑖[𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 ].𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔

∗ 𝐿𝐿𝐿𝐿𝐿𝐿ℎ𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏

Figure 65: BT for the update of lighting data

The physical equivalent of the employed Light Level is the Illuminance [9]. A distinctive feature of Illuminance is that it refers to the illuminated object and not to the source. The Patient 129

illuminance produced by a light beam on a surface is defined as the ratio between the luminous flux Φ and its area :

𝑆𝑆 = Φ 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 The luminous flux is a power, defined as the ratio𝑆𝑆 between the electromagnetic energy produced by the sourceΦ in the visible spectrum and time. The illuminance, in physical reality, is measured in [ ].

𝑙𝑙𝑙𝑙𝑙𝑙

Figure 66: Scene without advanced light rendering

Figure 67: Scene with advanced light rendering 130 Simulation of Healthcare Facilities with Unity game engine

Figure 68: Shadows on walls and agent

Figure 69: Example of texture framed by the top

Patient 131

Figure 70: Influence of the actor position on the Overall and patient's Light Level

133

Chapter 5

Application & Outcomes

This chapter describes the experience inside San Raffaele Hospital that gave me the opportunity to apply my model to a real situation like the emergency room of a real hospital. The second section presents some results that can be obtained with a model like the one I have developed that can represent important inputs for an early simulation of a structure that has not yet been realized. 134 Simulation of Healthcare Facilities with Unity game engine

5.1 San Raffaele Hospital – HSR

The IRCCS San Raffaele Hospital is a scientific-clinical-academic structure of international importance and highly specialized for various important diseases, inaugurated in 1971 and recognized in 1972 as a "Scientific Research and Treatment Institute" (“Istituto di Ricovero e Cura a Carattere Scientifico” - IRCCS).

Other related structures are the San Raffaele Turro and the Cardinal Schuster and San Donato Milanese polyclinics, for a total of 1,318 beds.

The 2016 data show that a total of about 34,000 surgeries were performed, 45,580 hospitalizations, over 950,000 outpatient services and 67,770 accesses to the Emergency room. The San Raffaele is a High Specialty Emergency Center (“Emergenza Alta Specializzazione” - EAS).

As part of the research, since 2001 the IRCCS San Raffaele Hospital is recognized by the Ministry of Health as a Scientific Hospitalization and Treatment Institute for the specialty of Molecular Medicine. In 2017, 1,416 articles were published on the most important international scientific journals [17].

5.1.1 Internship

In order to apply the simulation system created by me during the thesis work to a real situation, it was decided to start a collaboration with the San Raffaele Hospital in Milan. I was included in the "Advanced Technology in Health and Wellbeing" unit, which deals with the creation of technological tools able to improve the experience of patients in hospitals and more generally of all those suffering from some illness.

My experience mainly consisted in interfacing with some of the personalities involved in the management of the Emergency room in order to overlap the real structure with the model I created. My activity focused on the study of the emergency room’s waiting room. However, in order to better simulate the waiting room, also the remaining part of the emergency room was modelled to ensure greater completeness of the investigation carried out. Application & Outcomes 135

5.1.2 Obtained Data

The data received as input for my work essentially consist of a record relating to the patients transited from the emergency room in a given period of time and the plan of the emergency room itself.

The San Raffaele hospital provided me with the data related to the patients passed through their emergency room from 1 June 2017 to 31 May 2018. The data received were used to create the population used for the simulation.

The data was provided anonymously in a simple Excel file. Consequently, all the information not useful for the purpose of my simulation have been purified. The remaining data have been written in text files in order to be read and used by Unity. For the conversion, Matlab software was used in order to exploit the possibility of expressing all the data relating to schedules, durations and dates in a complete and homogeneous form.

At the end of the organisational phase the useful information that has been obtained are:

• Date and time of entry in the emergency room. • Gender (male or female) of the patient. • Age of the patient. • Code of the patient's emergency status according to the current standard. In descending order of gravity, the codes are expressed by the following colours:

o Red: Emergency. The individual has at least one of the vital functions impaired and he is in immediate danger of life.

o Yellow: Urgency. The patient presents a partial impairment of the functions of the circulatory or respiratory system, complaining of intense pains. There is no immediate danger of life but he urgently requires medical supervision.

o Green: Minor urgency. The patient reports lesions or complains of symptoms that do not affect vital functions but he must still receive treatment.

o White: No urgency. The subject does not need first aid and can contact his personal doctor. 136 Simulation of Healthcare Facilities with Unity game engine

• Visit room where the patient receives specific treatment for his problem. In the simulation model, the visiting room is intended as "Ward" because the examination rooms in the emergency room are divided in a similar way to the hospital wards. They are:

o Maternity unit and Gynaecology. o Surgical ward. o Medicine. o Orthopaedics. o Pediatrics. o Urgencies. o Ophthalmology. o Consultations. • Duration of treatment at the visiting room. • Place from which the patient leaves the emergency room after receiving the necessary treatment. For the purpose of simulation, the exit location can be:

o A department inside the hospital. o Exit from the structure to autonomously return home.

5.1.3 Emergency room blueprint

The Technical Area of the San Raffaele Hospital provided me with a bidimensional planimetry which I then converted into a three-dimensional model that can be used in the simulation.

The information that can be obtained from the document concerns:

• Appearance of the building. • Position of walls. • Position of doors and windows. • Allocation of rooms including the examination rooms, the waiting room and the acceptance office. • Location of accesses. • Location of the exits. Application & Outcomes 137

5.1.4 Creation of the physical model

Once the planimetry was obtained, the goal was to transform it into a three-dimensional physical model that could be imported into Unity, completed with the components of the simulation developed by me and finally used for the actual simulation and obtaining of results and indications.

The planimetry has been an important starting point for the creation of the three- dimensional model. However, it did not contain all the information I needed and so I had to proceed to a phase of direct observation of the spaces. Some emergency room areas are understandably confidential but I could attend the waiting room, the very object of my study. In this way I was able to insert part of the furniture, the lightings necessary for the luminous characterization and the position of the dispenser. Part of the observation phase was then dedicated to the definition of operations and discomfort situations.

Not all the objects have been reported in the model because they were considered not useful for the current level of the simulation. In fact, it should not be forgotten that this thesis work is intended as a sort of pilot project for the evaluation of spaces exploiting simulation and not as a fully defined quantitative study. With the evolution of the approach, the methodology and the available technologies, a complete simulator could be obtained. This will substitute the actual architectural practice, mainly based on the human decision and taste.

5.1.5 Importation

From the operational point of view, the floor planimetry was used as the basis for the creation of the 2D sketching foundation of the 3D CAD model realized in Autodesk Inventor. The model was then exported to a ".obj" sharing format for later introduction into Unity. The model was easily recognized by Unity as a set of walls. However, it has been scaled so that it can match the size of the agents used.

Then all the active components were added, such as chairs, position of triage’s waiting line, dispenser, lightings, workstations and staff. The visiting rooms, the bathrooms and the exits have been assigned to the right locations in the model. The floor on which the 138 Simulation of Healthcare Facilities with Unity game engine

navigation mesh is imprinted was created. Attention has been paid to both the position and the rotation of the elements so that the simulation can properly work.

This phase of importing and converting into a three-dimensional model that can be used by simulation is delicate but simple enough because it does not require particular skills: it consists essentially of moving elements already present and previously developed into the 3D editor. At the beginning this phase will be probably carried out by the architect who created the design of the building and subsequently completed by real users of the emergency room as doctors and nurses, also for the constant updating of all the available resources.

Figure 71: Pan of the Emergency room of HSR

Figure 72: View from the top of the Emergency room Application & Outcomes 139

Figure 73: Global partition

Figure 74: Arrangement of the wards inside the surgical area

Figure 75: Arrangement of the wards inside the medical area 140 Simulation of Healthcare Facilities with Unity game engine

Figure 76: Detail of the waiting room under examination

Figure 77: View from the back with light rendering on

Figure 78: Pop-Ups subdivision in the waiting room Application & Outcomes 141

Figure 79: Top view with lights on (perspective vision)

Figure 80: Isometric view for the texture analysis 142 Simulation of Healthcare Facilities with Unity game engine

5.2 Outcomes

This section contains the results obtained from the performed simulations. It is important to underline how the impression is purely qualitative and not quantitative, given the variability of the processes involved and the lack of an objective framework of definitions. However, the results show important situations which can give interesting insights for the design or re-evaluation of an existing space. These results are mainly used to evaluate and praise the capacity of the developed simulation system to foresee problems that could be resolved in advance during the design phase.

5.2.1 Ordinary situations

This paragraph contains some typical situations that occur during the emergency room’s activities. These are ordinary activities that therefore do not give rise to situations of discomfort for patients.

In Figures [81] and [82] we find the representation of a situation in which the waiting room is not particularly populated. People tend to keep away from each other with a homogeneous distribution within the available space.

Figure 81: Side view of the room, scarcely populated Application & Outcomes 143

Figure 82: front view of the waiting room, scarcely populated

In Figure [83] we find a detail of the area in which the triage and vitalist procedures are carried out. It should be noted that in front of the triage (personnel in purple) there is a single line of people while in front of the vitalist area we find only the patient under examination. This is because, both within the simulation and in reality, waiting for triage is managed via a single line while patients waiting for the vitalist wait in the chairs area just behind. If we had chosen to support the vitalist's waiting with a second single line, some space problems would have arisen, thus creating unpleasant situations.

Figure 83: Detail on the traige and vitalist phases

Figure [84] shows a situation in which two patients are taking advantage of the toilets at the same time, naturally patients of different gender. In Figure [85], on the other hand, 144 Simulation of Healthcare Facilities with Unity game engine

the details of when one of the patients leaves the respective toilet is shown, thus allowing a third patient to be able to use the toilets in case he needs them.

Figure 84: Both toilets occupied

Figure 85: One of the toilet is occupied, one is free

In Figure [86] a waiting patient takes advantage of the dispenser to replenish the lost hydration. Naturally, he must be in a waiting position such that his BT has allowed him to go to the dispenser. Application & Outcomes 145

Figure 86: Detail of a patient restoring his hydration

Figures [87] and [88] show the detail of a patient who is going to the ward from which he will receive the treatment. In the second of the two images the imprint of the navigation mesh on which the patient can move is also given thanks to the pathfinding performed by the A * algorithm.

Figure 87: Patient who is reaching the ward 146 Simulation of Healthcare Facilities with Unity game engine

Figure 88: The walkable area

Figure [89] shows the detail of a patient who is in the ward treatment phase. In particular, this patient is characterized by a red emergency code and therefore is staying in “urgencies” ward.

Figure 89: Detail of a patient in urgencies ward

5.2.2 Problematic situations

Within this paragraph some non-ordinary situations encountered during the simulation are reported. These are situations in which one or more patients are subjected to discomfort, due to the invasion of their personal space or due to exaggerated stresses from an acoustic point of view. Application & Outcomes 147

In Figure [90] a situation of possible conflict between two patients is reported. The first, in green, is returning after the vitalist phase and intends to sit on one of the chairs, waiting to be called for the examination at the ward. The second patient, in yellow, gets up from the chair to go to the ward after being called by the staff. This is just one of the many situations in which an actor within the simulation, and therefore a person in the reality, has to dodge another person. This is not a situation of great annoyance but nevertheless highlights the possible birth of crossed flows inside the waiting room that make the environment less comfortable and efficient from the point of view of the flows.

Figure 90: Collision due to path intersection

In Figure [91] we see a situation in which a very large number of people are lined up to receive the triage. The relative line extends even outside the appropriate room, creating a situation of discomfort both for those who have to reach the vitalist and for those who have just made the triage and have go to sit waiting to be called by the vitalist. 148 Simulation of Healthcare Facilities with Unity game engine

Figure 91: Obstruction due to insufficient space

Figure [92] shows a situation that occurs quite frequently. The waiting room still contains free chairs that could accommodate other patients, but some of them decide to still remain standing. The motivations may be different but the main one is that they want to avoid sitting immediately next to other people. Sometimes patients stand because of the immediacy of the treatment.

Figure 92: Patients stand despite the presence of free chairs

At the same time, in Figures [93] and [94] we have a room that is completely full from the point of view of the occupied seats, but without the presence of standing people. The result strongly depends on the type of people involved at that moment of the simulation. Application & Outcomes 149

Figure 93: Front view of the full waiting room

Figure 94: Side view of the full room

In Figures [95] and [96] we find the situation of maximum crowding of the waiting area with all the chairs that have been occupied and some additional person standing.

Figure 95: No chairs available and standing people (side view) 150 Simulation of Healthcare Facilities with Unity game engine

Figure 96: No chairs available and standing people (front view)

Figure [97] represents another clogging situation due to the entry into the emergency room of two people and the simultaneous exit of a patient.

Figure 97: Flows intersection at the entrance/exit of the emergency room

Figures [98] and [99] represent the meeting between patients or staff within the corridor. In the first situation, since there are only two people, practically no problem occurs while in the second situation the presence of three people can cause a problem of passage especially if one of the people were to come from one of the door facing the corridor. Application & Outcomes 151

Figure 98: Non-problematic flow of people in a corridor

Figure 99: Problematic flow of people in a corridor

In Figure [100] a situation is presented where the patient circled in red is called by the nurse who is near the triage. The simulator signals this situation as being of high discomfort because the patient may have many difficulties hearing the call from the nurse, being surrounded by a large number of people, as well as being close to the toilets and the dispenser. Naturally it is a situation exasperated by the high density of people but it highlights a possible problem of space distribution. 152 Simulation of Healthcare Facilities with Unity game engine

Figure 100: Hearing problem for a patient (red circled) because of excessive crowding 153

Chapter 6

Conclusions

This chapter contains some critical considerations regarding the work performed, the limitations of the approach and possible future developments. 154 Simulation of Healthcare Facilities with Unity game engine

6.1 Results

The main result obtained is to have a complete and functional simulation. It is in fact simulated the passage of the patient through all the phases that characterize his treatment, then triage, collection of vital signs and visit at the ward. The parallel procedures performed by the patient for the regulation of physiological parameters are then also simulated.

This simulation appears as a kind of pilot project for the creation and use of pop-up objects. It can be considered a good starting point for the realization of more complex simulations from the point of view of the procedures involved as well as of the professional skills.

The main advantages of this type of simulation are scalability and modularity. Scalability allows the use of a much larger number of pop-ups but also of patients involved without the need to change the way the simulation is carried out but only the number and arrangement of the pop-ups. Modularity consists in adding new types of pop-ups without necessarily going to modify those already existing in the considered simulation.

From the point of view of design indications, the situations set out in the previous chapter can be considered regarding verifiable situations during the use of the environment by agents. All these situations can be identified automatically, at least partially, by recording values relating to light, noise and contacts. The runs of the simulations can be used for collecting unexpected events and situations with high discomfort that must however be viewed real-time by the professionals who are analising that particular implementation of the simulation. Conclusions 155

6.2 Limitations

The main criticism that can be addressed to this approach to the simulation is the inability to simulate the emergency room operations in its entirety. In fact, only some phases have been considered and therefore the evaluations on the goodness of planning can be carried out only on some parts of the emergency room, essentially the waiting room, and only with regard to certain procedures.

Many of the procedures that are performed within the emergency room are based on the experience of the staff involved as well as the tradition of that particular hospital in addressing certain problematic situations. Many of these procedures have extreme variability and some are extremely rare and therefore there are no quantitative data that can actually be used to teach the simulation.

Although the simulation allows to implement behavioural models within pop-ups, it is necessary to consider the lack of a large number of these models at literature level. The various existing models are based on particular observations of some phenomena in specific situations and their generalization for simulation instruction appears really difficult. A large number of hypotheses should be carried out. 156 Simulation of Healthcare Facilities with Unity game engine

6.3 Future Developments

The next phase of this simulation model will consist in a comparison with architects and medical personnel, so those who are the actual builders and users of the building we want to investigate. They will be able to give indications both as regards modifications to the layout of the building and as regards the procedures carried out in the buildings.

A step forward must be made regarding the standardization of procedures observed within the emergency room or at least a definition of the level of detail to which they can be analysed and then reported within the simulation. In this way the model's forecasting capacity should significantly improve, thus increasing the scope of the use of this work for the effective evaluation of the environments.

Improvements to the simulation model itself will initially have to concern the horizontal plane, i.e. increase the number of pop-ups and professionals involved in order to embrace the simulation of wider real situations and try to use the model for other fields of application.

It will then be necessary a vertical improvement as regards a sort of validation of the values related to the luminous and acoustic stress to which the patients are subjected. The actual implementation of the collection of these data within the simulation can however remain virtually unchanged, it will be enough to modify only some of the formulas used in the scripts. 157

Appendix A

In this appendix the scripts utilized in Unity game engine are reported. 158 Simulation of Healthcare Facilities with Unity game engine

Central Scheduler Appendix A 159 160 Simulation of Healthcare Facilities with Unity game engine

161

162 Simulation of Healthcare Facilities with Unity game engine 163

Chairs Pop-up

164 Simulation of Healthcare Facilities with Unity game engine

Single Line Pop-Up 165

Group Movement Pop-Up

166 Simulation of Healthcare Facilities with Unity game engine

Toilets Pop-Up

167

Triage Professional

168 Simulation of Healthcare Facilities with Unity game engine

169

Vitalist Professional

170 Simulation of Healthcare Facilities with Unity game engine 171 172 Simulation of Healthcare Facilities with Unity game engine

173

Ward Professional

174 Simulation of Healthcare Facilities with Unity game engine

175

176 Simulation of Healthcare Facilities with Unity game engine

Patient 177 178 Simulation of Healthcare Facilities with Unity game engine

179

180 Simulation of Healthcare Facilities with Unity game engine

181

Noise Source

182 Simulation of Healthcare Facilities with Unity game engine

Light Management 183

184 Simulation of Healthcare Facilities with Unity game engine References 185

References

[1] Kartikeya Date, Davide Schaumann, Yehuda E. Kalay. “A Parametric Approach To Simulating Use-Patterns In Buildings: The Case of Movement”. eCAADe 2017 – ShoCK. Rome, Italy (2017).

[2] Davide Schaumann, Simon Breslav, Rhys Goldstein, Yehuda E. Kalay. “Simulating the Behavior of Building Occupants using Multi-agent Narratives: A Preliminary Study in a Generic Hospital Ward”. Building Simulation. San Francisco, CA, USA (2017).

[3] Davide Schaumann, Michal Gath Morad, Einat Zinger, Yehuda E. Kalay. “A computational framework to simulate human spatial behavior in built environments”. Symposium on Simulation for Architecture and Urban Design. London, May 2016.

[4] Kartikeya Date, Nirit Putievsky Pilosof, Davide Schaumann, Yehuda E. Kalay. “A study of human behavior simulation in architectural design for healthcare facilities”. Annali dell'Istituto superiore di sanità 52(1):24-32. March 2016.

[5] Hadas Sopher, Davide Schaumann, Yehuda E. Kalay. “Simulating Human Behavior in (un)Built Environments - Using an Actor Profiling Method”. January 2016.

[6] Davide Schaumann, Yehuda E. Kalay, Seung Wan Hong, Davide Simeone. “Simulating Human Behavior in not-yet Built Environments by means of Event-based Narratives”. SimAUD. Washington DC, USA. April 2015.

[7] Davide Simeone, Stefano Cursi, Ilaria Toldo, Davide Schaumann. “A Simulation Model for Building Occupancy Prediction”. January 2015.

[8] Davide Simeone, Yehuda E. Kalay, Davide Schaumann. “Using game-like narrative to simulate human behaviour in built environments”. 18th International Conference on Computer-Aided Architectural Design Research in Asia (CAADRIA 2013). Department of Architecture-NUS, Singapore.

[9] Philomena Bluyssen, 2009, “The Indoor Environment Handbook”, 1st ed., Earthscan and RIBA Publishing, London, Chap. 1 and 3. 186 Simulation of Healthcare Facilities with Unity game engine

[10] Peter E. Hart, Nils J. Nilsson, Bertram Raphael. “A Formal Basis for the Heuristic Determination of Minimum Cost Paths”. IEEE Transactions on System Science and Cybernetics.

[11] Amit Patel, 2018, “Introduction to A*”, from http://theory.stanford.edu/~amitp/GameProgramming/AStarComparison.html [12] “Introduction to A*”, Red Blob Games, from https://www.redblobgames.com/pathfinding/a-star/introduction.html

[13] “Inner workings of the Navigation System”, Unity Documentation, from https://docs.unity3d.com/Manual/nav-InnerWorkings.html

[14] “NavMesh Agent”, Unity Documentation, from https://docs.unity3d.com/Manual/class-NavMeshAgent.html

[15] Chris Simpson, 2014, “Behavior trees for AI: How they work” from http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_ AI_How_they_work.php

[16] Eric Begue, 2016, “Behaviour Tree scripting for Unity”, from http://www.pandabehaviour.com/?page_id=23

[17] “Ospedale San Raffaele” https://www.hsr.it/chi-siamo/ List of Figures 187

List of Figures

Figure 1: Main components of the Navigation System Figure 2: Two alternative corridors for the destination Figure 3: Approaching the visible corner Figure 4: Obstacle avoidance by RVO method Figure 5: Outline of the Navigation procedure Figure 6: Carving procedure by Global Navigation Figure 7: NavMesh Agent Properties Figure 8: NavMesh Bake Settings Figure 9: Virtual floor divided into edges and nodes Figure 10: Progressive numbering of the frontier Figure 11: Retracing from destination to start Figure 12: Saving in calculations thanks to early exit strategy Figure 13: Progress quantification with steps (left) and distance (right) Figure 14: Frontier propagation by BFS (left) and Dijkstra (right) Figure 15: Comparison between BFS (left) and GBFS (right) in exploration without obstacles Figure 16: Comparison between BFS (left) and GBFS (right) in exploration with obstacles Figure 17: A* seen as composition of Dijkstra wiht GBFS Figure 18: Example of a Behaviour tree Figure 19: Arrangement of the different types of nodes Figure 20: Example of a sequence composed by actions Figure 21: Example of a conditional checking sequence Figure 22: Example of a selector node used for alternative ways to perform an action Figure 23: Generic structure of a stack element Figure 24: Pop-Up totally empty Figure 25: Intermediate filling with no standing people Figure 26: Intermediate filling with standing people Figure 27: full sitting slots with no standing people 188 Simulation of Healthcare Facilities with Unity game engine

Figure 28: full sitting slots with standing people Figure 29: Adding people phase Figure 30: Collecting at the start Figure 31: Collecting phase completed Figure 32: Actual group movement Figure 33: Approach of the destination Figure 34: Procedure completed and elimination of the Pop-Up Figure 35: Beginning of the line with only three people Figure 36: Adding of two people Figure 37: Completion of the adding procedure Figure 38: Exit of the first agent of the line Figure 39: Reorganization of the remaining agents Figure 40: Exit of one of the intermediate actors Figure 41: Reorganization of the line after an intermediate departure Figure 42: Blue agent is under the Hydration Threshold Figure 43: Withdrawal procedure to reintegrate the hydration level Figure 44: Completion of the procedure with a total reintegration Figure 45: Withdrawal procedure for the red agent with incomplete reintegration Figure 46: Emptying of the dispenser Figure 47: Empty Pop-up Figure 48: Seizing of the female WC Figure 49: Satisfying of the physiological need Figure 50: Seizing of the male WC Figure 51: Saturation of Pop-Up capacity Figure 52: Freeing of the female WC Figure 53: Freeing of the male WC Figure 54: BT of the Vitalist Figure 55: BT of the Ward Figure 56: BT of the patient Figure 57: MAIN tree Figure 58: TOILETS tree Figure 59: DISPENSER tree List of Figures 189

Figure 60: Agent outside of any noise Figure 61: Agent under the influence of Sound 1 Figure 62: Exit from Sound 1 and entrance into Sound 4 sphere Figure 63: Agent under the simultaneous influence of Sound 2 and Sound 3 Figure 64: Representation of the texture conversion Figure 65: BT for the update of lighting data Figure 66: Scene without advanced light rendering Figure 67: Scene with advanced light rendering Figure 68: Shadows on walls and agent Figure 69: Example of texture framed by the top Figure 70: Influence of the actor position on the Overall and patient's Light Level Figure 71: Pan of the Emergency room of HSR Figure 72: View from the top of the Emergency room Figure 73: Global partition Figure 74: Arrangement of the wards inside the surgical area Figure 75: Arrangement of the wards inside the medical area Figure 76: Detail of the waiting room under examination Figure 77: View from the back with light rendering on Figure 78: Pop-Ups subdivision in the waiting room Figure 79: Top view with lights on (perspective vision) Figure 80: Isometric view for the texture analysis Figure 81: Side view of the room, scarcely populated Figure 82: front view of the waiting room, scarcely populated Figure 83: Detail on the traige and vitalist phases Figure 84: Both toilets occupied Figure 85: One of the toilet is occupied, one is free Figure 86: Detail of a patient restoring his hydration Figure 87: Patient who is reaching the ward Figure 88: The walkable area Figure 89: Detail of a patient in urgencies ward Figure 90: Collision due to path intersection Figure 91: Obstruction due to insufficient space 190 Simulation of Healthcare Facilities with Unity game engine

Figure 92: Patients stand despite the presence of free chairs Figure 93: Front view of the full waiting room Figure 94: Side view of the full room Figure 95: No chairs available and standing people (side view) Figure 96: No chairs available and standing people (front view) Figure 97: Flows intersection at the entrance/exit of the emergency room Figure 98: Non-problematic flow of people in a corridor Figure 99: Problematic flow of people in a corridor Figure 100: Hearing problem for a patient (red circled) because of excessive crowding Ringraziamenti 191

Ringraziamenti

Il percorso che mi ha portato alla scrittura di questa tesi è stato lungo e molto impegnativo. Sono stati cinque anni particolarmente intensi che hanno contribuito alla formazione della mia persona. Fortunatamente non ho affrontato questo percorso da solo.

Desidero ringraziare i miei compagni di università per le grandi risate e il supporto reciproco, la vostra compagnia ha reso sicuramente più dolce un’esperienza tanto dura. Ringrazio i miei amici di una vita, Daniele, Nicolò, Thomas, Marta e Mauro: mi siete sempre stati vicini e mi avete sempre supportato.

Ringrazio i professori del Politecnico di Milano per gli insegnamenti di questi cinque anni e per la passione che mettono nel loro non facile lavoro. In particolare, dedico un ringraziamento speciale al mio relatore, Andrea Matta, per la fiducia riposta nei miei confronti e nel mio lavoro.

Dedico alcune parole alla mia famiglia. Ai miei parenti, che mi hanno sempre incoraggiato con una parola di ottimismo.

A mio fratello Andrea. La tua intelligenza e il tuo impegno sono straordinari, sei sempre stato un esempio da seguire. Sono fortunato ad averti, ti voglio tanto bene.

Ai miei genitori, per il sostentamento economico, per l’enorme pazienza e per l’amore incondizionato che mi avete sempre donato. Mi avete sempre supportato nei numerosi momenti di sconforto e nervosismo. Vi ringrazio per i sacrifici che avete fatto e per i valori che mi avete trasmesso: senza di voi non avrei potuto tagliare questo traguardo. Spero un giorno di diventare persone come voi, siete speciali e vi voglio davvero un mondo di bene.