Figure 1 - Illustration of WSDOT Regions
Washington State Department of Transportation
May 22, 2006
For the PDF version of this document, please click here.
TABLE OF CONTENT
1. Executive Summary
2. Introduction
3. Project Background
3.1 Project Objectives
3.2 Project Partners
4. Projects Events
4.1 Project Outreach and User Needs Assessment
4.1.1 Outreach Activites
4.2 Design and Development of CARS CAD Module
4.3 Implementation and Use of the System
5. Project Results
5.1 Concept of Operations
5.2 System Summary
5.2.1 WSP CAD Export
5.2.2 CARS-CAD Data Import
5.2.3 CAD Data Retrieval
5.2.4 CARS-CAD Data Conversion
5.2.5 Event Deletion
5.3 Summary of Use and Operational Status
5.4 Challenges and Resolutions
6. Conclusions and Next Steps
6.1 Review of Project Objectives
6.2 Topics for Ongoing Consideration
The Washington State Department of Transportation (WSDOT) operates a number of traveler information dissemination systems that collectively inform Washington travelers about active and planned events on the roadway network both pre-trip and en-route to their final destination. The WSDOT public Internet site receives millions of visitors each month and the 511 phone system receives thousands of calls each day. Travelers visiting these information sources are seeking real-time alerts of adverse weather events, traffic events, and accidents that will impact travel. WSDOT has a network of automated weather sensors, and in-field traffic monitoring devices, however accident and incident reporting remains a manual task.
The primary emergency response to most traffic accidents in the state of Washington is provided by the Washington State Patrol (WSP). Given that emergency cellular 911 calls are received at the WSP dispatch center and in-field troopers regularly report progress as they respond to accidents and events in the field, the WSP dispatcher center quite regularly is the most comprehensive source of information about incidents and accidents that impact the Washington roadway system.
At the onset of this project, the relay of information from WSP to WSDOT was either performed verbally using either radio or telephone reports, or by the transfer of data to a read-only monitor located in the WSDOT Northwest Region radio room that is separate from any CAD system used by WSDOT. It is easily understood that during emergency events, this communication link can significantly increase workload.
The Washington State CAD-TMC project has created an automated link from the WSP CAD system to the WSDOT statewide Condition Acquisition and Reporting System (CARS). [1] This link now ensures that WSDOT operators in each of the six traffic management centers are alerted about each accident reported into the WSP CAD system. Further, a simple event verification screen has been added to the CARS user interface that WSDOT operators use on a daily basis. This verification screen allows operators to quickly and easily accept events for inclusion into the statewide reporting system.
While this project was funded and performed as a Field Operational Test (FOT), the result is an ongoing sustainable system now hosted and operated by WSDOT that has become a part of the daily routine of operators around the state, and will remain in operation.
The USDOT Intelligent Transportation System - Joint Program Office (ITS-JPO), Public Safety Program funding and cooperative approach to this project has demonstrated, first hand, that a data exchange from law enforcement CAD systems into DOT traffic management and traveler information systems is not only possible, but very beneficial to travelers and TMC operators.
Some specific benefits and results experienced by this project (that are detailed in this Final Report) can be summarized as follows:
1. Ongoing operational status. As noted before, there are no plans for terminating the operation or use of this valuable system.
2. Proven use in both urban and rural settings. The architecture of the system supports the WSP to WSDOT data exchange in all areas of Washington, from the urban areas of Seattle to the remote rural areas found in the Eastern portion of the state.
3. Decision support minimizes operator input. Often, WSDOT operators need only one click of the mouse to accept a full event into the system for immediate delivery to the public over the 511 phone system and public web page.
4. Operators edit events to add critical information. When appropriate, operators use the convenient event verification screen to add extra critical information describing the event.
5. Regional filtering with statewide entry options. During normal operational periods, WSDOT operators are not burdened by alerts of events in regions for which they have no entry responsibilities. However, any operator can elect to view (and edit and accept) events occurring anywhere in Washington, giving full "virtual" functionality to the system.
The result of this project has been much more than an exercise and demonstration of a technology and approach. The network of six WSDOT TMCs now operate an additional software tool as part of their suite of software products that, collectively, help them to manage the Washington road network and keep travelers informed of critical events that impact travel. The deployment of this solution in related projects involving the CARS system in Florida, New York (and six additional planned deployments) is a testament to the Federal Highway Administration (FHWA) "Pooled Fund" approach as all states collectively participate in the CARS Pooled Fund activity. In addition, Washington State may soon benefit as partner states continue to add functionality and features to the CAD-CARS software.
This final report is intended to document the events and results of the Washington State CAD - TMC Integration project. Section 3 describes the project background, including information on project partners and overall project objectives. Section 4 describes the events that occurred during the project. Section 5 describes the results of the project, including the concept of operations, a summary of the implemented system, results from operators' use of the system, and a recap of the challenges encountered and key decisions reached during the project.
The Washington State Department of Transportation (WSDOT) has operated the Condition Acquisition and Reporting System (CARS) since the year 2000. Currently, CARS operates statewide, allowing authorized users the ability to enter road, weather, traffic, construction, accident or special event conditions into the statewide system. CARS has proven to be an effective mechanism for assembling data in one central location and disseminating the information through the 511 phone system and the WSDOT traveler information web pages found at http://www.wsdot.wa.gov/traffic/.
The Washington State Patrol (WSP) operates a Computer Aided Dispatch (CAD) system statewide to allow entry of events that are reported to the State Patrol and subsequently responded to by the dispatch of one or more troopers. In many cases, the events entered in the State Patrol CAD system are the exact events needed in the CARS system (only less details are required in the CARS system). The Washington State Patrol has recently implemented a new statewide CAD system.
The primary objective of the Washington State CAD - TMC Integration project has been to integrate the State Patrol CAD system with the CARS system. The software developed to accomplish this integration is known as the CARS-CAD module. CARS-CAD has broadened the reach of CARS to include the automatic input of incident reports from the Washington State Patrol's (WSP) computer-aided dispatch (CAD) system. CARS now includes a framework for this type of event data exchange via an interface that is fluent in messages defined by two major ITS standards groups: TMDD and IEEE 1512. The TMDD Committee's Event Report Message (ERM) was the first message implemented by CARS, which allows it to input event reports from external systems, as well as to share its own database of current events with other centers. CARS has also been upgraded to support simple TMDD FEU messages. (FEU, or Full Event Update, is the successor message to ERM.)
The intent of the Washington CAD-TMC Project was to accomplish the following project objectives:
Objective #1
To implement and demonstrate a link between the WSP CAD system and the CARS system operated within Washington state in order that pertinent accident and event data will be shared with TMC operators using the CARS system and disseminated through the existing dissemination mechanisms such as 511 and the traveler information web pages.
Objective #2
To incorporate and demonstrate the use of ITS standards whenever possible, particularly to show how different standards work together, such as IEEE 1512 and the ITE/AASHTO Message Sets for External Traffic Management Center to Center. By demonstrating the open use of standards, it was hoped to that the ease in expanding this system to other states and areas could be demonstrated.
Objective #3
To extend the integration to include secondary responders, such as Skagit EMS to demonstrate how medical responders will be able to offer improved service from this information.
The key partners of the Washington CAD-TMC project have been the following:
This section outlines the Washington State CAD-TMC Integration project events that occurred during the project timeline of August, 2003 - December, 2005. For presentation in this report, project events are summarized into three primary sets of events:
The remainder of this section describes these events.
4.1 Project Outreach and User Needs Assessment
During the four month period from August, 2003 to January, 2004, a series of outreach meetings were conducted with Washington State DOT CARS operators and Washington State Patrol CAD operators and administrators. The intent of these meetings was to work together with the eventual users of the system to understand the critical functionalities of the system. Outreach meetings were conducted in the primary CARS data entry offices in each WSDOT region. Figure 1 illustrates the six WSDOT regions.
Figure 1 - Illustration of WSDOT Regions
The meeting locations to represent each region were held as follows:
In each meeting, WSDOT and WSP operators were introduced to the preliminary project concept of operations, and invited to offer reactions and input to the proposed deliverables. The most critical feedback received from CARS operators around the state was the strong desire to review and verify each CAD event before it was formally ingested as a CARS event. This feedback significantly changed the original concept of the project, as originally the project was intended to be an automated ingest of CAD events into the CARS system. However, given the strong requests from the operators, the system was designed and developed to require operator verification of events using an event verification screen. The outreach meetings were also used to prepare users for the system and to discuss training and deployment issues.
A series of meetings involved Skagit EMS during the early stages of the project. However, the results of these meetings did not result in a clearly defined role for Skagit EMS, within this project. Therefore the third objective for the project was not achieved.
4.2 Design and Development of CARS CAD Module
The majority of efforts within this project have been the design and development of the software product known as the CARS-CAD module. CARS-CAD provides an automated data transfer and a data translation between CAD and CARS so that accident and incident information is inserted into the CARS database and appears to CARS operators through an event verification screen. An event is verified instantly if it is entered by a responder in the field, or if the operator feels that there is a high probability that an incident has occurred. Once incident reports are accepted into the CARS system as events, they can be disseminated to the public through WSDOT's 511 service and traveler information web site.
Building upon the outreach meetings and concept of operations, between January 2004 and March 2005, the project team developed system requirements, a detailed design document, and finally the CARS-CAD software. The process involved a release of a very preliminary software and demonstration to the operators in one region (Vancouver, Washington). These operators contributed significant feedback on the original Alpha version and this feedback was incorporated into the formal design and development process.
4.3 Implementation and Use of the System
The final set of events completed within the project was the formal implementation of the system and use by WSDOT CARS operators. Acceptance testing and system implementation was performed over a two month period with completion in April, 2005. The Washington CARS-CAD software is hosted and operated in Olympia, Washington and resides inside the WSDOT Intranet network. After receiving release notes, administrator guides, and technical launch support from Castle Rock Consultants, WSDOT now administers and hosts the CARS-CAD system.
Operators using the CARS-CAD system log in to the CARS graphical user interface (GUI), from any Internet compatible computer with access to the WSDOT Intranet. Operators do not need any local software running on the machine to use the CARS-CAD system, with the exception of the Internet Explorer browser.
CARS-CAD includes the automatic input of incident reports from the WSP CAD system. CARS now includes a framework for this type of event data exchange via an interface that is fluent in messages defined by two major ITS standards groups: TMDD and IEEE 1512. The TMDD Committee's Event Report Message (ERM) was the first message implemented by CARS, which allows it to input event reports from external systems, as well as to share its own database of current events with other centers. CARS has also been upgraded to support simple TMDD FEU messages (FEU, or Full Event Update, is the successor message to ERM).
Also, in recent months, through a separate project with the New York State Department of Transportation, CARS was upgraded to support some 1512 messages as part of a series of ongoing initiatives to import incident data from emergency responders in New York State [2]. As a result of those efforts, the CARS interface now supports the automatic input of incident reports from the New York Thruway's CAD system into the New York State CARS deployment, by way of 1512. It is planned that CARS-CAD, as described here, will capitalize on the new CARS interface developed by New York, using 1512 to push data into the CARS database.
In the world envisaged by the ITS Standards Development Organizations (SDOs), the WSP CAD system would support 1512 off the shelf, making the CARS-CAD module redundant. If that were the case, then the two systems, CAD and CARS, would now be virtually ready for plug-and-play event exchange information, as pioneered in New York.
However, because the CAD system does not currently have such an interface, CARS requires a special module to retrieve incident reports from an FTP site, to which the WSP's CAD reporting tool will push data files. Every two minutes, WSP CAD creates a data file containing a list of current, abbreviated incident reports in tab-delimited format. The posting of the data to the FTP site triggers a data analysis routine on the WSDOT FTP server, whereby state plane coordinates in the WSP data file are converted to latitude and longitude so that events can be situated properly on the CARS map after the import. The data in the text file-including the original data posted by WSP, as well as the latitude and longitude appended by WSDOT-will form the basis of the incident data automatically input into CARS via this module, to be known as CARS-CAD.
Because using ITS standards whenever possible is a requirement for all CARS-related modules, the design concept of CARS-CAD envisions a temporary translation tool that converts the nonstandard data on the WSP website to basic 1512 messages for input to CARS. The tool will serve as a proxy for WSP, pushing 1512 messages to CARS on behalf of WSP, as if it were the sending center. This approach has the benefit of ensuring that CARS is already prepared for future, more advanced 1512-based data exchanges with the WSP and other agencies involved in emergency management.
It is important to note, however, that the range of structured data available from WSP is limited. In the live CAD system, much of the information that is important from a DOT and traveler information perspective is entered in free-text fields. Free-text entry introduces spelling errors and inconsistent shorthand, both of which render any data parsing and mapping routine vulnerable to error.
Another concern is that the WSP CAD reporting tool operates on cyclical update intervals (currently, approximately every 2 minutes), which introduce a latency that is typically avoided in an event-triggered push (currently implemented with SOAP in the NY CAD system) where new information is distributed as it becomes available, on an as-needed basis. Also, the WSP CAD server is external to WSDOT and is therefore not time-synchronized with the CARS deployment. Therefore, all the CAD information must be re-imported to CARS every few minutes, whether or not it has actually changed.
In spite of these significant, known difficulties, project team members have made their best efforts to capture accurate and timely data from the FTP site for input to CARS. However, some loss of incident report detail and timeliness is an inevitable consequence of the data exchange model and the quality of the data.
It is strongly recommended that steps be taken in the near future to 1) publish more consistent and structured data to the WSP data file on an absolute time schedule; or, better, 2) build a 1512-compliant interface for the source CAD system, based on event-driven SOAP data pushes.
This section presents a high level summary of the CARS-CAD system deployed within the Washington CAD-TMC project. Earlier deliverables documented the requirements and detailed design during the project development. This summary section is included as an overview of the system as implemented.
The exchange of event data from the WSP CAD system to the WSDOT CARS system begins with an export of non-standard event descriptions generated by the WSP CAD system. The WSP CAD system generates a data file containing public information about active events in the CAD system and transfers the file to WSDOT using an FTP file transfer. Outside of generating this data file, the WSP performs no additional activities to support the CAD-TMC data exchange (outside of their routine of entering events into CAD).
CARS-CAD converts non-standard WSP CAD data into IEEE 1512 standard data as a first step in the data processing. CARS-CAD bases its exchanges of the converted data on draft national ITS center-to-center (C2C) standards. IEEE 1512 draft standards shall provide the basis for these exchanges, as already deployed in other CARS states.
CARS-CAD facilitates a one-way CAD to CARS data exchange. As WSP Communications Officers (COs) add, update, and close incident reports in the CAD system, corresponding event reports are inserted in and removed from CARS, with operator confirmation. When TMC personnel approve CARS-CAD reports, they also have the opportunity to edit and modify the reports before committing them to CARS.
Data exchanges utilize an IEEE 1512 XML interface to gain access to the CARS database. Internal transfers between CARS-CAD and the CARS database support use of direct database access. The purposes of using the 1512 standard for CARS-CAD data imports (via a translation tool) are to help insulate CARS from the effects of changes to the proprietary WSP CAD software, and to encourage a future version of the WSP CAD system to adopt the 1512 standard.
The data import process can be broken down into four main steps, described below and illustrated in Figure 1, that together form a cycle that CARS-CAD executes at regular intervals. A setting (default = 2 minutes) allows CARS system administrators to adjust the repetition interval.
Figure 2 - Data Flow
Outside of CARS, the WSP CAD system maintains and manages incident/event reports entered by COs.
Every two minutes, the WSP CAD reporting tool creates a data file, that contains a list of current, abbreviated incident reports, and pushes it to the WSDOT FTP site. Another automated routine, developed and maintained by the WSDOT Office of Information Technology (OIT), collects the file and performs a conversion on some of the location data in order to append a latitude and longitude to each incident report. The latitude and longitude helps CARS-CAD situate the event in the correct location on the CARS map. It then posts the data to a new directory on the WSDOT FTP site for CARS-CAD to retrieve. Finally, CARS-CAD collects this file for parsing and input to CARS.
All open incidents related to traffic (as filtered by the WSP CAD system) are included in the output files. An incident is considered open from the moment it is first entered into CAD until the dispatcher manually changes its status to closed (or merges it with one or more other open incidents). An event is typically considered to have ended when WSP troopers exit the scene.
The first step in the CARS-CAD data import cycle is the automated retrieval of the most current WSP data via retrieval of the data file. FTP pulls shall be made by CARS-CAD at a configurable time interval (default, one minute).
Because the WSP CAD data file is not time-synchronized with the WSDOT systems, an overall latency of up to four minutes can be expected to result from this publish and retrieval process. With a 60-second read cycle, only one read in three can be expected to contain any updated WSP data, but the "wasted" reads will help CARS avoid adding significant additional latency into the data retrieval cycle.
5.2.4 CARS-CAD Data Conversion
After a new set of WSP CAD data is collected, CARS-CAD analyzes the report, looking for incidents that need to be sent to CARS. It accomplishes this task by identifying a description, location, and any other parse-able information reported about each incident in the output file.
CARS-CAD then translates each of the relevant incidents to a 1512-based incident report message (IDX), which it sends to the CARS XML interface. Incidents that have been updated, closed, or otherwise removed since the last data collection interval are captured, also. Updates are transmitted as a further IDX message, whose update counter is incremented. Incident reports that disappear from the CAD report cause a 1512-based incident closure message (CIE) to be sent to CARS [3].
When a new message is received from WSP, CARS-CAD posts the details to an Event Verification Screen (EVS) instead of immediately adding it to CARS.
Designated operators are alerted with a flashing icon (flashing between 
and 
) that appears on all CARS screens, indicating that new information has been posted to the EVS that requires their attention. When users click the flashing icon, they arrive at the EVS. If no operator responds either by clicking on the icon or switching to the EVS screen within a specified time (DOT-configurable, the default time is 15-minutes), an email is sent to designated supervisors. The email send feature address(es) to which this and all CAD-related supervisor notifications should be sent will be stored in a configuration file.
CARS-CAD pushes all of the prepared event reports to an Event Verification Screen (EVS), illustrated in Figure 2 below, where new, updated, and deleted incidents are stored, awaiting operator verification. The EVS allows operators to view the original text pulled from the CAD log, as well as the proposed corresponding event for insertion into CARS.
Operators are offered four options for each event:
Accept: Clicking the Accept button inserts the event into CARS, making it a part of the active Situation List. Accepted events are not user editable or deletable through the Situation Map. Rather updates from CAD will automatically propagate to these situations. Users can edit Accepted events from the EVS (described in more detail later in this document).
Hold: When an operator clicks the Hold button, the event report remains in the message verification screen but will not be committed to the CARS database of active situations. The date, time, and username of the operator who clicked the Hold button appears on the screen for other operators to see.
Take Over Event: When an operator clicks the Take Over Event button, the event report message is posted to CARS. By clicking Take Over Event the user is accepting responsibility for message updates. Unlike the Accept option, taking over the event disables automatic updates of the situation from CAD reports. On the other hand, this type of acceptance allows manual editing and deletion of the event from within the Situation map, including (if desired) editing the duration for the event. These types of events remain in CARS until the duration time has elapsed, or a user has deleted them. These events are not canceled when the CAD system sends a cancel report.
Edit: The edit button allows the operator to edit or add more information to an event. An operator selects it from the EVS Situation List and then clicks the "Edit" button in the main screen panel. Situations which are edited in this manner are still linked to future updates from WSP, however any changes/additions that the users performed while editing the event are remembered and maintained even as new information arrives from WSP CAD. Note that events edited with the edit button are not considered to be 'take over' events.
There are two ways in which CARS-CAD events can be ended:
Edit: The edit button allows the operator to edit or add more information to an event. An:
5.3 Summary of Use and Operational Status
In April, 2005, the Washington State CAD-TMC implementation of the CARS-CAD software was completed and began full operational use. A six month Field Operational Test (FOT) was conducted and involved an ITS-JPO sponsored evaluation team to assess the operational status and impacts of the system. Beyond the FOT timeline, the CARS-CAD software is operational and will remain operational for daily use by operators throughout the state. The results of this project are summarized by the following highlights:
5.4 Challenges and Resolutions
This section outlines the primary challenges and issues that were encountered by the project team, and the approach followed to resolve each issue.
Different coordinate mapping systems. It was discovered early in the project that the WSP CAD system uses state plane coordinates while the WSDOT TMC and CARS system uses latitude/longitude for referencing locations. This resulted in a challenge in that the geo-location of events was required to "snap" each event to the nearest roadway and point on the road. To solve this issue, WSDOT developed and implemented a conversion tool that immediately processes the incoming WSP state plane coordinates and produces the resulting latitude/longitude coordinates. The results are that an additional process must be run on an additional server (as the computations are significant), and this has added to the architecture and complexity of the system. However, once the new system was developed, tested and implemented, it resolved this issue.
Lack of a role for Skagit EMS. The original concept for this project was to use the CAD-TMC project to engage a local emergency responder and create a one-way (or perhaps two-way) exchange of data. While the intent was there from both parties, the efforts of several meetings were not successful in defining a sustaining role for Skagit EMS. The involvement of Skagit EMS was a goal from the onset of the project, however did not affect the core of the project, which was to exchange event data from the WSP CAD system to the WSDOT CARS system. Therefore, this did not impact the results experienced by WSDOT or WSP.
Non-standard WSP CAD data output. National ITS standards, such as IEEE 1512, allow for unrelated systems to exchange data seamlessly. However, the WSP CAD system does not support a standardized output. In addition, much of the data that is exchanged is free text, abbreviations, or codes, and therefore conversion of the data output is very challenging. Nonetheless, this challenge was understood when the project was proposed. The project team approached this challenge considering both the short term and long term. The CARS-CAD software was written to initially convert the WSP CAD data into the IEEE 1512 standard, and then to pass the IEEE 1512 compliant data into the Washington CARS system. This required modifications to the CARS system to be able to receive IEEE 1512 compliant event data. This approach also offers a long term solution in that if/when the WSP CAD system migrates to eventually supporting the IEEE 1512 standard, the conversion tool can be removed, and the CAD system can send events directly to the CARS system using IEEE 1512.
Time lag due to ftp push. Another challenge with the project was the unavoidable time lag that results because of the fact that the WSP CAD system will push a data file out once every two minutes. Also, because the WSP system is not synchronized with the WSDOT system, the WSDOT CARS-CAD cycle may begin up to one minute after the ftp push occurs. This challenge results in the time delays experienced by the system. The solution was to minimize the cycle time as much as possible. However, the long term proper solution to this time lag is to have the WSP CAD system push events directly to the CARS system (as happens in New York and Florida) to avoid this critical time delay. In order for this to be achieved the CAD system would be required to operate on 1512 standards.
This section provides some concluding thoughts on the WSDOT CAD-TMC project, as well as offers suggestions for next steps.
6.1 Review of Project Objectives
Objective #1
To implement and demonstrate a link between the WSP CAD system and the CARS system operated within Washington .
This objective has been completed, both during the operational test, as well as by establishing a long term ongoing link between WSP CAD and CARS. The fact that this link will continue in full operation under WSDOT funding represents the value of this project to the CARS users and travelers throughout Washington state.
Objective #2
To incorporate and demonstrate the use of ITS standards whenever possible, particularly to show how different standards work together, such as IEEE 1512 and the ITE/AASHTO Message Sets for External Traffic Management Center to Center. This objective has been accomplished through the use of IEEE 1512 for transmission of the CAD events into the TMDD based CARS system. Ideally, the CAD vendor would output the CAD data in IEEE 1512 standards so no conversions need to occur. However, this is not possible and therefore a IEEE 1512 conversion is performed and then the CAD events are passed to CARS in the IEEE 1512 standards format. Therefore, when the CAD system does convert to IEEE 1512 standards, the 1512 conversion can be removed and the core CARS-CAD component will remain operational.
Objective #3
To extend the integration to include secondary responders, such as Skagit EMS to demonstrate how medical responders will be able to offer improved service from this information. As noted earlier, this objective has not been fully accomplished as the role of Skagit EMS was hard to define within this project. However, the architecture of this project allows additional users with Internet access to benefit from the data received from the Washington State Patrol CAD system.
6.2 Topics for Ongoing Consideration
The following topics represent lessons learned and/or topics proposed for further consideration as the concept of CAD-TMC integration is pursued.
One-way vs. two way flow of information. The WSDOT CAD-TMC project continues to demonstrate the one-way flow of information from law enforcement CAD systems to State DOT TMC and traveler information systems. However, initial feedback indicates that some data exchange from State DOTs to law enforcement CAD would also benefit the law enforcement dispatchers. This flow of information may include traffic flow/speed information and/or roadwork and major event information.
Non-standard CAD data output. As noted previously, the lack of the use of ITS standards by the CAD vendor contributed to a large portion of the development efforts. The success of this project, and the proven effectiveness of law enforcement and DOT data sharing should prompt an action to motivate CAD vendors to implement ITS standards compliant solutions. The number of CAD vendors is large, and therefore this task will not be trivial, however there is a role for Federal involvement in providing incentives to law enforcement CAD vendors to develop standards compliant software products.
Footnotes
[1] CARS is a non-proprietary, standards based condition reporting system that allows authorized users to enter, view and disseminate critical road, travel, weather and traffic information. Developed as part of a Federal Highway Pooled Fund, CARS is owned by a Consortium of States. Currently, ten states have deployed the CARS system (Minnesota, Iowa, Missouri, Alaska, Washington State, New Mexico, Kentucky, Maine, Vermont, and New Hampshire). Additional information about CARS may be found at http://www.carsprogram.org/public.htm.
[2] 1512 defines message sets for emergency responders such as police, fire, rescue, and ambulance services to share incident data.
[3] A CAD > CARS latency is introduced by the two-minute cycle required for the CAD system to publish a current incident list to the web, as well as for the time required for the lat/long conversion and data collection routines. Thus, information is up to four minutes old when it is inserted into the CARS database (plus any extra time required for manual verification, where needed). A future system upgrade to SOAP push (as used in New York State) could eventually eliminate most of these message publishing delays.