The Optrak Data Model

Optrak holds a good deal of detail about your operation: your sites, your orders and the goods themselves, and — kept separately — your vehicles, tractors, trailers, drivers and equipment. Much of it will look familiar if you have used an ERP or a warehouse system. Holding all of it is what lets the software produce a plan that works when someone has to run it.

Why Most Routing Software Knows Less

Route planning has a long history behind it, and nearly all of it goes back to one description of the job written down in 1959: a depot, a list of customers each wanting a certain quantity, a fleet of vehicles that can each carry a certain amount, and the task of finding the cheapest set of rounds. That description is neat, and sixty years of work on it has produced very good methods for solving it.

Real operations are not that shape. A customer is not one quantity — it is orders, placed at different times, each with its own delivery window. A vehicle is not one thing — it is a tractor, a trailer and a driver, any of which might be paired differently after lunch. And what fits on a vehicle does not add up in a straight line: two half-pallets are not one pallet’s worth of space.

Tim Pigden’s 2013 paper Missing from the Model made that argument. You can bolt an approximation of each of these onto the neat description, and most routing products do. It holds up until two of them start to interact — when whether two orders can travel together depends on when they were placed, when swapping a trailer depends on which drivers are qualified for it, when whether a load fits depends on the sequence you call at the sites in. The paper ends on the line these things are missing from the model.

Why the Detail Matters

If what the software knows doesn’t match how the operation really runs, it is planning against a false picture, and it will produce rounds that don’t work. The planner then has to go through the output and fix it by hand. Sooner or later they do one of two things:

• stop using the optimiser and plan by hand
• change the data until the rounds come out runnable — for instance, telling the system a vehicle holds less than it does, so that loading stops failing

The first wastes the software. The second builds permanent slack into the operation: in that example, vehicles that are never quite filled, on every round, every day.

What Optrak Holds, and What It Works Out

Three kinds of thing it holds: the sites you go to, the orders and goods you move, and the vehicles, drivers and equipment you move them with. Each of those breaks down further — an order is not one number, and a vehicle is not one object — and the sections below say how.

Three more it works out from them, while the plan is being built rather than once it is finished: what will fit on a vehicle, how long the roads take, and how much fuel or charge gets used.

Sites

Every place a vehicle goes — a depot, a customer, a public charger, somewhere to park overnight — is somewhere Optrak plans around in its own right, not just a point on the map with a few minutes added on for the drop. Each one carries its own opening times (several a day if need be, in its own time zone), what can get in and out (weight, size, and local rules such as no artics), how long loading and unloading takes and how that changes with what is being dropped, what training the person doing it needs, and anything that isn’t allowed there. Depots carry the shift as well: checks at the start, paperwork at the end, and overnight pre-loading counted against the vehicle rather than the driver’s day. Chargers and overnight stops are planned the same way as everything else — Optrak can put a charging stop or a night’s rest into a round exactly as it puts in a delivery.

Orders, Products and Shipments

Where most routing software keeps one quantity per customer, Optrak keeps five separate things: orders, the lines on them, the products themselves, the containers they travel in, and shipments. Products describe what is being carried — size, weight, hazardous goods (ADR) codes, and what vehicle or equipment is needed to handle them. Orders and their lines record who has asked for how much of what, and the rules for that order: the earliest and latest it can be delivered or collected. Shipments record how the orders for one site are grouped — what should travel together, what goes on or in the same container, and what is too big for one vehicle and has to be split.

Fleet and Resources

Vehicles, drivers and equipment are held separately, because in a real yard they come apart. Vehicles divide into rigids, tractors and trailers, and each carries its own layout — moveable bulkheads in a multi-temperature trailer, compartments in a tanker. Drivers are people, with shifts, break rules and qualifications, rather than something attached to a vehicle. Equipment can belong to the vehicle (a tail-lift), to the site (a loading bay), or to the round itself (a Moffett, a pallet pump). Because the three are kept apart, Optrak can put a tractor on a different trailer part-way through a shift, put two drivers on one vehicle, or run a vehicle across two shifts.

Loading

Working out what will actually fit, given the shape of the load space and any compartments in it:

• The 3D loader handles mixed goods that stack — which way up things can go, what can stand on top of what, and how the weight sits over each axle.
• The 2D loader handles floor plans — what stands where on the vehicle floor — including multi-temperature trailers where the bulkheads move.
• The bulk loader handles tankers with compartments, and which products can follow which in the same compartment before it needs washing out — a table you set yourself.

The load is checked at every stop on the round, after each drop and each collection, not just as it leaves the depot.

Traffic and Journey Times

How long a road takes depends on when you drive it. Optrak uses TomTom’s lorry-aware maps, which give an expected speed for each street in five-minute slices through the day, worked out from millions of recorded lorry journeys. Lorry data rather than car data matters here: it accounts for lorry bans, weight limits, low bridges, and junctions a car can use and an artic cannot. Optrak asks for a journey time the same way it asks for a distance, and gets back the time for when that trip actually starts, rather than an average for the week. Journey times that vary with the time of day are becoming common in this kind of software; what differs between products is how fine the detail is, where the underlying data comes from, and whether it sits alongside everything else being checked or off to one side.

Fuel and Charge

How much energy a vehicle uses on each stretch of road, worked out from the vehicle itself, what it is carrying at that moment, the speeds and the hills on the way, the time it sets off, and the weather. The method comes from the Cambridge Centre for Sustainable Road Freight and is quick enough to be used while the plan is being built, not just checked afterwards. The same stretch of road can be worked out for different loads and different departure times, which is what makes it usable inside the search. Traffic is allowed for by telling apart stop-start traffic, which uses more energy, from traffic that is simply flowing more slowly, which can use less. Energy is worked out in the same preparation step as distances and journey times, so Optrak can ask for it as readily as it asks for either of those. The same method covers diesel and other fuels as well as electric.

How the Parts Work Together

Nothing Gets Past the Rules

Every change the optimiser considers — every drop moved, every round rebuilt — is checked before it is allowed: whether the load still fits and still comes off in the right order, whether the products can travel together, hazardous goods rules, whether the driver is qualified and available, whether that tractor and trailer can be paired, whether the equipment is there, whether the delivery windows still hold, and for an electric vehicle whether there is enough charge left with the safety margin you have set. Anything that breaks a rule is thrown out on the spot.

So a plan that doesn’t work never gets as far as the output. If Optrak gives you a round, its load has been checked, its driver and vehicle are allowed, its journey times fit its delivery windows, and its charge holds up. If you can get a plan out of Optrak that breaks a rule you have set, that is a bug.

One Preparation Step, One Run

Distances, journey times through the day, and energy use are all worked out in the same preparation step, and the optimiser draws on all of them together. That is what lets delivery windows, what fits on the vehicle, and how much charge is left all hold at once in a single run. Software that gets one of these right but treats the others as a separate exercise, or as a check at the end, produces rounds that look right from one angle and don’t work once you put them together.

Mixed Fleets

Because the energy method covers diesel as well as electric, and because each vehicle carries its own fuel or energy figures, a mixed fleet can be planned in one go — diesel, electric, HVO, CNG, LNG, biofuels — with comparative CO2 figures reported alongside cost and time. That matters to a depot part-way through a transition: a mix of diesel HGVs, electric vans and HVO-capable trucks can be planned as one fleet, each vehicle costed on its own terms, rather than run separately by fuel type and reconciled by hand afterwards. Nothing extra is needed to do it — it falls out of keeping energy and vehicles in the same model.

How This Compares

Plenty of routing and transport software does some of this well. There are mature systems for driver scheduling and drivers’ hours, load-builders with published benchmarks, electric-vehicle tools that model energy use credibly, systems for compartmented petroleum tankers, and palletisation tied into routing. Journey times that vary through the day are becoming standard. No single item on the list above is Optrak’s alone; for any one of them, some product on the market does something comparable.

What differs is having all six in the same place. Standalone load-builders only do loading, which suits a system that plans the round first and loads it afterwards. Electric-vehicle energy is usually a separate tool that checks rounds the planner has already built. Vehicles and drivers are often held separately in the data and yet can’t be planned separately — reassigning a tractor to another trailer mid-shift, for instance. Keeping all six in front of the optimiser while it works is what produces rounds that hold up on every count at once, without the round of planner rework that comes from checking things one after another.

Where most of these constraints are slack — one product, packed goods, vehicles all the same, drivers fixed to them, no compartments, diesel only, light traffic — the difference doesn’t amount to much in practice, and a simpler system will produce plans much like Optrak’s. Where it tells is the kind of operation the 2013 paper took as its examples, and operations like them: petroleum haulage where one operator’s product can’t follow another’s, multi-temperature distribution with moveable bulkheads, mixed bulk and packed lubricants where it only pays to deliver them together, weekend newspaper distribution where the dispatch is split — and the cases the paper anticipated without naming, such as fleets part-way through a change of fuel, town centre work where the trailer changes mid-shift, and electric HGVs running close to their range.

Where to Go Next

For how all this is used while a plan is being built, the optimisation engine covers the methods that draw on it — including in-route charging, which places charging stops inside a round when an electric vehicle can’t do it on one charge.

For what it looks like in a particular trade, bulk multi-compartment distribution leans on orders, resources and the bulk loader; multi-temperature distribution on the 2D loader, orders and journey times; and e-HGV transition on energy use and in-route charging.

If you are weighing Optrak against another system, the questions worth asking any alternative cover vehicles and drivers, loading, electric-vehicle energy, and how they fit together — which is where these differences actually show up.

For the argument itself, the Pigden 2013 paper sets out the position the data model is built around, with worked examples from real operations.

References

Pigden, T. (2013). “Missing from the Model: Orders, Drivers, Tractors and Trailers and Non-Linear Loading.” GECCO ‘13 Companion, 1079–1084. DOI: 10.1145/2464576.2482686.

Dantzig, G.B. and Ramser, J.H. (1959). “The Truck Dispatching Problem.” Management Science 6(1), 80–91.

Visser, T.R. and Spliet, R. (2020). “Efficient Move Evaluations for Time-Dependent Vehicle Routing Problems.” Transportation Science 54(4), 1091–1112. DOI: 10.1287/trsc.2019.0938.

Madhusudhanan, A.K.; Na, X.; Cebon, D. (2021). “A Computationally Efficient Framework for Modelling Energy Consumption of ICE and Electric Vehicles.” Energies 14(7), 2031. DOI: 10.3390/en14072031.