|
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.
|
