Overview#
This section is a brief documentation to how shared mobility is modeled in the Polaris project.
Shared mobility refers to ride-hail (or TNC, for short) and future SAV/SAEVs. In Polaris, shared mobility is modeled from both an operator and a vehicle perspective. At a higher level, the TNC operator centrally assigns new ride requests to individual vehicles depending on the assignment strategy (e.g., zone-based, coordinate-based) and monitors the demand-to-supply ratio within traffic analysis zones (TAZs) or neighborhoods to determine if repositioning the fleet is required. The TNC vehicle executes pick-up, drop-off, and repositioning tasks depending on the instruction received from the operator. The TNC vehicle executes charging decisions and monitors occupancy for DRS trips, as determined by modeling parameters to prevent stranded and/or overbooked vehicles.
We tell POLARIS that we are using TNCs (SAVs) in the global scenario.json file (or _saev for SAEVs, if you choose to rename your scenario filename). There are two critical TNC-related scenario parameters. The first is a boolean indicating that we are using TNCs and the second points to the FleetModel.json file (or similar filename) that defines the key attributes and characteristics of the TNC Operator(s) (e.g., base fleet, seat capacity, matching algorithm, repositioning, DRS, geofence, stop aggregation, and EV characteristics). The Scenario Prototype file sets these global parameters while the fleet model file declares the data members of the TNC Operator.
Strategy Branches#
The TNC operator may require different repositioning, passenger-vehicle assignment, and charging strategies, depending on the region, time of day, demand patterns, and/or fleet vehicle composition. Modelers must specify the strategy in the fleet model to simulate. Each strategy is defined in the code and is built off of the “default” strategy. The list of strategies that can be declared in the fleet model file are listed below.
There are several strategies that are defined in TNC_Operator_Methods.h (see block below):
dll: assignment-based strategy
DRS_Iterative_Assignment: passenger-vehicle assignment strategy (requires KDTree)
joint_evcr: optimization-based idle vehicle dispatch strategy for repositioning & charging (requires GLPK or CPLEX)
parking: parking strategy for idle vehicles
c2c: passenger-vehicle and routing assignment strategy (requires CPLEX)
day_ahead_charging: optimization-based idle vehicle dispatch strategy for repositioning, charging, discharging & maintenance (requires CPLEX)
default: default strategy
riley: assignment strategy in collaboration with Georgia Institute of Technology for ODMTS
stable_matching: stable-matching strategy that takes into account vehicle and rider preferences
dynamic_fare: fare-related strategy to dynamically set fares by time of day or zone-based surges, for different service types
AlonsoMora: DRS matching strategy by Alonso-Mora et al.
Default Strategy#
The default strategy uses a zone-based passenger-vehicle assignment strategy. In the function do_assignment the request information is passed to another function that finds the closest available vehicle to the new passenger request. In the case of dynamic ride-sharing (DRS), the closest available vehicle may also be a non-empty vehicle that has passenger(s) en route to their destination. Additional checks are done to ensure that vehicle seating capacity are respected and detour delays do not exceed service limits. A battery range check is conducted for all-electric vehicles too.
The default strategy uses a baseline repositioning strategy that is applicable for non-electric vehicles. The strategy is decentralized, such that the TNC vehicles performing repositioning are based on their current location, and demand (# of requests), and supply (# of vehicles) aggregated at the TAZ level. This strategy uses the GLPK solver.
The default strategy can charge electric vehicles using heuristic policies ONLY.
Assignment Check: If a vehicle is currently charging and is allowed to leave a charging station early (EV_SERVE_IF_CHARGING_FLAG = true), then there is a check to ensure that the state of charge (SOC) is at least greater than or equal to a defined threshold (say, EV_SERVE_IF_CHARGING_SoC = 60.0).
Low Battery Check: If a vehicle’s SOC is less than a minimum value (say, MIN_EV_SoC = 20.0) the vehicle will go charge.
Idle Check: If the operator wants idle vehicles to charge (EV_CHARGE_IF_IDLE_FLAG = true), this code checks if the vehicle’s SOC is less than a minimum threshold for idle charging (say, EV_CHARGE_ON_IDLE_MIN = 40.0).
The default strategy can use an electric vehicle charging station (EVCS) generation heuristic (GENERATE_EVCS = true). Additional details on this is located in a file .
The default strategy may also send vehicle to maintenance (“service” in the code) depots for daily maintenance or cleaning ONLY trips.
The default strategy does NOT do parking.
The default strategy will initialize vehicle locations. If there is no tnc feedback (for consistency between scenarios or for multi-day convergence in fleet operations), the initial vehicle locations are randomly assigned based on the land area of the TAZ. Smaller TAZs have a higher probability, since downtown areas are likely to have smaller TAZs and more TNC trips. In the default strategy with tnc feedback the initial vehicle location from the historical result file is used.
Georgia-Techn ODMTS Strategy#
Optimization-based strategy for pooling in on-demand multimodal transit systems (represented by a fleet of shared vehicles here).
Important
Lu, J., Riley, C., Gurumurthy, K.M. and Van Hentenryck, P., 2023. Revitalizing Public Transit in Low Ridership Areas: An Exploration of On-Demand Multimodal Transit Systems. arXiv preprint arXiv:2308.01298.
Stable Matching Strategy#
A stable and fair matching algorithm (SFMA) can pair riders and drivers in an EV ride-sourcing market in a large-scale network simulation. SFMA is a decentralized algorithm that allows for a relatively fair consideration on both riders’ and drivers’ preferences (e.g. waiting time, travel cost, charging conditions) and no pairs of riders and drivers in the matching set wants to change their matching. Three ride-sourcing scenarios, including comparisons among leveraging conventional, electric, and automated electric vehicles, are evaluated by implementing SFMA into POLARIS. The performance of the SFMA on system level metrics with varying emerging technologies is demonstrated through the vehicle-rider matching rate, the waiting time, VMT and empty VMT, and obtained revenues.
This strategy can take into account both driver and rider preferences and allows to set weights for driver rating and electric vehicle preference. It is an assignment strategy only.
Important
Shen, H., Huang, Y., Gurumurthy, K.M., Auld, J.A. Stable and fair matching: Ride-sourcing service with electric vehicles. Presented at the 37th International Electric Vehicle Symposium & Exhibition, April 23-26, 2024, COEX, Seoul, Korea.
Dynamic Fare Strategy#
Simple strategy to allow different operators to set their own fares based on operations across times of day or zones
The following paper uses the strategy and documents some more details and could be useful.
Important
Sambasivam, B., Gurumurthy, K.M., Kockelman, K.M. Simulating Price-Based SAV Fleet Competition Between Multiple Operators. Presented at the 103rd Annual Meeting of the Transportation Research Board in Washington, DC.
Alonso-Mora et al. DRS Matching Strategy#
Includes the DRS matching strategy published by Alonso-Mora et al. for maximizing pooling. Strategy only provides assignment code. The repositioning aspect is not yet included.
Important
Alonso-Mora, J., Samaranayake, S., Wallar, A., Frazzoli, E. and Rus, D., 2017. On-demand high-capacity ride-sharing via dynamic trip-vehicle assignment. Proceedings of the National Academy of Sciences, 114(3), pp.462-467.