5.4.1 Some Uses of the Model

The hypercube queueing model represents an important planning tool that can be used in a variety of applications by planners and administrators of service agencies operating in the server-to-customer mode. In this section we briefly describe several applications that we feel are likely to be important in many cities and towns.

Police-beat design. Suppose that a city's police department has not redesigned its beats (sometimes known as "sectors") for many years. Then, owing to changing population patterns and other factors in the evolution of the city, the distribution of crimes and other incidents that give rise to calls for police service are likely to have changed significantly from the time of last beat design. This could result in an intolerable situation in which some patrol officers are working considerably longer hours responding to calls than are others. Compounding the problem, crime preventive patrol is probably least prevalent in the high-workload areas, since the high call-for-service workload in these areas sharply reduces the time available for patrol; yet, it is probably these areas that most need such patrol.

In this case the model can be used to assist the police planner in redesigning beats to correct the current imbalances. The model provides outputs on travel times, workloads of each police vehicle, preventive patrol frequencies, and other factors that allow simultaneous consideration of response-time reduction, workload balancing, preventive patrol strength, and so on. The model reveals the trade-offs one must confront in attempting to reach acceptable performance in each of these categories.

In using the model the police planner must specify the beat configuration that he or she desires. Then the model computes the numerical values for each of the performance measures (e.g., travel times, etc.). Undoubtedly, each police planner will have his or her own set of issues-some quantitatively oriented and some not-that will be important in the beat-design process. For instance, the well-known police planner 0. W. Wilson⁴ focused heavily on workload balancing in his recommended beat-design procedures. In most cases, however, regardless of the planner's particular set of issues and their relative priorities, the model described here should be useful in his or her thinking primarily because it computes rapidly and effectively many operationally oriented performance measures that come into play in the beat-design process.

Response-area design for ambulances or emergency repair vehicles. Suppose that an agency administrator disperses ambulances or emergency repair vehicles throughout the city, prepositioning them in a way that best anticipates likely calls for emergency service. Then, the system planner needs assistance in determining good locations for the units and reasonable areas of primary responsibility for each. The model can be used for this purpose, in much the same way as a police planner would use it to design police beats. Here, however, the positions of the vehicles (while not responding to emergencies) are most likely fixed at preselected sites, whereas the police cars are likely to patrol throughout their beats. And the time for an ambulance to service a medical emergency usually includes travel time to and from a hospital (to transport the patient), a time not experienced in the police example (except when transporting arrestees to a police stationhouse). So in the ambulance case it is much more likely that travel times (time to the scene, time from the scene to the hospital, time from the hospital back to the prepositioning site) will play a dominant role in the overall time required per incident. This effect should be less prevalent in the emergency repair case. (In the police case, on-scene service time is usually significantly greater than travel time.)

Thus, the ambulance or emergency repair system planner can use the model to explore the consequences of alternative prepositioning sites for his vehicles and alternative districts of primary responsibility for each. Since travel times play such an important role in ambulance services, it is likely that the emergency medical planner will have to adjust the service time of each ambulance separately to reflect the different geographical travel time factors affecting each one. The emergency repair system planner may or may not have to do this. If adjustment is necessary, the hypercube model does allow server-specific mean service time calibration (see Section 5.3.1).

The final site selection and district design could include factors of workload balance, travel-time reduction, neighborhood integrity, and so on. Again, analogous to the police-beat example, the exact trade-off among the various factors must be determined by the user of the model, not by the model itself.

Nonscheduled social service home visits. Consider a social service agency that "dispatches" personnel to demandresponsive home visits. The personnel could be social workers, physicians, or practical nurses.

Suppose that personnel at a number of facilities, each containing one or more "response agents," decide to provide service cooperatively throughout the city or part of the city. A person requiring service at home would call a central number and one of the response agents in the closest facility would be dispatched, if at least one is available. If not, an agent from a nearby facility would be dispatched, if at least one is available. Otherwise, the service request would enter a queue of other waiting requests.

In this case the hypercube model could be used to examine the consequences of assigning different numbers of response agents to each of the facilities. It could also be used to explore questions of facility (re)location, consolidation, and so on.

Note that in this application several servers may be at the same location, and thus the dispatcher most likely would treat each of them equally, since they all have identical travel times. However, if one of the available social service agents is more familiar with a particular family's situation, he or she may be preferred by the dispatcher. Statistically, preferences based on such microscopic matters should "balance out," and the agents at any particular facility would appear to be "tied" for dispatch preference.

Demand-responsive delivery. The hypercube model could also be used to model certain demand-responsive delivery systems. The model would apply in at least two alternative system configurations: centralized or decentralized.

1. Centralized. In a centralized or coordinated system, an individual requiring delivery of a particular item (part for an automobile or computer, pizza, etc.) would call a centralized number. A dispatcher there would assign a free truck in a facility near the caller to deliver the item, paralleling the social service application above. If no truck is available, the request would be entered in a queue of waiting requests.

2. Decentralized. In a noncoordinated system, the individual requiring delivery of the item may first call the closest (or otherwise most preferred) agency to request the delivery. Then, either that agency dispatches a truck to the caller or the caller decides that the delay would be too great (the agency is "busy") and then calls a secondmost-preferred agency. He or she continues this sequential calling process until an agency is found that is sufficiently "available" to provide an acceptable response time. Interestingly, a determined caller could yield a "system" performance equivalent to that of the centralized system.

Each of the agency-specific examples above can be varied over a rather wide spectrum of management or planning options. The next several sections illustrate some examples from this spectrum.

Assigning bilingual personnel. Suppose that personnel in a particular response unit are bilingual, fluent in English and a second language (say Spanish, Chinese, Portuguese, German, Italian, or some other language predominant in one or more sections of the city). Then the planner using the model (for response-area design or any other purpose) would want to be careful to give first preference to this bilingual unit in responding to requests for service from each neighborhood having the second language as its primary language. This consideration of matching the service capabilities of the unit to the needs of the neighborhood would probably outweigh narrow efficiency considerations such as minimizing travel times.

The planner using the model can specify that the dispatching process is such that this specialized unit will be assigned to any service request from these neighborhoods, provided that the unit is available when the request arrives. If not, then another (less preferred) unit would be assigned to the request.

The planner may wish to explore various prepositioning sites or patrol areas for the bilingual unit as well as for other units within the area under study.

Units of last resort. Given any one of the agency-specific applications above, we might imagine a situation in which all the regular response units would be simultaneously busy. Then a service request that arrives during that time might be handled by one of several "units of last resort." These units would not ordinarily be used in the routine assignment of units to service requests; however, they would be called upon during heavy workload conditions to avoid the formation of (or reduce the probability of) queues.

In practice, these units of last resort could be sergeants' cars (police), mobile cardiac care units (emergency medical services), social service supervisors (for nonscheduled home visits), or other backup personnel (for demand-responsive delivery and emergency repair services).

The user of the model can easily replicate this situation by adjusting the dispatching strategy to assign last preference to the units of last resort. In this way, the model assigns the regular response units to all service requests in the area as long as there are regular units available. However, whenever they are all simultaneously busy, the model (replicating the actual dispatcher) will assign the units of last resort to requests for service. Given this added complication, the user can still address issues of workload balance, responsetime reduction, prepositioning, and so on. This would include a calculation of the request-for-service workloads of the "last-resort" units and a calculation of how frequently they respond into each of the neighborhoods in the area.

Overlapping police beats. Most police departments, when considering the beat-design process, view beats as separate nonoverlapping areas where primary responsibility can be assigned to one patrol unit. However, we appear to be seeing more and more variations on a new theme-overlapping beats, where the same neighborhood(s) will be patrolled by two or more police cars. The model will allow exploration of a wide variety of such overlapping beat plans.

Example 1

One large U.S. city has "umbrella cars," each of which is assigned to patrol two regular (touching) beats. Thus, if beats A and B are side by side, they will be patrolled by car A (patrolling beat A), car B (patrolling beat B), and an umbrella car (patrolling both beats A and B). The dispatching strategy for calls from beat A is usually to assign car A, if available, and otherwise to try (in sequence) car B, the umbrella car, and finally, other cars in the command area.

Example 2

Another large U.S. city divides each command area into two or more sergeant's zones. Each sergeant's zone has assigned one sergeant's car and several regular patrol cars. These patrol cars share patrol responsibility for the entire zone, and there are no regular beats within the zone.

Example 3

Several smaller communities divide their area into regular beats, but assign two patrol cars to each beat. This is perhaps the simplest form of overlapping beat structure.

These and other overlapping beat structures can be studied-in terms of the quantities computed from the model-by the police planner. With overlapping beats, it is especially difficult to predict ahead of time the requestfor-service workloads or preventive patrol levels of each of the units. The model performs this task, in effect aiding the planner in considering the many different factors that come into play.

Similar policies can be studied by any (nonpolice) agency that employs mobile rather than fixed-position units.

Priorities. While many server-to-customer services place priorities on the types of calls they receive-either explicitly or implicitly-it is often not necessary to consider these priorities directly in the model for planning purposes of response area or beat design, positioning, and so on. For those cases in which priorities must be included in the model, the user can adapt the model to reflect a certain limited class of priority call-handling and dispatching procedures. However, complicated priority-oriented procedures cannot be treated by the model-and this is perhaps the model's largest single limitation at its current state of development.

As an example of a situation that can be treated by the model, consider a city that has one emergency medical unit specializing in cardiac arrests ("heart attacks"). If a cardiac arrest is reported from anywhere within the city and if the special unit is available for dispatch, it is assigned to the incident. Otherwise, another (nonspecialty) unit is assigned. To model this situation, the user essentially splits each reporting area into two reporting areas-one generating cardiac arrest calls and the other generating all other emergency medical calls. Then the cardiac arrest unit is given first dispatch preference for all "cardiac arrest reporting areas." This way of adapting the model to a special type of service request and a special type of unit will allow the user to compute separately the travel times to each type of request, the workloads of each of the units for each type of request, the fraction of cardiac arrest calls handled by the cardiac arrest unit, and so on.

If additional types of specialty units and/or service requests are considered, such as paramedic versus EMT-1 units,⁵ this procedure of splitting reporting areas by type of request can be continued into three, four, or more splits. We call this process "layering" of reporting areas. However, our experience is that the volume of data produced by the model can quickly overwhelm the user and obscure simple relationships that (s)he could more readily see if there were fewer priority levels. Thus, there exists an important trade-off between the fine-grained detail of the system replicated by the model and the ability of the user to comprehend, interpret, and act intelligently upon the output of the model.

An EMT-1 person is someone who has received approximately 81 classroom hours of emergency medical training; a paramedic typically receives about 1,000 hours of training.

The model cannot be used to study the following types of priority dispatching schemes:

1. Selective stacking (queueing) of low-priority requests to await the attention of the server having those requests in its primary response area.

2. Preemption (interruption) of a unit on a low-priority service request to send it to a high-priority request.

3. Priority-oriented schemes for dispatching requests delayed in queue.

If the system planner wishes to analyze these types of operation (which may be very important in a particular application), he or she should probably use a simulation model (see Chapter 7).

The foregoing examples have described a variety of applications of the model. There are many others, and these become apparent by using the model, first for the simpler applications and then-as confidence and familiarity with the model build in the model user-in more advanced applications.

⁴ See, for example, 0. W. Wilson, and R. C. McLaren, Police Administration, McGrawHill, New York, 1977.