Computer-aided dispatch (CAD), also called computer-assisted dispatch, is a method of dispatching taxicabs, couriers, field service technicians, mass transit vehicles or emergency services assisted by computer. It can either be used to send messages to the dispatchee via a mobile data terminal (MDT) and/or used to store and retrieve data (i.e. radio logs, field interviews, client information, schedules, etc.). A dispatcher may announce the call details to field units over a two-way radio. Some systems communicate using a two-way radio system's selective calling features. CAD systems may send text messages with call-for-service details to alphanumeric pagers or wireless telephony text services like SMS. 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, call takers, and field personnel with respect to control and use of analog radio and telephone equipment, as well as logger-recorder functions.
Methodology
edit
Computer-assisted dispatch systems use one or more servers located in a central dispatch office, which communicate with computer terminals in a communications center or with mobile data terminals installed in 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 to 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 # - 110001 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 in which the type codes reside, 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
edit
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 or 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 and Avtec's Scout system. This allows for easy customization and modification of the dispatch key layout.
Service levels and geographic information
editComputerized 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
editThe 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.[1] 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
editGeocoding 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 system 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
editThe most expensive and technically challenging systems fully utilize the capabilities of geographic information systems (GIS) and automatic vehicle location (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
editCAD 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 automatic vehicle location (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 exchange (EDI)
editIn 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.[2]
The usage of EDI applied to CAD is specific to the law enforcement community and should not be confused with Electronic Document Interchange (EDI) standards for eCommerce. Within law enforcement EDI is used as a buzzword to represent all electronic automated messaging.
More mature efforts to interconnect CAD can be found in the standards developed for the Intelligent Transportation Initiatives program of Department of Transportation.[3] This initiative sponsored the IEEE 1512 series of protocols for emergency management[4] which provides sophisticated means to coordinate incidents across operations centers using CAD software.
Additional work is occurring under the National Information Exchange Model[5] to link homeland security with CAD. Also the OASIS international standards body has produced standards[6] funded in part by the DHS and the disaster management e-gov initiative[7] to communicate in emergencies.
Other interoperability technologies can bridge disparities between the data-format, software, and hardware that constitute various computer-aided dispatch systems in various jurisdictions. Middleware, software and servers (data brokers), can translate and integrate various systems into a seamless automated dispatch system. One example of such middleware (provided by Utah-based FATPOT Technologies/CII)[8] exists in Orange County, Calif., where the Fire Authority has integrated different emergency service answering points into a seamless dispatching network. A similar project was completed for the Silicon Valley Regional Interoperability Project (SVRIP), and is part of the Dept. of Homeland Security's CADIP report.
Australia and New Zealand use the ICEMS protocol for messaging between different CAD systems operated by various emergency services organisations.
Part of business enterprise computing system
editIn business use of CAD, the dispatch system may be a module or part of a larger enterprise computing system. Rather than having multiple infrastructures, being able to have a single infrastructure with many applications running on it is important.[9]
At the high end of enterprise integration for CAD there is SOS. SOS or systems of systems is a methodology and a set of technology for linking distributed independent applications into one meta-system or system of systems.[10] These methods were originally being used at DOD for command and control (C2) but have now been applied to dispatch in efforts like the Department of Transportation Intelligent Transportation System at the Transportation Management Centers[11] and other efforts involving DHS counterterrorism or fusion centers. Some local jurisdictions have also integrated their dispatch systems using EAI (Electronic Application Integration) software.
Recent developments
editComputer aided call handling (CACH) is built on the premise that effective call handling is the foundation for an efficient dispatch response. By using structured call handling and a series of risk calculations, such systems can make objective dispatch recommendations based on information provided by the caller.
See also
editReferences
editOriginal article
edit- Horn, D. W., (2005). An Integrated Public-Safety Computer-Aided Dispatch System. In-press Master's Thesis Project, Regis University, Denver, CO.
Notes
edit- ^ This would work for any system including taxis or parcel pick up.
- ^ Associated Public-Safety Communications Officers web site, Data Transfer Committee, Focus Group III. Archived 2006-10-10 at the Wayback Machine The A.P.C.O. refers to this as Project 36.
- ^ Intelligent Transportation Systems
- ^ "IEEE Incident Management Working Group". Archived from the original on 2009-04-19. Retrieved 2009-02-28.
- ^ NIEM.gov
- ^ OASIS EM TC and EDXL Emergency Data Exchange Language
- ^ "Egov.gov". Archived from the original on 2008-09-08. Retrieved 2019-07-08.
- ^ "Fatpot.com". Archived from the original on 2018-07-10. Retrieved 2019-11-13.
- ^ Multiple Applications with Same Infrastructure A Model for Applications, Sourced March 2007.
- ^ System of systems System of Systems
- ^ Ops.fhwa.dot.gov
12.^ https://www.intrado.com/life-safety# is an example of an Emergency Call Handling system that feeds CADs