2002-2009

Mn/DOT funded the large portion of this project with their own (non ENTERPRISE) funds, but roughly one third of funds were supported by ENTERPRISE. The result was that this project demonstrated to all ENTERPRISE members the potential for voice entered reports into a condition reporting system.

All ENTERPRISE members were able to trial the system by simply calling the number and entering events into Minnesota (test system), and even allowed in-field operators to trial the system to learn how easy or difficult entry may be. The intent was that this project could hold the potential for increasing the quality and quantity of events entered into condition reporting systems of all the ENTERPRISE member states.

For those ENTERPRISE states using the CARS condition reporting system, this would transfer directly to their systems with minimal set up efforts. For states not using CARS but using other condition reporting systems, the Voice XML grammars and experiences developing the Voice XML system will benefit other states (assuming they use VXML or similar 511 development software).

Project History

The intent of this project was to develop and demonstrate the capability for in-field personnel to verbally enter situations and events into condition reporting systems and/or 511 phone systems by calling an interactive phone system. This demonstration allowed ENTERPRISE member states to experience the design decisions that were reached, as well as allowing ENTERPRISE members’ staff (ie. construction or maintenance personnel) to trial the voice interactive system to determine if their state wishes to develop such a system. Minnesota was interested in statewide deployment of this system and was willing to fund the large percentage of costs, but has asked for minimal ENTERPRISE funding to reflect the benefit other member states will receive by being able to trial such a system.

Many ENTERPRISE states currently operated a condition reporting system, where events (road construction, accidents, weather, delays etc.) were entered manually by DOT staff. These condition reporting systems often served as the data resource for 511 phone systems, traveler information web pages, and Highway Advisory Radio (HAR) broadcasts.

Language in the next Transportation Authorization Bill included provisions that each state DOT must operate a condition reporting system within 2 years. One challenge with condition reporting systems was the need to keep current and accurate and informative information in the system. States like Minnesota, Iowa, Alaska had invested in automated ingests of such things as loop detector data, R/WIS data. Minnesota had also funded and deployed a mobile reporting system that allows snow plow operators to enter driving conditions using web-enabled cell phones from the vehicles. This eliminates the need for someone in the field (who arguably knows best what the conditions are) from needing to radio in a report to then be entered by someone at the operations center.

The web enabled cell phone entry (named Mobile Data Automated Reporting) MDARS was a huge success in the limited deployment area in Minnesota (Southeast Minnesota). Snow plow operators preferred to enter conditions directly from the vehicles, and operations center staff appreciated not having to hear reports over the radio and enter them into the condition reporting system.

The Vision:
While the web-enabled cell phones provided a very useful tool, it was still restrictive in that users would need to have web enabled cell phones and a web service plan. This also posed a potential problem when expanding statewide as web enabled cell access is not currently available everywhere.

Therefore, Mn/DOT proposed to demonstrate a migration from web enabled cell phone use to allow authorized users to call a phone system (MN will use their existing 511 system) and speak events in to the phone when prompted by the system. This allowed operators in the field to answer simple questions and verify the event in the end and have the event entered in to the system. Therefore, this allowed entry from any phone (cell or landline) and need not require any special equipment purchases or service plans.

Project Activities

The four tasks required to complete this project included the following:

Task 1: Develop Concept of Operations and Functional Requirements
In Task 1, Castle Rock developed a ConReq (Concept of Operations / Functional Requirements) document defining the MDARS Voice Reporting system. The ConReq contained sufficient detail to describe to Mn/DOT the functionality of the system and served as a design document for software developers. Topics defined within this task included:

• The manner in which locations are spoken and described;
• The dialogs and prompts that ‘tease’ out the appropriate information from callers;
• Authorization when calling; and
• Levels of detail that will be accepted for entry.

To complete this task, Castle Rock will perform the following activities:

• Review usage of MDARS (web enabled cell phone activity);
• Meet and work with Mn/DOT to understand the needs and interests for functionality of the MDARS Voice Reporting System;
• Discuss similar interests from additional CARS states at performing voice entry;
• Consider the interests from Mn/DOT and other states, as well as the capabilities of the CARS system and develop the ConReq document; and
• Meet with Mn/DOT to discuss and finalize the ConReq document.

Task 2: Software Development
Efforts in Task 2 developed the software to achieve the requirements defined in the ConReq. Efforts within this task included:

• Development of Voice XML based system to prompt callers with the target questions and recognize spoken replies;
• Development of grammars to perform voice recognition;
• Voice recordings to support new dialogs; and
• Ingest module to ingest the Voice XML based input into CARS using the TMDD FEU standards.

Task 3: QA and System Testing
Efforts in Task 3 conducted QA testing on the CARS-Voice system to test performance against the ConReq. The Castle Rock QA Team developed a test plan, and summarize the test results with a QA report. Any issues or challenges which arised were addressed by the software development team and retested prior to completing this task.

Task 4: Training
In Task 4, Castle Rock performed training to the designated lead person in each District in a ‘train the trainer’ format. Castle Rock and Mn/DOT arranged logistics of the training, however roughly 5 days were anticipated to perform the training within the state. Castle Rock prepared a training manual, a users manual and a cheat sheet to guide entry into the system.

Variable Message Signs (VMSs) are widely used to advise motorists of roadway conditions and incidents so that appropriate actions can be taken by the driver to enhance the safety and efficiency of transportation operations. VMSs are often supplemented by Highway Advisory Radios (HARs) in urban and recreational areas to provide a comprehensive Advanced Traveler Information Systems (ATIS). While extensive work had been done studying the use of the VMS technology for incident scenarios, little or no known work had been done to define practices and policies for use of VMS and HAR during non-incident conditions.

Variable message signs are often used in both urban and rural applications to provide information to motorists related to incidents. An incident is any non-recurring event that causes a reduction in roadway capacity or an abnormal increase in demand. Some examples of incidents include traffic collisions, disabled vehicles, spilled cargo, highway maintenance and construction projects, weather-related concerns, and special events attracting large numbers of vehicles. Significant research has been done in the art of displaying and formatting messages for incident applications; these messages typically include a location and problem description in the message.

Many state transportation departments and other local and municipal agencies have been at the forefront of ATIS implementation, providing motorist information in order to create a more efficient and safer transportation system. Numerous agencies also maintain a large number of urban and rural permanent VMSs, as well as a number of HAR transmitters, during construction and incident-related conditions. However, many agencies, such as the Arizona DOT, only made limited use of their ATIS infrastructure for non-incident-related conditions. Because there were no official documents and information related to the non-incident use of VMS and HAR, this research provided guidance to the ENTERPRISE members in developing policies for non-incident use of VMS and HAR.

Project Activities

The work completed as a part of this project included the following:

Task 1: Literature Search

A thorough literature research was conducted to identify pertinent documents related to non-incident usage of VMS and HAR.

Task 2: VMS and HAR User Surveys

This task identified and made telephone contacts with VMS and HAR users at all 50 State transportation departments to learn what each department’s current polices and practices were related to non-incident usage of VMS and HAR. Some examples of questions that practitioners were asked include:

• How many VMSs or HARs are you responsible for?
• Do you use your VMSs and HARs during non-incident conditions?
• What types of non-incident information do you display on your VMSs?
• How are your HARs used during non-incident conditions?
• Do you have warrants for each type of message you disseminate?
• Do you have examples of formats of the common messages used during non-incident conditions?
• Can you identify any difficulties with VMS or HAR usage during nonincident conditions?
• What is the public perception of the ATIS program, which you operate?

It was anticipated that more detailed follow-up questions would be asked of those practitioners who make frequent use of non-incident-related messages for their ATIS operations.

Task 3: Draft Report

A concise draft report was developed to document the results of the literature search, and practitioners’ interviews. The report contained summaries of the responses received in tabular and graphical formats. A main focus area of the report was recommendations for non-incident use of the VMS and HAR ATIS technology. The consultant also endeavored to qualitatively identify the benefits of non-incident use of the technology. The report included an Executive Summary of key findings.

Task 4: Final Report

Following review by ENTERPRISE and other interested parties, the project consultant incorporated comments and prepare a final report. The report was presented both electronically and in hard copy formats. The consultant developed a PowerPoint presentation of the project findings for public presentation.

Deliverables

• The following products were delivered from this project:
• A Final Report that can be used by ATIS operators to develop policies and procedures for non-incident use of VMS and HAR.
• A public presentation of the report’s findings to an appropriate national technical audience, as recommended by the ENTERPRISE group.

The ENTERPRISE Travel Time Best Practices Research Project involved contacting numerous State Department of Transportation (DOT) representatives to discuss best practices for travel time data collection, processing, and information reporting. The final report summarizes the results of the conversations and lessons learned.

In addition to simply documenting the practices implemented in each state, research was also conducted on the specific approaches used for monitoring and reporting information. Therefore, there are a number of matrices in the final report, each one presenting a different perspective on the topic of travel time prediction and reporting.

The intent of this research was not to develop a lengthy white paper on the topic of travel time reporting, but rather to present quick facts in an easily referenced format to support ENTERPRISE member agencies in understanding what has worked and what has notworked in the field of travel time reporting.

The explosive rate of deployment of digital personal communication services (PCS) worldwide, is creating new opportunities for deploying ITS technology in remote locations otherwise unreachable by economically viable methods.

The digital PCS data services are cost competitive and offer a means of reducing the recurrent costs of existing distributed ITS systems. Several agencies in Ontario, including the City of London and York Region are interested in verifying this communications technology for traffic signal control systems (TSCS) communications.

The purpose of this project was to test the next generation of digital wireless technology offered by PCS (personal communication service) service providers and determine if it can support the communications requirements for the urban traffic signal control systems utilizing legacy NEMA traffic signal controllers.

Phase 1

During 2007, the ENTERPRISE Program funded an evaluation of the Kansas Rural Transit Intelligent Transportation Systems (ITS) currently being operated in Hays and Hutchinson, Kansas.  The intent of the evaluation was to document the users perceptions and experiences with the system in order to help the Kansas Department of Transportation (KDOT) determine if and when to expand the ITS technologies to other locations throughout the state. 

The technologies operated by the Kansas rural ITS project include Automated Vehicle Location (AVL) on transit vehicles, Mobile Data Terminals (MDT) in the transit vehicles and data communications between the dispatch center and vehicles, and Computer Aided Dispatch (CAD) systems.

Phase 2

The findings of the 2007 evaluation activities confirmed that the ITS technologies provided benefits to dispatchers, supervisors, drivers, and riders in both Hays and Hutchinson.  However, nearly every individual commented that the systems had many instances of failures in either the equipment or the communications systems.  In order to better understand these system failures, a second evaluation effort was performed to document what systems are having problems, and ideally to help lead to resolving the problems.

The objective of this project was to examine whether a typical DMS can be reliably powered by a solar/wind HRPG. The project location was near a State highway and hasdan easy access to utility grid power, and thus the location was not selected based on the needs and cost benefits of an HRPG but rather selected based on the convenience of field tests and availability of a DMS for testing. Since solar/wind HRPGs were not available on the market, the researchers designed and put together a solar/wind HRPG using off-the-shelf products. Installation was done with the help and resources provided by the Minnesota Department of Transportation (Mn/DOT). The DMS was originally designed and installed to be powered by a grid AC source.
Consequently, power efficiency was not a concern in the design. This project replaced the grid AC power supply with a solar/wind HRPG.