Completed

Inform

The Inform Project followed the ENTERPRISE Simple Solutions project and focused on disseminating the cost effective, low tech solutions for rural transportation community through the development of a website. Through the Inform web site, local agencies could enter information either on the local characteristics or the recognized needs of their area. Based on user input, the Internet site recommended and offered information on those simple solutions most applicable to the local agency. The web site proved to be very popular, receiving thousands of hits and dozens of serious inquiries from rural transportation professionals. Through it, ENTERPRISE provided a much-needed link between the ITS community and rural transportation professionals.

Inform also promoted the simple solutions and ITS through the network of Local Technical Assistance Program (LTAP) / Technology Transfer (T2) centers. The centers in some ENTERPRISE states were used to provide feedback on the scope and the “look and feel” of the web site, and to disseminate the simple solutions to their constituents. In total, there were thousands of individual project descriptions and full Simple Solution reports distributed in the United States and Canada, and the Inform project was a major success story.

Inform Next Step

Now that rural communities had access to ITS solutions that they can implement, the logical next step was to make widespread rural ITS a reality. To facilitate that, the Inform Next Step project helped rural transportation professionals identify a wider range of potential applications, plan ITS strategies and utilize the national ITS architecture and the applicable standards by enhancing the Inform website. Strong, usable tools provided all rural planners with the ability to create cohesive plans that build strength by integrating different ITS elements and existing infrastructure. By ensuring architecture compliance, ENTERPRISE and the FHWA promoted system compatibility among various rural jurisdictions that might not have the time or money to work together to achieve it on their own.

Project Duration: 1997-2001

The Herald Field Operational Test (FOT) tested AM radio as a low-cost way to broadcast traveler information in rural areas. It tested the feasibility of broadcasting data on the inaudible portion of an existing AM broadcast. Two systems were tested, the Herald system developed during the FOT, and a system from Mikros Systems Corporation. Both systems proved it is technically feasibly to broadcast data over AM without degrading the audio programming. And both systems proved to be strong candidates for low-cost rural traveler information dissemination.

Project Duration: 1995-1997

This ENTERPRISE project developed a guidance document on the deployment and operation of low-visibility warning systems. Research and evaluation was conducted on the effectiveness of the visibility detection hardware and methods of providing advanced warning of low visibility events to motorists. A workshop was held that convened transportation professional that have first hand knowledge of the operation on low visibility warning systems. The results and input gathered at the workshop as well as the research and evaluations of deployed systems, contributed to the development of the visibility warning systems guidance document.

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.