Challenges Faced and Tactics Used to Integrate Real-Time State Police
CAD Data with the VDOT Richmond District Smart Traffic Center
Lessons Learned Document
Version: Final
Issued: -Jan-2005
PDF Version 238KB
Prepared for: Commonwealth of Virginia |
Prepared by: Open Roads Consulting, Inc. |
|
|
CHANGE HISTORY
RICHMOND/TRI-CITIES SMART TRAFFIC CENTER (STC)
Version |
Author(s) |
Description |
Date |
Draft-1 |
David Robison, Matt Sargent |
The original document |
16-Dec-004 |
Final Draft |
Steve Beckwith |
Management review |
Preface
RICHMOND/TRI-CITIES SMART TRAFFIC CENTER (STC)
This document discusses the significant issues encountered during the development effort of integrating the Transportation Management System (OpenTMS) deployed at the VDOT Richmond District Smart Traffic Center (STC) with the real time State Police data coming from the Virginia State Police (VSP) Computer Aided Dispatch (CAD) system. This Lessons Learned Document is intended to provide some guidance to projects undertaking similar tasks and challenges.
TABLE OF CONTENTS
1. OVERVIEW
1.1 Identification
1.2 Lessons Learned Definition
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Document Overview
2. Project management Lessons Learned
2.1 FHWA and VDOT Cooperation
2.2 VDOT and VSP Cooperation
2.3 VDOT and Contractor Cooperation
2.4 ORCI and NGC Cooperation
3. TECHNICAL Lessons Learned
3.1 Standards for Data Exchange
3.2 Publish/Subscribe Service
3.3 Available Data Issues
3.4 Security to Sensitive Data Issues
3.5 Early Deployment Strategies
3.6 Rapid Prototyping
4. Post Deployment Lessons Learned.
4.1 General Experience
4.2 Operations Experience
2.1 Expansion Beyond Richmond STC
2.2 Future Use
7. Cost Overview
1. OVERVIEW
1.1 Identification
This document contains the lessons learned for the system integration of the Virginia State Police (VSP) Computer Aided Dispatch (CAD) system with the VDOT Richmond District Traffic Management System, OpenTMS. This project is commonly referred to as the VSP-CAD Implementation effort. This effort had two general thrusts: First; integrate the data arriving from the VSP into the OpenTMS Traffic Control System and second; update and customize OpenTMS’ Incident Management subsystem to more effectively utilize this integrated data.
The start of this project began with a Concept Study [1], conducted prior to Open Roads involvement. The study found that there would be significant benefit to the integration of the Virginia State Police Division 1 CAD system and the Richmond Smart Traffic Center. The study recommended the sharing of the data from the VSP CAD system as a course of action. On the VSP side, some software modifications and a modest amount of hardware could deliver near real-time data to VDOT at the Richmond STC. The data would contain up to the minute status of events dispatch to the police. On the STC side, software modifications would be more significant. The changes would allow the data to be tightly integrated into the traffic management system, OpenTMS, at a detailed level. This would allow the staff at the STC to use the VSP-initiated traffic incidents as an integrated part of the operations within the Richmond STC. This “lessons learned” document describes the challenges faced and tactics utilized in the design and development of the VDOT STC side of this project.
1.2 Lessons Learned Definition
During this effort, several issues and challenges arose that were noteworthy in that they were significant in nature and/or they were not limited to a particular system. The lessons learned documented all have certain features in common:
- Significant impact on the success or failure of a project;
- Not immediately evident or significant - they were discovered after development began or even during the final phases of the project;
- Wide in scope - encompassing more than a small part of the system under development; and
- Noteworthy - documenting the experience holds value for other efforts that will attempt similar projects.
1.3 Definitions, Acronyms, and Abbreviations
Additional definitions specific to software engineering may be found in IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology.
AMBER |
America's Missing: Broadcast Emergency Response |
CAD |
Computer Aided Dispatch |
CAD2CAP |
Process responsible for converting VSP CAD data to CAP messages |
CAP |
Common Alerting Protocol v. 1.0 |
FHWA |
Federal Highway Administration |
GIS |
Geographical Information System |
IEEE |
Institute of Electrical and Electronics Engineers |
IOC |
Interim Operation Center |
ITS |
Intelligent Transportation Systems |
MoM |
Message Oriented Middleware |
MOU |
Memorandum of Understanding |
NGC |
Northrop Grumman Corp. |
OASIS |
Organization for the Advancement of Structured Information Standards |
OpenTMS |
Open Transportation Management System |
ORCI |
Open Roads Consulting, Inc. |
OS |
Operating System |
P/S |
Publish/Subscribe |
RFP |
Request for Proposal |
STC |
Smart Traffic Center |
TMC |
Traffic Management Center |
TMDD |
Transportation Management Data Dictionary |
VDOT |
Virginia Department of Transportation |
VSP |
Virginia State Police |
VTTI |
Virginia Transportation Technology Institute |
XML |
Extensible Markup Language |
1.4 References
[1] |
Richmond Regional Data Sharing Concept Study; Issued: March 2003 |
[2] |
Final VSP Standards White Paper v1.0; Issued: 2-Dec-2003 |
1.5 Document Overview
The following list describes the organization of this document.
Section 1 |
Overview -- This section provides project background, acronyms, and references. |
Section 2 |
Project Management Lessons Learned – Describes lessons learned associated with the management, resources, and organizations. |
Section 3 |
Technical Lessons Learned – Describes lessons learned associated with technical aspects of the effort. |
Section 4 |
Post Deployment Lessons Learned – Describes activities that have occurred after the initial deployment. |
Section 5 |
Cost Overview – Briefly reviews the project costs. |
2. Project management Lessons Learned
The lessons learned in this section deals with those that relate to how the project was managed, how human resources were utilized, and how different organizations communicated and worked together.
This project involved the participation and cooperation of the following public and private organizations:
- Federal Highways Administration (FHWA) – Sponsor;
- Virginia Department of Transportation (VDOT) – Sponsor and Project Management;
- Virginia State Police (VSP) – Sponsor and Project Management;
- Open Roads Consulting, Inc. (ORCI): VDOT software development contractor; and
- Northrop Grumman Corp. (NGC): VSP software development contractor.
The diagram below depicts the relationships between the these federal and state agencies and their respective contractors.
It should be noted that this diagram depicts the contractual or “formal” relationships between the organizations. The “actual” involvement of these organizations is better depicted in the following schematic.
Perhaps, the greatest key to the success of this project was the open exchange of ideas and information between all organizations involved. One quick example was when a developer from ORCI needed to talk to a developer at NGC, they could communicate directly without having to first go through VDOT then VSP then to NGC. This saved enumerable amounts of time and provided for an efficient and beneficial exchange of information that was needed during the development phase.
2.1 FHWA and VDOT Cooperation
While there was a contractual relationship between FHWA and VDOT, it became clear early on that FHWA was committed to the mission and success of the VDOT Richmond District during this project. For example, when issues were raised about the exact protocol to use for the exchange of information between VSP and VDOT, FHWA was willing to evaluate the available protocols. This evaluation is documented in the paper titled “Final VSP Standards Whitepaper”. After reviewing candidate standard's stability, the current usage of the standard by others, the usability of the standards considering the fact that the VSP legacy CAD system would not be changed, and other issues with standards (e.g. TMDD and P1512) as they relate to the VSP CAD system, FHWA concurred in VDOT's recommendation to use the Common Alert Protocol (CAP). This one decision contributed significantly to the timely completion and success of this project.
2.2 VDOT and VSP Cooperation
Both VDOT and VSP shared a common enthusiasm and commitment to the successful development of the integration between their two respective systems. Both organizations embodied a, “what can I do for you?” attitude. It was their joint commitment to the project that facilitated the rapid resolution of issues and the continued good morale on the project.
The Richmond Regional Data Sharing Concept Study [1], was performed at the start of the project. It provided for a common understanding of the project and established a common goal for both agencies. This document also aided in communicating these goals and understandings to the other members as they were added to the team.
In hindsight, one step that would have even furthered the good cooperation between the two agencies would have been the use of a formal Memorandum of Understanding (MOU). While there was a good understanding of the expectations of both agencies during the design, development, and deployment phases, there was some ambiguity regarding the on-going support required for the long term operations phase. This ambiguity was not intentional, but was simply an oversight of the support activities that would be required during the operational phase. If time had been taken up front to develop a formal MOU, it is possible that the operational needs might have been identified earlier on in the process so they could be properly addressed by both agencies.
2.3 VDOT and Contractor Cooperation
This project benefited from the well established relationship between VDOT and ORCI staff. In fact, many of the same staff responsible for the development of the Richmond STC central software also participated in the VDOT/VSP integration project. ORCI's intimate knowledge of the Richmond STC system and software allowed them to identify any technical issues related to the integration early in the design process. The existing working relationship between VDOT and ORCI helped facilitate open and effective communications between the two organizations.
2.4 ORCI and NGC Cooperation
Because of the general atmosphere of cooperation that prevailed during this project, it afforded direct communications and cooperation between the technical staff of ORCI and NGC. The ability for the technical counterparts of each organization to communicate and discuss issues on an ad hoc basis eliminated delays sometimes associated with asking and receiving information between contractors.
Another key aspect to the cooperation between ORCI and NGC is that nether company was overly concerned with “defending their turf”. Both parties related on a professional level and issues were resolved based on the needs of the client, not each other's system. Both companies realized that they could only be successful if the other company was also successful.
3. TECHNICAL Lessons Learned
The lessons learned in this section deal with those lessons discovered in the technical area of the project. As is the case with most technical projects, an eye was cast for future expandability and current reliability. There were many technical choices that were made during this effort. The significant ones are documented in this section.
3.1 Standards for Data Exchange
One of the goals of this project was to develop a standards-based interface between VSP and VDOT. Three benefits of using standards follow:
- They allow developers to build upon an established knowledge base developed during the creation and maintenance of the standard;
- They extend the overall longevity of a system; and
- They facilitate the expansion of additional inputs and outputs into and from the system.
The goal of the project was to develop an interface that, not only would support the needs of the Richmond STC, but could also serve the needs of other state agencies and STCs. This necessitated an open and standard interface that would be easily integrated into other systems.
Because of the budgetary constraints of the VSP, it was realized early that the VSP could not be expected to make significant changes to the CAD system to support current ITS standards. This was a key discovery early on in the project that affected many of the later technical decisions that were to be made. Identifying this constraint early saved significant time during the design phase by eliminating options early that would have not been viable in the long run. Because of this constraint, an alternate means was required to deal with accepting data from the VSP CAD system in its current format. Because of this, the standard needed for the interface between the VSP and VDOT had to efficiently represent the data received from the CAD system.
A review was made of other National CAD-TMC integration efforts around the United States. Special attention was paid to their protocol selection and their success with the implementation. Out of this search, three standards were considered:
- TMDD Message Sets;
- IEEE 1512 Standards; and
- Oasis CAP Standard.
As part of the analysis of these standards, sample CAD messages were mapped to each standard and the resulting XML message was generated and evaluated. These results were published in the Final VSP Standards Whitepaper. The first two standards did not provide for an intuitive mapping between the CAD message and the resulting XML message. While these standards excel at the exchange of incident information between management centers, and even provide for the cooperative management of incidents, they did not “fit” for the exchange of dispatch data from the VSP CAD system to VDOT's STC system. This does not preclude their use at a later date, if and when VSP upgrades their CAD system to natively support one of these protocols, but for this effort, they were not viable options.
The working model where the VSP was sending VDOT alerts received from the dispatchers and the troopers in the field was adopted. The alerts were not classic incidents as defined within the Intelligent Transportation System (ITS) field but these “alerts” could eventually become an STC “incident” if the STC operator recognized the alert as an incident that needed to be managed. Choosing an alert protocol (CAP) would also allow us to distribute other alerts that could affect traffic using the same interface, such as weather alerts, flood alerts, and AMBER alerts.
3.2 Publish/Subscribe Service
While the scope of the initial project was a connection between the VSP CAD system and the Richmond STC system, VDOT anticipated the desire to distribute the CAD data to other state agencies. These agencies might include other VDOT Smart Traffic Centers, the Transportation Emergency Operations Center, and the interim and future 511 system.
Because the staff and budgetary resources at VSP were limited, it was decided that the future users of the CAD data should be able to be added without having to require changes to the system to be made from the VSP side. VSP should be able to send their data to a single receiver that would be responsible for forwarding that data to the interested end users. Also, it was envisioned that those end users would be other computer systems as well as humans.
Prior to the agreement on the exact protocol to be used for sharing data between VSP and VDOT, it was observed that all the considered protocols had a few things in common. First, they were all based on the XML standard. Secondly, they were all message based. In other words, each of the standards defined a set of XML messages to be used in the data exchange. Therefore, it became logical to search for a publish/subscribe system that was optimized for the passing of XML-based message. These systems are often referred to as Message Oriented Middleware (MoM). Various commercial and open source Message Oriented Middleware (MoM) systems were investigated. The goal was to select an existing MoM system that could be easily deployed and meet the needs of the project. MoM systems that could operate in a Publish/Subscribe (P/S) mode were desired. In this mode, the VSP CAD system would “publish” their messages to the MoM server and the Richmond STC would “subscribe” to those messages. The MoM would then forward the published messages to the subscribed users. In the future, when other agencies wanted access to the CAD data, they would simply become another subscriber to the MoM.
The resulting system is depicted below:
The decision to use an existing MoM Publish/Subscribe system eliminated the need to develop a custom P/S system to support the exchange of XML data. It also provides a platform that is portable across multiple hardware and OS platforms as well as multiple languages. This reduces the cost of integrating the VSP CAD data into other systems.
3.3 Available Data Issues
One of the key issues regarding the available data from VSP was the lack of geo-location data. Location information is entered into the VSP CAD system as a free form text. While there is somewhat of a standard pattern of how the location data is entered into the incident, it is not consistent across all operators. This is not an issue for VSP, since their CAD system is not GIS based, but it did become an issue for the Richmond STC since their central system software is GIS based. During discussions with VSP about the ability to get geo-location data from their CAD system and the effort required to provide the data, it quickly became clear that the changes required to the VSP side would be prohibitive and beyond the scope of this project. It was therefore decided that, though not currently populated, the current latitude/longitude fields from the CAD system would be sent to VDOT in the case that, at some later time, VSP would be able to provide such data.
Investigation was also made of what could be done on the VDOT side to translate the free form location field to obtain the incident's GIS location. In the interest of not delaying the project's schedule, it was decided that any effort to translate the free form location field would be left for a separate project.
3.4 Security to Sensitive Data Issues
Early on in the project, the team discussed and decided on what type of information should be shared between VSP and VDOT and how sensitive information contained in those incidents would be handled.
There are many activities of the Virginia State Police that do not directly impact the motoring public, and as such, are not of interest to VDOT. For example, a ‘warrant served dispatch’ does not impact the roadways and does not concern VDOT or their operators. It was decided that VSP CAD incidents would be first filtered by their “10-Code” (the 10-Code defines the VSP incident type). The following table identifies the initial set of 10-Codes to be sent from VSP to VDOT.
1011 |
VANDALISM |
1030T |
TERRORIST RELATED INCIDENT |
1043 |
INVESTIGATE SUSPICIOUS UNKNOWN |
1043P |
INVESTIGATE SUSPICIOUS PERSON |
1043V |
INVESTIGATE SUSPICIOUS VEHICLE |
1044 |
PEDESTRIAN ON HIGHWAY |
1046 |
DISABLED VEHICLE |
1046A |
DISABLED VEHICLE ABANDONED |
1046O |
DISABLED VEHICLE HAZARD |
1046H |
DISABLED VEHICLE OCCUPIED |
1047 |
TRAFFIC PURSUIT |
1048 |
WANTED INDICTED |
1050 |
VEHICLE CRASH UNKNOWN INJURIES |
1050A |
VEHICLE CRASH ANIMAL INVOLVED |
1050D |
VEHICLE CRASH PROPERTY DAMAGE |
1050F |
VEHICLE CRASH FATALITY |
1050I |
VEHICLE CRASH WITH INJURIES |
1050P |
VEHICLE CRASH PRIVATE PROPERTY |
1050S |
STATE VEHICLE ACCIDENT |
1053 |
ASSIST OTHER AGENCY |
1054 |
LIVESTOCK IN HIGHWAY |
1057 |
HIT AND RUN UNKNOWN DAMAGE/INJ |
1057D |
HIT AND RUN PROPERTY DAMAGE |
1057F |
HIT AND RUN FATALITY |
1057I |
HIT AND RUN INJURY |
1057S |
HIT AND RUN STATE VEHICLE |
1058 |
TRAFFIC CONTROL |
1060 |
FIRE |
1060B |
FIRE/BRUSH |
1060V |
FIRE/VEHICLE |
1061 |
EXPLOSION |
1063 |
HAZARDOUS MATERIAL INCIDENT |
1068 |
THROWING MISSILE AT VEHICLE |
1069 |
TRAFFIC OTHER |
1073 |
KIDNAPPING/ABDUCTION |
1076 |
DEBRIS IN ROAD |
1077 |
BRANDISHING A FIREARM |
1082 |
DEAD BODY |
SIG18 |
PLANE CRASH |
MEDIC |
MEDICAL EMERGENCY |
TP |
TRAFFIC PURSUIT |
SP |
SUBJECT PURSUIT |
STORE |
STORING A VEHICLE |
VDOT |
CALL FOR VDOT SERVICE |
Additionally, most of the textual data regarding an incident was contained in the incident's Miscellaneous (MISC) segments. Some of this textual information contained information deemed “sensitive” by VSP. Such data included the names and description of individuals and vehicle license plate numbers. To separate out the textual data that would be important to VDOT from data that was sensitive in nature and of not great importance to VDOT, a new incident segment type, the “ROADI” segment type, was added to the VSP CAD system. This new segment type was intended to be used by the CAD dispatchers to record textual information regarding the incident that would be of interest to VDOT managers and operators. The ROADI segment gave operators two options for entering textual data, the MISC segment and the ROADI segment. The primary difference being that the ROADI segment would be passed onto VDOT operators while the MISC segment would not. The two segment types did not require the operator to double-enter the data, but rather to chose if the textual data being entered was of interest to VDOT operators or not. Thus the MISC segments would be filtered, there by protecting any sensitive information, while the ROADI segment would be sent with information of specific interest to VDOT. The current segment types being sent to VDOT include:
ENTRY |
This segment is sent when a new incident is entered into the CAD system. |
CHANGE |
This segment is sent when static data pertaining to an incident is changed. Such as the location, duty post, and 10-Code. |
ONSCENE |
This segment is sent when the first officer arrives on scene. |
DISP |
This segment is sent when an officer is dispatched to the scene. |
CLEAR |
This segment is sent when the last officer leaves the scene. |
ROADI |
This segment is sent when information pertaining to the highway needs to be communicated to VDOT. |
3.5 Early Deployment Strategies
Because of the use of a 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:
- The CAD-to-MoM-to-Viewer integration was developed and validated early on in the project;
- VDOT would get an early estimate of the amount of CAP messages that they would be receiving from the CAD interface;
- The bandwidth required for the message volume could be evaluated early in the project;
- The viewer would provide a “template” for the future CAP integration with the STC system;
- 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; and
- 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 agencies to see the type of information they would eventually be able to receive;
- The AlertViewer could eventually be made available to other agencies to view the CAD data without having to invest significant monies into a complicated system integration; and
- 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 our regular 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.
3.6 Rapid Prototyping
The early stages of a project can be difficult. The developer is trying to nail down requirements so that they can deliver a solid product and a firm estimate of cost. The client is 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 our 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.
Firstly, 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.
The second reason for hardcopy screens was 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.
4. Post Deployment Lessons Learned
4.1 General Experience
During the initial days of the systems deployment, a few issues surfaced that required cooperation between all parties to resolve. While not necessarily “major” in nature, the resolution of these issues greatly increased the usability of the system.
- Incidents not cleared. Early experience with the AlertViewer showed a small subset of incidents were entered but never cleared. At first this was thought to be an anomaly. Code was added to the VDOT side to clear any incident with no activity for the past 24 hours. Further investigation showed that this issue was an ongoing issue. With the support of NGC, the cause of this problem was identified. What was happening was that incidents were starting out with a 10-Code that was passed to VDOT and then the 10-Code was changed to one that was filtered from being sent. This left the original incident remaining to appear as open even though it had been cleared under a different 10-Code. To resolve this, incidents were sent from VSP to VDOT if either the original 10-Code or the current 10-Code matched the permissible list of codes.
- Duplicate Incident Numbers. Reviewing the program logs it was noticed that new incidents were being received with incident IDs that matched previous incidents. These new incidents appeared to have been assigned a duplicate incident ID. In talking with VSP, it was learned that officers, on occasion, will reopen a previously cleared incident to record further information regarding the incident. What appeared as a new incident was really the reopening of an old incident. Code was added to the program that translated the incident data to its CAP message to keep information on cleared incidents for up to 1 hour in case an incident was reopened by an officer.
- Lack of Information. Within the first few months of use, a handful of incidents were identified where the incident was properly sent to VDOT but insufficient textual information was included for VDOT to ascertain the severity of the incident. It was determined that the problem was that not all dispatchers were using the ROADI segment to record information of importance to VDOT. Instead, this data was recorded in the MISC segment that was being filtered by VSP. VSP undertook an effort to provide better training of the dispatcher regarding the use of the ROADI segment. To date, however, this issue is still a problem. While some dispatchers make good use of the ROADI segment, its use is not consistent among all the VSP dispatchers.
4.2 Operations Experience
In the short time that the VSP-VDOT CAD integration has been in production at the Richmond STC, there have been two key observations made by the STC operators.
- The operators have been able to see and track a significantly greater number of incidents than were previously tracked by relying on the VSP scanner and phone calls from VSP dispatchers. STC operators now have a much better picture of what is happening on the roadways.
- There have been much fewer calls from the VSP dispatchers to the STC operators. This is due to the VSP dispatchers being aware that VDOT is monitoring the data they enter into the CAD system. Therefore, the VSP dispatchers assume that the need to call the STC operators is greatly reduced. The only problem that this has created for the STC operators is receiving consistent information in the ROADI segment of the data stream. This leads some VSP dispatchers to erroneously assume that information entered (in a MISC segment) has been read by STC operators and therefore there is no need to phone VDOT. The consistency of using the new ROADI segment to provide roadway information versus using the MICS segment will be an ongoing training effort that is required for the interface between VSP and VDOT to continue to be successful.
2.1 Expansion Beyond Richmond STC
Presently, two separate efforts have been initiated to extend the user of VSP data beyond the Richmond STC.
- Staunton STC -- As the CAD integration was being developed, deployed and tested at the Richmond STC, the Staunton STC was being brought on-line. While the Richmond STC coverts the central and southern portions of the I-95 corridor, the Staunton STC is responsible for the norther portions of the I-81 corridor. The managers at the Staunton STC realized the significant benefit that the VSP data could bring to their operation in Staunton. To support the Staunton STC, the AlertViewer was initially deployed on the operator's workstations to allow them to view and monitor the VSP incidents within the area of the STC's responsibility. This instillation was completed in less than 1 day. The installation required a change to the Richmond STC firewall to allow access to the P/S service by operators at the Staunton STC. Also, a configuration change was required to the AlertViewer configuration file to specify the location of the P/S service and to select the incidents of interest to Staunton. Subsequently, the fully integrated OpenTMS Incident Management subsystem has been deployed at the Staunton STC.
- DOT Interim Operation Center (IOC) -- Previous to the VSP-VDOT CAD integration effort, The IOC, located at the Virginia Transportation Technology Institute (VTTI), was responsible for monitoring the VSP incidents along the I-81 corridor and for providing incident information to the I-81 511 system. The IOC accessed the VSP data by establishing a telnet session with the CAD systems for the various VSP districts. This “scan” of outstanding incidents was done on a scheduled basis. It was up to the IOC operator to determine the severity and nature of the incident and if the incident should be added to the 511 system. The IOC expressed interest in obtaining the VSP CAD data from VDOT's P/S service since this data was provided in real-time. Also, receiving this information electronically would help further the automated processing of VSP incidents by the IOC operators. The VTTI technical staff was, in a relatively short amount of time, able to write a client application for the P/S system to receive the VSP incidents in real time. This new client is still in the “alpha” stage of being used by the IOC. The main issue regarding its use at the IOC is that operators at the IOC are receiving far less information about an incident than they were when using the telnet sessions. This is due to the filtering of the MISC segments by VSP prior to the data being sent to VDOT. Previously, the IOC operators, using the telnet interface, we able to view all the MISC segment data entered by the VSP operators. What they are finding is that not all the data pertinent to traffic operations is being entered into the ROADI segment and much of the data is being left in the MISC segment, which is currently being filtered. Options are currently being reviewed by VTTI, VDOT, and VSP to address this issue.
2.2 Future Use
A number of future uses of the VSP-VDOT CAD integration system are being considered by VDOT.
- There is a desire to deploy the CAP Viewer at other STCs in the state, including the Hampton Roads STC, Northern Virginia STC, and Fredericksburg STC.
- There are plans in place to move the hosting of the P/S system from the Richmond STC to another location to support further statewide deployment of the system.
- VDOT and ORCI are also investigating what would be required to provide a fully redundant system for the transfer of VSP CAD data. This would include redundant servers and the ability of the client applications to automatically “fail over” from one server to the other as needed.
- There are plans to develop a service that would attempt to parse and translate the free form location field into GIS coordinates.
- A prototype system has been developed by ORCI to investigate the feasibility of sending filtered CAP messages via e-mail, pager, and instant messenger.
- There is a desire to have the CAD data included, and integrated, into the Archival Data Management System being maintained by the University of Virginia's Smart Travel Lab.
7. Cost Overview
The development of the VDOT portion of the CAD/STC integration was completed for under $250,000. The effort included the design, prototyping, software development, integration, testing and training of VDOT personnel. Approximately 37 percent of the effort was expended on the design and prototyping. The remaining 63 percent of the budget was expended on the software development and integration effort.