Configure your scenario below. Settings are sent to the API as YAML on start.
Where the simulator talks to backend-web.
Base address of backend-web. Driver bots log in here, start trips, send GPS, and board passengers through this API.
10 = ten simulated seconds per real second.
Free driving routes via OSRM + OpenStreetMap. No API key.
Who drives the simulated buses.
One or more operators from backend-web. Drivers list updates when selection changes.
Drivers from selected companies — all checked by default. Label shows username · company.
username · company
0 = unlimited per simulated 24h. Example: 8 = each driver runs up to 8 trips per sim day, then waits for the next day.
0 = no cap for the whole simulation. Use a small number for quick smoke tests.
How and where new passengers appear.
Fraction of new passengers who flag down the bus without an app booking. 0.9 = 90% walk-on.
Fraction who reserve through the app. Bots respawn automatically while the run is active. Set 0 to disable auto-spawn (use Companies tab to add manually).
Average spawn rate in simulated time. 30 ≈ one new passenger every 2 simulated minutes.
Walk-on passengers without the app. 0.7 = 70% queue at an official stop, 30% wait at a random roadside point (orange dots on the map).
How the bus moves and reports location.
How often the driver sends GPS while a trip is active (simulated seconds). Lower = smoother map track.
GPS ping when on shift but between trips — keeps the unit shown as online in backend.
Typical speed between stops. Affects how fast the bus completes the route.
Shortest time the bus stays at a stop for boarding/alighting. Each stop picks a random wait between min and max.
Longest stop time. Example: min 15 + max 45 → each stop lasts 15–45 simulated seconds before the bus leaves.
What to verify. Full bus must log a rejection — never silent.
Mixed normal = everyday traffic. Overcapacity = bus filled on purpose, then extra passengers must be rejected. Watch live feed for onboard_rejected or reservation_rejected.
onboard_rejected
reservation_rejected
What: Driver bot runs real trips. Passenger bots board when seats are free — walk-on (flag-down) or with an app reservation. Nothing is staged except regular spawn rates from your form.
Live feed: passenger_boarded, passenger_alighted, gps_position. If the bus is full and someone still tries to get on: onboard_rejected — message no free seat (driver bot) or reservation_rejected (app customer). You must see that the system knew the vehicle was full.
Pass: Manual smoke: trips run, GPS updates, passengers board/alight. Any full-bus attempt produces a visible rejection in the live feed — never silent.
What: After 60 seconds the trip is pre-filled to ~95% capacity. Then 10 customer bots try to confirm an online seat reservation on the same trip.
Live feed: reservation_rejected on the customer bot, or backend returns HTTP 409 on confirm. The passenger bot must not get a seat when the bus is already full.
Pass: Automatic: at least one confirm → 409 response counted. Proves backend blocks overbooking for app reservations.
What: 15 walk-on passenger bots appear immediately and try to board through the driver (flag-down, no app). If seats are gone, onboarding must fail.
Live feed: onboard_rejected — no free seat or API 409 on onboard. Driver bot logs that boarding failed because the vehicle was full.
Pass: Automatic: at least one onboard → 409 counted. Proves driver API rejects walk-on when no seats remain.
What: Enables capture uploads during the trip. All simulated photos agree with the registered passenger count on the manifest.
Live feed: capture_upload events during the run. After stop, run YOLO analysis in backend-web.
Pass: Manual in backend-web: screenshot analysis shows no discrepancy between registered passengers and AI count.
What: Enables capture uploads where every photo intentionally disagrees with the manifest (simulated overcrowding / count mismatch).
Live feed: capture_upload events with mismatch payload. After stop, run YOLO analysis in backend-web.
Pass: Manual in backend-web: audit finding appears (registered vs AI peak mismatch).
Simulated cabin photos for passenger-count checks.
Share of uploads where AI passenger count matches the trip manifest. 0.8 = 80% correct photos.
Share of uploads that intentionally disagree with manifest — tests overcapacity / audit alerts in backend.
Run summary
Add operators and buses while the simulation is running.
Passengers are independent from the driver form. Pick online or walk-on; optionally limit to one company's routes.