Completed

The history of the project dates back to 1993 when ENTERPRISE first partnered with the Federal Highway Administration (FHWA) to pilot the Mayday (emergency notification) project referred to as Colorado Mayday.

Since 1993, numerous Field Operational Tests (FOTs) have been conducted to test Mayday products or services. Also, there were private Telematics Service Providers (TSP) that offered commercial products that deliver Mayday services to travelers. The most widely known TSP at that time was OnStar, with several million subscribers nationwide.

The premise of this project, however, was not to assume that the challenge of locating stranded or injured motorists in need of urgent care has been completely solved by private sector communication media or TSPs such as OnStar. Instead, this research project was intended to seek opportunities for those who do not subscribe to the monthly services of TSPs, or who have vehicles where TSP products and services are not available.

This document presents a summary of findings of Phase 1 (survey of existing and emerging E-911 technologies). The report is based on an initial status provided to project members and the Enterprise group at the December 2006 meeting. This summary report includes additional research based on the feedback of project members and Enterprise group. The report was used as the basis of the Phase 2 workshop, as well as the final report (Phase 3).

The NTCIP standards development effort started in 1992, and it continues with new standards, amendments, and updated standards. The development of these standards provides a major step towards the goals of interoperability and interchangeability of ITS systems. The NTCIP documents are designed with many options in order to meet the varied needs of different projects. While this flexibility allows the standards to be referenced by many projects, each procurement specification must explicitly call out which options are required for the specific project. Additionally, the need to test for compliance to both NTCIP and non-NTCIP project requirements proves to be a continuous challenge.

In order to provide a reference implementation for NTCIP implementations, FHWA sponsored the development of the NTCIP Exerciser. The NTCIP Exerciser is a useful tool to test certain NTCIP implementations but it had some limitations:

• The NTCIP Exerciser did not support routable protocols (i.e., TCP/IP)
• The NTCIP Exerciser did not support Dynamic Objects;
• The NTCIP Exerciser software was not maintained, meaning that none of the clarifications and updates found in amendments and new NTCIP standards was considered; and
• The NTCIP Exerciser had an interface that requires a great deal of NTCIP expertise but is cumbersome to use and provides little assistance for novices.

Only very few NTCIP experts were available to provide this type of NTCIP-compliance testing, which resulted in:

• Dependency on very few NTCIP experts; and
• Delays in scheduling the services of these few NTCIP experts, which might have resulted in project-delivery delays.

Some agencies had therefore gone the route of performing cursory tests or to believing equipment supplier’s statements that they are NTCIP-compliant. This approach allows any interoperability problems to remain hidden until an existing system is extended (either with equipment from a different vendor or new models from the original vendors), which was one of the main reasons why rigorous ITS standards testing needed to be performed with delivery of the first system.

As such, initiatives were executed by organizations such as the ENTERPRISE Consortium to develop test procedures and perform project requirements/NTCIP standards testing. The ENTERPRISE Consortium developed and made available a number of procurement scripts and test procedures that can be used to purchase and test dynamic message signs (DMS) and environmental sensor stations (ESS, also known as RWIS).

However, the availability of these tools was not sufficient to address the above-mentioned issues due to the complex nature of the tools. Thus, this project was being proposed to simplify the user interface for these tools. Without this simplification, every project would have required extensive manual testing by an expert or risk non-interoperability. Naturally, this would result in numerous repetitions of efforts among agencies, even though this could be avoided. Additionally, a general approach by a group of state and local agencies as represented by both the ENTERPRISE Consortium and the I-95 Corridor Coalition also leveraged the combined buying power and ultimately led to reduction in purchasing costs.

Project Summary

This project was proposed as a public/private joint effort among the ENTERPRISE Consortium, the I-95 Corridor Coalition, FHWA, NEMA, and Trevilon.

This project also did not start from zero, since it leverages off previous ENTERPRISE and FHWA efforts. Additionally, the consultants’ experiences in working with both organizations (ENTERPRISE and I-95 Corridor Coalition) in developing relevant material, which was used as the starting point, expedited the process and the progress of this project. The existing ENTERPRISE tools had already been proven to work satisfactorily but it was important to enhance these tools to:

• Cover additional field devices; and
• Provide a ‘friendlier’ interface to the newcomer to NTCIP to utilize the NTCIP Exerciser.

The Team (Trevilon and PB Farradyne) is very well suited to provide the needed expertise having worked with the member agencies and the organizations for a number of years and being recognized as industry experts in terms of NTCIP standards and their implementation.

Project Activities

The following tasks were performed in this scope of work.

Task 1: Develop Paper Tools for CCTV Procurement

Several agencies identified their interest in deploying NTCIP-compliant CCTV equipment now that this standard was completed. However, these agencies were acutely aware of the challenges of being among the first to deploy a standard and requested expert assistance in order to minimize problems encountered in this effort. There were two subtasks to this effort as described below.

Task 1.1 Develop CCTV Procurement Specifications

Previous INCH projects had produced guides for developing procurement specifications for NTCIP-compliant dynamic message signs (DMS) and environmental sensor stations (ESS). This task extended this previous work by developing a similar guide for the procurement of closed-circuit television (CCTV) camera controllers. The task did not include any software development efforts to add this capability to the SpecWizard software.

Discussions at the August ENTERPRISE meeting in Burlington, VT, identified this as the highest priority item for the INCH III effort. It was expected that this work will be performed under the Federal Highway IQC support contract that had already started.

Task 1.2: Develop Test Procedures for CCTV

Previous INCH projects had produced written test procedures detailing the precise steps that need to be taken in order to test DMS and ESS devices for compliance with the NTCIP requirements. This task extended this previous work by developing similar test procedures for CCTV camera controllers.

This task was identified as the second highest INCH III priority at the Burlington, VT meeting and is similarly within the scope of the FHWA IQC project.

Task 2: Provide On-Site Testing Services

This task included all work and costs required to perform on-site testing of one device for NTCIP compliance. The test was conducted per the procedures of the current version of the relevant ENTERPRISE test procedures. It was expected that these tests will be required prior to the completion of the automated software tools to be developed in Task 3, although early versions of the software may be used to automate some tasks and test the development to date.

The project estimate was based on four distinct tests as follows:

(1) One test at an I-95 site of a DMS
(2) One test at an I-95 site of either an ESS or a CCTV controller
(3) One test at an ENTERPRISE site of a DMS
(4) One test at an ENTERPRISE site of either an ESS or a CCTV controller

Task 3: Develop User Friendly Test Software

In order to overcome the challenges related to testing NTCIP equipment, ENTERPRISE had expressed interest in funding the development of a series of front-end modules that will greatly simplify performing the ENTERPRISE test procedures for various devices.

This front-end user-interface was designed to guide the NTCIP novice through an interview process to determine the user’s needs and the device’s proclaimed capabilities and then used this information to test the project-specific requirements of the device and produce a project-specific summary report. This process allowed a user to quickly assess the conformance of a subject device while providing manufacturers with a detailed report summarizing the problems found.

The following subtasks identified the individual efforts required to develop the various components of this software while Annex A provided a more detailed discussion of the goals related to this software development effort as well as the proposed architecture and maintenance for the software.

Task 3.1: DMS Wizard

The DMS Wizard guides the user through the process of performing the ENTERPRISE Test Procedures for Dynamic Message Signs.

Task 3.1.1: Release Executable for DMS Wizard

The proposed lump-sum funding for this task covered 50% of the expected costs of the wizard to automate testing of DMS devices. It provided for the free distribution of this software; however, the source code remained the property of Trevilon Corp, who provided the other 50% of the funding.

As this was the first wizard developed, this task also included the development of the generic user interface that will bind all of the wizards together into a single software application.

Task 3.1.2: Testing the DMS Wizard

This task funded the independent testing of the software developed in Task 3.1.1.

Task 3.1.3: Three Months Maintenance for the DMS Wizard

Three months of software maintenance was be provided. These maintenance activities included correcting any bugs discovered through the independent testing as well as resolving bugs reported during this time frame.

Task 3.1.4: Release DMS Wizard Source Code

Due to the limited public funds available for this project, Trevilon Corp. offered to provide partial funding for the development in exchange for owning the rights to the software code. Alternatively, a public source may have funded this task and Task 3.1.3, in which case the rights were placed in the public domain.

By investing in the software and receiving ownership, Trevilon became financially involved and had an incentive to maintain the software over time in exchange for the rights to charge for future updates. In return, the public agencies avoided having to make any financial commitment for the long-term maintenance of the software, but were able to purchase updates when deemed appropriate.

Alternatively, a public agency may have funded the remaining development costs up front and thereby ensure that the software code is freely available, while also assuming the burden of developing a maintenance program in order to ensure that (1) any bugs can be resolved quickly and (2) the software is updated periodically to reflect revisions in the standards.

Task 3.2: ESS Wizard

The ESS Wizard guides the user through the process of performing the ENTERPRISE Test Procedures for Environmental Sensor Stations.

Task 3.2.1: Release Executable for ESS Wizard

The proposed lump-sum funding for this task covered 50% of the expected costs of the wizard to automate testing of ESS devices. It provided for the free distribution of this software; however, the source code will remain the property of Trevilon Corp, who will provide the other 50% of the funding.

Task 3.2.2: Testing the ESS Wizard

This task funded the independent testing of the software developed in Task 3.2.1.

Task 3.2.3: Three Months Maintenance for the DMS Wizard

Three months of software maintenance was provided. These maintenance activities included correcting any bugs discovered through the independent testing as well as resolving bugs reported during this time frame.

Task 3.2.4: Release ESS Wizard Source Code

Due to the limited public funds available for this project, Trevilon Corp. had offered to provide partial funding for the development in exchange for owning the rights to the software code. Alternatively, a public source may fund this task and Task 3.2.3, in which case the rights would have been placed in the public domain

Task 3.3: CCTV Wizard

The CCTV Wizard guides the user through the process of performing the ENTERPRISE Test Procedures for Closed Circuit Television Camera Controllers.

Task 3.3.1: Release Executable for ESS Wizard

The proposed lump-sum funding for this task covered 50% of the expected costs of the wizard to automate testing of CCTV devices. It provided for the free distribution of this software; however, the source code will remain the property of Trevilon Corp, who will provide the other 50% of the funding.

Task 3.3.2: Testing the ESS Wizard

This task funded the independent testing of the software developed in Task 3.3.1.

Task 3.3.3: Three Months Maintenance for the DMS Wizard

Three months of software maintenance was be provided. These maintenance activities included correcting any bugs discovered through the independent testing as well as resolving bugs reported during this time frame.

Task 3.3.4: Release ESS Wizard Source Code

Due to the limited public funds available for this project, Trevilon Corp. had offered to provide partial funding for the development in exchange for owning the rights to the software code. Alternatively, a public source may fund this task and Task 3.3.3, in which case the rights will be placed in the public domain.

Task 3.4: SNMP ++ Software

SNMP++ is existing freeware developed by Hewlett Packard and provides a software library to perform all of the standard SNMP operations. A book is available for purchase that documents the software design and provides a sample application. We used this software as the base of the product due to the fact that it is freely distributable and the interface is well defined. This selection allowed future projects to extend the work of this project to other devices, if deemed appropriate.

Task 3.5: WinSock

All 32-bit Microsoft Windows operating systems came with a WinSock interface. This was the software interface used by virtually all web browsers, e-mail applications, etc to communicate over the Internet. The SNMP++ software uses this interface as well, which ensures a robust design and presence on all target machines.

Task 3.6: T2/PMPP Subnet Connection

All 32-bit Windows operating systems were provided with drivers for Ethernet and dial-up networking interfaces that meet the NTCIP requirements. However, the T2/PMPP protocol stack combination was not supported by off-the-shelf software. However, NEMA had already expressed interest in funding the development of such software and this proposal assumed that this NEMA project would move forward. This additional software completed all regularly used communication profiles within the industry. If NEMA had not fund this effort, it could readily be funded by another source at some point in the future.

However, it should be noted that it is unclear at this time whether this software will support the relatively uncommon communications stack of T2 over PPP. This issue was investigated once NEMA had made its final funding decision.

Task 4: Hands-On Training for Wizards
While the software developed under this project was largely self-explanatory, public agency personnel are still be able to benefit from a hands-on training course designed to introduce the user to the overall testing process. Topics covered by this training course would include:
· Importance of testing;
· Understanding NTCIP requirements;
· Understanding the types of operations performed during the test procedures;
· Process to prepare the test environment, including hands-on exercises;
· Understanding how to configure a test and to save the settings;
· Process of running the test, including hands-on exercises;
· Understanding the output generated;
· Understanding related software packages that address features not covered by this software; and
· Understanding how to get technical support.

Task 4.1: Develop Course Materials

This task developed detailed training materials for a two-day hands-on training course on the use of the software. The training materials were be delivered under the project and be distributed under an ENTERPRISE name in the public domain.

Task 4.2: Deliver Course

This task consisted of the delivery of the two-day training course to a group up to 12 people at a member agency’s facility. The cost associated with this task includes the necessary computer rentals.

Task 4.2.1 Deliver Course at Site 1

One course was given for the I-95 Corridor Coalition.

Task 4.2.2 Deliver Course at Site 2

One course was given for the ENTERPRISE membership.

Many states and regions have web-based and/or telephone-based traveler information systems.  Some information is rapidly changing and is only of interest to travelers in that region, such as congestion and incident information.  Some information is more slowly changing and is of interest to distant travelers who will be passing through the area in the near time frame, such as lane or road closures due to construction or weather.

A truck driver heading northwest out of Chicago does not care about the current travel time on a road segment in the Minneapolis area, but the driver does care that I-90 across southern Minnesota is closed completely due to extreme snow conditions.  The truck driver needs to know that information before reaching Tomah, WI, where the choice is made whether to take I-90 or I-94.

Currently, in order to gain information about a cross-country trip, the traveler must access each state or region’s individual traveler information systems along the route and piece together the big picture.  This is made more difficult by the fact that no standard exists for naming web sites to ensure that the traveler can easily find each site reporting on the route.

There would be value in having a single nationwide traveler information system that provides information that is of interest to the cross-country travelers.  This system would not provide information that is only of regional interest, such as current congestion or incident information.  Each state or region would provide their information of nationwide significance to this single system in the standardized format of the nationwide system.  A traveler could access this single system and find out information affecting their entire cross-country trip from one system.  Another scenario would be that multiple private

States and regions may additionally provide information of regional interest on their own separate systems.  The nationwide system could provide a link to the state or region’s local system.  Each state or region’s separate systems do not have to be standardized across regions since one region’s information of regional interest is not of value in a different region.       

Because a nationwide ATIS crosses state lines, the USDOT would be a candidate for deploying and operating such a system.  However, the USDOT does not have authority to operate systems on state roads.  Therefore, ENTERPRISE, as a pool of multiple states, should consider the best means to bring a nationwide ATIS into existence.

The objective of this project would be to do preliminary analysis for a nationwide ATIS and recommend the best approach for implementing the system.

Project Activities

This project will be executed by 4 key tasks, as follows:

• Task 1: Define a concept of operations for a nationwide ATIS, including documenting who would use the system for what purpose and what the outcome would be.
• Task 2: Define information that should be considered to be of nationwide significance (as opposed to of regional interest only).
• Task 3: Analyze the feasibility of a nationwide ATIS, including benefit-cost, technical feasibility, and non-technical considerations.
• Task 4: Analyze possible approaches for implementing a nationwide ATIS and recommend one or more approaches to pursue.

Deliverables

The following products will be delivered from this project:

• Deliverable 1: Draft & Final Concept of Operations Working Paper
• Deliverable 2: Draft & Final Feasibility Analysis Working Paper
• Deliverable 3: Draft & Final Implementation Recommendations Working Paper
• Deliverable 4: Draft & Final Report incorporating working papers

Several states had implemented new techniques for maintaining motorist travel times through construction zones. The Arizona DOT had put into practice mechanisms such the “lane rental” program, which rewarded contractors for keeping lanes open and and charged them a fee for closing lanes for more then five minutes. Another mechanism used by the Arizona DOT, rewarded the contractor with a bonus if travel times through the construction zones are similar to those before construction began. Additionally an ENTERPRISE project entitled “Video Imaging for Travel Estimation”, sought to evaluate the accuracy of a license plate recognition system as a travel time measurement tool.

Project Activities

This project identified other practices used in the area of travel time estimation through construction zones, and provided information related to to the following:

• Type of construction;
• Geographical location;
• Methodologies and systems used for travel time estimation;
• Plans and reports; and
• Lessons learned.

A consultant was selected to research and evaluate varying methods of maintaining travel times through construction zones. The research was conducted initially through the Internet and telephone interviews to gather information on technologies and methods states have found successful in improving traffic flows. A follow on focus group convened individuals with first hand project experience. Discussions were facilitated by a brief review of the complied telephone and internet research based on examples from ENTERPRISE states and other agencies. Information compiled from the focus group served as the foundation for the lessons learned best practice document. Finally the document presented a detailed summary of recommended maintaining travel time mechanisms for states interested in deploying such tools.

On January 20, 2000, the Federal Communications Commission (FCC) authorized new, non-commercial Low Power FM (LPFM) broadcast stations throughout the FM band at powers of up to 100 watts. Using a 30 meter (100 foot) mast, high quality coverage is possible over a 7 to 12 mile diameter, according to terrain and the strength of competing FM stations.

Transportation agencies were given priority over education, church and community group applicants in that, for example, they could apply for many licenses within a state. However, all applications had to be made within a very narrow time window of June 11 to 15, 2001 . Once granted, the licenses are good for eight years.

The new LPFM service provided a unique opportunity to get rural roadway, weather and tourism ITS information into every car and truck at a reasonable cost. FM offers high quality reception and other benefits over traditional AM Highway Advisory Radio. LPFM is affordable, at about $12,000 per station for the broadcasting equipment. However, many LPFM sites -perhaps over a hundred – may ideally have been needed to cover a single state

Project Activities

ITS proponents may have felt that the LPFM concept was relatively ‘low tech’. Advanced Traveler Information Systems (ATIS) technologies using digital traffic messages had been proposed for over fifteen years, without reaching the marketplace. Instead of waiting for ATIS digital systems, LPFM required nothing more than the car radio already found in every vehicle, albeit served with content using the latest MP3 technologies.

While LPFM avoided the critical mass problem that has frustrated ATIS, LPFM can still take advantage of future ATIS sub-carrier systems. Sub-carrier data could be added to LPFM to carry digital traffic messages right into vehicles. And while sub-carrier data rates could be quite low, the cellular design of LPFM meant that local data could get priority. The same Internet connections to LPFM stations that carry MP3 also support digital traffic message services.

There were however, several challenges which need to be addressed before successful implementation and deployment could occur. The project took the following approach:

Task 1 – Develop recommended alternative for each site with opposing applications.

Although the FCC has given priority to transportation agencies over education, community and church groups, there were cases where agencies are competing for air space. Task one suggested and developed methods for creating a mixed use air space which would allow for traveler information messages to be spliced with either education, community or church group program content.

Task 2 – Begin negotiations for space sharing on cell and radio towers

LPFM service is capable of operating from a transmitter attached to a cell or radio tower. Institutional negotiations occurred to determine the cost of installation, rental fees and other issues which may arise in the future.

Task 3 – Preparing for equipment deployment

Task three identified the necessary equipment for a single, state or county wide LPFM operation. The equipment included the following:

• Fix signs with flashing beacon;
• Transmitter;
• PC’s;
• Software Integration (CARS, Foretell, MP3)
• Radio Data System Technologies

Task 4 – Develop LPFM content and quality control

Task four developed traveler information content to be disseminated to motorists such as road and weather conditions, timing of recorded sequences and sponsorship messages and the format that message sets were developed and disseminated.

Task 5 – Begin sponsorship negotiations

Private sponsorship was well established in public broadcasting. Since March 1984, FCC had allowed public broadcasters to carry sponsors’ information such as (1) slogans or ‘logograms’ which identify rather than promote, (2) location information, (3) value-neutral descriptions of product lines or services, and (4) brand names, trade names and product/service listings. In the context of LPFM, such business sponsorship can not only fund vital public safety information, it also helps travelers find out the facts on local services and visitor attractions.

Task five identified the role of sponsors and the format of the sponsorship messages. Furthermore negotiations with sponsors reviewed issues such as maintaining and updating message content.

Deliverables

A document recommending best practice approach for LPFM implementation and deployment.

Field studies in the Netherlands have shown that a new algorithm can accurately monitor and detect freeway traffic incidents. This project addressed the problems associated with, the tedious human task involved in freeway video surveillance as well as potentially inefficient incident detection algorithms that were in place in the United States.

With regard to the high success rate the algorithm has proven to show in the Netherlands, incorporating such a program into Enterprise member jurisdictions may be highly effective. In order to move forward however, statistics on traffic flow disruptions, video coverage capacity and the necessary detection equipment available needed to be determined.

Dutch DOT prepared a review sheet so that Enterprise members can conduct a survey of incident detection conditions in their jurisdiction.

Enterprise members needed to identify the feasibility of implementing such a program within their jurisdictions. Members then recognize the necessary local arrangements before conducting a field trial version at the cost of $50,000 and considered what arrangements ultimately imply and cost. After careful consideration, potential site selection was discussed at an Enterprise meeting.

Project Activities

The goal of the JAAP project was accomplished through three tasks. These tasks include, a survey of incident detection technologies in place, usefulness assessment document and deployment recommendations.

Task 1. Survey Development and Distribution
A survey that identifies the current incident detection technologies, processes and algorithms as well as the perception of effectiveness and existing infrastructure (e.g. detectors, video surveillance and traffic operations center), was developed and distributed to Enterprise members.

Task 2. Usefulness Assessment
A document that assessed which members are likely candidates, based on the existing technology and the amount of additional technology required to support such a system within the member’s jurisdiction.

Task 3. Deployment Recommendation
The last task entailed determining if a field operational test is feasible. If a candidate is found, arrangements with the member for deployment would be made in addition to a recommendation of whether or not a test should take place.

Deliverables

• A completed survey from participating Enterprise members.
• A usefulness report and potential members for deployment.