04:30. The driver badges in at the warehouse. For the next two hours it is picking, checking and loading. This is work, it is logged as work, and the working time clock is running.
06:30. The vehicle pulls out of the yard, and the optimised route begins. From the planning engine’s point of view, this is minute zero. A fresh driver, a full allowance, the first mandatory break comfortably far away.
10:15. The plan schedules a break. On paper it is perfectly placed. In reality the driver has been on duty for nearly six hours, and the break was legally due earlier.
That gap between minute zero and the real start of the shift is the first thing this feature addresses.
Telling the optimiser what already happened
Break settings now take an initial object, and it sits on the vehicle’s break configuration — once on the driving break settings, once on the working break settings, alongside the general values already there.
The detail that catches people out is which direction it points. You do not declare what the driver has already spent; you declare what is left. The initial object reuses the same field names as its parent: maximumDrivingDuration on the driving side, maximumWorkingDuration on the working side, both in seconds, plus minimumBreakDurations — the breaks still outstanding, as a list of seconds. Two hours of warehouse work before departure is therefore expressed as a reduced remaining working duration, not as an elapsed figure.
Both fields are required once you use the object. There is no partial form where you state the remaining duration and let the optimiser infer the outstanding breaks: if you declare an initial state, you declare the remaining allowance and the breaks still to be taken.
Two rules govern how the values relate to the general settings. The initial remaining duration must not exceed the general maximum, since you cannot have more allowance left than the regulation grants. And the initial break list must be a suffix of the general list: if the standard pattern is a 15-minute then a 30-minute break, a driver who has already taken the first one has only the 30-minute break remaining, so the initial list is the tail of the general one.
The override applies to the first driving or working period after the route starts, and only to that one. Every subsequent period reverts to the general settings, which is what you want — the day is normal from the first break onwards. Worth noting too that the optimiser will not plan a break before the route start, even if the route begins later than it could.
The effect is quiet but significant. Break timing shifts earlier where it should. Route length adjusts to the allowance that is actually left. And a plan that used to look compliant while being unrunnable becomes a plan a dispatcher can hand over without recalculating anything by hand.
It matters most in the operations where routes are only part of the day. Depot work before departure, a shift picked up mid-way from another driver, a handover after a delivery leg — in all of these, the route is not the shift, and the optimiser needed a way to know the difference.
Where a break cannot happen
The second addition is about geography rather than time. Left to its own logic, the engine places breaks wherever they cost least, and cost does not know about parking.
Consider a residential delivery round. Between two customer stops the vehicle is on a narrow street with parked cars on both sides — there is no space to stand a truck for 45 minutes. Or take the moment just after leaving the depot: the driver has spent the loading window resting, and a break in the first half hour is both unhelpful and, in some yards, physically impossible.
Forbidden break positions let you rule those transitions out. Each entry in the list is a small condition on the pair of locations either side of the break, expressed with three optional fields: previousLocationCategory for the location before it, nextLocationCategory for the location after it, and vehicleCategory to scope the whole rule to part of the fleet. The feature belongs to the location constraints family in the request; the documentation gives the exact path to put it under.
How much you specify decides how sharp the rule is. Give both location fields and the break is forbidden only when both match at once — no break between a customer and another customer, while a customer-to-depot transition stays available. Give only the previous location and the rule applies regardless of what follows: forbid breaks after a depot and the driver never breaks straight out of the yard. Omit the vehicle category and the rule covers every vehicle; supply it and only the large trucks that genuinely cannot park are restricted.
Every category field accepts negation with a leading exclamation mark, and that turns out to be the more practical form in daily use. Rather than listing each category where stopping is impossible, forbid the transitions that are not depot-related and the break has to land at a site with facilities. One rule instead of a dozen.
The same “ignored if nothing matches” behaviour applies here as elsewhere in the category system: if no location carries the category named in a condition, that condition is ignored rather than rejected. Convenient for days when a category is absent from the data, and worth remembering when a rule looks like it is not firing.
What changes for the people involved
For the dispatcher, the value is that fewer plans need fixing. A break scheduled in a place with no parking used to be found by a human — either at the planning desk in the morning or, worse, by the driver at 13:00 on a street with nowhere to stop. Both of those repairs disappear when the rule is in the model.
For the driver, breaks land at sites with somewhere to sit, a toilet and space for the vehicle. That is not a small quality-of-life difference over a working year.
For developers and for teams embedding PTV Developer into their own dispatch or telematics product, the interesting shift is that break behaviour is now inspectable and configurable. Two things that were previously outside the optimiser’s view — pre-route duty and site suitability — are now inputs. That means the plan the engine returns can be trusted as the plan that will run, and the wrapper logic that used to nudge breaks around can be deleted.
A caveat worth flagging
Both controls narrow the solution space. Forbid enough transitions and there may be no legal position left for a required break on a given route, and the work that cannot be placed within the rules comes back unscheduled rather than squeezed in. That is the honest outcome, and it is more useful than a plan that fails at 13:00 — the unscheduled list tells you which restriction is doing the damage. In practice, defining the categories where breaks are welcome, and forbidding the rest by negation, is the more robust way to express the intent.
Why this shows up now
Working-time enforcement has become a documentation exercise as much as a driving one. Tachograph data, digital timesheets and audit trails mean the pre-route hours are recorded whether or not the planning system knows about them, and a plan that ignores them is a plan that produces an infringement someone has to explain. Meanwhile urban delivery keeps growing in exactly the streets where a truck cannot stop.
Break placement was the last part of the route the optimiser decided on its own. Now it takes instructions.
