Computer-assisted dispatch

From Wikipedia, the free encyclopedia

You have new messages (last change).
The CAD system of a fire department on a busy day. The line at the bottom is about to be dispatched. (Note:addressed have been changed for privacy reasons.)
The CAD system of a fire department on a busy day. The line at the bottom is about to be dispatched. (Note:addressed have been changed for privacy reasons.)

Computer-assisted dispatch (also called CAD) is a method of dispatching taxicabs, couriers, field service technicians, or emergency services assisted by computer. It can either be used to send messages to the dispatchee via a mobile data terminal (also called an 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, calltakers, and field personnel with respect to control and use of analog radio and telephony equipment, as well as logger-recorder functions.

Contents

[edit] Manual dispatching

Main article: Dispatch (logistics)

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.

[edit] Computer-assisted method

Computer-assisted dispatch systems use one or more servers located in a central dispatch office, which communicate with mobile data terminals installed in the remote vehicles. There are a multitude of CAD programs that suit different department needs, but the layout of each system is the same. The purpose of CAD in the first place is to quicken the information that is received or transmitted from the call-taker or dispatcher to those who will facilitate the original call.

In an ideal setting, a call is received by a call-taker and information about the call is inputted into the CAD template. Generally, Location, Reporting Party and Incident are the main the 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 look something like this based on the examples below:

LOCATION - 1400 Madison
RP       - Doe, John, 555-5555
INCIDENT - BURGLARY (in progress)

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)

-----------------------------------

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.

[edit] Service 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?

[edit] 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. [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.

[edit] 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?

[edit] 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.

[edit] 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?

[edit] 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.

[edit] 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.[2]

[edit] 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.[3] One example is Command Alkon's COMMANDconcrete software, which manages orders, batch processing, and delivery for concrete plants. One optional component of the system is called "Truck Tracking." The module tracks the status of concrete delivery vehicles, which jobs they are assigned to, estimated time until available. It is a CAD for use with a fleet of transit mixers. [4]

[edit] References

[edit] Original article

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

[edit] Notes

  1. ^ This would work for any system including taxis or parcel pick up.
  2. ^ Associated Public-Safety Communications Officers web site, Data Transfer Committee, Focus Group III. The A.P.C.O. refers to this as Project 36.
  3. ^ Multiple Applications with Same Infrastructure A Model for Applications, Sourced March 2007.
  4. ^ Brochure: COMMANDseries, COMMANDconcrete, Truck Tracking (CC-TT), Command Alkon, Inc., Birmingham, Alabama, USA, 2006.

[edit] See also

[edit] External links

[edit] CAD & Related Software Packages

Retrieved from "http://en.wikipedia.org../../../c/o/m/Computer-assisted_dispatch.html"