Future Mobility Support

In most cases, future scenarios can be represented by the core activity-based model component sensitivities. For example, changing land use scenarios, demographic shifts, and changes in the roadway and transit networks are all supported by the ABM components estimated from household surveys and calibrated to base year conditions. However, representing new vehicle technology and mobility services require an extension of the core activity-based model sensitivities. SERPM 8 includes several components and enhancements to support the testing of "Future Mobility" scenarios. The types of future mobility supported by these components are:

• Connected / self-driving / driver-less vehicle impacts on behavior and network performance;
• Mobility services provided by transportation network companies (TNCs); and
• Vehicle technology threshold for managed lane usage.

The selection of these future mobility features for inclusion in SERPM 8 was determined by a previous project working with SERPM 7. Reference files to that project are available here.

The new component to the activity-based model stack are highlighted in green in the following flow chart.

Connected / self-driving / driver-less vehicle impacts on behavior and network performance

A range of vehicle technologies are included in this area of future mobility. The model user will determine what level of vehicle technology is represented in the scenario and the implications on travel behavior and the network performance. Research into the impacts of this technology on travel behavior and network performance is ongoing and ultimately the true response is unknowable so definite parameter guidelines are not available. Whenever possible, it is recommended that a range of inputs be tested and the model results be considered not as predictions, but rather experiment results useful to gain insight into potential futures. The considerations the model user must make to inform the scenario configuration (and associated component in parentheses) are:

• How widely adopted is this vehicle technology by market segment (Vehicle Technology Component)
• Can vehicles be parked more efficiently and/or at an remote lot, thus leading to a decrease in parking fees (Mode Choice Component)
• Is the vehicle self-driving, and thus allows passengers to do other things with their time (Mode Choice Component)
• Is the vehicle self-driving, and thus allows solo passengers under age 16 (Mode Choice Component)
• Are the vehicles more efficient on the roadways and is the adoption rate high enough to warrant a change in roadway characteristics (Highway Assignment)

Vehicle Technology Component

This component simulates if the vehicles owned by the household are conventional or have some level of advanced technology. Vehicle technology is represented as a binary value, i.e. only one level of advanced vehicle technology is represented in the scenario. Moreover, the simulated vehicle technology is applied to all vehicles used by household members (i.e. vehicles are not simulated explicitly).

The model user will decide the vehicle technology implications and implement that in the other components. The vehicle technology component is specified by the UEC file referenced by autotech.uec.file in the serpm_abm.properties file.

Mode Choice Component

The tour and trip mode choice UEC files (defined by tourModeChoice.uec.file and tripModeChoice.uec.file in the serpm_abm.properties file) include three new parameters to support adjusting the following utility components of auto modes:

• In-vehicle time sensitivity (ivt_discount - the in-vehicle travel time of private auto modes is multiplied by 1 - the value);
• Parking costs (prk_discount - parking costs associated with private auto modes is multiplied by 1 - the value);
• Minimum driving age (sovAgeReduction - drive-alone modes are available to travelers at least as old as 16 - the value).

Highway Assignment

If the vehicle adoption rate is near universal, it may be interesting to test system response to different roadway network conditions. The highway assignment parameters are stored in the Inputs\Highway\Parameters folder of the model.

Mobility services provided by transportation network companies (TNCs)

The implementation of TNCs in SERPM was designed to address the following characteristics of these mobility services:

• Non-universal adoption of TNCs by all travelers;
• Availability of TNCs is different in dense, urban areas than suburban and rural areas;
• TNCs are a new mode in the traveler's alternative set with unique inputs and availability rules;
• Travelers may use TNCs flexibly across trips in their tour; and
• TNCs will produce indirect VMT relative to traveler demand.

Non-universal adoption of TNCs by travelers

Not all travelers have TNCs in their mode choice set. Use of TNC services requires a smart phone, credit account, and membership with a service provider. Moreover, travelers may not see the need to explore using TNCs (e.g. own a car / reliably travel with family) or are not comfortable traveling in a stranger's car. To represent this behavior, SERPM 8 has a household-level component that simulates TNC membership with sensitivities to household income, age, education, land use (density), and commuting distance. The TNC Membership component is specified by the UEC file referenced by tncmemb.uec.file in the serpm_abm.properties file.

Availability of TNCs is higher in dense, urban areas than suburban and rural areas

If a traveler is willing to use TNC services, rides are theoretically available anywhere in the SERPM region. However, TNC drivers concentrate in dense, urban areas where there are more potential travelers. Rides originating in suburban areas may be served, but could require a longer initial wait time due to the lower density of drivers. To capture the differences in initial wait times, a TNC wait time attribute tncWait is added to the MAZ input file. The value set by MAZ will be used as the initial waiting time in minutes for TNC travel from that zone.

There is no additional time (terminal time) at the destination end. Regardless of the land-use density, a TNC trip is assumed to end at the requested location and not require additional walking time.

Travelers may use TNCs flexibly across trips in their tour

Unlike traveling with a private auto, using a TNC for any trip on a tour does not preclude changing modes on subsequent trips. Therefore, TNC is available on all tours with a non-drive-alone mode, except for walk and bike tours.

TNCs will produce indirect VMT relative to traveler demand

SERPM 8 optionally (by scenario manager key control) will generate vehicle trips to represent TNC repositioning between passenger trips, i.e. between the drop-off of the last trip and the pick-up of the next trip. Repositioning trips should be sensitive to the distance between drop-offs and pick-ups to reflect the efficiency of the system. The implementation in SERPM 8 does not try to represent the actual deployment of TNC vehicles and assumes that all trips are chained. New drivers starting service and drivers going out of service are not considered, however the implied assumption is that these legs would go to destinations similar to TNC trip destinations. This is not an unreasonable assumption, but may limit the usefulness for detailed study areas.

The repositioning trips are calculated by the following algorithm:

By Time Period and ride-alone / share-ride:

1. Calculate Row and Column marginals for TNC vehicle trip tables
2. Find zones with unbalanced demand:
   1. Calculate the Max(Row – Column, 0) to get the origin need or attraction;
   2. Calculate the Max(Column – Row, 0) to get the destination excess or production
3. Use the difference vectors as a production and attraction table for repositioning trips
4. Distribute trips using a doubly-constrained gravity model, sensitive to zone distance

Repositioning trips are assigned to the highway network as part of the associated TNC user class.