Demand‑Responsive Bus Service: Architecture, Business Model, and Scheduling Engine

Product Background – Demand‑responsive bus (DRB) is a non‑fixed‑route, real‑time ride‑pooling service that adjusts vehicle capacity and routes according to user travel demand. DiDi’s DRB leverages flexible fleet dispatch and dynamic route planning to provide economical, direct, seated, and efficient public‑transport service.

Business Model – Traditional bus operates on static routes. DRB introduces three layers: (1) static area‑station layer (designing large, medium, and virtual stations), (2) line layer (defining connectivity between stations), and (3) integrated service layer (handling passenger‑vehicle matching, dispatch, and service execution). Different scenarios (commuting, hub evacuation, tourism, community, industrial park, university town) can adopt distinct bus product modes. The platform reduces development cost and cycle for B‑side partners by providing a unified technical capability.

Product Service Architecture – The system consists of passenger app, driver app, management backend, and a matching engine. User requests are placed into an order pool, periodically sent to the engine, which selects appropriate algorithms to match orders with vehicles and generate pickup‑dropoff sequences. Results are cached in the backend and pushed to the apps for real‑time updates.

Scheduling Modes – Two modes are defined: static scheduling , which plans fleet allocation based on time‑slot demand, road conditions, driver work‑time, vehicle mileage, etc., and dynamic scheduling , which continuously generates pooled routes and assigns the most suitable vehicle in real time, considering rules, vehicle status, and location.

Line‑Station Model Evolution – DRB extends the traditional line‑station model to a network‑style graph with station‑to‑station reachability constraints, enabling flexible route expressions for hub‑evacuation, micro‑circulation, and mixed‑mode operations. The model supports various constraints such as ordered stations, mandatory stops, dynamic boarding point adjustment, and custom path planning based on operator experience.

Core System Architecture – The platform integrates high‑frequency traffic big‑data, clustering algorithms for optimal service area, and a VRP‑type matching engine. The combinatorial nature of M vehicles and N orders leads to exponential solution spaces; therefore, heuristic, tabu‑search, and domain‑specific initialization are employed to obtain near‑optimal solutions while balancing pooling rate and passenger experience.

Open Platform – DiDi offers an open API/SDK for partners to embed DRB capabilities into their own systems, supporting both direct operation within the DiDi app and independent integration. The platform encourages collaboration with public‑transport operators, community managers, and technology partners.

Recruitment Notice – The Innovation Bus team is hiring front‑end, back‑end, and algorithm engineers. Interested candidates can apply via [email protected].