Inside Haro’s Two‑Wheeler Scheduling: From Real‑World Challenges to a Simulation Platform

Overview of Two‑Wheeler Scheduling

Scheduling allocates scarce resources to tasks over time to optimize one or more objectives. In the two‑wheeler (shared bike) scenario, future rider demand is forecasted, vehicles are allocated to stations, and tasks are assigned to operations staff, aiming to satisfy rider demand, minimize relocation cost, increase vehicle turnover, improve operations efficiency, and enhance user experience.

Comparison with Food‑Delivery and Ride‑Hailing Scheduling

All three domains involve task generation, dispatch, and fulfillment. Two‑wheeler scheduling has higher complexity in task generation due to three factors (algorithm trigger timing, offline conditions such as weather, competition, and regulatory interference). Dispatch complexity is lower because fewer entities are matched and real‑time requirements are relaxed. Fulfillment complexity is higher because driver execution is hard to monitor, unlike the rating systems in food‑delivery and ride‑hailing.

Key Technical Challenges

Inaccurate positioning; different vehicle models have varying GPS precision.

Vehicle dispersion; drivers must collect scattered bikes.

Demand volatility; seasonal and peak‑hour fluctuations.

Supply‑demand imbalance; vehicle fleet cannot keep up with growing demand.

City‑specific differences; development stage and policy affect deployment.

Algorithm black‑box; makes performance evaluation ambiguous.

Information silos; real‑time vehicle status changes are not promptly reflected upstream.

Computational complexity; diverse scenarios dramatically increase algorithmic cost.

Algorithm Goals: “Multi‑Fast‑Good‑Cheap”

The solution targets four dimensions: Multi – high coverage of scenarios and personalization; Fast – real‑time generation, dispatch, execution, and feedback; Good – satisfaction for business and drivers; Cheap – reduction of both labor and compute costs.

Solution Architecture

The layered architecture addresses each goal. For “Multi”, a station‑group scheduling strategy provides city‑specific policies. For “Fast”, demand forecasting, real‑time task dispatch, and optimal route planning are implemented. For “Good”, global matching, task aggregation, revenue estimation, and lean management improve outcomes. For “Cheap”, elastic computing, an MR scheduling framework, and volatility alerts increase resource utilization.

Effect‑Evaluation Challenges

Five obstacles hinder algorithm impact measurement: (1) Low efficiency – each iteration takes about two weeks to evaluate; (2) Lack of control – offline operations execution cannot be fully monitored; (3) High interference – numerous external factors reduce measurement accuracy; (4) Poor quality – post‑deployment experiments show low positive lift; (5) Weak credibility – partners distrust the model due to poor online performance.

Simulation System Introduction

To overcome evaluation challenges, a simulation system replicates the physical world, enabling offline verification and predictive analysis. The workflow models physical scene attributes and behaviors as digital features and models, then transforms them into a simulated environment through engineering pipelines.

Feature Data

Physical‑world information is organized into five dimensions: Station data (basic info, order flow, real‑time vehicle count, historical demand, travel times); Vehicle data (basic info, real‑time tags, battery level, health, rider revenue); Capacity data (driver profile, vehicle profile, real‑time status, scheduling, cost); External data (holidays, weather, competitor activity, map data, regulatory interventions); and Evaluation metrics (stock‑out events, orders, dispatch volume, turnover, revenue).

Simulation Model

The model simulates two aspects: natural vehicle flow (how bikes move between stations) and model inputs (real‑time supply‑demand forecasts and capacity simulations) that feed the scheduling algorithm.

Vehicle Natural Flow Simulation Steps

Compute outbound vehicle count for a station at a given time using station, vehicle, and external features; filter by comparable historical dates and exclude abnormal vehicles.

Calculate inter‑station transfer probabilities using station flow orders, travel times, and external factors; employ a roulette‑wheel selection to capture stochastic events.

Combine outbound counts with transfer probabilities to generate a simulated flow matrix for the target timestamp.

Realism Metric

Realism quantifies how closely simulation matches reality. Data from a specific city and date are aggregated into station‑level and time‑level rankings for both real and simulated outflows. A POS‑style similarity algorithm compares the orderings, yielding 93% similarity for hourly rankings and 85% for station rankings, indicating high fidelity.

Engineering Support

Implementation relies on three pillars: Data computation (massive, heterogeneous IoT data from millions of bikes across thousands of cities); Dispatch middle platform (experiment creation, configuration storage, asynchronous data feeding, real‑time feedback, result persistence); and Front‑end visualization (experiment management, parameter setting, map‑based playback, and reporting).

Benefits and Outlook

The simulation platform delivers six major gains: (1) Nationwide city coverage; (2) Hour‑level evaluation speed versus weekly; (3) Expected two‑fold increase in positive online recovery rate; (4) Multi‑dimensional, customizable metrics; (5) Controllable interference factors; (6) Full process replay and analysis. Future stages aim for scenario‑driven modeling, intelligent perception with autonomous feature learning, and broader business enablement.