Skip to main content
A heavy long-distance operation runs multi-day corridors between distribution points, mixing scheduled warehouse pickups, loop tours that consolidate full loads without a fixed endpoint, and a real overnight rest built into the schedule rather than assumed. Fuel and CO2 costs scale with the actual load carried, not just the kilometres driven.

What makes this vertical distinctive

  • Reserved warehouse slots — an early pickup window at the warehouse is reserved for one specific vehicle, on top of the standard hours everyone else sees.
  • Load-aware CO2 accounting — CO2 is calculated from the load actually carried per leg, not from distance alone.
  • Consolidation loops — a truck with no fixed home base opens and closes its tour on whichever point it visits first, minimizing empty running.
  • A real overnight rest — a two-day route plans an explicit rest period, not just a working window that happens to span two days.

Combined example

Reserved warehouse slots

order-warehouse-dock’s window carries resourceTags: ["dock-slot:reserved-a"] — only tractor-reserved-1, which holds that tag, can be assigned this early slot; every other resource is restricted to whatever untagged window exists elsewhere on the same stop. See Restricting a window to specific resources — the exact worked example this follows.

Emissions scaled to load carried

truck-1.CO2EmissionCalculation mirrors the Cost object’s shape: a flat km rate plus costPerCapacityPerTravelledKm, which multiplies the weight actually carried on each leg by the distance travelled. A fully loaded leg reports more CO2 than an empty return leg over the same kilometres, instead of both being priced identically by distance alone.

Consolidation loops

truck-loops-1 has no departure and sets arrival: "atFirstPosition" — its tour closes on whichever stop the engine assigns first, rather than a fixed depot. Paired with order-loop-0’s pickup-then-delivery stops (successiveStops: true, matching weight capacities), this lets the engine build a self-contained loop sized to whatever load it consolidates. See Depot vs. position for how "atFirstPosition" fits alongside a normal fixed departure/arrival.

A real overnight rest

truck-1.workingTimeWindow spans two calendar days, but that alone wouldn’t force any rest between them — the workingDurationSlidingBreak (an 11-hour minimum every 12 hours) is what actually reserves the overnight period, which is why order-day2-delivery’s window only opens the next day. See Modeling multi-day sleepovers — the exact worked example this follows.

Full payload

The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (workingTimeWindow, departure, arrival), the complete objectives list, and enough orders (including an LTL pickup/dropoff pair unloaded in strict LIFO order) to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own.

See also

Ready to model an operation like this one? Send your first API call with your own data, or contact customer.success@kardinal.ai to walk through your specific constraints.