Completed

Type III transponders are a suitable means for two-way communication between vehicles and road infrastructure. The transponders are small and are mounted on the interior of the vehicle windshield. Currently they are used for parking management and for data exchange for commercial vehicle border crossings. Because of these existing uses, there is a large number of Type III transponders already in use in commercial vehicles, and the infrastructure for the two-way communications is in place. Additionally, because of their current uses, Type III transponders are available in production quantities at competitive prices.

This project developed and evaluated a system for providing real-time, in-vehicle safety warnings to travelers through the use of Type III transponders. The development and evaluation performed in this project lead to recommendations for a full operation test deployment.

The project identified the appropriate structure and format for safety warning transmission to Type III transponder equipped vehicles. The Bearer Application Protocol (BAP) form data transmission developed the safety warning message list. An interface and software program provides and displays in-vehicle safety warnings. Finally, the
project made recommendations for a full test deployment.

The Colorado Mayday Field Operational Test was intended to develop and test an invehicle device that could be manually triggered in an accident or emergency and would report the vehicle location along with other vehicle-specific information. The project was proposed to the Federal Highway Administration (FHWA) in January 1994, and testing commenced in early 1995. Three phases were planned, of which two were completed. The first phase assessed the design and technical performance of the Mayday system through limited testing. The second phase tested the system in real-world conditions on a small scale basis. The final phase was to be a full-scale test involving 2000 motorists that would use the system in actual emergencies.

Other elements of the project included evaluating the system’s fit within the National ITS Architecture, the feasibility of marketing a low-cost system, and expanding the program to a nationwide program.

The low-cost Mayday system is comprised of three principal elements, defined as follows:

Mayday in-vehicle unit
The in-vehicle unit housed the low-cost location device which provided the GPS data from which the vehicle position could be derived; the button box used to operate the system and request assistance; and the interface equipment used to control the
communications system.

Communications system
A two-way communications link transmitted, request information to the control center and receive confirmation messages from the control center.

Mayday control center
The control center received all emergency assistance requests originating from the invehicle units. The requests were processed, identifying the vehicle location and type of assistance required. The control center then routed the request to the appropriate response agency and notified the motorist of the action taken and the anticipated response time.

The results of the Colorado Mayday project proved the concept, and established a series of functional requirements for how such a system would need to operate on a national level. The Colorado Department of Transportation (CDOT) Mayday Project Manager, Neil Lacey, participated in the Multi-jurisdictional Mayday Group, in order to share these lessons learned with private sector Mayday products and services.

Project Duration: 1995-1997

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.