General Questions

• When did the DMA Program begin and when will it end? The DMA Program started in September 2009 and will end in late 2016 or early 2017 when all currently funded projects have been completed.

• What are the objectives of the program?
  The objectives of the DMA Program are to

• Create applications using frequently collected and rapidly disseminated multi-source data from connected travelers, vehicles (automobiles, transit, freight) and infrastructure
• Develop and assess applications showing potential to improve nature, accuracy, precision and/or speed of dynamic decision
• Demonstrate promising applications predicted to significantly improve capability of transportation system
• Determine required infrastructure for transformative applications implementation, along with associated costs and benefits

• How many projects are in the DMA Program?

The DMA program contains six bundle application prototype development projects: Enable Advanced Traveler Information Systems (EnableATIS), Freight Advanced Traveler Information Systems (FRATIS), Integrated Dynamic Transit Operations (IDTO), Intelligent Network Flow Optimization (INFLO), Multimodal Intelligent Traffic Signal System (MMITSS) and Response, Emergency Staging and Communications, Uniform Management, and Evacuation (R.E.S.C.U.M.E.). Each project has its own impact assessment team to evaluate the benefits of the bundle applications. The Open Source Application Development Portal (OSADP) project was created to develop, operate and maintain an open source portal that will enable stakeholders to collaborate on application development. The DMA-ATDM AMS Testbed project was created to develop multiple virtual AMS Testbeds to evaluate system-wide impacts of DMA applications and ATDM strategies, both individually and in logical combinations.

• What are the major accomplishments of the DMA Program to date?
  To date, the DMA Program has accomplished the following milestones:
  • Identified and prioritized candidate mobility applications for development
  • Produced a fully-elaborated collection of foundational research (Concept of Operations, Systems Requirements, etc.) for each selected bundle of applications
  • Enabled development of functional prototypes and demonstrations to further advance the program proof of concept
  • Sponsored additional program efforts including the AMS Testbed and the Open Source Application Development Portal (OSADP)
  • Fostered innovation and collaboration between the U.S. DOT, state and local agencies, vehicle and equipment manufacturers, academia, research organizations, and interested parties

• What are the primary products of the DMA program?
  The open source codes and the data from the six DMA bundle application projects are available for public downloading and use, as well as documentation of DMA application prototype design and evaluation results.

• How did the DMA Program decide on what applications to develop?
  The DMA Team conducted a series of stakeholder engagement activities, including webinars and workshops, in order to identify the applications to be developed within the DMA Program.

• Will I have access to the bundle prototype source code?
  Yes, most DMA bundle prototype source code and supporting documentation have been uploaded to the Open Source Application Development Portal (OSADP) website at http://www.itsforge.net/. You can also find the expected source code upload schedule on the website.

• Will I have access to the field test/demonstration data?
  Yes, data from the field tests/demonstration will be uploaded to the ITS Public Data Hub (IPDH) website: https://www.its.dot.gov/data/.

• When can I expect to see the bundle evaluation results?
  Preliminary evaluation results were presented for each bundle during the 2015 DMA Webinar Series. Complete evaluation results are expected to be released by late summer 2015.

• When can I expect to see the AMS Testbed results?
  The AMS Testbed team posted preliminary results on the DMA website on March 20, 2015. Comprehensive results and final reports are expected to be released to the public by the end of 2015.

• How may I learn about the concept and design of the DMA bundles?
  Each bundle prototype development has gone through concept development, prototype design, and field test/demonstration stages. All major project efforts are documented and made public. To find a complete list of DMA publications, please go to: http://www.its.dot.gov/pilots/pilots_mobility.htm.

Bundle/Project Questions

DMA-ATDM AMS Testbed

• How is the AMS Testbed different from the Connected Vehicle Testbeds?

Connected Vehicle Test Beds are real-world, operational test beds. AMS Testbeds are a set of computer-based models that attempt to represent reality. AMS Testbeds model an actual metropolitan region or corridor’s transportation system in a virtual environment.

• Why do we need an AMS Testbed? What are the advantages?

An AMS Testbed affords the capability to conduct robust testing and experimentation before field deployment.  It allows for an examination of impacts at various levels of market penetration of new technology (e.g., connected vehicles), and under varied demand patterns that may not exist in field tests (e.g., weather, incidents, work zones).  An AMS Testbed allows for the identification of optimal strategies for field deployment, reduces the agency risk and increases agency confidence, and reduces the likelihood of failed/ineffective field deployment.

• How is the AMS Testbed effort different from the bundle-specific impacts assessment efforts conducted under the DMA Program?

The DMA bundle-specific impacts assessment efforts examined if prototypes of individual bundles had an impact when small-scale demonstrations were conducted.  The impacts assessment efforts also examined the potential benefits of individual bundles when deployed at a larger scale (i.e., higher market adoption of connected vehicle technology) on the same network where the bundle was prototyped.  In contrast, the AMS Testbed effort affords the capability to examine the system-wide impacts of combinations of synergistic DMA bundles and ATDM strategies, and identify conflicts and synergies for maximum benefit.  The AMS Testbed will also examine the impacts of DMA bundles and ATDM strategies when prediction and active management (two key tenets of ATDM) are coupled with connected vehicle technology.

• What simulation tools are being used in the AMS Testbeds? Are the tools universal across the different locations? 

There is no constraint on the use of a single simulation tool across the AMS Testbeds.  The Testbeds are using a range of tools (e.g., activity-based travel demand models, dynamic traffic assignment, microsimulation models, and communication models) depending on the strategies being modeled at the site and the availability of existing models for the site.  For example, the Dallas AMS Testbed is using DIRECT (Dynamic Intermodal Routing Environment for Control and Telematics), which is a simulation-based dynamic traffic assignment model for urban intermodal transportation networks, as a DIRECT model has already been developed for the Dallas site as part of the ICM Program.  The Chicago AMS Testbed is using DYNASMART (Dynamic Network Assignment-Simulation Model for Advanced Road Telematics), which is another a simulation-based dynamic traffic assignment model. A DYNASMART model that has been tailored to model weather phenomena in Chicago already exists. 

• How will the AMS Testbed effort model the DMA Cooperative Adaptive Cruise Control (CACC) application? The application has not yet been developed by the DMA Program.

The AMS Testbed effort plans to use the CACC algorithms currently being developed by researchers at the Saxton Transportation Operations Laboratory under the sponsorship of the FHWA R&D.  Another option that is being explored is the use of the CACC algorithm developed by California PATH.

• Does the project scope include remote rural corridors?

While emphasis has been placed on urban areas with recurring congestion, the Phoenix Testbed area includes rural corridors within the Greater Phoenix region.

• Will some of the DMA applications and ATDM strategies conflict and potentially mitigate benefits?

The AMS Testbed effort will evaluate concurrent deployment of DMA and ATDM strategies in areas including Pasadena, Phoenix, and Chicago.  The AMS Testbed effort will specifically examine if such conflicts occur between applications and under what conditions.

• How can I get involved in the AMS Testbed effort?

Engagement and outreach is a vital consideration for this effort.  The ITS JPO encourages operators, modelers, and potential stakeholders to contact program personnel with their interest.

FRATIS

• Was the Dallas-Fort Worth FRATIS project coordinated with the Dallas Integrated Corridor Management (ICM) Project?

A cooperative effort was considered, however the Dallas ICM project did not occur on a designated freight corridor.

• Is the Bluetooth technology used in the pilot similar to the technology used for freeway travel time estimation?

Yes. The FRATIS pilot utilized MAC ID matching to measure wait times at terminals.

• Is decreased delay factored into emission changes?

This relationship will be examined by the impacts assessment team. Additionally, project data are posted to the Research Data Exchange (RDE) for further analysis.

• To what extent have information technology standards been considered in the prototype development, especially standards for information exchange and the governance of the intermodal environment?

The project team attempted to adhere to existing standards wherever possible. This prototype utilized Bluetooth, IEEE, and SAE standards.

• How was queue length data obtained via Bluetooth equipment for this prototype?

Queue length collection varied slightly depending on the location of each deployment. In Dallas, Bluetooth and WiFi readers recorded locations through MAC addresses. In Los Angeles, the deployment featured an additional validation step. Camera systems also measured queue lengths in most cases.

• What efforts will be undertaken to ensure a lasting commitment from the drayage industry?

This project effort featured strong partnerships with drayage partners as well as public agencies. Emphasizing the benefits of future FRATIS deployments will be a critical aspect of future deployments. 

• Are any smaller facilities or ports going to be used for future studies?

There are no plans to conduct further demonstrations under this project effort. However, stakeholders have expressed interest in extending LA FRATIS. Interested parties are encouraged to consider a FRATIS-oriented proposal for the CV Pilot Deployment effort.

IDTO

• Who is envisioned as the host of an IDTO DMA application?

We anticipate cooperative arrangements between councils of governments, metropolitan planning organizations, regional commissions, departments of transportation, and other organizations.

• How was communication and application security implemented in the prototype?

The IDTO application transmits information from the user’s smartphone using a secure HTTP connection and will utilize secure cloud storage.

• Have there been any observations regarding transit vehicle driver reactions?

The demonstration did not identify any problems, and project personnel have received positive feedback regarding the T-CONNECT application.

• What type of training did the drivers receive?

The drivers received training for operation of mobile data terminals. Dispatchers also received instruction concerning the facilitation of user transfer requests.

• What was the accuracy of the Automated Vehicle Location (AVL) information? Was it accurate enough and what was the time tolerance you experienced?

User volume was not high enough to offer a definitive conclusion, but coordination of schedules did function properly. AVL accuracy was sufficient to determine the need for connection protection, but could benefit from further refinement. The deployed bundle will optimally feature location updates within 30 to 60 seconds.

• How does the IDTO bundle address requester authentication and security?

Users are required to create an account and sign in so they may use the service. Personally identifiable information is protected using security authentication services.

• Did the T-DISP demonstration allow drivers to pick up passengers who were not at the bus stop? If so, how far and what criteria was used to pick up these passengers?

T-DISP has two major components: the ability to integrate the schedules from multiple providers to a single application so that the users can plan their trips; and the ability to also allow the users to identify their current locations and specify their destination. The two major components have not yet been merged into one application. Therefore the current model is station-to-station, with possible future enhancement.

• What is the methodology used to assess the efficacy of the program?

Application effectiveness is measured by travel time, ease of use of the applications, and how the trips of other passengers are affected. Operators additionally will evaluate deployments based on costs versus benefits.

• Was DSRC utilized in the two IDTO demonstration projects in Columbus and Florida? 

These demonstrations did not utilize DSRC technology.

• How did T-CONNECT’s decisions integrate with the agency's own real-time transit arrival information? What's the maximum holding time?

Integration between these systems functioned as designed. Hold times will vary based on agency policy and real-time transit arrival information. The Columbus demonstration featured a one minute hold, which would be nullified if the hold resulted in the bus falling five minutes or more behind schedule.

• Are there any plans to demonstrate the combination of the IDTO T-CONNECT application with the MMITSS applications?

Not currently, but USDOT will consider future opportunities for inter-bundle interfacing.

• Did any of the demonstrations occur during inclement weather?

The demonstrations did not experience any weather that was severe enough to interrupt planned operations.

INFLO

• Did the INFLO prototype include CACC?

No, only Dynamic Speed Harmonization (SPD-HARM) and Queue Warning (Q-WARN) were prototyped and demonstrated. It was determined that CACC required additional research.

• Was any consideration given for integrating signalized arterials?

The INFLO prototype effort was limited only to freeways, although the vision for the INFLO bundle also includes deployment on arterials and rural roads.

• Were the speeds shown on the overhead signs advisory or were they enforceable as well?

The INFLO SPD-HARM recommends only target advisory speeds and are not enforceable.  Speeds recommended by WSDOT’s Variable Speed Limit (VSL) system that are displayed on the overhead signs are regulatory messages and are enforceable.  During the demonstration the SPD-HARM speeds were disseminated to the drivers of the connected vehicles on their in-vehicle systems on sections of the roadway where VSL were not displayed on overhead signs.  The demonstration did not alter the speeds shown on the overhead signs, which continued to show the speeds recommended by WSDOT’s VSL system.  Drivers were advised to comply with the speeds shown on the overhead signs.

• Is the SPD-HARM application designed on a per-lane level? If yes, is there any concern on potential induced lane change and safety?

The SPD-HARM prototype was designed and developed for a segment, rather than a per-lane level, due to lack of fidelity in lane-specific positioning data. 

• What data were collected from the prototype effort?

The project team utilized multiple sources of data to drive the algorithms. Sources included WSDOT sensor data as well as BSM data from vehicles. 

• What communication mechanisms are used in the INFLO prototype to transmit both BSMs from connected vehicles and SPD-HARM and Q-WARN messages to the connected vehicles?

The INFLO Prototype uses both DSRC and cellular communications.  BSMs are transmitted via DSRC from connected vehicles to other connected vehicles and Roadside Units (RSU) that are in the vicinity.  The RSU sends the captured BSMs to a Traffic Management Entity (TME) via cellular communications.  When an RSU is not in range, BSMs are sent via cellular communications directly to the TME.  SPD-HARM and Q-WARN messages are sent from the TME to the connected vehicles’ in-vehicle systems through the RSU via DSRC or directly via cellular communications when an RSU is not in range.  Communications between the TME and the RSU occur via cellular communications. A virtual TME was used for the demonstration.

• What was the headway between instrumented vehicles during the test?

Headways differed depending on the test day. The demonstration featured headways of 15 minutes, five minutes, and one minute.

• How far apart were the DSRC roadside units placed?

Three DSRC units were installed approximately half a mile apart. Cellular communications were used when vehicles were outside of DSRC range.

• Will the algorithms and data be available for researchers?

Yes, the algorithms, including code and documentation, will be available via the Open Source Application Development Portal (OSADP).  The data will also be available via the Research Data Exchange (RDE).

• Did the INFLO impacts assessment effort consider weather effects? Was the simulation modeling conducted only for the California site?

The simulation study in the INFLO impacts assessment effort was limited to the California site. Weather was simulated by adjusting the drivers’ desired speeds and car following parameters to match observed freeway performance during rain events.

• Were the target speeds recommended by WSDOT’s VSL system comparable to those recommended by INFLO SPD-HARM?

On average, speeds recommended by INFLO SPD-HARM were lower than those displayed on WSDOT’s VSL signs.  However, this may be attributed to sampling bias.

MMITSS

• Shouldn't travel time reliability be included as a performance measure?

The MMITSS team estimated travel time variance (a measure of reliability) during the deployment effort.

• Do you have a bibliography of papers that describe your control algorithms?

The Transportation Research Part C: Emerging Technologies journal has published a paper that details the referenced algorithms. The authors of this paper are Yiheng Feng, Mehdi Zamanipour, Shayan Khoshmagham, and Larry Head.

• Can you clarify which method was used to conduct communication with intersection equipment and users/vehicles?

The MMITSS field test utilized Wi-Fi communication. Roadside equipment vendor Savari has developed SmartCross, which utilizes LTE-Cloud communication. Future testing of this capability is anticipated in the near future.

• Will signal timing be optimized off-line for the base case, or will existing timing be used for the evaluation?

The project team utilize both the existing signal timing and the optimized timing for the evaluation.

• What software was used for the model analysis?

The study uses VISSIM with MMITSS APIs developed by the prototype development team.

• Did the test results utilize existing or optimized timing is the basis for comparison?

The Anthem results compared both existing and optimized (but not actuated) timing. The California test utilized existing conditions as provided. MMITSS uses a priority-based coordination that will be used for comparison to traditional coordination.

• What signal timing algorithm was used for the base model?

All signal timing was conducted using the Econolite ASC/3 SIL algorithm interfaced with VISSIM.

• Is the California test segment part of the San Mateo SMART corridor, which has implemented a traffic light synchronization project?

No, the SMART corridor is located north of the intersections utilized for MMITSS.

• Are there any planned tests or evaluation plans for saturated conditions?

Future simulations will include a traffic demand component. Additionally, California PATH is a significantly congested corridor.

• What security measures exist to prevent MMITSS from being compromised?

The MMITSS effort attempted to adhere to existing system architecture relevant to security. For example, IEEE 1902.2 provides security and encryption mechanisms, and the intention is to expand the MMITSS concept with these standards in mind.

• What technology was used for the Freight Signal Priority (FSP) application?  Is it the same transponder as the Transit Signal Priority (TSP) application?

The onboard equipment (OBE) is the same for both applications, with the equipment configured for freight vehicles in this instance.

• Do plans exist to examine the interaction between MMITSS transit applications and other transit DMA applications?

Please refer to the AMS Testbed project for examinations of synergistic deployments of the Dynamic Mobility Applications.

OSADP/RDE

• Is there a data collection architecture that you can share for some of the examples cited?

Each data environment on the RDE has its own data format; there is no standard architecture for data environments. Each data environment contains a standard format metadata document that describes the data content and format.  Some data environments contain additional more detailed metadata documentation.

• Is there a way for others to share data directly with the RDE?

There is currently no method for users to upload data directly, but users may utilize the “Contact Us” feature of the RDE if they have data they would like to share.  The RDE support team will review the offered data for release.

• How do you track the different versions of the CV file formats? Is the metadata site specific and file version specific?

Yes, the RDE contains a version-tracking capability.

• Will the OSADP be updated with all of the other applications that the DOT has been working on through the connected vehicle program (i.e. safety pilot)? If so, when might this happen?

There are currently no plans to upload Safety Pilot information to the OSADP. However, we anticipate information from programs such as DMA and V2I to be uploaded. Most DMA application codes have been uploaded to the OSADP. The portal will notify registered users when new software and data becomes available.

• How do I download the sample data for TCA 2.3?

This information is available on the OSADP site with the TCA software. Any other problems you may have either running the software or finding files can be posted on the OSADP forums for that given application.

R.E.S.C.U.M.E.

• In the demonstration video, did the responding officer have a device on his/her person that provided warning of the approaching vehicle?

Yes, the responder carried a Motorola mobile radio typical of responder communication gear.

• Was CapWIN developed as an open source code so that it can be uploaded to the OSADP?

CapWIN was developed with Federal funds and is technically GOTS (government off-the-shelf) software. We will consider alternative means to share with any interested parties.

• How is the GPS accuracy improved in R.E.S.C.U.M.E. applications?

In order to provide the functionality of the INC-ZONE and RESP-STG applications, differential GPS was utilized in order to provide lane-level accuracy.

• Are the DSRC communications mentioned expected to be some of the same connected vehicle communications being piloted currently?

Yes.  However, in order for the INC-ZONE application to be immediately useful, it will be necessary to use a different technology given the current lack of market penetration of DSRC-enabled vehicles.

• Would this be used to warn drivers about fog or smoke blinding drivers?  Could it slow all drivers by lowering speed limits ahead of these conditions in order to prevent blind high speed crashes?

Not as it is currently designed.  However, the Road Weather Management program is working on applications to warn of smoke or fog or other atmospheric events, and issue appropriate warnings.

• For the simulation runs along U.S. 101, was the Trajectory Converter Analysis (TCA) 2.3 tool utilized? Also, is the VISSIM simulation input file available for others to review as an example for future simulation model development?

The TCA 2.3 tool was not utilized for this particular analysis since it works only with VISSIM 5.40. A new TCA which works with VISSIM 7 would need to be developed for this purpose. TCA 2.3 is available for V5.40 on OSADP currently and is also available for Paramics. The VISSIM input for the U.S. 101 simulation is available on the OSADP.