2002-2009

Over the past few years, many transportation agencies have been extensively using RWIS for snow and ice control. These agencies were then facing issues of how best to utilize and integrate their RWIS equipment and the different equipment of their own and other agencies. This equipment could be placed in the same region or be across jurisdictional boundaries.

Because of the proprietary nature of some RWIS information and the inability of different systems to easily exchange information, many agencies found it difficult to exchange information and receive full value from their RWIS investment. An example is in Arizona where there is more than one type of RWIS sensor in the field. This requires each sensor to have its own CPU that functions independently of any others. The ideal was to have all sensors reporting to a single CPU where information can be integrated and processed. The INCH project may address this issue for new equipment, but this project examined how states are integrating existing equipment.

The RWIS Guidance and Reference Document examined best practices and success stories of provinces and states in North America. It looked at innovative approaches to collecting and providing road and weather condition information for diverse users. It focused on how agencies have successfully integrated various weather information sources, both within their jurisdictions and outside. It also discussed how agencies get RWIS information to their maintenance crews, other response agencies and the general public.

This project referenced success stories in a way that helped agencies be able to utilize RWIS equipment and data for multiple purposes.

Project Activities

The goal of RWIS Guidance and Reference Document was accomplished through three tasks. These tasks include literature and Internet review, in-depth interviews and surveys with RWIS developers. It developed the guidance document and distribute it over the Internet and at conferences.

Task 1. Literature and Internet Review
The consultant looked through available RWIS literatures and existing Internet web sites to identify current best practices for integration, data collection, presentation and dissemination. Best practices were defined by complexity, ease of understanding, and agencies’ ability to incorporate information from multiple types of equipment. The purpose was to find solutions for a range of agencies with varying expertise and needs from RWIS.

The review also looked at best practices in disseminating RWIS information to users. It did not focus on display technologies, but in how states have developed simple, automated systems for disseminating RWIS data. It also examined the state of the practice for integration of RWIS with equipment such as dynamic message signs, highway advisory radio, speed warning systems and condition reporting systems (e.g., FORETELL, CARS). Traditionally, it has been difficult to get data to some dissemination systems because each RWIS type is collected and processed by different workstations.

Another aspect of the document review was to identify practices in agencies that share information across jurisdictional boundaries. It also examined how agencies may provide information to the National weather Service. Many agencies struggled with how to easily share essential information and the document will detail how it was done successfully in some areas.

Task 2. In-depth Interviews and Surveys with RWIS Developers
The consultant conducted in-depth interviews and surveys with RWIS developers in states with best practices in order to know about their system and functionality. The surveys focused on identifying the challenges and issues that arose during the development of their RWIS systems.

In particular, this effort examined jurisdictional and proprietary information issues. It examined how some agencies successfully overcame the difficulties in integrating data form different systems.

The surveys and interviews also examined the costs of developing means for exchanging and disseminating information.

Task 3. Develop the Guidance Document
Based on the above review and findings, the consultant developed a reference guide. The RWIS guidance document was targeted at agencies that were developing or expanding their RWIS capabilities. The final document was disseminated in electronic form to the public through the ENTERPRISE web site. It was also made available at conferences and to ENTERPRISE members who would like to share it with other interested agencies.

Deliverables

• A document summarizing the findings about current best practices of RWIS.
• A document summarizing interviews and surveys findings.
• The final report in electronic and paper form

Effective traffic management for unplanned incidents requires tools and resources that can be deployed rapidly to respond to unpredictable conditions and circumstances. For work zones, closures or restrictions, special events, and other planned activities, agencies will typically develop a strategic traffic control or management plan. A key tool in helping to execute the plan would likely be fixed or portable VMS with vital instructions or information about immediate hazards and conditions.

Incident conditions that require rapid deployment of portable or truck mounted VMS often require very specialized, incident-specific information that might not be found in pre-planned message sets. Furthermore, the nature of rapidly deployed VMS is that they are highly mobile, and would need to be changed to reflect conditions as conditions change. Truck mounted, mobile VMS often need to be programmed on-site, meaning drivers/response crews need to have the expertise and/or resources on-hand to program a message appropriate to the situation, severity, and location. The size of a truck-mounted sign is typically only 2 lines, whereas freeway VMS are 3 lines.

The unique nature and uses of truck mounted or other portable VMS, particularly for rapid deployment in response to an incident or emergency, warrants additional study and review of current agency practices and technologies with regard to rapid VMS deployment, MUTCD guidelines for these signs (including use of standardized icons), and the potential for developing message set standards.

Project Summary

There were at the time two response teams that operate within Maricopa County specifically for traffic control/traffic management support during incidents. AZTech’s Regional Emergency Action Coordinating Team (REACT) provided emergency closure, detour and other traffic management support for incidents on arterials in several cities in the County, and ADOT’s ALERT (Arizona Local Emergency Response Team) provides emergency closure and traffic management support for Phoenix metro area freeways. Both of these response groups relied heavily on ITS technologies that could be rapidly deployed, specifically portable and mobile VMS.

Rapidly deploying a technology such as portable VMS for incident conditions required unique applications, approaches and considerations. This project established parameters for an operational definition of ‘rapid deployment of VMS for incident management’ and identify available ‘best practices’ from Maricopa County agencies and other areas that are using rapidly deployed VMS for incident and emergency conditions. Included in this survey were how or when standardized message sets were used for rapid VMS deployment. Available VMS technologies that would typically be used for rapid deployment were reviewed, and specific challenges, limitations, constraints, etc. were identified that could impact development of recommended standards or best practices. The project also looked at how MUTCD provides guidance or standards for this unique and specialized use of portable/mobile VMS. The result was a summary of best practices, special considerations, and recommended practices, technologies and operational uses for rapidly deployed VMS for incident management.

Project Activities

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

Task 1: Survey of Literature and Current Practices
A literature search and review of current practices relative to other regions to identify current uses of portable/mobile VMS for incident management was conducted. Any existing practices identified were documented. As part of the survey, agencies were contacted to see if they have current operational practices that involve rapid deployment of VMS signs for incident management that perhaps are not documented in any literature. Potential agencies to contact were identified by MCDOT/AZTech, REACT and ADOT’s ALERT in consultation with ENTERPRISE participants. This survey addressed such items as operational uses or practices, technologies used, message sets, and lessons learned. The results of the literature search and survey were then documented.

Task 2: Assess Portable/Mobile VMS Technology
Available VMS technology that could be used for rapid deployment will be identified and assessed. The purpose of this assessment was to document features and functions of available portable/mobile VMS technology, identify operational requirements (particularly that could affect or hinder rapid deployment), capabilities of the technology (brightness, matrix size), communications requirements, and ability to integrate portable/mobile technologies with incident management practices as well as broader ITS programs. Programming and software requirements were also identified (i.e., programmed on site, ability to use stored message sets, etc.). The results were documented, and included recommended (but not brand specific) technology requirements and features for portable/mobile VMS that are conducive to rapid deployment for incidents.

Task 3: Review of MUTCD Guidance/Criteria
A review of appropriate MUTCD chapters and sections was conducted to see if there was sufficient criteria to address message sets, sign sequence, viewing distance, length and time guidelines, standardized icons, and other aspects, particularly as they relate to the application of portable/mobile VMS for incident management. A new chapter of the MUTCD was developed to specifically address VMS boards, and a draft was obtained (if possible) for review. Applicable MUTCD guidance appropriate for rapidly deployed portable/mobile VMS boards was documented and cited. A potential outcome of this task could have included additional requirements that would need to be addressed as part of a revision to the MUTCD.

Task 4: Final Report
Tasks 1, 2 and 3 were summarized in a final report, to include current status and use of portable/mobile VMS for incident management by agencies, applicable message sets, technology and operational requirements, and ‘best practices’ for operations and ease of integration of this unique technology application into existing practices and programs. Case studies of agencies successfully using this technology were highlighted.

Deliverables

The following products were delivered from this project:

• A summary and report that documents status, technology, and best practices for rapidly deploying VMS for incidents.
• Potential input for a revision to the MUTCD chapter addressing VMS boards for unique requirements of this specific technology application.

The Phase 1 – PCS Total Monitoring Station Demonstration Project, during the winter of 2005 and 2006 at three locations along Highway 21 near Kincardine Ontario, successfully demonstrated; the use of 1xRTT commercial data radio communications, the use of solar power and illustrated a definite co-relation between quantifiable visibility readings from the road side sensors and driving conditions.

The conclusions of the project are that the technology worked well and that the TMS’s are a useful tool for research into the co-relation between visibility, traffic conditions and human observations of road conditions.  However, it was also concluded that the system was not ready for operational deployment due to a user interface which was not designed to provide a user friendly operator interface with integrated video.  As well, in order to continue the research aspects an additional sensor, specifically an anemometer to measure wind speed was required.  It was recommended that an algorithm be developed in order to calculate a “visibility index” using data from a variety of sensors.

It was recommended that the system be upgraded to meet the operational requirements; replace “loaned” equipment and incorporate the recommended additional sensors in order to continue research during the winter of 2007 and 2008.  As well as providing a base for additional visibility research; this will allow the Ontario Ministry of Transportation (MTO) and the Ontario Provincial Police (OPP) to investigate whether the TMS would be a valuable component to a modern motorist advisor and road closure system.

Project Activities

The following activities will be conducted by the Consultant:

Project Management
This activity includes: Liaison with MTO SWR, MTO ITS Office and Transport Canada, Prepare progress reports for ENTERPRISE, Co-ordination with suppliers, Management of Delcan staff, QA/QC according to ISO requirements, Scheduling and financial management

System Design
System design includes two main components. The first is to update the design of the system in terms of hardware and software configuration, relative to the demonstration project.  The other component is to define the users / operators requirements in terms of screen layout and functionality.   This will involve review by; and discussions with MTO SWR Operations centre as well as the OPP.

Procurement
The final equipment required to meet the new requirements will be selected.  This will be procured by Delcan and integrated with the existing ATC’s.  This setup and hardware integration will be conducted by Delcan in its equipment lab.
Additional equipment required includes equipment which was previously on loan and has been returned; and new equipment required to meet the new functionality.  Specifically the equipment required is:

• low light dome cameras
• video encoders to convert the analog camera output to digital IP
• anemometers at each location to measure wind speed
• a digital power meter at one of the locations to measure the actual power used in order to accurately size the batteries and solar cells in the future
• additional serial input / outputs to connect the additional sensors
• real time operating system for the controllers (QNX)
• a new wireless modem to replace the one which was previously damaged.

Software Development
The existing software in the field controller and in the server needs to be updated to: provide a new graphical user interface, interface with the new sensors and the development of the algorithm which will determine the “visibility index”.  The activities include:

• Software design for the new components
• Software development and testing of the updated ATC software
• Development of a new browser based graphical user interface to incorporate the requirements of an operational system (refer to Operational Requirements  below) and provide a link from MTO’s RWIS Server’s web page
• Software updates for the central server and development of the algorithm to co-relate wind speed and visibility to generate the “visibility” index. A link to the RWIS Server will also allow weather and pavement conditions from appropriate RWIS to be considered.  The algorithm will consider the rate of change of the data as well as the current measured values.  The parameters of the visibility index can be adjusted through the GUI to improve performance over time.  To develop the algorithm data collected during the demonstration project will be utilized.
• Software integration and testing
• Provide support to the implementation team during system integration and testing.

Field Work Supervision
This activity includes providing instructions to the electrical contractor and assistance to SWR’s maintenance and operations forces.  It also includes inspection during the field installation and documentation of the installation.

Integration and Testing
Integration and testing involves testing the entire system in Delcan’s lab, integration with the components in the field and testing in the field.  It is composed of the following steps

• Factory acceptance testing which will test all of the functions and the hardware in Delcan’s lab
• Integration of the three stations and central computer once the field equipment is installed
• Site acceptance testing which ensures that the hardware and software operates correctly in the field.

Data Collection and Evaluation
Once Integration and Testing are completed data can be collected and the algorithm tested and adjusted under winter conditions.  This activity consists of the following tasks:

Develop evaluation criteria in consultation with MTO and OPP

Review the output of the algorithm, the visibility index, and compare it with the recorded images and field observations

Meet with users to obtain observations and inputs

Adjust parameters to refine the output of the algorithm to reduce false alarms and missed events

Prepare a report to document the results of the project

Schedule and Deliverables

The following products will be delivered from this project:

September to November 2007	Consultation MTO ITS Office, SWR /Region  Develop Proposal and Cost Estimate
January 7, 2008	Approval to Proceed & Initiate Procurement
February 18, 2008	Procurement & Field Software Development Complete
March 3, 2008	Field Installation & Commissioning Complete
March 10, 2008	Operational Test Period & Initial Data Collection Complete
March 17, 2008	Acceptance  & On Line Operations
April 13, 2008	2007/08 Winter Data Collection Complete
April 21, 2008	Progress Report Complete
December 23, 2008	Final Data Collection Complete
February 17, 2009	Final Evaluation Report Complete

The Autonomous Monitoring Station (AMS) concept is based on the use of a general-purpose controller to support multiple ITS field components. The primary goal of this project was to demonstrate the feasibility of using low-cost wireless communications and solar power to deploy autonomous road monitoring stations in remote sites.

Three sites were equipped and monitored along Highway 21 in southwestern Ontario during winter 2005-06. Visibility sensors and vehicle detectors collected visibility levels and traffic conditions (volume and speed) and summarized data every fifteen minutes. When visibility deteriorated below a predefined threshold, video images were collected and transmitted to the central database server for comparison to field observations.

The system developed and tested proved to be reliable and cost effective to support road operators in rural areas. Further AMS system research and development was recommended, including providing more automated alerts in poor visibility conditions and improving the user interface for operational use.

Phase 2 – Autonomous Monitoring Station

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.