Non-homogeneous servers in emergency medical systems: Practical applications using the hypercube queueing model

Transcription

1 Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Non-homogeneous servers in emergency medical systems: Practical applications using the hypercube queueing model Reinaldo Morabito a,, Fernando Chiyoshi b, Roberto D. Galvão b a Departamento de Engenharia de Produc-ão, UFSCar, São Carlos, SP, Brazil b Programa de Engenharia de Produc-ão, COPPE/UFRJ, Brazil Abstract In this paper, we study the effects of considering homogeneous versus non-homogeneous servers in applications of the hypercube queueing model. This is important since approximate methods available for solving the model for homogeneous servers are computationally much less time-consuming than the exact methods required for the non-homogeneous case. Illustrative examples are initially presented to show the degree to which using homogeneous versus non-homogeneous servers can differ. Then, two ambulance deployment applications dealing with Brazilian emergency medical systems, in a city and along a highway, are analyzed. The basic operational characteristics of non-homogeneous systems were compared to the respective predictions produced under the simplifying assumption of homogeneous servers. It was found that, even when the degree of non-homogeneity of the servers is not highly significant, homogeneity may lead to poor predictions of the actual operational characteristics of non-homogeneous systems. r 2007 Elsevier Ltd. All rights reserved. Keywords: Emergency medical systems; Queueing; Hypercube model; Ambulance deployment; Non-homogeneous servers 1. Introduction The hypercube queueing model, proposed by Larson [1], and studied by several authors (e.g., [2 4]) is an important tool for planning service systems, especially within urban environments where servers travel to offer some type of service to clients (server-to-customer service). The model takes into account geographical and temporal complexities of the regions under consideration, and is based on spatial queueing theory and Markovian analysis approximations. Basically, the idea is to expand the state space description of a queueing system with multiple servers in order to represent each server individually and incorporate more complex dispatch policies. A number of system performance measures can be estimated, either region-wide, or for each server or region. These include workloads, mean response times, and fraction of dispatches of each server to each region, among others. Applications of the hypercube model in the United States include the location of ambulances in Boston [5] and Greenville, NC [6], police patrolling in New Haven [7] and Orlando, FL [8], and a program for visits by the social system (see [9, Chapter 5]). More recently, the hypercube has been considered as a deployment model for response to terrorism attacks and other major emergencies [10]. Corresponding author. addresses: morabito@power.ufscar.br (R. Morabito), chiyoshi@pobox.com (F. Chiyoshi), galvao@pep.ufrj.br (R.D. Galvão) /$ - see front matter r 2007 Elsevier Ltd. All rights reserved. doi: /j.seps

2 2 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Some examples of the use of the hypercube model in Brazil include the design of a repair service related to interruptions in the distribution of electrical energy, studies of the public emergency medical system of the City of Campinas [11], and emergency medical systems that operate on highways in the states of Rio de Janeiro and Sa o Paulo [12,13]. Other references related to applications and extensions of the hypercube model can be found in Halpern [14], Jarvis [15], Batta et al. [16], Swersey [4], Chiyoshi et al. [17], Saydam and Aytug [18], Galva o et al. [19] and Atkinson et al. [20]. To solve the hypercube model, it is necessary to find the solution to a system of 2 n linear equations (where n is the number of servers in the system) that provides the equilibrium probabilities of all possible states of the system (the state probabilities). For moderately sized systems, this can be done in a number of ways, such as using Gauss elimination method, or the iterative method of Gauss Seidel [21]. For larger systems (n415), these exact methods become computationally prohibitive. Larson [22] proposed an approximate method based on a system of n non-linear equations to solve the model, but it is valid only if the servers are homogeneous. Nevertheless, the method is computationally much less time-consuming than exact methods, with average errors of less than 4% when the corresponding values are compared with exact solutions. In the present paper, we assume that the servers are non-homogeneous within applications of the hypercube model. Since systems with such servers require an exact method of solution, our approach can only be justified if both: (i) the application under consideration requires the use of non-homogeneous servers; and (ii) it can be shown that the values of the output measures of the hypercube model differ substantially from the homogeneous case when non-homogeneous servers are considered. Regarding the first point, systems with non-homogeneous servers can be found in several practical applications. For example, in the emergency medical systems of some Brazilian cities, ambulances can be either advanced support (VSAs) or basic support vehicles (VSBs) [11]. Such servers, even when they share the workload, may realize average service times that differ substantially as a function of the service offered. On the other hand, it is possible to find systems with similar servers in terms of vehicle, crew and equipment, but with different service times when their fixed location is considered. For example, for emergency service systems available on certain Brazilian highways, the average service times can vary due to travel time, which is obviously a function of their locations (see [12,13]). The second point is dealt with in the remainder of the paper. In Section 2, illustrative examples show the degree to which solutions of the hypercube model using homogeneous and non-homogeneous servers can differ. Two practical applications of moderate size (no15) are then discussed in Sections 3 and 4. Although the differences in output measures do not appear to be as significant in these applications as in the illustrative examples, they still suggest the need to use non-homogeneous servers in selected real-world scenarios. Finally, in Section 5, we discuss the results of Sections 2 4, and present our conclusions. 2. Illustrative examples In this section, the effects of non-homogeneity of the service rates are analyzed through three illustrative models based on a three-atom network with three servers. These structures, referred to as toy-models by some authors, are the smallest, non-trivial models to incorporate the basic characteristics of systems under analysis. By their very nature, they are used to gain insight into problems of interest, but are generally unable to address the complexity of real-world systems. As previously noted, the insight we seek here involves the degree to which the operating characteristics of the hypercube model depart from predictions offered by homogeneous server-based models. To this end, the toy-models seem appropriate tools because, as it will be shown below, strictly regular and symmetric structures can be built into such structures and, in a controlled experiment, the net effect of server nonhomogeneity on the output measures can be evaluated. The first model (here, Model I) is the classical hypercube, in which the home locations of the servers are decentralized, and a fixed-preference dispatch policy, with preferences set according to the shortest travel distance/time criterion, is in use. The other two formulations (here, Models II and III) incorporate those characteristics of the models used in the case studies of Sections 3 and 4, respectively.

3 Model II is a centralized structure in which all servers have the same home location. Further, since distance is no longer a meaningful criterion for defining priorities, a random dispatch policy is assumed. Model III has as its distinguishing feature the fact that the backup is partial, in the sense that servers cannot service calls from all atoms. It is assumed there is no point in dispatching a server when the travel distance/time exceeds a predefined limit. Although the decision whether or not to assume a waiting line of calls is not critical in Models I and II, the decision to not service a call in Model III is supported by the existence of a secondary emergency system to handle overflows from the main system. In this case, a zero-capacity waiting line model seems appropriate. The network on which Models I III are defined consists of a region with three atoms connected by one-way roads, as shown in Fig. 1. It is assumed that the centroids of the atoms are located at the vertices of an equilateral triangle with sides of unit length. The inter-atom travel distances are shown in Table Model I R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 3 As noted earlier, Model I, is a decentralized structure with a shortest distance-based dispatch policy. Each atom is the home location of a server, and a fixed-preference dispatch policy, with preferences set according to shortest distances, is in use. The preference matrix is shown in Table 2. For a zero-capacity waiting line system, the hypercube state probabilities are defined by a set of flowbalancing equations built around the hypercube states [9]: State Equation {0 0 0} lp 000 ¼ m 1 p 001 +m 2 p 010 +m 3 p 100, {0 0 1} (l+m 1 )p 001 ¼ l 1 p 000 +m 2 p 011 +m 3 p 101, {0 1 0} (l+m 2 )p 010 ¼ l 2 p 000 +m 1 p 011 +m 3 p 110, {1 0 0} (l+m 3 )p 100 ¼ l 3 p 000 +m 1 p 101 +m 2 p 110, {0 1 1} (l+m 2 +m 1 )p 011 ¼ (l 1 +l 2 )p 001 +l 1 p 010 +m 3 p 111, {1 0 1} (l+m 3 +m 1 )p 101 ¼ l 3 p 001 +(l 1 +l 3 )p 100 +m 2 p 111, {1 1 0} (l+m 2 +m 3 )p 110 ¼ (l 3 +l 2 )p 010 +l 2 p 100 +m 1 p 111, {1 1 1} mp 111 ¼ lp 110 +lp 101 +lp 011, Fig. 1. Map of the three-atom region. Table 1 Inter-atom travel distances From atom i To atom j

4 4 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Table 2 Server dispatch preferences Atom i Server preferences 1st 2nd 3rd where l j is the arrival rate of calls from atom j; m i is the service rate of server i; m ¼ m 1 +m 2 +m 3 is the total service rate; l ¼ l 1 +l 2 +l 3 is the total arrival rate; and p, followed by a sub-string of 1 s and 0 s, refers to the probability of the corresponding state, where 1 implies an available server and 0 a busy server. For instance, p 011 is the probability that servers 1 and 2 are busy and server 3 is available (note that the server states are described from right to left). Consider the equilibrium equation for state {0 1 1}. Note that on the left side (outflow rate of state {0 1 1}), the system leaves state {0 1 1} if a call arrives, or a service is completed by servers 1 or 2. Conversely, on the right side (inflow rate of state {0 1 1}), the system enters state {0 1 1} if: (i) a call arrives from atoms 1 or 2 when the system is in state {0 0 1}; (ii) a call arrives from atom 1 when the system is in state {0 1 0}; or (iii) a service is completed by server 3 when the system is in state {1 1 1}. (See Table 2.) The above set of equations is singular; an additional equation is thus required to determine the hypercube state probabilities. The standard procedure is to replace one of the equations by an equation related to the probability normalization condition. The flow equation associated with state {1 1 1} is a convenient candidate for replacement because the normalization equation can be used to handle a non-zero-capacity waiting line, if required. For a zero-capacity waiting line, this equation is p 000 +p 001 +?+p 111 ¼ 1, while, for an infinite capacity queue, it becomes p 000 +p 001 +?+ p 111 /(1 r) ¼ 1, where r ¼ l/m is the average workload of the system. It is assumed that the non-homogeneity of the system is characterized by the service rates of the three servers, these rates being such that m 1 4m 2 4m 3. It is further assumed that m 1 is symmetric to m 3 with respect to m 2, so that the ratio m 1 /m 3, referred to herein as the fast to slow ratio (FSR), is a proper measure of the system s non-homogeneity. To build the non-homogeneity measure as an input parameter of the model, the average service time is taken equal to the time unit, so that m 2 ¼ 1 and, thus, m 1 ¼ 2(1+1/FSR) 1 and m 3 ¼ 2(1+FSR) 1. In order to analyze the effects of the servers non-homogeneity on the output measures, we begin by selecting three of these metrics: workloads (r i ), dispatch frequencies (f i ), and average travel distances (Du i )of server i. Consider, for instance, the average travel distance formula (the analysis is similar for travel times): Du i ¼ Pj f ½1Š ij d ij þðd Q P S m i =mþ, þðp S m i =mþ Pj f ½1Š ij where f ½1Š ij is the fraction of all dispatches that send server i, when available, to atom j; d ij is the average travel distance from server i to atom j (when this server is available); P S is the system saturation probability; and D Q is the average travel distance to a queued call [9]. A closer look at this formula shows that it is a weighted average of distances in which the dispatch frequencies are the weights; its numerator is a weighted sum of distances while its denominator is the total dispatch frequency of server i, f i. The expression is, in fact, the average distance traveled by the server when it is dispatched to service a call, and could thus be called the average travel distance per dispatch. If we look at the numerator, it represents the average distance traveled by the server for each call serviced by the system. While the dispatch frequency shows the fraction of all calls serviced by the server, the average traveled distance per call is the share of the server of the total distance traveled by the fleet of service vehicles. The average travel distance per call of server i (the numerator of Du i, denoted by Du 0 i ) is included in this

5 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 5 analysis as a fourth measure of performance. Note that the average travel distance per call includes all calls, and not just those to which a particular server was dispatched. With the system workload set at 0.5 and evenly distributed demand assumed, the output measures for the infinite capacity model are shown in Table 3 for three levels of non-homogeneity of the servers (FSR ¼ 1.2, 1.5 and 2.0). Results corresponding to the homogeneous system (FSR ¼ 1.0) are included to show the regular and symmetric structure of the model; note that in this case every performance measure is the same for all three servers. The output measures for average server 2 are generally not affected by server non-homogeneity while those for slow server 3 are roughly symmetric to those for fast server 1. As one would expect, the fast server takes a greater share of the system s workload (here, the term workload bears its original meaning as load of work and does not refer to the corresponding output measure). At FSR ¼ 2.0, the fraction of all calls serviced by the fast server is f 1 ¼ , whereas the share of the slow server is f 3 ¼ (note in Table 3 that P i f i ¼ 1). This greater workload implies a higher proportion of calls from outside its preferential area, and, so, its average traveled distance per dispatch (Du 1 ¼ ) is also higher. The average distance traveled by the fast server for each call serviced by the system is also higher (Du 0 i ¼ 0:2629), due to the combined effect of higher dispatch frequencies and traveled distances per dispatch. Notice that, for FSR ¼ 2.0, the total distance traveled for each serviced call is ( ). The share of the fast server of this total is (44.1%), while that of the slow server is (23.3%). As for the output measure workload (the average fraction of time the server is busy), we see that the workload of the fast server, r 1, tends to be smaller for higher FSRs; yet, its increased activity in terms of number of calls serviced does not increase its utilization. In fact, the higher service rate of the fast server results in a higher idle time for the server. In order to assess the importance of server non-homogeneity on the performance measures of Table 3, Table 4 shows these measures expressed as percentage deviations from the corresponding values of the homogeneous system. When the output measures are so expressed, we find the least affected to be workload and the average traveled distance per dispatch. The most heavily affected measure is the average traveled distance per call, while dispatch frequency falls somewhere in between. The output measures related to travel distances must be taken cautiously. In a sense, all output measures are dependent on the network topology since the dispatch preferences are derived from the inter-atom distances. However, while this dependence is on the ordering of distances for workload and dispatch frequency, the distance-related measures are dependent on the distances themselves, implying a stronger network topology dependency. Table 3 Model I: effects of server non-homogeneity on the performance measures Performance measure Server Fast to slow ratio FSR Workload r i Fast Average Slow Dispatch frequency f i Fast Average Slow Travel distance per dispatch Du i Fast Average Slow Travel distance per call Du 0 i Fast Average Slow

6 6 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Table 4 Model I: effects of server non-homogeneity on performance under homogeneity (% deviation) Performance measure Server FSR (%) Workload r i Fast Average Slow Dispatch frequency f i Fast Average Slow Travel distance per dispatch Du i Fast Average Slow Travel distance per call Du 0 i Fast Average Slow From the data displayed in Table 4, it can be seen that, depending on the degree of server non-homogeneity, performance using models that assume homogeneous servers may be at great variance with respect to the nonhomogeneous case Models II and III Model II is a centralized formulation with random dispatch. Thus, all servers are located in the same atom and there is no preferential service area for them. Since there are no distance differences to distinguish the incoming calls, a random dispatch policy is assumed. In building the system s equations, we must argue differently from Model I. The transition rate, from, say, state {0 0 0} to state {0 0 1}, must be 1 3 of the total arrival rate since random selection of the server to be dispatched will assign 1 3 of all calls to server 1. In a similar way, the transition rate from state {0 0 1} to state {0 1 1} must be 1 2 of the total arrival rate for, then, we have only two servers from which to randomly choose, and, in the long run, server 2 will be chosen half the time. Keeping this in mind, the complete set of flow equations can be built for this model. In evaluating the dispatch frequencies of unqueued calls ðf ½1Š ij Þ, the random nature of the dispatch policy must be taken into account, and appropriate formulas constructed. For example, the dispatch frequency of server 2 to atom 3 is obtained by combining: the probability that the incoming call comes from atom 3, which is l 3 /l; of the probability that all servers are free; 1 3 half the probability that server 2 is one of two free servers; and the probability that server 2 is the only free server. The resulting expression is thus: f ½1Š 23 ¼ (l 3/l){(1/3)p (1/2)(p 001 +p 100 )+p 101 }. The dispatch frequencies for servicing queued calls can be evaluated using the usual formulas. Taking again the dispatch frequency of server 2 to atom 3, this frequency is evaluated as the joint probability that all servers are busy (P S ), that the call to be serviced comes from atom 3 (l 3 /l), and that the first server to become free is server 2 (m 2 /m). This results in: f ½2Š 23 ¼ P S(l 3 /l)(m 2 /m). Model III is a partial backup model. It assumes that each atom is the home location of a server, and that a server can only service calls from its preferential atom and from the second closest atom. Server 1, for example, can take calls from atoms 1 and 2 but not from atom 3. The corresponding dispatch matrix is shown in Table 5.

7 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 7 It may be assumed that the decision to not dispatch server 1 to atom 3 is based on the existence of a secondary service system to handle such a call; a zero-capacity waiting line model thus seems appropriate. The flow equations of the system can be built in the usual way. Care must be taken, however, when calculating some of the upward transition rates. Consider state {0 1 1}, for example, where servers 1 and 2 are busy and server 3 is free. A call from atom 1 will not change the state of the system because it cannot be serviced by server 3 (Table 5); the call will be lost to the system. The upward transition rate from state {0 1 1} to state {1 1 1} will therefore be: (l 2 +l 3 ). The dispatch frequencies can be evaluated in two steps, bearing in mind that, in this model, all dispatches are without delay. The dispatch frequency of server 3 to atom 2, for example, will be evaluated as the joint probability that the incoming call has originated in atom 2, that server 2 is busy, and that server 3 is free: f ½1Š 32 ¼ (l 2 /l)(p 010 +p 011 ). The dispatch frequency of server i to atom j is defined simply as the fraction of all dispatches that send server i to atom j; so we would expect P i;j f ½1Š ij ¼ 1. Due to lost calls, however, the dispatch frequencies based on this formula will sum to less than one; in fact, they will sum to the fraction of calls serviced by the system (or, one minus the fraction of lost calls). For this reason, a second step is required in which results from the first step are normalized to sum one. In order to provide a more comprehensive view of the effects of server non-homogeneity, Table 6 shows the performance measures of the fast server as percentage deviations from the homogeneous system predictions for each of the three models, at different levels of non-homogeneity, for homogeneous demand and r ¼ From Table 6, the conclusions regarding Model I seem to hold for both Models II and III. Depending on the degree of server non-homogeneity, model predictions based on the simplifying assumption of homogeneity may be at significant variance with the non-homogeneous situation. In fact, when the fast server is 20% faster Table 5 Server dispatch preferences, partial backup Atom i Preferences 1st 2nd Table 6 Models I III: effects of server non-homogeneity on the performance of server 1 [fast server] (% deviations) Performance measure Model FSR (%) Workload r i I II III Dispatch frequency f i I II III Travel distance per dispatch Du i I II III Travel distance per call Du 0 i I II III

8 8 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] than the slow server, results may be up to 9% in excess of homogeneous system predictions. This excess may rise to 20.9% and 37.3% if the fast server is, respectively, 50% and 100% faster than the slow server Larger models The data discussed thus far are based on a three-server hypercube model. It seems reasonable to ask how useful is the insight provided by the analysis of such a small structure? To answer this question, larger models with the same structure as the three-server structure were used; namely, a network based on homogeneous demand areas (atoms) connected by one way ring-roads, one server per atom, with one fast and one slow server. The number of servers with average service rate is then: (total number of servers 2), the two remaining servers corresponding, respectively, to a fast and a slow server. Table 7 shows the percentage deviations from the homogeneous model predictions for workload and total dispatch rate, as a function of server type and number of servers. For all models, the total workload was set to 0.5, and the degree of non-homogeneity (as measured by FSR) to 1.5. The data displayed in Table 7 show that the insight provided by the three-server hypercube model holds for larger models as well. Table 8 shows the computing times (in seconds) needed to run the hypercube model, using, respectively, the exact and approximate methods. Note that the latter can only be used for homogeneous servers; the corresponding computing times thus refer to only the homogeneous case. Times for the exact method, on the other hand, refer to only the non-homogeneous case. All problems were run on a Pentium IV microcomputer with 3.0 GHz and 512 MB of RAM. It should be observed that figures shown in the preceding sections were all derived from simple models, specifically designed to show the effects of server non-homogeneity on performance measures of the hypercube model. In the next two sections, the same effects will be analyzed for two models associated with real-world problems. 3. Case study 1: SAMU-Campinas In this section, we analyze the effects of non-homogeneous servers in a practical application: the public emergency medical system of the City of Campinas (SAMU-Campinas), studied in Takeda et al. [11]. In 1998, Table 7 % Deviations from homogeneous model predictions Performance measure Server type Number of servers (%) Workload Fast Average Slow Dispatch frequency Fast Average Slow 12.7% Note: System workload ¼ 0.5. Fast to slow service rates ratio ¼ 1.5. Table 8 Processing times (s) for solving the hypercube model (exact and approximate methods) Solution method Number of servers Exact o Approx. o0.01 o0.01 o

9 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 9 SAMU-Campinas covered an area of 796 km 2 with approx. 909,000 inhabitants. This region had, at the time, 10 ambulances dedicated to emergency calls: two vehicles for advanced support (called VSAs), and the other eight for basic support (VSBs). The area was divided into five reporting regions (Central, North, South, East and West), while the emergency calls were divided into two classes: those for advanced support (advanced calls, for short), preferentially served by a VSA, and calls for basic support (basic calls), preferentially served by a VSB. The City s operational policy in 1998 included the following: VSAs and VSBs, when available for service, were to stay at system base (one of the public hospitals located within the Central region). If an advanced call arrives, the system dispatches an available VSA; if all VSAs are busy, then the system dispatches an available VSB; if all VSBs are also busy, the call is kept in a waiting list until either a VSA or a VSB becomes available. Similarly, if a basic call arrives, the system preferentially dispatches a VSB. The total number of queued calls (advanced and basic) is limited by the number of vehicles operating in the system, that is, usually up to 10 calls. If a new call arrives when the system is busy (i.e., 10 calls being served plus 10 calls waiting in line), then this call is immediately transferred to another emergency system. Takeda et al. [11] analyzed SAMU-Campinas using a hypercube queueing model composed of 10 atoms (each of the five regions was split into two atoms, one for advanced calls, the other for basic calls), and 10 servers (two VSAs and eight VSBs). The system obeyed the following preference dispatching rule: for advanced-call atoms (even-numbered atoms 2, 4, 6, 8 and 10), the primary servers are the VSAs with the backup servers being the VSBs. For basic-call atoms (odd-numbered atoms 1, 3, 5, 7 and 9), the primary servers are the VSBs with the backup servers being the VSAs. This policy thus considers priorities on both the type of call and type of server, allowing the separate computation of performance measures that are of key importance to the system: the mean travel times for each type of call; the workloads for each type of server and call; the fraction of advanced calls served by VSAs, and so on. This simple adaptation of the hypercube model to deal with priorities is referred to as the layering of reporting regions [9]. The resulting model involves the solution of systems of 2 10 linear equations; it was solved using the Gauss elimination method. Additional details on the model can be found in [11]. The arrival rates (advanced and basic) are considered exponentially distributed with the following values (calls per hour): l 1 ¼ , l 2 ¼ , l 3 ¼ , l 4 ¼ , l 5 ¼ , l 6 ¼ , l 7 ¼ , l 8 ¼ , l 9 ¼ and l 10 ¼ (l ¼ P 10 j¼1 l j ¼ 5:4054), all measured in a certain peak period of the system [11]. The service times (VSAs and VSBs) are also considered exponentially distributed with values m 1, m 2,..., m 10, measured in the same peak period. At the time data were collected, all service rates were similar (approximately one call served per hour) due mainly to the system configuration (all ambulances located in the Central Region). The validity of the exponential distribution assumptions here is supported by data presented in [11]. The mean travel times between atoms and the mean on-scene service times are different for the VSAs and VSBs: the former travel faster (approximately 20% faster) than the VSBs; on the other hand, the on-scene times of the VSAs are, on average, higher (5% higher). The combination of these characteristics, together with the centralized configuration, yields very similar mean service times for the VSAs and VSBs (63 and 66 min, respectively). For current purposes, we initially considered all servers (VSAs 1 and 2 and VSBs 3, 4,..., 10) to have mean service times of 1 h (i.e., as if they were homogeneous with service rates m 1 ¼ m 2 ¼? ¼ m 10 ¼ 1 calls per hour; m ¼ P 10 i¼1 m i ¼ 10). We also used the arrival rates for each atom and the mean travel times between atoms as computed in [11]. The servers share the overall system workload using the priority dispatching policy mentioned above. (For advanced atoms, the primary servers are the VSAs, and the backup servers the VSBs; for basic atoms, the primary servers are the VSBs with the backup servers being the VSAs.) The maximum number of calls allowed in the waiting line is 10. The first data columns of Tables 9 and 10 show the workloads (r i ), and mean travel times (Tu i )[Table 9] of the servers, and the mean travel times to the atoms (Ta j )[Table 10], all of which were obtained for what we call Configuration 1. Note that, similar to the travel distance per dispatch Du i in Section 2, Tu i (Ta j ) is the weighted average of the travel times (where the dispatch frequencies are the weights). The corresponding formula s numerator is the weighted sum of the travel times while the denominator is the total dispatch frequency of the server. Tu i and Ta j are therefore mean travel times per dispatch.

10 10 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Table 9 Workloads (r i ) and mean travel times (Tu i ) of servers, in minutes: comparison between Configurations 1, 2 and 3 homogeneous versus non-homogeneous servers Server i (VSAs and VSBs) Configuration 1 Configuration 2 Configuration 3 m 1 ¼? ¼ m 10 ¼ 1 m 1 ¼ m 2 ¼ 0.5, m 3 ¼? ¼ m 10 ¼ m 1 ¼ m 2 ¼ 2, m 3 ¼? ¼ m 10 ¼ 0.75 r i Tu i r i Tu i r i Tu i VSA VSA VSB VSB VSB VSB VSB VSB VSB VSB Table 10 Mean travel times (Ta j ) to atoms (advanced and basic), in minutes: comparison between Configurations 1, 2 and 3 homogeneous versus non-homogeneous servers Atom j (advanced and basic) Configuration 1 Configuration 2 Configuration 3 m 1 ¼? ¼ m 10 ¼ 1 m 1 ¼ m 2 ¼ 0.5, m 3 ¼? ¼ m 10 ¼ m 1 ¼ m 2 ¼ 2, m 3 ¼? ¼ m 10 ¼ 0.75 Ta j Ta j Ta j Advanced Advanced Advanced Advanced Advanced Advanced Basic Basic Basic Basic Basic Basic All As one would expect, the workload is equally shared by all servers of the same type (VSAs and VSBs), where the mean travel times of the VSAs are, on average, shorter than those of the VSBs since the former are generally more time efficient (see Table 9). Substantial improvements can be realized in this emergency system by decentralizing part of the VSBs located in the Central region, as shown in [11]. Tables 9 and 10 compare the results of Configuration 1 with two possible variations: Configuration 2, with m 1 ¼ m 2 ¼ 0.5 and m 3 ¼ m 4 ¼? ¼ m 10 ¼ 1.125, and Configuration 3 with m 1 ¼ m 2 ¼ 2 and m 3 ¼ m 4 ¼? ¼ m 10 ¼ 0.75, both of which also satisfy m ¼ P 10 i¼1 m i ¼ 10 calls per hour (i.e., system capacity remains unchanged). Note that in Configurations 2 and 3 we, respectively, halve and duplicate the VSA service rates with respect to Configuration 1. In addition to the expected effect of changes in service rates on server workloads (r) (Table 9), observe that the impact of servers on mean travel time (Tu i in Table 9) and the atoms (Ta j in Table 10) are relatively small.

11 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 11 This is in spite of substantial variations in the service rates. Although demand is not perfectly homogeneous, and the dispatch priorities are not totally random in the present case (because of the layering of regions), current results are in accordance with those obtained for Model II in Table 6. In the latter case, travel distance per dispatch of the servers (Du i ) were not affected by the non-homogeneity of the servers. (See Table 6, Model II, for information related to the fast server; results for the slow and average servers were the same.) We also ran configurations that are not reported in Table 10. Fig. 2 illustrates the variation of mean travel times to advanced calls (Series 1 in the figure) and to all calls (Series 2) for service rates of the VSAs varying from 0.1 to 4 calls per hour (or, equivalently, for service rates of the VSBs varying from to 0.25 calls per hour). Note that as we increase the service rates of the VSAs (or, equivalently, reduce the service rates of the VSBs), the mean travel time to all calls diminishes (see Series 2 of Fig. 2) because the VSAs service more calls than do the VSBs, and their travel times are shorter. On the other hand, the mean travel time to an advanced call increases as the service rates of the VSAs become: (i) too small (less than 0.5 in Configuration 2), as the VSAs become less available to service advanced calls, or (ii) too large (greater than 2 in Configuration 3), as the VSBs become less available to service basic calls. It is worth mentioning that the behavior of travel times could not be evaluated with this level of detail if the analysis were limited to homogeneous servers. Another important advantage of considering non-homogeneous servers in the hypercube model involves the calibration process of mean service times (m 1 i ). In certain emergency systems, travel time can represent a significant proportion of total service time. In SAMU-Campinas, for instance, travel time from the operational base to the locale of the call corresponds, on average, to 12% of the total service time of VSAs and VSBs [11]. As this proportion increases, adjustment of the mean service time of each ambulance becomes more important in order to reflect the effects of relevant geographic factors. This may also have importance for the analysis of scenarios where some, or all, ambulances, are decentralized. The approximate method of Larson [22] to solve the hypercube model assumes that the m i s are the same for all servers and inputs to the model, independent of both server location and dispatching policy. With exact methods (considering the servers as non-homogeneous), it is possible to compute the m i s as outputs of the model (as functions of the system configuration). This can involve a calibration process using the iterative procedure of Larson and Odoni [9]. As a matter of illustration, Table 11 presents the results obtained for Configuration 1 following the calibration process. In this experiment, we considered as model inputs the on-scene service times, assumed exponentially distributed with means of 50 min (Configuration 1a) and 40 min (Configuration 1b); that is, 15 Mean travel times Travel times (min) Series1 Series Service rate of the VSA's Fig. 2. Mean travel times to advanced calls and to all calls.

12 12 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Table 11 Workloads (r i ), mean server travel times (Tu i ) and mean travel times to atoms (Ta j ), in minutes: comparison between Configurations 1a and 1b Server i Configuration 1a Configuration 1b Atom j Configuration 1a Configuration 1b r i Tu i r i Tu i Ta j Ta j VSA Advanced VSA Advanced VSB Advanced VSB Advanced VSB Advanced VSB Advanced VSB Basic VSB Basic VSB Basic VSB Basic Basic Basic All approximately 83% and 67% of the mean service time of Configuration 1 (m 1 i ¼ 1 h), respectively (in SAMU- Campinas, the mean was 53 min [11]). We sought the mean travel times (Tu i s) and service rates (m i s) of the ambulances. After calibration (five iterations were necessary for a precision of 10 6 in the m i s), the initial values m 1 ¼ m 2 ¼? ¼ m 10 ¼ 1 changed to m 1 ¼ m 2 ¼ , m 3 ¼ m 4 ¼? ¼ m 10 ¼ (Configuration 1a), and to m 1 ¼ m 2 ¼ , m 3 ¼ m 4 ¼? ¼ m 10 ¼ (Configuration 1b). Note that, in both cases, the overall capacity of the system was modified with respect to Configuration 1: Configuration 1a resulted in m ¼ 9.4 (o10) calls per hour, whereas Configuration 1b yielded m ¼ 11.2 (410) calls per hour. Comparing Tables 9 and 10 with Table 11, we observe that changes in the server workloads can be substantial. The effect on more aggregate performance measures, such as mean travel time, however, was relatively small. This was expected given the results of Model II in Section 2 (see the 0% deviation in travel distance per dispatch for the fast server in Table 6; results for the slow and average servers were the same). 4. Case study 2: Anjos do Asfalto In this section, we revisit the case of an emergency medical system on a Brazilian highway, named Anjos do Asfalto, which was analyzed in Mendonc- a and Morabito [12]. In , this system consisted of a central station and six fixed bases located along the highway connecting Rio de Janeiro and Sao Paulo. Each base had an ambulance that, when available for service, was in the base. The allocation of ambulances to service accidents is coordinated in the following way: when there is an accident, the central station is called and immediately dispatches, to the site of the accident, the ambulance of the base that is closest to the scene. If that ambulance is busy (unavailable), the central station dispatches the ambulance of the second nearest base. If this ambulance is also busy, the central station transfers the call to another emergency system, usually a local system (generally unable to provide service with the quality available from the highway emergency medical system). Under these circumstances, the call is said to be lost. Notice that given this dispatching policy, the system will never have a queue of waiting calls. Mendonc- a and Morabito [12] analyzed the system Anjos do Asfalto using a hypercube queueing model composed of 10 atoms and six servers, which followed the partial backup dispatching policy described above. The model involves systems of 2 6 linear equations, which was solved using the Gauss elimination method. (More details of the model can be found in [12].) In that paper, the user interarrival times were considered exponentially distributed with the following rates (arriving calls per minute): l 1 ¼ , l 2 ¼ , l 3 ¼ , l 4 ¼ , l 5 ¼ , l 6 ¼ ,

13 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 13 l 7 ¼ , l 8 ¼ , l 9 ¼ and l 10 ¼ (i.e., l ¼ P 10 j¼1 l j ¼ 0:018), measured during a selected peak period of the system. The service times were also considered exponentially distributed with the following rates (served calls per minute): m 1 ¼ 0.019, m 2 ¼ 0.014, m 3 ¼ 0.017, m 4 ¼ 0.010, m 5 ¼ and m 6 ¼ (i.e., m ¼ P 6 i¼1 m i ¼ 0:097), measured in the same peak period. The validity of the exponential distribution assumptions in this system is supported by data presented in [12]. The loss probability of a call and the overall mean travel time to a call were approximately 5% and 8.6 min, respectively. Table 12 compares the original results (Original Configuration) with those obtained assuming homogeneous servers (Homogeneous Configuration), with all servers having the same service rate: m 1 ¼ m 2 ¼? ¼ m 6 ¼ (note that the original overall capacity m ¼ is maintained). Note that differences between the server workloads in the two configurations can be substantial (e.g., 29% for server 4 and +29% for server 5). On the other hand, differences in more aggregate performance measures, such as mean server travel time, were not necessarily significant (Table 12). Thus, system loss probability and overall mean travel time vary less than 5% between the two configurations. In order to highlight the effect of non-homogeneous servers in the current study, we arbitrarily chose a configuration with very different servers (Very Heterogeneous Configuration), in which the service rate of the ambulance in base i is twice that of the ambulance in base (i 1), that is: m 1 ¼ , m 2 ¼ , m 3 ¼ , m 4 ¼ , m 5 ¼ and m 6 ¼ (note that the overall capacity is maintained, i.e., m ¼ P 6 i¼1 m i ¼ 0:097 calls per minute). Table 13 compares results of the Homogeneous Configuration with those obtained for the Very Heterogeneous Configuration. Observe that for some servers the difference in mean travel time is substantial (e.g., from 7.5 to 12.2 min for server 2). In some sense, this was expected; refer to Model III in Section 2. In this model, the demand is perfectly homogeneous and the calculations were made for r ¼ 0.5. Notice that in Table 12 the demand is not homogeneous and the workloads are below 0.5. Although the Very Heterogeneous Configuration and Model III are not strictly comparable, the trend observed in Table 12 is to some extent present in that model (see Table 6). System loss probability and the overall mean travel time vary from 4.8% to 16.7%, and from 8.3 to 9.7 min, respectively. Finally, in order to illustrate the benefits of using non-homogeneous servers in the process of calibrating average service times (m i 1 ), we performed an experiment assuming that the on-scene service times are exponentially distributed with means of 60 min (Configuration calibrated with 60 min) and 50 min (Configuration calibrated with 50 min). The mean on-scene service time of Anjos do Asfalto belongs in this interval, as reported in [12]. After calibration, the initial values: m 1 ¼ m 2 ¼? ¼ m 6 ¼ changed to those presented in Table 14. Notice that in both cases the overall system capacity differs from that of the Homogeneous Configuration: In the first case, the capacity is m ¼ (o0.0970), whereas in the second this capacity is m ¼ ( ). It should be noted that in Table 14, although some values of m i and r i have deviations larger than 10% from corresponding values in the Homogeneous Configuration, the deviations between mean travel times, Tu i, are relatively small (less than 5%). The variations in Tu i are consistent with the results of Section 2 (observe the 4.2% variation shown for the fast server of Model III in column FSR ¼ 1.2 of Table 6). System loss probability and the overall mean travel time of the configurations calibrated with 60 and 50 min are 5.8% and Table 12 Workloads (r i ) and mean server travel times (Tu i ), in minutes: Comparison between the Original and the Homogeneous Configurations Server i Original Configuration Homogeneous Configuration % Deviations r i Tu i r i Tu i r i Tu i

14 14 R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] Table 13 Workloads (r i ) and mean server travel times (Tu i ), in minutes: comparison between the Homogeneous and the Very Heterogeneous Configurations Server i Homogeneous Configuration Very Heterogeneous Configuration Deviations (%) r i Tu i r i Tu i r i Tu i Table 14 Service rates (m i ), workloads (r i ) and mean server travel times (Tu i ), in minutes: comparison between the Homogeneous Configuration and Calibrated Configurations Server i Homogeneous Configuration Configuration calibrated with 60 min Configuration calibrated with 50 min m i r i Tu i m i r i Tu i m i r i Tu i %, and 8.5 and 8.2 min, respectively. They also do not differ substantially from values reported for the Homogeneous Configuration. 5. Concluding remarks In this paper, we studied the effects of considering homogeneous versus non-homogeneous servers in practical applications of the hypercube model. We initially presented illustrative examples with centralized and decentralized home locations of servers, fixed and random preference dispatch policies, total and partial backup, and infinite and zero-capacity waiting lines. Experiments with these examples showed that, depending on the degree of non-homogeneity of the servers, model output measures can differ substantially from the homogeneous case to when non-homogeneous servers are considered. These results imply that, in order to appropriately analyze the situations mentioned above, as well as other situations that may arise in practical applications, decision- and policy-makers should at least consider the use of non-homogeneous hypercube models. We then analyzed two practical applications of the model requiring the use of non-homogeneous servers. In these applications, the servers had different average service times depending on the type of service offered and their home locations. Variations in average service times had their expected impact on server workloads. The effects on aggregate output measures such as mean travel time, however, were relatively small when considering homogeneous versus non-homogeneous servers. Although the effects on aggregate output measures were more significant in the illustrative examples of Section 2, the results presented in the current paper still suggest use of non-homogeneous servers in selected real-world applications. Also noteworthy is that it would have not been possible to evaluate the behavior of travel times at the level of detail done here had the analysis been limited to homogeneous servers.

15 Another advantage of considering non-homogeneous servers in hypercube models is the calibration of mean service times. In certain emergency systems, travel times may represent significant fractions of total service times. Further, as these fractions increase, the adjustment of mean service times becomes important in reflecting the effects of various geographic factors and dispatching policies on servers. An accurate service time calibration in such cases thus suggests the need to consider non-homogeneous servers. It is worth mentioning that in order to solve the hypercube model for non-homogeneous servers, highly time-consuming exact methods must be used since the approximate method of Larson [22] assumes that servers are homogeneous. For larger systems, exact methods become computationally prohibitive, especially when embedded into optimization schemes that require repeated solutions of the hypercube model. An alternative for evaluating systems with non-homogeneous servers that are too large for hypercube techniques is discrete simulation. Extensions of the approximate method to deal with non-homogeneous servers are currently limited to situations with no waiting lines [15]. An interesting topic for future research would thus be the development of approximate methods for other non-homogeneous applications, such as those considered in this paper. Another possible line of research would involve the embedding of these methods into optimization procedures for the design and planning of large emergency systems. Policy implications of the present work suggest that a detailed and accurate statistical analysis of the data pertaining to a given application must precede the design of server-to-customer systems. Issues such as appropriate home locations of servers, the nature of dispatch policies, backup systems, the relative magnitude of travel times, and the nature of resulting waiting lines must be carefully considered in light of the corresponding data. It would then be possible to determine whether a simplified model with homogeneous servers could suffice to correctly describe the system under design, or whether a more sophisticated model with non-homogeneous servers would need to be considered. Acknowledgments R. Morabito et al. / Socio-Economic Planning Sciences ] (]]]]) ]]] ]]] 15 The authors thank two anonymous referees and Prof. Barnett R. Parker for their useful comments and suggestions. This research was supported by the Brazilian National Research Council (CNPq Grants / 01-2, /03-3, /95-7) and by FAPERJ, the Research Foundation of the state of Rio de Janeiro (FAPERJ Grant E26/ /2000). References [1] Larson RC. A hypercube queueing model for facility location and redistricting in urban emergency services. Computers & Operations Research 1974;1: [2] Brotcorne L, Laporte G, Semet F. Ambulance location and relocation models. European Journal of Operational Research 2003;147: [3] Kolesar P, Swersey AJ. The deployment of urban emergency units: a survey. In: Swersey A, Ignall E, editors. Delivery of urban services TIMS studies in the management sciences, vol. 22. Amsterdam: Elsevier Science B.V.; p [4] Swersey AJ. The deployment of police, fire and emergency medical units. In: Pollock SM, editor. Handbooks in OR & MS, vol. 6. Amsterdam: Elsevier Science B.V.; p [5] Brandeau ML, Larson RC. Extending and applying the hypercube model to deploy ambulances in Boston. In: Swersey A, Ignall E, editors. Delivery of urban services TIMS studies in the management sciences, vol. 22. Amsterdam: Elsevier Science, B.V.; p [6] Burwell TH, Jarvis JP, McKnew MA. Modeling co-located servers and dispatch ties in the hypercube model. Computers & Operations Research 1993;20: [7] Chelst KR, Barlach Z. Multiple unit dispatches in emergency services: models to estimate system performance. Management Science 1981;27(12): [8] Sacks SR, Grief S. Orlando Police Department uses OR/MS methodology, new software to design patrol districts. OR/MS Today 1994;February:30 2. [9] Larson RC, Odoni AR. Urban Operations Research. EnglewoodCliffs, N.J: Prentice Hall, Inc.; [10] Larson RC. OR models for homeland security. OR/MS Today 2004;31:22 9. [11] Takeda RA, Widmer JA, Morabito R. Analysis of ambulance decentralization in an urban emergency medical service using the hypercube queueing model. Computers & Operations Research 2007;34(3): [12] Mendonc-a F, Morabito R. Analysing emergency medical service ambulance deployment on a Brazilian highway using the hypercube model. Journal of the Operational Research Society 2001;52: