OpenHail: An Event-Driven Gymnasium Environment for Electric Ride-Hailing Fleet Control

1 Introduction

• Electric fleet control couples service and charging decisions: serving requests consumes energy and delays charging, while charging reduces vehicles available for current demand.Source: §1 · p. 1
• OpenHail provides fixed-size Gymnasium observations and joint actions for request assignment, repositioning, and charging.The interface includes action validation and utilities for constructing feasible-action masks.Source: §1 · p. 2
• Its decision-epoch mechanism separates internal simulator events from policy interactions, supporting event-driven, periodic, hybrid, and policy-requested control.These interaction modes use the same operational model.Source: §1 · p. 2
• The environment adds battery dynamics and finite-capacity charging facilities with explicit travel and charging states and first-in–first-out queues.Source: §1 · p. 2
• OpenHail supplies seeded configurations, baseline policies, evaluation utilities, and automated tests for operational invariants and computational scaling under three control workloads.Source: §1 · p. 2

2 Background and Related Software

• The reviewed software spans transportation-system testbeds, fleet-service simulators, and controller-facing environments organized around repeated observation–action interfaces.Source: §2.1 · p. 2
• AMoDeus and MaaSSim model transportation or platform interactions, while RidePy, FleetPy, and EV-Sim focus more directly on fleet operations.RidePy is modular and event-based; FleetPy combines assignment, repositioning, routing, and charging; EV-Sim represents asynchronous electric ride-hailing operations.Source: §2.1 · p. 2
• pyhailing lacks battery and charging representation and has request-dependent observation and action dimensions; RideGym emphasizes pooling and dispatching without electric-fleet decisions.Source: §2.1 · p. 3
• FleetPy is the closest comparison in electric operations and Gymnasium support, but its wrapper exposes zonal dispatching rather than joint assignment, repositioning, and charging.Table 1 compares service scope, policy interfaces, control decisions, and electric operations; listed control decisions may cover only part of a wider simulator.Source: §2.1 · p. 3

3 The OpenHail Architecture

• The architecture has six components: OpenhailInstance, RequestManager, VehicleManager, StateObserver, SummaryManager, and OpenhailEnv, which coordinates the others.Source: §3 · p. 3

3.2 Library Implementation and Interface

• The observation dimensions N, M, and D—the vehicle count, maximum exposed pending requests, and reposition-location count—remain fixed during an episode.The Gymnasium reset and step methods return observations and interval rewards, and the environment ends at the configured planning horizon.Source: §3.1 · p. 4, §3.2 · p. 5

3.1 Core Components and Event Dynamics

• The seeded request manager maintains a fixed-size buffer, while vehicles track battery and job states across service, repositioning, charger travel, waiting, and charging.Charging posts are assigned to queued vehicles first-in–first-out; travel times, energy use, and charging duration follow configured rates, without network congestion or route choice.Source: §3.1 · p. 4
• Operational events update the simulated state, while decision epochs return an observation and request a policy action.Request arrivals, service and charging completions can trigger decisions; repositioning completions remain internal, and periodic clocks, maximum intervals, or policy-requested times can also set epochs.Source: §3.1 · p. 5
• Each step applies service, repositioning, and charging instructions, allocates charging posts, advances internal events to the next exposed epoch, then returns an updated observation.Source: §3.1 · p. 5

3.2 Library Implementation and Interface

• The action tuple combines per-request vehicle assignments, per-vehicle repositioning or charging instructions, and an optional absolute future decision time.Service assignments must meet pickup and energy constraints, and repositioning must be reachable with the available battery.Source: §3.2 · p. 5
• Feasible-action masks help policies filter assignment and repositioning choices, while strict validation raises an exception for detected violations.The scalar reward represents net operating value between decisions, with service revenue and travel, repositioning, and charging costs reported through reward components and information fields.Source: §3.2 · p. 6
• The configuration runner supports experiments across policies, infrastructure alternatives, and random seeds, including comparisons of decision schedules and charging capacity.Source: §3.2 · p. 6

4.2.1 One-Day Policy Evaluation

• Runtime is measured per episode and decision epoch as fleet size and reposition-location count increase, with request volume proportional to fleet size.The one-day evaluation covers 16 configurations and five paired instances per configuration; controllers share environment seeds within each configuration.Source: §4 · p. 6, §4.2.1 · pp. 6–7

4.1 Software Verification

• Unit and integration tests cover seeded demand, Gymnasium observations and actions, time bounds, energy and reward accounting, and charging queues.Tests also cover complete baseline episodes, rendering without state mutation, and PPO checkpoint loading and saving.Source: §4.1 · p. 6

4.3 Post-hoc Simulation Performance

• PPO requires 1.62–2.18 times nearest's episode duration; at 2,000 vehicles, its median time per epoch is 0.864–1.057 milliseconds.Figure 2 reports episode duration, while Figure 3 reports time per exposed decision epoch.Source: Figure 2 · p. 7, Figure 3 · p. 8, §4.3 · p. 8

4.2.2 PPO Training

• Training each 500-episode PPO agent takes 0.54–21.03 hours per configuration; larger fleets take longer at each location count, while location-count effects are non-monotone.Training time includes periodic evaluation.Source: §4.2.2 · p. 7, Table 4 · p. 8

4.3 Post-hoc Simulation Performance

• Across tested configurations, median controller computation time is lower than median environment-update time for all three policies.For the largest configuration, PPO's median agent time is 27.36 seconds versus 15.67 seconds for random feasible, while environment time is 50.85 versus 49.78 seconds; Table 5 medians use five paired rollouts and wall time includes measurement-loop overhead.Source: Table 5 · p. 9, §4.3 · p. 9

• OpenHail provides a common Gymnasium interface for request assignment, repositioning, and charging, supporting policies that account for passenger service, vehicle availability, and charging queues.Source: §5 · p. 9
• In the largest tested configuration, median wall-clock runtime per simulated day ranges from 37.53 to 78.22 seconds across three controllers on one allocated CPU.Source: §5 · p. 9
• OpenHail supports configurable decision frequency and timing, including selection of which operational events trigger policy decisions.The paper identifies comparisons among event-responsive, periodic, and policy-requested decisions as a direction for further research.Source: §5 · p. 9