ITS - Intelligent Transportation Systems Report ITS Home Page
Table of Contents


2. IMPLEMENTATION RESULTS

2.1 INTENDED SYSTEM ELEMENTS AND FUNCTIONS

Utah's integrated CAD-TMC system was intended to include the following elements and perform the associated functions:

The system architecture developed for the Utah CAD-TMC integration FOT is shown in figure 2.8

Flow chart describing components and interfaces of the Utah CAD-TMC system architecture.D
Figure 2. Utah CAD-TMC System Architecture.9

2.2 IMPLEMENTED SYSTEM

For the FOT, the participating agencies used their existing CAD and related technologies. The Traffic Operations Center's (TOC) CommuterLink continued to provide the current ITS technologies, including closed-circuit television (CCTV) roadway coverage. UDOT distributes CommuterLink's CCTV video images and image selection controls to SLCPD, SLCFD, VECC, and UTA. Traffic information also is available via CommuterLink's Web pages (http://commuterlink.utah.gov/ie.htm). The CAD-TMC integration FOT tested the specific effects of introducing the shared data from the participating agencies, as facilitated by CAD-to-CAD ISRs and CAD-to-ATMS IAMs, regarding the performance of responders and related benefits.

The primary system changes that were required were involved only in the software applications. Since modifications to each participating agency's CAD system are maintained by the vendors, system reliability is not viewed as a future issue, and is a good means to support those systems. UTA modified its own software, and maintains its CAD system in-house. The integration software will be maintained by UDOT on an ongoing basis, along with its other systems.

Overall, the project participants indicated that the technical implementation was successful. Agencies were able to either modify their systems themselves, as was the case for UTA; have their systems integrator modify their system, as was the case for UDOT; or have their vendor modify their system, as was the case for VECC and SLCPD. (At the time during which this report was written, SLCFD was still working with its vendor to complete modifications to its system to allow participation in the integrated system.)

2.2.1. Data Exchange

From the time the project was first implemented, participants expressed concern about the following issues:

Amount of Data Exchanged

Early discussions among the project participants led to slightly different approaches taken to address these concerns, depending on the agency involved. The concerns surrounding the amount of data exchanged led to discussion about filtering the records that would be exchanged. Ideally, only certain types of entries would be exchanged. However, because this information had never been exchanged before, it wasn't clear how to filter the entries by type.

The decision was made by most agencies involved to give the individual dispatcher or operator the responsibility to determine what entries should be transferred to the integrated system. Operator interfaces were generally modified to add a feature to share the entry by selecting to share the information and to which agencies the information would be sent. Drop-down menus were generally used as a means to simplify and speed the operator's action and to minimize the impact on operator or dispatcher workload. Operators at each agency were able to screen the entries in the integrated system and could decide whether to view a specific entry and whether or not to bring the entry into their systems.

The result, however, was to add a step to the operator work process. In general, this led to additional work to already busy operators. In the case of the two agencies that probably have the greatest need to exchange information, UDOT and DPS, it was determined that the existing level of integration is sufficient, since each agency already has access to the other's system. Both the UDOT and DPS felt that the added actions are unnecessary. Since UDOT and DPS already access each other's data, the benefit of taking additional steps to ensure the information goes into the integrated system is not obvious. As a result, neither agency chose to add their entries to the integrated system very often.

For SLCPD, adding the step of deciding when the appropriate time is to allow the system to exchange information about a particular event means that the dispatcher must go back and select an entry for it to be shared. This step was also out of the normal work process. The dispatcher, after entering the event, would move on to other activities, usually with other events and emergencies. Without any cue from the system, the dispatcher had to recall that there was an event in which other agencies might be interested, determine whether or not the situation might compromise actions being taken by police officers, and then go back to the event and send the event information to the integrated system. The result was that very few SLCPD events go into the integrated system.

Operator Workload

The preceding discussion about the added steps necessary for operators/dispatchers to make decisions regarding information exchange relates directly to the second concern, operator workload. Agencies also were concerned about any increase in the operator or dispatcher workload. One agency, in particular, was so concerned that this element regarding operator workload became the driving force behind its decisions regarding the system implementation. Instead of requiring their operators to decide which entries may be appropriate to send to other agencies and determine the agencies with which to share the information, VECC decided to send all information directly to the integrated system.

Because some of VECC's client agencies were concerned about how the data might be used, VECC decided to take a conservative approach to the data that would be sent to the integrated system. Event type and location were selected as the fields that were of most interest to other agencies. The free text field was not included. As a result, the direction of travel is not included in the data that is sent from VECC to the integrated system. The result was that the UDOT operators would review the incidents in the integrated system that come from VECC. If one of the entries looked like it would be of interest to them, the UDOT operators needed to verify the direction that is affected by the incident. If a camera provided a view of the location, it was determined that the operator would use that device to confirm the direction affected by the incident and verify the incident itself. If no camera was located in the area, the operator would listen to the scanner and try to find other ways (such as telephoning VECC) to verify the incident and determine direction.

Appropriate Data to Be Exchanged

The concerns surrounding the sensitivity of some data being exchanged required that certain data fields would be transferred and others would not. There was no distinction between data that would be sent to one agency versus another agency. The agencies chose a relatively conservative approach to which data fields were sent out, in part, because they were not certain how the information might be used or distributed once it was transferred. As mentioned above, VECC chose to send all of its records to all agencies, but was one of the most conservative in what fields are actually sent for each event-just event type and location.

In some cases, the limited data that exchanged did add to the operator workload. As mentioned previously, the UDOT operators have to find alternative sources of information to add needed information and to verify the events that come in from VECC.

None of these results were particularly surprising when one considers that this system allowed data exchange that could never be exchanged in the past. The agencies took a prudent approach to provide the information that seemed the most useful in the manner that was viewed to work best with each agency's existing business practices. As will be stated in later sections on lessons learned, the agencies discovered what works well, what needs to be improved, and are committed to make improvements as they have resources to do so.

2.2.2. System Modifications

To integrate the various CAD systems and the TMC, each system had to be modified. The partner agencies modified their own systems, generally through contracting with the original system providers. In the case of UTA, the modifications were made by internal staff. For the agencies that used the original system providers, separate contracts were issued.

Some issues surfaced surrounding the codes used in each system. These codes represented a variety of information from incident type to geographic location. The base systems included slightly different codes for similar information, and there were not always direct correlations between the codes used among the different systems. The UDOT system integrator provided an XML template that included the current version of 1512 codes, but the translation from the vendor codes to the standard codes was a bigger issue than envisioned. The translation wasn't always straightforward because there wasn't a one-to-one correlation. Mapping from one agency's terminology to another's created some difficulties.

2.2.3. Use of Standards

Department of Justice Standards

The CAD vendors tended to use Department of Justice (DOJ) standards. Currently, the DOJ has an effort underway to get all CAD systems to use one standard to ensure that the various CAD systems can communicate with one another. However, UDOT uses ITS standards in its TMC and wanted to continue with those standards to remain consistent with the rest of its system. UDOT uses the IEEE 1512 family of standards for incident management as its primary standards. Therefore, both DOJ and ITS standards had to be used. Although there are current efforts underway to make these two families of standards consistent, they are not yet completely harmonized.

Geo-location Standards

It was determined that different geo-location referencing schemes also are used by the different systems. While most systems use latitude-longitude geo-location, the DPS CAD system used State plane coordinates, which were translated into latitude-longitude coordinates in the integrated system.

Since the location information from VECC included an event's latitude and longitude coordinates, the integrated system could automatically place the event once the UDOT operator accepted the event in the UDOT system. This automated action was found to reduce an important but previously manual step in the UDOT operator's process, which resulted in saved time in the operator workload.

2.2.4. UTA

Each participating agency added software capability to send and receive IEEE 1512 standard messages to indicate a new incident or to post/update the status of an existing incident. UTA had developed its CAD system in-house, and had the flexibility to incorporate its desired level of functionality as appropriate.

Given the limited initial knowledge about which types of messages would prove useful to send and receive, UTA opted to be able to view and generate every message type. UTA expressed concern about the potential to miss out on important information by not viewing any particular pre-designated types of messages, given that even relatively minor incidents have the potential to significantly affect transit operations.

Therefore, the protocol for determining whether or not a message is useful to UTA was modified as follows:

The UTA dispatcher was notified of all incoming messages on the system's primary CAD screen. This primary screen notification provided a listing with a summary title for all recently received messages, in reverse chronological order. The UTA dispatcher is able to select an item from the list to view more specific details about an incident and its status/history. In addition to using this information to assist with whatever operational actions are considered appropriate, the dispatchers use the existing documentation arm of the UTA CAD system to log any incidents considered relevant to UTA operations.

UTA expressed that the current system using the full message set was consistent with its original intentions, and originally thought that all participating agencies also were also going to send and receive the full message set. However, some other participating agencies limited the types of messages they would send or receive, and it was UTA's understanding is that in some cases, those choices are affected by constraints associated with the need to work with the CAD system vendor to implement the changes.



8 Incorporated from: State of Utah, "A Proposal for the Integration of Computer-Aided Dispatch - Traffic Management Integration Field Operational Test," p. 16, (July 11, 2002).

9 Source: State of Utah, "A Proposal for the Integration of Computer-Aided Dispatch - Traffic Management Integration Field Operational Test," p. 16, (July 11, 2002).

Previous | Next