Traffic Management Division
Computer Aided Dispatch Integration Field Operational Test
Final Report

For the PDF version of this document, please click here.

 

Utah Department of Transportation Logo
Utah Department of Transportation

Prepared by:
TranScore Logo
488 East 6400 South, Suite 375
Murray, Utah 84107

 

Table of Content

1. Project Overview

2. Approach and Results
 2.1 IEEE 1512-Based Interface
 2.2 Point-to-Point Architecture
 2.3 Phased Development
 2.4 Minimal Business Practice Impact

3. Challenges of the Field Operation Test
Exhibit 2: Point-to Point Architecture
 3.1 Institutional Challenges
 3.2 Technical Challenges
 3.3 Personal-Related Challenges

4. Lessons Learned
 4.1 Team Cooperation
 4.2 Agency Support for Staff
 4.3 Standards Usage
 4.4 Agency/Vendor/Integrator Relationships
 4.5 Recommended Enhancements

5. Field Operation Test Team Members and Responsibilities
 5.1 Utah Department of Transportation
 5.2 Integration Team Responsibilities
 5.3 Partner Responsibilities
 5.4 FOT Evaluation

6. Conclusion

Appendix A - UDOT Required Messages Set
Appendix B - List of Acronyms

1. Project Overview

In February 2003, the Utah Department of Transportation (UDOT), the Utah Department of Public Safety (DPS), the Salt Lake City Police and Fire, the Valley Emergency Communications Center (VECC), and the Utah Transit Authority (UTA) were awarded a grant from the USDOT Intelligent Transportation Systems Joint Program Office - Public Safety Program. The purpose of this grant was to conduct a field operation test (FOT) to integrate UDOT's CommuterLink Advanced Traffic Management System (ATMS) with five independent computer aided dispatch (CAD) systems.

The goal of the FOT was to demonstrate that system vendors can develop a standards-based interface to share and exchange data among transportation and emergency management centers with minimal impact on existing agency business practices. These centers share a goal of responding to emergencies, and they share a need for basic information such as the nature of the problem, location, severity, and impact. Automating the exchange of this information can immediately provide dispatchers, managers, and field commanders with a clearer understanding of resource, asset, and traveler information needs. The automated exchange of information also ensures that all participants receive the same information, efficient status updates, and more reliable information directly from responsible agencies.

The Utah CAD FOT successfully demonstrated that several independent CAD systems and the UDOT incident management system could be integrated to share data and improve incident response and management. Using national standards, the Utah CAD FOT team developed an interface among six systems, four of which are proprietary. In addition, the integration was achieved with minimal impact on existing agency business practices.

2. Approach and Results

Four guidelines drove the Utah CAD FOT team's approach to developing the CAD-ATMS interface:

  1. Implement an interface based on IEEE 1512 standard.
  2. Implement a point-to-point architecture.
  3. Use a phased approach to interface design and development.
  4. Minimize the impact on agency business practices

2.1 IEEE 1512-Based Interface

Each agency's CAD system and the UDOT ATMS have different methods of storing and using similar data. The Utah CAD FOT project team identified the information to be shared among the partners, resulting in a set of ten basic messages that were reviewed and agreed to by all participants. The incident description message set in the IEEE 1512 Standard for Common Incident Management Message Sets for Use by Emergency Management Centers contains the messages necessary to share basic incident information. The integrated system also used the International Traveler Information System data dictionary for activity codes. Appendix A contains the UDOT message set compared to the IEEE 1512 message set.

The Utah CAD FOT team developed a common interface so each system could send and receive data in a format usable by the other systems. Each partner converted their CAD system's internal data to the IEEE 1512 format for transmission to the other partners. When a CAD system receives a message in the standard format, it converts the message to its internal format for use in its system (see Exhibit 1).

Exhibit 1:  CAD System Standards Interface
Exhibit 1: CAD System Standards Interface

2.2 Point-to-Point Architecture

Communications for the Utah CAD FOT could be point-to-point, with each system sending incident data to all other systems, or it could be centralized, with all systems sending incident data to one system for dissemination to all participants. Point-to-point architecture was chosen early in the project, primarily so there would be no single point of failure. If one CAD system or the UDOT ATMS fails, the remaining systems continue to send and receive incident data, and the near real-time exchange of information is preserved. Point-to-point architecture does require that each agency stays up-to-date on communication addresses for all participants. Exhibit 2 illustrates the point-to-point architecture.

2.3 Phased Development

The Utah CAD FOT team took a phased approach to the interface design and development. Design of one interface, between the UDOT ATMS and Utah DPS CAD, began ahead of the others. All project partners reviewed the first interface as it was being designed, and they provided input. While software code development went forward on the DPS CAD interface, the other partners began work on their design. Additional code development followed, in some cases using code that had been developed for the first interface. Finally, the first team went to test mode, and lessons learned were again provided to the other partners while they were still developing the software. This process shortened the development time and effort for the other partners.

2.4 Minimal Business Practice Impact

A new technology application that adds to an already busy operator's workload will not be well accepted unless it is of significant value. The Utah CAD FOT team strived to minimize workload impacts and to involve the operations staff in the process early so that they could participate in the solution. The UDOT ATMS for example, automatically places an incident on the map, which reduces operator workload and increases the accuracy of incident location data. Most Utah CAD FOT partner systems require that operators manually select message recipients, and to manually accept or reject incoming messages. As a result of these new processes, UDOT operators are receiving more frequent and more reliable data.

3. Challenges of the Field Operation Test

The Utah CAD FOT team experienced challenges during the field operation test at three levels: institutional, technical, and personnel-related.

Exhibit 2:  Point-to-Point Architecture
Exhibit 2: Point-to-Point Architecture

3.1 Institutional Challenges

Institutional issues invariably arise when coordinating a project involving six agencies. Although the Utah CAD FOT team has a history of working together and sharing information, there were several challenges to overcome, some of which are inter-organizational issues rather than intra-organizational issues.

3.2 Technical Challenges

Technical issues affect the design and development of the integrated CAD-ATMS.

3.3 Personal-Related Challenges

Personnel-related challenges were the result of user uncertainty about, and perception of, the new system.

4. Lessons Learned

Through the course of the project, the Utah CAD FOT team learned several valuable lessons that are transportable to agencies undertaking a similar project.

4.1 Team Cooperation

Team cooperation was the most important element in the success of this project. When challenges arose, it was essential that the agencies worked together with mutual trust to resolve issues, even though the participating agencies often had different focuses (e.g., emergency responders focus on efficiently managing the scene, while DOT focuses on minimizing delay and preventing secondary crashes).

Each agency stated that working together helped them understand the issues of the other agencies and helped them understand how they can work together even more closely. Understanding a partner's situation also contributed to successful negotiations between partners when different approaches or results were desired.

In other communities planning to integrate CAD systems, players should work on interagency relationships at leadership and working levels prior to beginning the integration project. The agencies should clearly define the role of each participant and gain each agency's commitment to fulfill their responsibilities through a formal memorandum of understanding.

4.2 Agency Support for Staff

Agency support for staff is essential to ensure that the project tasks are completed on schedule. In most cases, agency personnel supporting the integrated system development had jobs that at times took priority over the Utah CAD FOT project. Managers must be made aware of their staff's involvement in and importance to the project, and they must be committed to that involvement to the point of providing flexible work schedules and time away from other responsibilities.

4.3 Standards Usage

Standards usage will likely be a challenge in any project of this type. The industry standards differ among the agencies involved in the integration project. It is essential that the team decide at the start of the project which standard will be used for all shared data. The Utah CAD FOT used the IEEE 1512 standard data structure and the International Traveler Information System data dictionary for activity codes. In addition, emerging standards will not have a history of real-world application to guide the standard, which was the case with IEEE 1512 during this project. In that case, the integration team and the standards development body will be well served if the team shares experience in using the standard.

4.4 Agency/Vendor/Integrator Relationships

Agency/vendor/integrator relationships were crucial to the timely completion of the Utah CAD FOT. The lead agency, partner agencies, CAD system vendors, and agency contractors must establish relationships at the beginning of the project to enhance the likelihood of project success. CAD system vendors are usually competitors, and agency staffs have competing priorities beyond the integration project. In order for the integration to proceed smoothly, all parties must have a commitment to the project's success.

The contracting arrangement was another factor in the Utah CAD FOT. In this project, each participating agency contracted with their CAD system vendor, and each agency was responsible for their CAD vendor's performance. This approach was a strategic decision due to the belief that vendors would be responsive to agencies that are their customers. This added another communications layer, which was complicated by agency staff's competing work priorities. When vendor communications were not handled efficiently through a partner agency, UDOT or the systems integrator often contacted vendors directly, which led to confusion over who vendors should take direction from. The project may have run more smoothly if the lead agency was also the single contracting agency. It is hard to say if this approach would have been better due to the fact that UDOT did not have a customer relationship with the other agencies' CAD vendors.

The phased design and development process also played into successful vendor/integrator relationships. Each CAD system vendor/developer worked directly with the agency using their system and with UDOT but not with other CAD system vendors. The Utah CAD FOT approach allowed the vendors to incorporate the interface into their system without comparing designs and proprietary data with other vendors.

Another component of vendor relationships is CAD system update cycles. Vendors usually develop and upgrade systems with their own funding, so they program strictly scheduled updates for their systems to increase efficiency, accommodate internal testing procedures, and control costs. A project such as the Utah CAD FOT may not fit well into vendor's update schedules, may conflict with existing priorities, and may be assigned a lower priority. A well-planned, phased development enables agencies to coordinate their new interface with the vendor and receive the new interface with the next update.

4.5 Recommended Enhancements

Some lessons were learned during the integrated interface's operational period and resulted in the following recommended enhancements.

Automated message sending is very important to reducing the dispatcher's or operator's burden and responsibility. After the system had been in use for a while, automated message sending was reassessed for the DPS CAD system. A methodology based on the incident location/jurisdiction and the activity code has been successfully implemented and is currently in production. This methodology is applicable to other CAD systems.

Selective message filters check message parameters such as location and incident type to determine if UDOT should respond. Filters help reduce the number of non-applicable messages being delivered to agencies. They could also benefit users if the filters were modifiable to support existing conditions, such as filtering out low impact incidents during a period of many incidents such as a major snowstorm.

Compatible GIS systems expedite incident location and mapping. The CAD systems in the Utah CAD FOT use different means of locating incidents, which were then translated into one of three common methods (street address, cross street, and geo coordinates).

5. Field Operation Test Team Members and Responsibilities

UDOT, Utah DPS, Salt Lake City Police and Fire, VECC, and UTA were the agencies on the Utah CAD FOT team. Computer Information Systems (CIS) included a financial contribution, and all partnering agencies contributed their resource time and services.

UDOT selected TransCore as their systems integrator to provide overall management and system design to integrate the UDOT CommuterLink incident management system, and to provide an independent coordination role with each of the CAD vendors on behalf of UDOT. CIS was selected to serve as the CAD integrator to help with the initial development and debugging process prior to hand-off to the other vendors in the phased development process. UTA developed their own CAD system; other vendors and the agencies they support are:

5.1 Utah Department of Transportation

UDOT established a memorandum of agreement (MOA) with each partner to identify responsibilities; coordinated the integration with the partner agencies; and provided an interface specification and interface development lessons learned to the partners. UDOT held periodic coordination meetings with the partners to review progress and remedy issues. UDOT also coordinated the project efforts with USDOT and their FOT evaluation team.

5.2 Integration Team Responsibilities

The integration team lead (TransCore) supported UDOT in developing the:

The integration team lead developed the UDOT ATMS interface to the CAD systems and transferred the lessons learned to the partner technical teams as part of the phased development process. The integration team lead also supported UDOT at partner and USDOT management meetings.

5.3 Partner Responsibilities

Partner agencies were responsible for coordination within their agency to ensure that their staff was available to support the Utah CAD FOT. Partners also coordinated the interface requirements and the delivery schedule with their CAD vendor. The partners supported the integration of their CAD systems into the Utah CAD FOT system and supported the USDOT data collection and evaluation of the effort.

5.4 FOT Evaluation

USDOT selected SAIC to lead the Utah CAD FOT evaluation team. UDOT and the Utah CAD FOT system integrations contractor (TransCore) met with the Utah CAD FOT evaluation team several times and provided information on the Utah CAD FOT approach and existing capabilities. The Utah CAD FOT team supported the USDOT evaluation team in establishing the evaluation criteria and data collection plans. The Utah CAD FOT team also supported the evaluation team's analysis by providing additional information, such as documenting and collecting data on operational procedures and impacts.

The goals of the evaluation were to capture and publicize lessons learned by organizations deploying the Utah CAD FOT, to enable other organizations to duplicate what worked and avoid what did not work. The evaluation team compiled and compared before and after data on incidents, traffic performance, crashes, and transit operations to identify the impacts and system improvements achieved as a direct result of the integration. The evaluation team also monitored the process and after-affects of working together to see if operational changes occurred as a result of this improved interagency communication and coordination.

The evaluation process began early in the project starting with the team building stage and followed the project through the planning, design, deployment, and use stages to determine what impacts the deployment had on the transportation system.

Complete results of the evaluation are documented in "Computer-Aided Dispatch - Traffic Management Center Field Operational Test: State of Utah Final Report."

6. Conclusion

This field operation test successfully met the project goals and objectives and proved that it was possible to integrate emergency responders' CAD systems with transit and DOT traffic management systems. This test also proved that the process of jointly working together to implement a shared vision can result in improved coordination between agencies that otherwise might not have the opportunity to work together. The technical challenges sure to be encountered are much easier to resolve if all project partners, from management to front-line staff, are committed to work together for the benefit of the overall program. The education and understanding that results from this close communication is in itself a beneficial by-product.

Appendix A - UDOT Required Messages Set

UDOT DATA IEEE 1512 MAPPING DESCRIPTION
Incident Number

IDX.Header.SenderIncidentID

and

IDX.Header.OtherCenterIDs

Sender’s ID for this incident.

Other center’s IDs for this incident. FOT partners would have to search this list for their own ID. We need to come up with a scheme for identifying each agency’s IDs. If the incident isn’t known to the local CAD there will be no match and the operator would have to associate this incident information with a record already in their system or create a new incident using this information as a seed.

Incident Type IDX.Basics.IncidentType

Code that identifies type of incident. Sending-center perspective.

This is the standard list. Each agency would cut this list down and only use the ones that apply to them. Before transmitting they would translate their local code to one in this list. When receiving, they would translate the code from this list to the one in their local CAD system.

1=accident;

2=serious-accident;

3=injury-accident;

4=minor-accident;

5=multi-vehicle-accident;

6=numerous-accidents;

7=accident-involving-a-bicycle;

8=accident-involving-a-bus;

9=accident-involving-a-motorcycle;

10=accident-involving-a-pedestrian;

11=accident-involving- = a-train;

12=accident-involving-a-truck;

13=accident-involving-hazardous-materials;

14=earlier-accident;

15=medical-emergency;

16=secondary-accident;

17=rescue-and-recovery-work-in-progress;

18=accident-investigation-work;

19=incident;

20=stalled-vehicle;

21=abandoned-vehicle;

22=disabled-vehicle;

23=disabled-truck;

24=disabled-semi-trailer;

25=disabled-bus;

26=disabled-train;

27=vehicle-spun-out;

28=vehicle-on-fire;

29=vehicle-in-water;

30=vehicles-slowing-to-look-at-accident;

31=jackknifed-semi-trailer;

32=jackknifed-trailer-home;

33=jackknifed-trailer;

34=spillage-occurring-from-moving-vehicle;

35=acid-spill;

36=chemical-spill;

37=fuel-spill;

38=hazardous-materials-spill;

39=oil-spill;

40=spilled-load;

41=toxic-spill;

42=overturned-vehicle;

43=overturned-truck;

44=overturned-semi-trailer;

45=overturned-bus;

46=derailed-train;

47=stuck-vehicle;

48=truck-stuck-under-bridge;

49=bus-stuck-under-bridge;

126=accident-cleared;

127=incident-cleared.
Location IDX.Basics.IncidentLoc  
Date & Time IDX.Description.time

Issue time/version stamp.

Note: This is the time of the MESSAGE, not the INCIDENT.
Priority IDX.Severity.priority

A number assigned by the agency to indicate the impact of this incident on the transportation network. The priority level describes the class of precedence of an event. A "1" assumes the greatest priority.

Remarks IDX.Description.DescripLongText

Description of the incident.

May include other incident information in text form the operator will have to read and apply when entering the incident in their local CAD.

Witness Name

IDX.Description. DescripWitnesses.bywhom.first

+

IDX.Description. DescripWitnesses.bywhom.last
Witness’ first name + Witness’ last name.
Witness Phone #

IDX.Description. DescripWitnesses.bywhom .hmph

or

IDX.Description. DescripWitnesses.bywhom .wkph
Witness’ home phone or work phone.
Responding Units

RespEquipType

1 Transit vehicle of property

2 Transit vehicle of another property

3 Transit Police

4 Transit Supervisor

5 Transit Repair Vehicle

6 Transit Tow Truck

7 Track Repair Vehicle

8 Overhead Wire Repair Vehicle

9 Other Repair Vehicle

10 Emergency Medical Service Chief

11 Advanced Life Support

12 Basic Life Support

13 Quick Response Unit

14 First Responder

15 Medical Evacuation

16 Other Medical Service

17 Supervisor-Police

18 Patrol Car

19 Motorcycle

20 Foot Patrol

21 Bicycle Patrol

22 Air Unit

23 K-9

24 SWAT

25 Hostage

26 Bomb Squad

27 Detective

28 Coroner/Medical Examiner

29 Police- Other

30 Suppression Chief

31 Engine/ Pumber

32 Ladder/Tower/Platform

33 Heavy Rescue/ Extrication

34 Brush/ Off-Road

35 Hazardous Material

36 Technical Rescue

37 Foam Unit

38 Investigator/ Fire Marshall

39 Inspector

40-149 Reserved for standard use

150-255 Reserved for Local use

or

RespStatusOtherText

describing the equipment requested.
 
Operator ID

IDX.Asgn-Resrc.DispatcherID

May also want…

IDX.Asgn-Resrc.AgencyID
The identification number of the dispatcher (transit or non-transit) giving the dispatch order.

 

Appendix B - List of Acronyms

ACRONYMS

ASN.1

Abstract Syntax Notation, Number One

ATMS

Advanced Traffic Management System

CAD

Computer Aided Dispatch

CIS

Computer Information Systems

DPS

Department of Public Safety

FOT

Field Operation Test

GIS

Geographical Information System

HTTPS

HperText Transport Protocol using a Secure Socket Layer

IDX

Incident Description

ITIS

International Traveler Information System

ITL

Integration Team Lead

MOA

Memorandum of Agreement

POC

Point of Contact

SLC-FD

Salt Lake City Fire Department

SLC-PD

Salt Lake City Police Department

UDOT

Utah Department of Transportation

USDOT

United States Department of Transportation

UTA

Utah Transit Authority

VECC

Valley Emergency Communications Center

WWW

World Wide Web

XML

Extensible Markup Language

(To download Adobe PDF Reader, please click here)