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

 

6. CONCLUSIONS AND RECOMMENDATIONS

This section provides the overall conclusions and specific recommendations as they relate to lessons learned regarding institutional and technical challenges to aid other States and agencies in determining the value of integrating a CAD-TMC system.

The project participants involved in the Washington CAD-TMC integrated system FOT identified a variety of evaluation findings in interviews with the Evaluation Team that will be of benefit to other jurisdictions considering similar deployments. Many of these have been discussed in previous sections of this document. They are presented in this section to summarize important aspects of the project so other agencies can easily identify them.

6.1 CONCLUSIONS

It is important to note that WSDOT and WSP have a long-standing relationship for sharing details of incidents that occur on the roadway system. WSP has provided a CAD listing of incidents for several years to the WSDOT TMCs to monitor to which incidents the field patrols were receiving and responding. With cameras or detectors available to WSDOT operators, they could verify the incidents and provide information to the media. The WSDOT operators could also use Dynamic Message Signs (DMS) to advise motorists of the incidents. That system was manual, however, and required the WSDOT operator to create an entry based on the input from the WSPCAD system.

An important and frequent participant in all roadway incidents is the WSDOT Incident Response Team. Expanded in recent years to all regions with Interstate highways, these operators are dispatched by the WSP, have direct mobile to mobile communications with troopers, and with the maintenance personnel in their regions. They respond to incidents to provide a full range of incident management services to prevent secondary crashes, reduce congestion, and restore normal traffic flow as quickly as possible.

For the CAD-TMC FOT to show substantial improvement in accuracy and timeliness was recognized as a challenge because of the already existing procedures and relationships in place. The FOT has proven worthwhile for the agencies to continue their quest to develop a true real-time data exchange system.

6.2 RECOMMENDATIONS

6.2.1 General Recommendations

  1. Involve IT staff early-on in the project planning process. Interviewees emphasized the importance of involving agency information technology staff early in the development of the integrated system. This is important so the IT organization provides technical input to the system to ensure that the computing and communication environment fit within each agency and can be effectively maintained.
  2. Understand the importance of close working relations from the start. All interviewees commented on the importance of a close working relationship among the agencies involved in this FOT. As is noted in section 2 of the report, WSP and WSDOT have established a Joint Operations Policy Statement governing incident response procedures, and conduct regular meetings to discuss operational issues. The two agencies had long-standing, well-established working relationships prior to the FOT that provided a forum for resolving issues encountered during the deployment.
  3. Provide dedicated staff working on integration, or staff with emphasis on integration. Interviewees mentioned that it was often difficult to spend enough time on the integrated system. Decisions and work items sometimes took longer than those involved would have preferred. Even though every agency supported the integrated system, staff had normal responsibilities with integration duties added on. It would be ideal if staff involved had a priority on the integrated system tasks.
  4. Understand the importance of considering role of business practices in the integrated system. As discussed earlier in this document, it is important that the integrated system not require a change in the operator's or dispatcher's work process. For example, as discussed in section 5, WSDOT originally intended to be able to populate event information in the WSP CAD system through a "hazard flag." The WSP CAD application did not lend itself to ingesting the WSDOT data as proposed and dispatchers would have to access WSDOT event information through a Web interface, and congestion information through either a Web interface or TMC workstation software. This approach would have required dispatchers to change their normal work processes to access and view this information.
  5. Coordinate deployment schedule with vendor schedule for system modifications and upgrades. As stated in section 5, CAD systems are generally off-the-shelf products. Vendors have a fixed release schedule, so it is important to coordinate project schedules with the vendors' release schedules.
  6. Define what data is exchanged and when. In Washington State, WSP had concerns about releasing all incident-related information recorded in the CAD system. The WSP did not want to provide WSDOT with information that might compromise the investigation of incidents or other proprietary information related to law enforcement activities. The two agencies eventually established a protocol on what information would be provided to WSDOT, and a filter was developed that selected only the agreed to information from the CAD system when incident information was pushed to the CARS system.

6.2.2 Technical Recommendations

  1. Coordinate deployment schedule with CAD vendor schedule for system modifications and upgrades. There were times that the project schedule was not met because the vendor release schedule was unknown when the CAD-TMC project schedule was developed.
  2. Establish common incident location identifiers. There was confusion and a potential problem identified with ability to correctly locate incidents because the WSP and WSDOT typically used somewhat different location identifiers. These location identifiers may be different names for the same landmark or may be different ways to describe the same location. It would be helpful to come to agreement on a method of describing locations among the parties involved. In addition, it would be beneficial to agree on as many common incident locations as practical.
  3. Consider system latency. It is critical to consider what is acceptable for latency in the system. This may differ from region to region, agency to agency, even operator to operator. Latency should be considered early during the system approach development phase and needs to be considered a system requirement once the appropriate levels of latency are identified.
  4. Consider automation. In general, the more automation, the better. Things to consider are whether operators sometimes or always need to verify incidents before the information is sent out. This may vary by situation, so the system needs to be designed with the needs of various operators and stakeholders in mind. There may need to be different approaches in rural and urban areas.

6.2.3 Institutional Recommendations

  1. Select response partners carefully. There must be a clear benefit to the partner in the integration. As mentioned is section 2.3, Skagit County EMS was too small with too focused a mission to really be a qualified candidate as a secondary responder incorporated in the integrated system. WSDOT initially selected Skagit County EMS because it was small and WSDOT thought it would be a better initial step to incorporate a smaller, less complex response agency. In hindsight, WSDOT representatives indicated that they should have selected a response agency where there were more traffic problems. For example, on an urban freeway where roving incident response vehicles have just started operation, it might be beneficial to know when and to what location local police and fire are dispatching response units. It would be interesting to determine if knowledge about the actions and location of the WSDOT incident response vehicles would be a benefit for dispatchers at these local agencies.
  2. Focus on primary objectives. In Washington State, the primary objective is providing improved traveler information. The primary view of success was whether or not information about incidents to the public is improved and provided on a more timely basis. By focusing on the primary objectives, trade-off decisions can be made more easily. Also, the focus on primary objectives helps determine the best design alternatives.
  3. Work process. WSDOT initially thought that providing information about traffic conditions and WSDOT incident management activities directly to WSP dispatchers would be beneficial to the dispatchers. However, the information was not integrated into the dispatcher's applications well, so the dispatcher's work process would need to change to make use of this information. As a result, WSDOT is now considering sending a map layer to the WSP dispatch terminals that will show events and perhaps traffic congestion. Also, WSP will be equipping vehicles with AVL. WSP has suggested that the WSDOT incident response vehicles and service patrols be equipped with AVL to display their locations in the WSP system. Together, these approaches will provide the functionality originally envisioned by WSDOT, and would fit much better into the WSP dispatchers' work process as well.
  4. System training. From interviews with development staff and operators, additional training would have been beneficial in the WSDOT system. There are some subtleties in how to configure the system to provide operators with the most benefits. Although it initially seems straightforward with little need for additional training, it is important to train operators on how to use the system features and to allow them to ask the developers how to use the system in specific situations to gain the desired results.

Previous | Next