Coupled, or just coincidence? Telling which truck is really pulling your trailer

Coupled, or just coincidence? Telling which truck is really pulling your trailer
A transport order looks tidy on paper. One load, a pickup, a few stops, a delivery. The real world — and the telemetry underneath it — is anything but. A tractor picks up a trailer somewhere it didn't start. The same tractor hauls a different trailer later in the day. Two tractors swap the same trailer at a relay point. Sometimes the trailer has GPS and the tractor doesn't — sometimes the opposite. The pings jitter, drop, and different vehicles report position at different frequencies.
Out of that mess we need a clean answer to a deceptively simple question: who carried what, from where to where, and when did it change hands? We call the answer a leg, and producing it reliably turns out to be much harder than it looks.
The trap: "the trailer moved, so it's a leg"
The obvious approach is to watch the trailer's GPS and call every movement a trip. It falls apart on contact with reality. GPS noise generates phantom trips. You can't tell which tractor was actually pulling — only that one happened to be nearby. And you can't distinguish a real coupling from two trucks that parked in the same yard, or drove parallel lanes of the same motorway for twenty minutes.
The location of a trailer tells you where the cargo is. It does not tell you what is pulling it. And in a mixed fleet — own tractors, chartered carriers, subcontractors, rentals — that second question is the one everything else depends on.
The core idea: co-travel is the proof
We don't ask "did the trailer move?" We ask: did this tractor and this trailer travel together — not once, but in a way that's physically impossible to fake by accident?
Two vehicles being in the same place at the same moment is cheap evidence; it happens at every truck stop in Europe. Two vehicles tracing the same path, turn for turn, over a sustained stretch of road is something else entirely. Sustained, corroborated co-travel is the signature of a physical coupling, and it's the signal our detector is built to find — efficiently, reliably and at scale.
The discipline is the important part: we're permissive about the data we accept, and strict about what we'll accept as proof. A single coincidence never gets promoted to a coupling. The system insists on several independent, time-aligned pieces of shared movement before it will say two assets are hitched.
Compare movement, not position
The intuitive way to test for co-travel is distance: are the tractor and trailer within so many metres of each other right now? It's also the wrong way. Raw (lat, lon, time) readings never line up exactly, the noise routinely exceeds the gap you're trying to measure, and the two assets almost never report at the same instant — one pings every 30 seconds, the other every 8 minutes. A proximity check on that data is fooled by parallel traffic in the next lane and blind to a real convoy whose pings simply didn't align in time.
So we stopped asking how far apart are they and started asking are they making the same journey — the same moves, in the same order, in the same time window. Reframed that way:
- Position stops mattering. Jitter washes out because a wobble in place isn't a move.
- Mismatched reporting rates stop being a problem. The question is about the shape of the journey, not a snapshot at a shared timestamp.
- Two vehicles in adjacent lanes are no longer confusable with a coupled pair. They aren't performing the same sequence of movements — they're just briefly near each other.
That shift — from measuring distance to matching movement — is the idea that makes the rest work.
Holding on through real life
The system treats a stop as what it almost always is — a pause, not a parting. Once it's satisfied two assets are coupled, it keeps them coupled through the interruptions every real journey is full of, and lets go only when they genuinely diverge for good. Distinguishing "parked together for an hour" from "this is where they parted ways" is a judgment call, and getting that judgment right is most of what keeps one real trip from becoming five fictional ones.
There's a subtler problem at the start of a leg. By the time co-travel has been confirmed, the truck has already been rolling for a while — but it was hitched and parked at the loading dock long before it moved. Marking the leg start at "the moment we were sure" would quietly amputate the beginning of the trip. So the system also works backwards and reconstructs the real start: the dock, at the load time, when the two assets were sitting together before anything moved. The leg you see begins where the work actually began, not where the algorithm caught up.
Swaps, ghosts, and the empty run in
A relay swap is the scenario worth picturing: three vehicles assigned to one five-stop load. Tractor one picks up the trailer and runs the first leg. It meets tractor two at a handover point, the trailer changes hands, and tractor two carries the remaining stops to delivery. The detector closes the first leg and opens the second on its own — the trailer's story stays continuous even though the power unit underneath it changed.
A swap is only declared when several strict, independent conditions about the trailer, the two tractors, the timing and the location all agree; it's never guessed from a single clue. The result is a single, honest "the trailer changed hands here" event — something completely invisible to anyone looking at either truck on its own. The algorithm works robustly even when the trailer stays alone for a long stretch of time before the second truck picks it up.

Two more cases the same machinery handles:
- Untracked tractor. When only the trailer has GPS — a rental or subcontractor tractor — the cargo is clearly moving with some power unit we can't name. We still record the leg rather than letting that stretch vanish.
- The empty run in. Before a laden leg, the system reconstructs the empty run the tractor made to reach the load. The timeline shows the full picture: drove in empty, then hauled out laden.
What it's actually for
None of this is in service of a prettier timeline. It exists to answer questions a dispatcher otherwise can't — and that show up constantly in a mixed fleet.
You can see the trailer, but the data you need lives on the truck. The cargo unit reports its position, but remaining drive time, fuel and energy consumption are the tractor's to give. Until you know which tractor was genuinely pulling that trailer — and over exactly which stretch — you can't attach the right drive-time or consumption figures to the right load. Co-travel detection makes that link, so the truck's data lands on the trip it actually belongs to instead of being guessed or left blank.
A swap is planned, but nobody knows where it'll happen. Two tractors are booked for one order and the dispatcher knows a relay is coming — the trailer will change hands somewhere on the route, but where and when is whatever the road decides on the day. The detector recovers the real handover from the movement itself: the point and time the trailer changed tractors, and a clean split of the work and the numbers before and after. No one keys it in; the timeline reflects what happened, not what was scheduled.
A trip crosses several carriers and you need one continuous story. Own tractor in, subcontractor out, a rental in the middle — to anyone watching individual vehicles it's three disconnected tracks. Stitched into legs, it becomes a single order with a clear chain of custody: who held the cargo, for which segment, with what evidence.
Why it's a record, not a guess
Everything above could be done by a black-box model that says "trust me." We deliberately didn't. The detector is deterministic and replayable: the same telemetry always yields the same legs, and every leg carries the evidence behind it — how much corroborated co-travel was seen, the distance and energy consumption pulled straight from on-board counters (diesel, AdBlue or electric, never estimated), and the boundary events that bracket it. A back-office view can redraw any leg over the map with the planned stops and the actual movement behind each decision, so a dispatcher or auditor can ask "why did the system call this a swap?" and get an answer in seconds rather than a shrug.
A leg you can't explain is a leg you can't defend — and in this industry, sooner or later someone asks you to defend it.
Where it runs today — and what's next?
Right now, Transport Leg Analyzer powers our CO2e reporting. Emissions numbers are only as honest as the trip they're computed over: which tractor actually pulled the trailer, how far it really ran laden versus empty, and what it burned doing it. Get the legs right and the carbon math is auditable rather than modelled. Get them wrong and you're reporting fiction with a decimal point.
A clean, evidence-backed answer to "who carried what, from where to where, and when did it change hands" is the substrate for a lot more than emissions — utilization, detention, deadhead, relay verification. We're starting with CO2e because that's where auditability bites hardest. Stay tuned.
If you're a forwarder or platform that wants trip stories built from evidence rather than assumptions, talk to us.
Glossary
- Leg — A single continuous stretch of transport: one tractor, one trailer, from coupling to uncoupling.
- Co-travel — The sustained, corroborated movement of two assets along the same path — the signature of a physical coupling.
- Relay swap — A planned handover where one tractor hands a trailer to a second tractor mid-route.
- Laden leg — A leg where the trailer is carrying cargo.
- Empty run in — The movement of a tractor to a loading point before picking up a trailer.
- Primary data — Measured operational data (e.g. fuel from on-board counters) rather than modelled or estimated values.
- Deterministic — Producing the same output for the same input every time; fully replayable and auditable.



















.png&w=3840&q=75)











.png&w=3840&q=75)

