Vessel ETA Prediction in Production: What the Academic Papers Don't Tell You

Written by:

E

Editorial Team

DSG.AI

Vessel ETA prediction using machine learning works. The papers prove that. What they don't prove is that your model survives contact with a live container operation. Academic benchmarks routinely achieve MAPE below 1%. Production deployments routinely disappoint. The gap isn't the algorithm. It's everything around it.

What the Literature on Vessel ETA Prediction Gets Right

The academic consensus is genuine and useful. AIS-derived features dominate: vessel speed over ground, distance to port, course deviation from the great-circle track, and vessel type are the top predictors across nearly every model family tested (Flapper, University of Twente, 2021). Tree-based ensembles (XGBoost, LightGBM, Random Forest) consistently outperform pure deep learning on port-specific datasets. Voyage data is tabular and non-sequential in the way that LSTMs require. Hybrid stacking approaches have pushed published MAPE below 0.25% on controlled test sets (MDPI Journal of Marine Science and Engineering, 2024).

Those numbers are real. The models do learn. But every paper in this literature shares one constraint: the test set contains only voyages that already happened. Production predictions must cope with voyages still in progress, in conditions that are changing right now.

Three Production Gaps the Papers Don't Cover

1. AIS Data Is Noisier Than the Benchmarks Assume

AIS is the backbone of every published vessel ETA prediction model. It is also unreliable in exactly the situations that matter most: high-traffic coastal waters where transponder messages collide, areas with limited terrestrial receiver coverage, and vessels whose operators have reasons to go dark. The IMO mandates AIS carriage for all SOLAS vessels, but carriage doesn't guarantee clean data.

Research datasets are typically gap-imputed before modelling. Production data arrives raw. A vessel that goes dark for 18 hours and reappears 35 nautical miles from where your Kalman filter placed it creates a prediction state that most published architectures handle with a silent forward-fill. That's wrong. Your pipeline needs an explicit uncertainty mode: when AIS position age exceeds a threshold, say so. Never emit a confident point prediction from stale data.

Satellite AIS (S-AIS) closes some coverage gaps but introduces latency and interpolation artifacts. Production teams that assume consistent terrestrial AIS coverage are regularly surprised during high-traffic port approaches and in certain regional corridors.

2. Port State Is the Dominant Variable in the Approach Window

On a 14-day transpacific voyage, vessel kinematics explain most of the variance in arrival time. On the 48-to-72-hour approach window (exactly when the prediction matters for berth scheduling and inland logistics) port state dominates.

How many berths are occupied right now? What is the anchorage queue depth? Is there a labour action affecting throughput? What do the last 48 hours of berthing times look like compared to scheduled windows?

None of this is in AIS. It lives in port authority bulletins, terminal operating system (TOS) exports, and historical queue-depth timeseries you have to assemble yourself. A model without a real-time port state feature will produce systematically wrong approach-phase predictions. Papers exclude this feature because academic researchers rarely have access to live TOS data. Production engineers have to build the data pipeline before they can build the model.

3. MAPE Is the Wrong Metric for ETA Prediction

Read the benchmark tables carefully. MAPE (mean absolute percentage error) is reported almost universally across this literature. It is a poor fit for ETA prediction and it will lead you to select the wrong model.

Voyage ETA distributions are not normal. They are roughly bimodal: most voyages arrive within a few hours of plan, and a meaningful tail arrives late due to weather rerouting, port congestion, or mechanical delays. MAPE weights percentage errors uniformly across this distribution. A prediction that is 6 hours late on a 3-day voyage reports a MAPE of 8.3%, whether that 6-hour error costs you a berth slot or barely registers operationally.

What matters depends on the decision downstream:

Operational decisionMetric that matters
Berth slot allocationP50 and P90 arrival windows
Inland transport pre-positioningHours of lead time at 80%+ confidence
Port resource schedulingCalibration: does "72h out" mean 72h plus or minus 4h?
Demurrage exposure trackingExpected delay vs contracted notice period
Fleet planning beyond 1 weekForecast width, not point accuracy

When we built ETA prediction for a top 10 global container company, we moved away from MAPE as the primary evaluation metric within the first two months. The model that minimised MAPE was not the model that reduced berth conflicts. Quantile regression with q=0.1, q=0.5, q=0.9 targets gave us calibrated arrival windows. The P90 window is what the operations team actually plans against.

The Architecture That Works in Production

Two-stage modelling: a voyage-phase model for predictions more than 72 hours out, and an approach-phase model for within 72 hours. They share training data but use different feature sets.

The voyage phase draws on AIS kinematics, historical port performance distributions, and weather routing data. The approach phase adds live port state, anchorage queue depth, and current vessel lineup from port authority feeds.

Four design decisions that aren't in any paper:

Staleness windows for each feature. Port state data arrives on irregular cadences. Define explicit staleness thresholds per feature. If port data is older than 6 hours, fall back to historical port state baselines for that feature slot. Never silently forward-fill a dynamic feature.

Retraining cadence matched to disruption tempo. ETA models degrade fast during disruption events (a new port labour agreement, a route diversion, a seasonal weather pattern shift). Weekly retraining on a 90-day rolling window catches drift fast enough to matter. Monthly is too slow. Daily retraining introduces noise from short-term events that revert.

Quantile loss from day one. Train with quantile loss targets rather than fitting a point predictor first and retrofitting confidence intervals later. Retro-fitting uncertainty estimates onto a point-prediction model is painful and systematically wrong for the bimodal ETA distribution.

Output schema defined before model code. What does "ETA" mean in your TOS? UTC or local port time? Pilot boarding, berth arrival, or first line secured? A prediction that doesn't map cleanly to the downstream system's definition gets ignored, or misinterpreted. Define the contract first.

What We Measured at a Top 10 Global Container Company

When we deployed this architecture for a tier-1 global container carrier, the operational impact was direct. Container planning horizon extended from 1 week to 9 weeks of forward ETA visibility across the fleet. That shift enabled inland transport pre-positioning and berth scheduling at ranges the manual process couldn't support.

The outcome: $M+ in verified operational savings, primarily from reduced berth idle time and early demurrage detection. The same data pipeline feeding ETA prediction also powers detention and demurrage automation. Build it once to production standard and it compounds across use cases.

Realistic timeline: 3 to 4 months from scoping to a model serving live operational decisions. Not because machine learning is slow, but because port data integration takes time. The model itself is rarely the bottleneck.

Academic Papers Are the Starting Point, Not the Specification

Published benchmarks are advancing. Transformer architectures applied to AIS sequences, better imputation for coverage gaps, hybrid stacking methods (the 0.25% MAPE result cited above is a hybrid Extra Trees + LightGBM + Random Forest stack): these are real improvements. But the gap between 0.25% MAPE on a retrospective dataset and a model your operations team trusts for live berth scheduling is an engineering problem, not a modelling problem.

Papers are the right place to understand which model families perform on tabular maritime data. They are the wrong place to learn what to do when your AIS feed goes dark for 18 hours, or when a port agent switches TOS vendors and your feature pipeline stops validating.

We have shipped vessel ETA prediction and related agentic workflows as part of a 15+ workflow production system running daily for a top 10 global container company. For more on our maritime AI production work, see dsg.ai/maritime.