Arrival fired twice at the gate, and forty minutes late at the next stop

Three different faults produce the complaint 'arrivals are unreliable', and they need three different fixes. A boundary that runs through the parking bay fires twice, or nine times, because a stationary vehicle's fixes scatter across it. A ping interval longer than the vehicle's transit through the fence misses the crossing outright, so the arrival is stamped at the next fix — often the one taken after the driver has already tipped. And a fence drawn around the postal pin for a site never contains the gate the trucks use, so it either fires when a vehicle drives past on the trunk road or it never fires at all.

You do not have to guess which. Pick one arrival everybody agrees was wrong, pull the raw position reports for the hour around it, and plot them against the fence polygon. This page is about reading that plot. It does not redefine entry, exit and dwell — the 3 geofence triggers and the hysteresis that stops them lying covers the vocabulary.

Replay one bad arrival before you change any setting

1. Pick the incident. One site, one vehicle, one timestamp that operations will vouch for — 'he was on the bay at 09:12, the system said 09:51'.
2. Pull raw fixes, not the trail. Export every position report from 30 minutes before to 30 minutes after, with the accuracy field and both timestamps intact. A rendered breadcrumb has been thinned already and will hide the gap you are looking for.
3. Plot them against the polygon as it was that day. If the fence editor has no revision history, this step is where you find out, and that is a finding in itself.
4. Count the fixes inside the boundary. Zero inside means the crossing was never observed. One or two means it was observed but not confirmed. A dozen alternating in and out means the boundary is inside the scatter.
5. Measure the largest time gap between consecutive fixes on the approach. Compare it against how long the vehicle plausibly spent inside the fence before stopping.

Those two numbers — fixes inside the boundary, and the largest approach gap — separate all three faults. Everything below is what to do once you have them.

Duplicates: the boundary runs through the parking bay

A parked vehicle does not report one position. Consecutive fixes from a stationary receiver wander by several metres in open sky and by tens of metres in a yard walled with steel and stacked containers, because the receiver is resolving reflected signal as well as direct. Park with the boundary running under the cab and the reported position crosses it every few minutes, in both directions, for as long as the vehicle sits there. The event log is not lying about what it saw. It is reporting a crossing that happened in the data and not on the tarmac.

The tell in the replay is unmistakable: a cluster of fixes straddling the line, with speed at zero and, if the feed carries it, ignition off. The same scatter is what quietly adds kilometres to a stationary vehicle's odometer, which is the subject of the truck that has been parked since Friday and has driven nine kilometres — worth reading together, because a fleet with one of these usually has both.

Late: the crossing happened between two pings

This is the fault tuning cannot reach, because the evidence does not exist. At 90 km/h a vehicle covers 750 metres in 30 seconds. Sample it every 2 minutes and it covers 3 kilometres between fixes — straight through a 200-metre fence with nothing inside. The arrival is then stamped whenever the next usable fix lands, which is why the error looks random: sometimes 4 minutes late, sometimes 40.

The arithmetic to run per site is simple. Take the fence's smallest width, divide by the typical approach speed, and compare against the reporting interval. A 150-metre fence approached at 40 km/h gives roughly 13 seconds of crossing; the vehicle usually then slows or queues, which buys more, but you cannot count on it at a site with a straight-in bay. If the interval is not comfortably shorter than the crossing, the fence is not observable at that cadence and the fix is cadence, not hysteresis — the case made in ping cadence set by what the vehicle is doing.

One check before you blame cadence: confirm the vehicle was reporting at all. If the gap on the approach is not 2 minutes but 6 hours, you are not looking at an arrival fault, you are looking at a device that stopped talking, and the eleven vehicles that have not moved since morning is the page for that.

Never fired: the fence is around the postal pin, not the gate

Most fences start life as a geocoded address with a default radius, and a geocoder returns a point for a postal address — usually the office door, sometimes the centroid of a large parcel, occasionally a point on the road outside. On an industrial estate the goods-in gate a 16-metre articulated vehicle must use can be several hundred metres from that pin, on a different access road, behind a barrier that adds ten minutes of queueing outside whatever circle you drew.

• The signature. Arrivals at one site are early or late by roughly the same offset every time while the rest of the network behaves. A constant bias is geometry, not noise.
• The other signature. The fence fires for vehicles that never stopped, because the radius swallowed a road. Check whether the crossing fixes carry 50 km/h and a heading straight through.
• The fix is a polygon traced on the yard, not a bigger radius. Widening the circle to catch the gate also catches the neighbour's gate and the roundabout.
• Multi-tenant estates need one polygon per unit. Units 40 metres apart cannot be told apart by a shared fence, and the arrival lands against whichever consignee the code checked first.

An arrival event is not an observation that a vehicle arrived. It is an observation that a reported position fell on the far side of a line you drew, which is a different claim wearing the same name.

The decision tree, in the order it resolves

1. Are there fixes inside the polygon at all? No, and the vehicle was reporting normally — go to cadence and fence size. No, and the vehicle was silent for hours — this is a device or connectivity fault, not an arrival fault.
2. Are there fixes inside, but the arrival is stamped minutes after the first one? The confirmation rule is too heavy for the site: too many required fixes, or too long a hold, on a stop that only lasts 12 minutes.
3. Do fixes alternate across the boundary while speed is zero? Boundary scatter. Move the line, split entry and exit boundaries, add the accuracy gate.
4. Did the arrival fire while speed stayed above 30 km/h and heading stayed constant? The fence contains a road it should not.
5. Did the arrival land against the wrong consignee on a shared site? One fence is serving several tenants; split it per unit.
6. Is the offset the same at this site every time and in the same direction? The fence is centred on the wrong point.

A remediation table you can run site by site

Two structural points come out of running this a few dozen times. Arrival quality is a property of a site, not a fleet: one global radius over-fences the depots and under-fences the kerbside drops. And a fence is data with an owner and a revision history. Yards get re-laid, gates get moved, and nobody tells the tracking system.

Where a fleet runs two tracking vendors, check first that both produce arrivals under the same rules — a provider-side fence and one you evaluate yourself will disagree at the same site. The schema that hides that seam is one vehicle state from two telematics feeds, and the wider question of whose platform owns the logic sits in buying the integration layer or building one. If none of this is fixable because there is no fence editor and no way to replay a day, that tooling gap is the kind of work described under internal tools and ops. The rest of the territory sits in telematics and the live vehicle data plane, inside our logistics and mobility work.

• geofence
• arrival detection
• telematics
• fleet operations