Balance project goals against the constraints and capabilities of project partners.
Virginia DOT’s experience integrating data from public works and public safety agencies.
One of the primary lessons gleaned from this project was the necessity of balancing project goals against the constraints and capabilities of project partners. The following examples demonstrate how VDOT and the VSP worked together to resolve various technical, budgetary and data constraints on the part of the VSP.
Standards for Data Exchange
One of the goals of this project was to develop a standards-based interface between VSP and VDOT. Benefits of using standards include:
- 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
- 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 would support the needs of the Richmond STC and 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 VSP budgetary constraints, 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 key discovery affected many later technical decisions. Identify constraints such as this as early as possible in the design process. In VDOT’s case, identifying this constraint early saved significant time 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. 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 implementation. Three standards were considered:
- TMDD Message Sets
- IEEE 1512 Standards
- 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. 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. For this effort, however, 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 VDOT to distribute other alerts that could affect traffic using the same interface, such as weather alerts, flood alerts, and AMBER alerts.
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 VDOT offices. These offices might include other VDOT Smart Traffic Centers, the Transportation Emergency Operations Center, and the interim and future 511 system. Because staff and budgetary resources at VSP were limited, it was decided that future users of the CAD data should be able to be added without having to require changes to the system from the VSP side. VSP should be able to send their data to a single receiver that would be responsible for forwarding these 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. Second, 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 messages. These systems are often referred to as Message Oriented Middleware (MoM). Various commercial and open source 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 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.
Data Availability Issues
When sharing data between two systems, anticipate the possibility that data formats may not be compatible. 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 are 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.
Sensitive Data Issues
Devise a plan to deal with sensitive data. 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).
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, thereby protecting any sensitive information, while the ROADI segment would be sent with information of specific interest to VDOT.
Author: Robison, David, Matt Sargent, and Steve Beckwith
Correspondence with Robb Alexander , Virginia DOT, on April 6, 2006
Published By: Virginia DOT
Prepared by Open Roads Consulting, Inc. for the Virginia DOT
Source Date: January 2005
EDL Number: 14115URL: http://ntl.bts.gov/lib/jpodocs/repts_te/14115.htm
Open Roads Consulting
Robert Alexander, P.E.
Virginia Department of Transportation
Volpe National Transportation Systems Center
Average User Rating
Management & Operations > System Data & Storage
Policy & Planning > Planning
Policy & Planning > Architecture
Design & Deployment > Requirements & Design
Design & Deployment > Standards & Interoperability
Design & Deployment > Implementation
Technical Integration > Functional
Technical Integration > Jurisdictional
Technical Integration > Legacy Systems
Legal Issues > Liability
Legal Issues > Privacy
automated vehicle location, computer aided dispatch, automatic vehicle locator, AVL, CAD, AVL/CAD