Public transport planning usually brings three things to mind: the timetable, the vehicle assignment and the driver schedule. A table is filled in, every trip gets a vehicle and a driver, and the plan is considered complete.
But a bus does not spend its whole day in service. It leaves the depot in the morning, runs empty to its first stop, waits somewhere between trips, refuels or charges during the day, gets washed in the evening and spends the night somewhere. These are exactly the hours classic planning never sees, and they are exactly where the plan falls apart in the field.
Where does classic planning break down?
A plan limited to the trip, vehicle and driver trio leaves three questions unanswered:
1. Where does the vehicle stand between two trips? On paper there is a 70 minute gap between two trips. In the field, that vehicle either waits at the roadside near a stop or drives to the depot and back, generating deadhead mileage. Neither appears in the plan, and both cost money.
2. When will washing and refuelling happen? In most operations these tasks sit outside the plan, handled with an “it will get done at the end of the shift” mindset. The result: a queue at the washing bay, a line at the pump, and a morning trip that leaves late.
3. Is the vehicle in the right place at the end of the day? When today’s last trip ends at the wrong end of the network, the bill arrives in one of two ways: the vehicle either produces extra deadhead mileage returning to the depot that day, or the next day’s first trip starts with extra deadhead. A single day’s plan may look correct, but the difference accumulates over the week.
A schedule built without answering these three questions is not a plan, it is an optimistic estimate. We looked at why these dependencies make planning so difficult in Why is transportation planning hard?
How do you automate public transport planning end to end?
Public transport planning software has to see these hours too. That is why KentPlanner builds planning around the vehicle, not the trip. For each vehicle, the entire day is one uninterrupted timeline: depot pull-out, empty movements, trips, breaks, charging and refuelling, washing, parking and the return to the depot, all on the same line, with minute-level precision. Every one of these layers runs on a single AI model: a washing decision affects deadhead mileage, deadhead affects how many vehicles are needed, and vehicle count affects driver headcount, all at the same time.
Every empty kilometre on this timeline is calculated over the real road network, not as a straight-line distance. The run from the depot to the first stop, the transfer between two trips and the return from the last stop to the depot are each measured separately. That way, “can this vehicle make it there in time?” is answered by calculation rather than by guesswork.
On the same timeline, the system also catches conflicts automatically: overlapping duties on the same vehicle, a driver appearing in two places at once, the same pump or the same washing bay being given to more than one vehicle at the same moment, or parking area capacity being exceeded. All of this is checked before the plan is saved.
How are washing and parking areas included in the plan?
This is what really separates KentPlanner from classic scheduling tools: facilities are modelled as resources, not as notes in a notebook.
Washing centres. Each centre can have its own operating days, working hours and multiple washing bays. Washing duration varies with vehicle length: a 12 metre solo bus and an 18 metre articulated vehicle do not take the same time, and the system derives this from the vehicle model. A depot can be allowed to use only certain centres. Washing can be placed either before or after a trip, and the “wash at the end of the day” preference is enabled with a single option. The system routes the vehicle to a suitable bay, calculates the waiting time if the bay is busy, and raises a warning when that wait exceeds a reasonable limit.
Parking / holding areas. These differ from depots: a depot is a permanent home, while a parking area is a temporary holding point between trips and is defined directly by a stop. Each area has a capacity showing how many vehicles it can take at once. The planner sets the threshold themselves by saying “send the vehicle to the parking area on gaps longer than this many minutes”; the system detects those gaps, accounts for the round-trip deadhead mileage to the area, and rejects any solution that exceeds capacity.
Charging and refuelling. Stations are modelled at pump level, and each fuel type has its own operating hours. For electric vehicles the charging curve (how long each state-of-charge band takes) is used instead of assuming a fixed duration. Like washing, refuelling can be placed before or after a trip. Vehicles can be required to end the day at a certain charge level, and a maximum acceptable detour distance for fuel as well as a minimum refuelling percentage per model can be defined.
In short: washing, parking and charging are not the output of the plan, they are an input to it.
Automatic assignment options: every operation has its own rules
AI-powered automatic planning does not mean “press a button and let the system decide.” In the field, every operation, and even every route within the same operation, has its own rules. KentPlanner puts those rules in the planner’s hands:
- Stepped (laddered) assignment. Planning teams already know this term: vehicle and driver duty blocks rotating by shifting day by day. Weekdays and weekends can be set up with separate steps, or you can simply say “shift every N days.” When planning the next period, the system checks whether it can continue seamlessly from where the previous plan left off, so the rotation is not broken between periods.
- Equal kilometre distribution. Some operations and some routes want vehicle mileage to be spread evenly, so depreciation and maintenance load are shared equally across the fleet. Enabled with a single option.
- Deadhead penalty and maximum deadhead. The system penalises empty kilometres as a cost, and a limit such as “a vehicle may travel at most this many empty kilometres between two duties” can be applied.
- Direction rules. Some operators want the outbound/inbound order respected across all trips, some want it only per route, some look for round-trip integrity per route, and some want no rule at all. One of four behaviours is selected.
- Vehicle working limits. How many kilometres, how many minutes or how many trips may a vehicle work per day? The limit can be defined as hard or soft.
- Spare vehicle ratio and spare usage. Part of the fleet can be set aside as spare, and spares can be allowed to enter service in multi-day plans.
- Route limit per vehicle. Rules such as “a vehicle may work at most two routes per day” or “only this model may run on that route” can be defined.
- Break design. Breaks vary by time of day: a fixed number of minutes during night hours, a percentage of the round-trip duration during daytime peaks. How long gaps are used is configured separately.
- Scenario testing with a phantom vehicle. By including a vehicle that is not in the fleet, the question “what changes if I buy 3 more vehicles?” can be tested without adding a real vehicle to the fleet.
These options work together: for the same route, an “equal kilometres + deadhead penalty + end-of-day washing” scenario can be built alongside a “stepped assignment + spare vehicles” scenario and compared side by side. How the assignment engine handles vehicles and drivers together is explained in detail in How to optimize automatic vehicle, driver, and trip planning
How much does automatic planning actually save?
For every plan scenario the system produces measurable output: how many vehicles and how many drivers are required, how many of those vehicles work full day versus split shift, the separate totals for depot-related and between-trip deadhead mileage, the monthly cost, and the difference between scenarios along with the annual saving.
In the field, the biggest gains come not from the number of trips but from deadhead mileage and waiting at facilities. In setups where empty movements are calculated over the real road network and washing and parking areas enter the plan with their capacities, an improvement in the 10-15% range compared to a classic schedule is achievable. And this is obtained not by cutting trips, but by producing the same service with fewer empty kilometres. How that gain turns into a wider decision process across the platform is covered in Public transportation optimization
Frequently asked questions
What exactly does public transport planning software automate?
It automatically produces the timetable, the vehicle and driver assignment, depot pull-outs and pull-ins, empty movements between trips, and washing, charging and parking times inside a single plan. The planner sets the rules, and the AI produces the schedule that respects them.
Do we need to rewrite our existing timetable?
No. The system works with the GTFS data structure; your existing route, stop, trip and calendar data is transferred as is. Planning is built on top of that data.
How is deadhead mileage calculated?
Over the real road network, not as a straight-line distance. The run from the depot to the first stop, the transfer between two trips and the return from the last stop to the depot are measured separately, penalised as a cost, and capped by a limit the planner defines.
Can we intervene manually after the automatic plan is produced?
Yes. The automatic plan is a starting point; when the planner changes a single duty, the system recalculates the other blocks, deadhead mileage and facility usage affected by that change, and warns you before saving if there is a conflict.
Can charging be planned for electric buses?
Yes. Stations are modelled at pump level, a charging curve is used instead of a fixed duration, and vehicles can be required to end the day at a certain charge level.
Will the system fail to work if we do not define washing and parking areas?
It will work. These layers are optional; the more of them you define, the closer the plan gets to reality.
Closing
Trip, vehicle and driver planning is only the skeleton of a public transport plan. When where the vehicle waits, when it is washed, where it charges and where it ends the day are left out of the calculation, the plan undoes itself in the field.
KentPlanner brings these layers together on a single AI-powered timeline, puts the rules in the planner’s hands, and makes the cost of every scenario measurable. Planning is done with comparable numbers, not with intuition.