Connected Vehicle Pilot Deployment Program Driving Towards Deployment: Lessons Learned from the Design/Build/Test Phase
In September of 2015, USDOT selected New York City Department of Transportation (NYCDOT), Wyoming Department of Transportation (WYDOT) and Tampa Hillsborough Expressway Authority (THEA) as the recipients of a combined $42 million in federal funding to implement a suite of connected vehicle applications and technologies tailored to meet their region’s unique transportation needs under the Connected Vehicle Pilot Deployment Program.
Following the award, each site spent 12 months preparing a comprehensive deployment concept to ensure rapid and efficient connected vehicle capability roll-out. The sites next completed a 24-month phase to design, build, and test these deployments of integrated wireless in-vehicle, mobile device, and roadside technologies. As of early 2019, the sites are entering a third phase of the deployment where the tested connected vehicle systems will become operational for a minimum 18-month period and will be monitored on a set of key performance measures.
Given the promising future of connected vehicle deployments and the growing early deployer community, experiences and insights across all stages of the Design/Build/Test Phase of the CV Pilots have been collected to serve as lessons learned and recommendations for future early deployer projects and efforts.
The following lessons are reflections of the challenges uncovered by the sites during system acceptance testing of the technology and what future deployers should be conscious of.
Arrange a testing location that can accommodate the necessary test runs
- Testing should occur in a closed-environment that is sufficiently large.
- NYCDOT made available a test location within the Aqueduct Racetrack parking lot to demonstrate their CV applications.
- Through partnerships, WYDOT was able to perform testing on tracks owned by the Office of Emergency Management.
- THEA was able to close parts of the Selmon Expressway for the testing and demonstration of their CV technology.
Assess GPS accuracy of OBUs in dense urban environments to determine whether a correction is needed
- New York City is known for its "urban canyons" which provide a challenging environment for GPS technology that is often limited to open sky. As a result, additional techniques were required in the OBUs positioning algorithms to provide the accuracy needed for many of the V2V and V2I safety applications to function properly. Such augmentation of vehicle positioning was needed to provide continuous access to GPS positioning data so that the safety applications could continue operating while the connected vehicles passed under bridges, elevated roadways, through tunnels etc. while navigating the typical Manhattan streetscapes and traffic environment. The NYC Pilot vendors introduced a combination of supporting techniques to improve location accuracy, including:
- Dead reckoning
- CAN bus integration for speed information
- Inertial Measurement Unit (IMU) integration
- RSU time-of-flight feature.
Assess GPS in mobile devices to see whether it is precise enough for pedestrian safety applications
- An initial demonstration of New York’s Personal Information Device (PID) and its associated Mobile Accessible Pedestrian Signal System application in Manhattan experienced issues with the continuity of the PIDs’ GPS signal as the result of frequent loss of satellite signal. To address for the devices’ inaccurate GPS readings, NYC resorted to installing traditional ITS pedestrian detection equipment that utilized infrared cameras.
Similarly, during testing of Tampa’s Pedestrian Crossing (PED-X) smartphone application, the mobile devices were unable to determine the pedestrian’s location and speed with sufficient accuracy,.e.g. being unable to distinguish stepping into the street from standing on the sidewalk, leading to numerous false alarms. To correct this, THEA modified the vehicular side of the PED-X application to collect pedestrian location data from LIDAR sensors installed near the crosswalk that could provide more precise geo locations.
If using Dedicated Short-Range Communications (DSRC), consider purchasing interference tracking equipment to detect potential interference from other users in the 5.9 GHz band that can compromise data exchange
- Though the FCC originally allocated the 5.9 GHz band for DSRC-based ITS applications, in 2013 the FCC proposed allowing unlicensed devices to share the spectrum with primary users as long as they were not found to be interfering with the primary DSRC users. During the deployment period, THEA detected and tracked down an interference on their DSRC communication channels coming from a local amateur radio operator.
While the ham radio could not receive DSRC radio messages due to the far lesser range of DSRC, THEA’s DSRC radio would receive the ham radio messages, causing the DSRC radio to consider the channel "busy" and not "clear to send". The additional signal on THEA’s channels impacted the performance of their equipment in terms of data exchange and back haul speed, with testing indicating a degradation in data uploads by up to 50%. Upon review of these findings, Florida Department of Transportation (acting as the enforcement agency) ordered the amateur radio operator to vacate the channel.
Due to the scale of the NYC deployment, the NYC team invested in the purchase of sophisticated interference checking and RF spectrum analysis equipment. This equipment will allow them to locate and quantify field interference with GNSS and DSRC and to confirm the failures of the OBU and RSUs in the event of a suspected failure.
Tune the applications for the proper density and speed of the environment that you are deploying in
- In the absence of standard performance requirements for applications, it became evident that each CV Pilot vendor had their own interpretation and tuning of applications deployed. For NYC, it was key that the applications be tuned for urban density and speeds to balance proper alerts versus false alarms. This required:
- Consistent expectations for the drivers about the sensitivity of the applications across all vendors
- Performance tradeoffs
- Staging open sky testing (for baseline) and urban canyon testing.