5. Deployment Experience Assessment
This section focuses on the deployment experience of the NT-T/SP test, including operational experiences and lessons learned during development and deployment. The information in this section is mostly based on interviews conducted with representatives of PATH. The purpose of the interviews was to identify obstacles and difficulties that the project partners encountered as well as best practices and successes while implementing this application.
5.1 FINDINGS
The NT-T/SP test was somewhat unusual in that it effectively provided a consumer service, rather than a management or operations tool. While the PATH2Go tools comprised a 'beta' system, i.e. a pre-mass market application, with free participation for registered users, they nonetheless had to be managed in a rapidly changing product environment that demands high standards for customer service. It is not unreasonable to assume, therefore, that users would have their own expectations for mobile services and electronic consumer products based on similar commercially available products and services.
5.1.1 Background
Since its inception in 1986, PATH has been a leader in ITS research. Its research activities are focused on three program areas - Transportation Safety, Traffic Operations, and Modal Applications. PATH's Modal Applications Program conducts research on new concepts, methods, and technologies for innovating, enhancing and improving transit solutions. Related research areas include modal integration of transportation systems, bus rapid transit technologies, and innovative transit operations. PATH has also been active in research and demonstrations of smart parking initiatives that provide real time information to drivers regarding location and availability of transit parking.
For the SafeTrip-21 initiative, PATH leveraged its research capabilities and resources with its longstanding working relationships with transit agencies in the Bay Area. This was a key to developing the PATH2Go tools in such a way that they provided comprehensive, integrated, and real time transit travel information through the US-101 corridor.
5.1.2 PATH goals
PATH had two original goals for the Transit component of the test, namely to determine whether the PATH2Go tools could provide valuable information to transit riders, and to determine whether buses could serve as useful traffic data probes. For the Smart Parking component of the test, a specific goal was to determine whether real-time information related to auto and transit service within the test bed commuting corridor could induce a modal shift to transit, and provide congestion relief to the highway (US 101).
After the test was re-scoped towards the end of 2009 (due to distracted driving concerns related to use of smart phones while driving) expectations of any measurable modal shift occurring as a result of the test were minimal. In effect, the test became more focused on transit riders rather than auto drivers. Also, the goal of using buses as traffic probes was de-emphasized, in part because of the high level of effort required to develop the PATH2Go tools, especially the geo-fenced mobile application, and in part because PATH needed to ensure their relationship with transit agencies remained focused on providing real time transit status data. Additionally, the information provided bus probes was originally intended for providing comparative trip times, but with the test's shift away from mode-shift alerts, they were no longer as necessary. Consequently, the single goal of the test was effectively to determine whether the PATH2Go tools can provide valuable information to transit riders.
5.1.3 Implementation challenges and how they were overcome
The overriding implementation challenges were related to re-scoping of the NT-T/SP test to minimize the likelihood of PATH2Go users being distracted while driving. To achieve this, PATH made some innovative modifications to the mobile application regarding when it could be safely used:
- Prevent use of the mobile application if the user was in a moving vehicle, while allowing use of the mobile application if the user was on a moving bus or train;
- Allow use of the mobile application if the user was walking, or waiting at a bus stop or rail station;
- In situations where use of the mobile application was prevented from being used, display a simple message that explained that use of the system had been intentionally blocked; and
- Ensure this approach worked consistently across all three smart phone platforms - Android, iPhone, and Windows Mobile.
These modifications to the mobile application became known as geo-fencing. PATH had to provide sufficiently compelling assurance to USDOT that a driver could not use the mobile application in a car. This assurance was a pre-requisite to publicly launching the test. Unlike traditional geo-fencing (using a device's location to trigger an action), the geo-fencing modifications developed for the NT-T/SP test had to effectively determine the mode of travel on which a device was being used to trigger an action. There was no off-the-shelf product or proven technique that could be used by PATH to help meet USDOT's requirements. Consequently, PATH developed and implemented an approach to geo-fencing from scratch. This activity occurred during February and March 2010. USDOT confirmed the PATH's approach was acceptable by the end of April 2010.
While this geo-fencing activity was a pre-requisite for the test to proceed to launch, it both added to the overall complexity of the design of the mobile application, and somewhat detracted from the end product.
Other minor deployment issues related to instrumentation of parking lots with appropriate sensors to accurately count entering/exiting vehicles and to enable robust, real time estimates of utilization. This activity was shared by PATH and Parking Carma, one of the test partners.
5.1.4 Methodologies for determining user needs
No formal process was followed with regard to determining user needs. In part the test was motivated by a desire to incentivize modal shift by increasing awareness of the transit travel options in the US-101 corridor, and the original NT-T/SP concept offered the potential to address this issue. Following the re-scoping of the test to minimize distracted driver concerns, the importance of determining user needs was somewhat diminished as the focus of the test moved away from drivers to transit riders. By this time, the schedule to conduct the test no longer provided sufficient time to conduct a comprehensive user requirements analysis.
Consequently, the development of the PATH2Go tools was mostly influenced by the need to establish a database of transit services, including real time status from multiple transit agencies, address the development requirements of three different smart phone platforms, including geo-fencing, integrate the three PATH2Go tools, and ensure the highest possible quality for the user interface and overall user experience. These issues were addressed through regular coordination between team members responsible for these respective areas. User interface and application design issues were identified and addressed by members of the project team during these coordination efforts.
5.1.5 Institutional challenges
The development, deployment, and operation of the NT-T/SP test required extensive cooperation from SAMTRANS/Caltrain and VTA. This activity was critical to the test, as PATH needed to install various forms of tracking devices on trains and buses. Previous working relationships facilitated this process, although supporting the NT-T/SP test was, understandably not the highest priority for the transit agencies given the many demands on their limited staff resources. The PATH project team was therefore very respectful of the requirements of the transit agencies, and the availability of their key staff. For example, when PATH installed the tracking devices on Caltrain's locomotives, this was done at weekends over several weeks to avoid any possible disruption to rail services.
5.1.6 Approaches for managing anonymity and privacy
PATH worked closely with UC Berkeley's Committee for the Protection of Human Subjects (CPHS) to protect the privacy of the registered users. PATH was required to submit an application to CPHS stating what personal information would be collected and who this information would be protected.
Based on the user survey conducted with the registered users, there were no particular concerns about privacy, even though they could be potentially tracked whenever they used the mobile application.