Develop early deployment and rapid prototyping strategies to improve the project development process.

Virginia DOT’s experience integrating data from public works and public safety agencies.

Date Posted
09/16/2005
TwitterLinkedInFacebook
Identifier
2005-L00058

Challenges Faced and Tactics Used to Integrate Real-Time State Police CAD Data with the VDOT Richmond District Smart Traffic Center: Lessons Learned Document

Summary Information

This lesson is learned from the experiences encountered while integrating the Transportation Management System (OpenTMS) deployed at the Virginia Department of Transportation (VDOT) Richmond District Smart Traffic Center (STC) with real-time data from the Virginia State Police (VSP) computer-aided dispatch (CAD) system. This project had two thrusts: first, integrating data arriving from the VSP into the OpenTMS Traffic Control System, and second, updating and customizing the OpenTMS' Incident Management subsystem to utilize this integrated data more effectively.

The project began with a concept study, which found a significant benefit to integrating the VSP Division 1 CAD system and the Richmond STC. The study recommended sharing data from the VSP CAD system. On the VSP side, some software modifications and a modest amount of hardware would deliver near real-time data to the Richmond STC. The data would contain up–to-the-minute status of events dispatched to the police. On the STC side, more significant software modifications were required. The changes would allow VSP data to be tightly integrated into OpenTMS at a detailed level, allowing Richmond STC staff to use VSP-initiated traffic incidents as an integrated part of STC operations.

Lessons learned related to multi-partner cooperation, early deployment and prototyping, last-minute technical glitches, and post-deployment training.

Lessons Learned

Develop early deployment and rapid prototyping strategies to improve the project development process.



Early Deployment



Develop early deployment strategies. Such strategies can enhance the project development process by improving communications and providing opportunities for testing and evaluation. Because of the use of a Message Oriented Middleware (MoM) service, the project decomposed into two separate development efforts. First was the sending of VSP CAD data to the MoM service in the standard CAP message format. The second was receiving the CAP messages and integrating them into the Richmond's OpenTMS system. In terms of effort, it was estimated that the integration of CAP messages into the STC system was on an order of magnitude greater than the effort to integrate the CAD data into the MoM. VSP's and NGC's participation in the project was mostly connected to the integration of CAD messages to the MoM. There was a need to be able to validate that interface without having to wait for the completion of the MoM to STC system integration. It was decided that a simplified CAP message viewer would be developed to view the CAP messages sent by the VSP CAD system and forwarded by the MoM service. This AlertViewer would benefit the project in a number of ways:

 

  1. The CAD-to-MoM-to-Viewer integration was developed and validated early on in the project
  2. VDOT would get an early estimate of the amount of CAP messages that they would be receiving from the CAD interface
  3. The bandwidth required for the message volume could be evaluated early in the project
  4. The viewer would provide a “template” for the future CAP integration with the STC system
  5. VDOT operators would be able to build confidence in the integration by matching data from the interface with information they currently receive via phone calls and the police scanner
  6. VDOT would get an early return on their investment in the project
    • Early successes in the interface would maintain high morale during the project
    • The AlertViewer would allow other VDOT offices to see the type of information they would eventually be able to receive
    • The AlertViewer could eventually be made available to other VDOT offices to view the CAD data without having to invest significant monies into a complicated system integration
    • VSP's and NGC's involvement in the project would be greatly reduced beyond the initial CAD-to-MoM integration



The development and use of the AlertViewer was useful in fine-tuning the interface between the CAD system and the MoM server. The CAD event types that were useful were identified while other event types were tagged as not needed. Some small system integration problems were identified early in the effort and were fixed long before the MoM-STC system integration was completed. Data from this tool also became a discussion item during project progress meetings.



Through the use of the AlertViewer, it became apparent that VSP dispatchers were not using the ROADI segment consistently. Some operators made good use of the new segment while others simply ignored it. Because of this, VSP initiated a training program for all dispatchers on how to use the ROADI segment and how to enter information that would be useful to VDOT. This training greatly helped the exchange of information between the two agencies. Additionally, these types of activities were conducted in parallel with the continued STC integration effort.



Rapid Prototyping



Develop and implement rapid prototyping strategies. The early stages of a project can be difficult. The developers are trying to nail down requirements so that they can deliver a solid product and a firm estimate of cost. The clients are trying to make sure that the system that they are designing and ultimately paying for will satisfy their needs and not cause them undue hardship. Frequently these two groups are speaking very different languages. During the early stages of this project, a very valuable technique was employed to help bridge that communication gap. Prototype screens of the proposed system modifications were generated and paper copies were printed for use in briefing and requirements definitions meetings. Mock up screens with functional buttons could have been generated, but the paper versions of the screens were used for two very important reasons.



First, they could be marked up, written on and occasionally cut up. This allowed the client to clearly indicate how they felt about the capabilities of the modified system and the manner in which those capabilities would be presented. They were not shy about marking up the images and asking us about certain capabilities. Though this process of rapid prototyping, both the developers and operators were able to arrive at an accurate and consistent understanding of the end product that was to be developed. In short, there was a better ability to bridge any communication problems and speak the same language. The client was able to “see” what the system would provide, and the developers were able to understand client expectations.



Second, hardcopy screens were used to emphasize to the operators that the screens were temporary, changeable, and disposable. Often a client sees a mock-up or a prototype of some system screens and assumes that the system is complete or that too much work has been expended to change the screens – even though, the mock-up screens are usually very quickly created and have little or no underpinnings. In this situation, the use of screens printed on paper proved an effective methodology.