Computer-assisted dispatch

. The central idea is that persons in a dispatch center are able to easily view and understand the status of all units being dispatched. CAD provides displays and tools so that the dispatcher has an opportunity to handle calls-for-service as efficiently as possible.

CAD typically consists of a suite of software packages used to initiate public safety calls for service, dispatch, and maintain the status of responding resources in the field. It is generally used by emergency communications dispatchers, call-takers, and 911 operators in centralized, public-safety call centers, as well as by field personnel utilizing mobile data terminals (MDTs) or mobile data computers (MDCs).

CAD systems consist of several modules that provide services at multiple levels in a dispatch center and in the field of public safety. These services include call input, call dispatching, call status maintenance, event notes, field unit status and tracking, and call resolution and disposition. CAD systems also include interfaces that permit the software to provide services to dispatchers, calltakers, and field personnel with respect to control and use of analog radio and telephony equipment, as well as logger-recorder functions.

Manual dispatching

Computer-assisted dispatching improves the efficiency and accuracy of each step of the manual process:
* The call taker records the details on a paper card and offers advice to the caller.
* The paper card is passed by hand or sent on a conveyor belt or pneumatic tube to the dispatcher.
* The dispatcher allocates the task to one or more available mobile units depending on each units capability and location.
* The dispatcher passes the details of the task to the mobile unit by reading the details over two-way radio or telephone.
* The mobile unit advises the dispatcher of their progress through the task till its completion which are recorded on a paper log.
* Paper logs can be reviewed afterwards for accounting for services and investigating problems with service delivery.

Computer-assisted Dispatch Methodology

s located in a central dispatch office, which communicate with computer terminals in a Communications Center or with mobile data terminals installed police vehicles. There are a multitude of CAD programs that suit different department needs, but the fundamentals of each system are the same. They include:

* Log On/Off times of Police Personnel (sworn/non-sworn)
* Generating and archiving incidents that begin with a phone call from a citizen or originate from personnel in the field
* Assigning field personnel to incidents
* Updating Incidents and logging those updates
* Generating Case Numbers for incidents that require an investigation
* Timestamping every action taken by the dispatcher at the terminal

In an ideal setting, a call is received by a call-taker and information about the call is inputted into the CAD template. Simply, Location, Reporting Party and Incident are the main fields that have to be populated by type-codes. For example, if there was a Burglary in progress, the type-code for that Incident could be "BURG"; when BURG is typed out, then the program will spell out "BURGLARY (in progress)". If the Location was at the 1400 block of Madison, the type-code could be "14MAD." The Reporting Party information would be populated by the call-taker including Last Name, First Name, Call-Back number, etc.

A typical CAD printout looks something like this based on the example above:

----------------------------------- LOCATION - 1400 Madison RP - Doe, John, 555-5555, 1404 Madison INCIDENT - BURGLARY (in progress) SYNOPSIS - "Caller reports a possible burglary in progress based on seeing individuals inside the residence/Caller advises 2 persons inside the location and call advises the current residents are on vacation." -----------------------------------

Again, granted as it can be seen that the fields are spelled out, the call-taker uses those abbreviations that are already predetermined in order to quickly gather and transmit the information.

The dispatcher then receives the call from the call-taker and is able dispatch the call to those available. The dispatcher's screen would show the available personnel that are dispatchable. A typical setting can be exemplified by this:

----------------------------------- INCIDENT # - 554123 LOCATION - 1400 Madison RP - Doe, John, 555-5555 INCIDENT - BURGLARY (In Progress) SYNOPSIS - "Caller reports a possible burglary in progress based on seeing individuals inside the residence/Caller advises 2 persons inside the location and call advises the current residents are on vacation." UNITS - 746 (Pri), 749 (Cov) ----------------------------------- Units available - (3) Units out of service - (2) 745 - Avail. 746 - Not Avail. Inc # 554121 747 - Avail. 748 - Avail. 749 - Not Avail. Inc # 554122 -----------------------------------

Everything that is gathered, dispatched and disposed is usually stored in a central server where the type codes reside in, or possibly another server. All of these calls which have incident numbers attached to them can be recalled by an internal search engine. For example, a request for a printout of all calls to Madison in the past hour could be gathered by querying the CAD program by Location:

Search by: Location LOCATION [ ] --- Result: (Now filled in) Search by: Location LOCATION [14MAD ] --- Result: (1) Incidents

CAD can be used in a multitude of ways, whether it is for radio logs, call logs or statistical analysis.

Consoles

Typical of local government dispatching facilities, the Denver RTD's facility is one example of a transit dispatch center. Communications consoles are mounted in desk-style electronics racks. Features include multi-line telephones. Modern facilities usually include a variety of computing systems for operational and administrative purposes.

Consoles serve as a human interface and connect to push-to-talk dispatch radio systems. Audio from all channels is processed through audio level compression circuits and is routed to two separate speakers identified as "select" and "unselect". Each has a volume control. The select channel or channels carry the highest priority communications. To prevent missed messages on critical channels, the select volume may be configured so it cannot be set to an inaudible level. Unselect channels may be used for special events, other agencies, or purposes that do not involve dispatch and may be inaudible. By pressing a button, any channel on the console can be toggled between select and unselect status. Each channel has an independent push-to-talk button, allowing the dispatcher to talk over one channel at a time. For broadcast messages, a single button transmits over all selected channels at the same time. A digital clock and an LED bar-graph VU meter are included.

Each channel has a label identifying it and indicator lights and buttons to control settings. A typical channel has a busy light, a call light, select light, select button, and a transmit button. The steady, red busy light indicates another dispatch position is transmitting on the channel. The flashing yellow call light indicates a field unit is talking on the channel. The call light usually blinks for several seconds after a transmission ends allowing a busy dispatcher to look up from a telephone call and determine which channel the last message came from.

Some console dispatch panels are actually a PC based application. Such is the case of Zetron's Acom system. This allows for easy customization and modification of the dispatch key layout.

There are special speakers available for select and unselect audio such as the JED unit that was specially designed by Ed Taylor of Zetron. The speaker features a clipping indicator LED and a heavy duty base to keep it from falling over. The base also serves as a strain relief for the speaker wiring. The audio quality is exceptional which is critical for public safety applications.

ervice levels and geographic information

Computerized mapping, Automatic vehicle location, Automatic number identification and caller-identification technology are often used to enhance the service by pinpointing the locations of both the client and the most suitable vehicle for serving the client.

Some CAD systems allow several sources of information to be combined. For example, adding automatic vehicle location (AVL) and geographic information (GIS) could improve service by getting units to a service call location faster. Ideally, CAD is connected to monitor vehicle locations provided by an AVL system. This information is used to suggest the closest vehicle to an event. How is the closest unit determined?

Basic zone system

The simplest system is a beat or zone map system. For example, in a community with four fire stations, a grid is overlaid on a community map. Each zone of the grid is identified with a progression of police beats, ambulance zones, transit zones, or fire stations. [This would work for any system including taxis or parcel pick up.] One grid might be labeled: AB241. This means fire station 2, then 4, then 1, then 3 would respond to a fire call occurring inside this zone. The predefined order is created by persons with expertise in the service being provided, local geography, traffic, and patterns in calls for service.

Since only basic GIS information is included, if AVL was available, it would simply display service vehicle locations on a map. The closest unit would be interpreted by the dispatcher looking at vehicle locations projected on the map.

Where detailed geographic data are not available, units may be assigned based on the center of a district. To make the computing problem easier, the CAD system may use "centroids" to evaluate service vehicle locations. Centroids are estimated center points within a zone. The system calculates a distance from a fire station or AVL location to a centroid point. The closest fire station, according to CAD system rules, would be assigned. Systems may use centroids that are not exactly centered in order to skew or weight system decisions. Staff based at a fire station that is physically closer by drawing a straight line on the map may be slower to reach a zone. This can occur because responding units must drive around freeways, lakes, or terrain obstructions in order to reach a zone. A centroid may be moved because 200-car freight trains often block a railroad crossing used to access a particular zone.

This is the cheapest system to develop because it requires the least detailed geographic information and the simplest calculations. Another problem occurs where several services use the same system. Police and transit, for example, may have different ideas about what boundaries define the ideal zone or how centroids should be weighted.

CAD using geocoding

Geocoding is a translation system allowing addresses to be converted to X- and Y-coordinates. Someone placing a call for service has an address attached to a wired phone number or tells the dispatcher their address. For example, suppose the caller's address is "123 Main Street".

The GIS or CAD system includes a look-up table. The table may identify odd-numbered addresses in the community as being on the north and east sides of streets. Addresses from 113 to 157 Main Street are identified as being along Main Street's center line between Broadway and Washington. 123 is estimated to be on the north side of Main Street somewhere closer to 113 than 157. This estimate produces a latitude and longitude, or a set of Universal Transverse Mercator coordinates. The coordinates are close enough to identify the closest service vehicle. This system may automatically append the name of the nearest cross-street or intersecting street.

Again, the system uses a straight-line distance to determine which service vehicle is closest to a call for service. If an AVL system is used, the CAD will look through a list of most recent reported vehicle positions. Next, the positions are compared to the service vehicle status. The CAD system may identify several of the closest units that have a status of "available". The dispatcher makes an ideal choice from the CAD system shortlist.

This type of system is significantly more expensive than a zone system. The basic system may start with maps from the US Census Bureau or a county assessor's office. The quality of these maps may be good but will not be ideal for dispatching. There would normally be one or more persons on staff who would deal with data changes from new development, new streets, or data quality problems. The person would compile addresses and generate street centerlines in mapping software. Geocoding varies in accuracy depending on data sources and vendors. It normally takes years of work and planning before a system is implemented. Modern geocoded systems will often display service vehicle locations, the location of service calls, and the locations of callers on a map. This helps to disambiguate calls for service and reduces the likelihood of dispatching two reports of a single call for service as two separate calls.

Another problem comes from technologies using differing datums or coordinate systems. For example, suppose your AVL system uses degrees-decimal degrees format. The AVL display for a vehicle at the Heart Butte Post Office in Montana shows a latitude and longitude of 48.28333 N, -112.83583 W. The CAD system uses degrees-minutes-seconds format data and shows the same location as 481700N, 1125009W. How do you translate? This is sometimes a problem with neighboring CAD systems. Ideally, you should be able to send and receive calls to and from CAD systems in neighboring areas. What if the state or provincial government has standardized on a different coordinate system?

Full GIS/AVL integration

The most expensive and technically-challenging systems fully utilize the capabilities of GIS and AVL. In these systems, the street centerlines are described as "routable". In addition to geocoding and accurate street centerlines, intersections have attributes or scores. Can a service vehicle turn left from eastbound Carnegie Street onto northbound Hooligan Boulevard? A scoring system is used to assess the difficulty of making the turn. At one end of the scoring system there might be an interchange where service vehicles had unrestricted access in making the turn. Perhaps both streets are one-way, making it relatively easy to turn from one onto another. In the middle scores, a left turn might be blocked occasionally by heavy traffic, a draw bridge, or street cars. At the most difficult score, the two streets may cross but the lack of any interchange does not allow service vehicles to get from one to the other.

To calculate the closest service vehicles, the CAD system does a network analysis of the road system based on these routable street centerlines. It assesses the path from the service call to the AVL location of available vehicles. The system recommends the service vehicles with the shortest path.

Routable street centerlines take into account differences between northbound and southbound lanes on a freeway or turnpike. For example, to reach a point in the southbound lanes of a turnpike, service vehicles may need to drive north to the next exit then return on the southbound side. The analysis of a routable street network takes this into account so long as the event location is accurately reported. Routable systems account for barriers like lakes by calculating the distance of the driven route rather than a straight line distance. It is assumed the service vehicle driver knows the shortest path or that all drivers make similar numbers of wrong turns.

Concentration

CAD systems require support staff with special skills. This can lead to concentration of dispatch facilities, particularly where there is population growth or where automation is required to meet defined service objectives.

In any system, concentration of facilities increases risks of outages or massive failures. In a system where the call traffic is so high that advanced technology is needed to handle routine levels of day-to-day calls, relatively minor failures can have major effects on service levels. For example, where everyone is used to the convenience of AVL, an AVL outage can suddenly increase staff workloads. Suppose a failure causes a condition where CAD cannot recommend a closest unit. How will the dispatcher efficiently assess which unit to assign?

Data management problem

Data quality and data management are significant issues in every system. Part of managing the problem is to establish and enforce standards for data.

Staffing will periodically change as people retire or are promoted. One staff member entered street names, "McDonald" while others enter the same street "Mc Donald." When a complaint-taker is typing a street name into the CAD system, these will sort differently:

* Mc Donald Av
* Mc Intosh Av
* Mc Gulliver Wy
* Mc Zzyrx Rd
* McDonald Av

How will quality standards be implemented to prevent mis-sorted type-ahead feature entries?

Disambiguation can be a problem in cases, for example, where a service area has two Main Streets. In large service areas it is normal to have dozens to hundreds of duplicated and similar street names. The problem can be complicated if the person requesting service is not calling from a wired phone and their location is unclear. Some long streets may have identical address ranges in each city along their route. The caller is in front of 2200 Main Street, but which one? How will the decision-making process be reinforced by good data quality?

Systems require perpetual software upgrades each of which may normalize data differently. Or, a different company may win the low bid next time a system is replaced. Imagine taking a file of 270,000 addresses that took a staff ten years to compile and feeding them through a parsing filter to split street, drive, or road, from each record. Imagine a new system stores apartment and suite letters, (2200 A Main Street) in separate fields and you are responsible for the conversion.

Data exchange (EDI)

In public safety systems, standards are under discussion to allow disparate systems to exchange call information. For example, a call taker at the county fire department receives a call for an auto accident inside a city limit. Evolving standards will allow CAD systems to send messages to one another for calls originating outside local jurisdiction. Some entities have arrangements that already support data exchange between systems, but standards aim to make these interconnections more common. Because of auditing trail and fail-safe needs, the problem is more complex than it sounds. [ [http://www.apcointl.org/about/datatransfer/index.html#Focus_Group_Three_DTC_FG3 Associated Public-Safety Communications Officers web site, Data Transfer Committee, Focus Group III.] The A.P.C.O. refers to this as Project 36.]

Part of business enterprise computing system

In business use of CAD, the dispatch system may be a module or part of a larger enterprise computing system. Rather than having multiple infrastructure's, being able to have a single infrastructure with many applications running on it is important. [ [http://www.retrievercommunications.com/index.php?option=com_content&task=view&id=59&Itemid=45 Multiple Applications with Same Infrastructure] A Model for Applications, Sourced March 2007.]

References

Original article

* Horn, D. W., (2005). "An Integrated Public-Safety Computer-Aided Dispatch System." In-press Master's Thesis Project, Regis University, Denver, CO.

Notes

ee also

* Incident Command System
* Logistics
* Resource Ordering Status System
* Selective calling
* Emergency Medical Dispatcher

External links

* [http://cad.chp.ca.gov/ California Highway Patrol Online CAD Logs.]
* [http://caffeine.arc.nasa.gov/midas/Nine11_MIDAS.html NASA research into future console designs.]