}

The sat-nav ETA misses the break. The driver has to stop. In forty minutes. Driving time runs out. Forty-five minutes of rest. Set by Regulation (EC) 561/2006. A real arrival forecast counts that break. The sat-nav time does not. It only counts the distance left. The gap is not about precision. It is the mandatory break. A map app does not know it. Five hours by sat-nav. Six hours in real life. Not because of traffic. Because of the break.
Four numbers matter for the forecast. The European Commission's driving time and rest period page lists them. After 4.5 hours of driving, a break follows. At least 45 minutes. Or split. 15 minutes first. Then 30. Daily driving time ends at 9 hours. Twice a week, 10 hours. Daily rest lasts 11 hours. Reduced to 9. Only three times a week. Then weekly driving time: 56 hours. And the fortnight: 90 hours. Since 2020/1054, this version has applied EU-wide. Every one of these numbers can push back an arrival. The sat-nav time knows none of them. Not legal advice, just the rule numbers. Exceptions sit with the fleet manager.
A sat-nav divides kilometres by speed. That gives an ETA for the road. Not for the driver. A driver has been driving for three and a half hours. One hour is left before the break. The remaining drive takes two hours. The break falls right in the middle. The real arrival time shifts. By the length of the break. If the driver is also close to the daily limit, the rest period adds on top. Eleven hours. No exception. A forecast without this math shows the wrong number. It is only right by luck. Mostly on a quiet morning. Rarely on a long afternoon run.
The math needs five values. First, the position. From telematics. Second, the remaining distance to the ramp. As driving time. Third, the remaining driving time until the break. Fourth, the remaining daily budget. Fifth: does the rest period fall due before arrival? The forecast chains these values. If the remaining driving time covers the distance, the forecast stays close to the sat-nav number. If not, it adds the break. If the daily budget runs out too, it adds the rest period. Eleven or nine hours. This is a fixed rule. Not an AI model. The regulation has no odds. Only thresholds. A rule engine hits thresholds exactly. A trained model would only guess. This math needs no training. Just the five values. Kept current.
Remaining driving time used to sit only on the driver card. Readable inside the cab. Modern telematics reads it by remote pull. Or straight from a live API. We run a workflow for this. It pulls the forecast every five minutes. Over a SOAP API. And forwards it on. To a partner system. Since mid-July, over 17,000 runs. About 99.4 percent successful. The failures are almost always the other side. A timeout. A server error. No fault of our own. Around 400 vehicles on file. Only a share carries an active forecast. Usually around 64. The rest are parked. Or off shift. Remaining driving time is no longer an edge case. It is a data point. Fresh every five minutes.
Three things no rule removes. First, traffic. The remaining distance is only an estimate. Congestion shifts it. Second, ramp waiting time. A truck arrives. It often still waits. In front of the gate. That is no longer a driving-time question. It is a space question. Third, the driver's own call. The rule allows a break at one point. It does not force a stop there. A driver can stop earlier. By their own choice. Then the forecast shifts again. A good forecast shows a range. Early to late. Not one time that promises a certainty it lacks.
The arrival forecast is not an end in itself. It feeds two processes forwarders already run. Automated delivery notices. And demurrage evidence against the booked time slot. If the forecast runs past the slot, that is a signal. Not once the delay has happened. As soon as the math shows it. That is when the dispatcher should replan. Book a new slot. Or warn the customer. If dispatch waits too long, the window to replan is already gone.
Three honest limits. Not every telematics system exposes remaining driving time as an API. Some only expose raw driver-card data. With no finished forecast. Then the math has to rebuild what the vendor would otherwise deliver. More effort. Same result. Second, the exceptions. Craft trades. Certain vehicle classes. Cross-border edge cases. A rule engine covers the normal case. Not every exception. Third, and most important: this math is not legal advice. It shows a plausible arrival. It says nothing about a driver's actual compliance. Whether a driver really takes the break is the driver's call. Not the forecast's.
A remaining-driving-time source from telematics. A rule engine with the thresholds from Articles 6 to 8. A range instead of a single time. A threshold that warns. Before the delay hits. None of this is exotic. What is new is only this: the mandatory break becomes part of the arrival forecast.
How does your dispatch calculate arrival today? With the sat-nav time? Or with the mandatory break? Send me the number. Then I will show you in a process check how the rule gets into the forecast.