Container terminal & port operations optimisation (berth, quay crane, yard stacking, truck slots)

A container terminal is a tightly coupled system: when a vessel arrives early or late, the berth plan, crane assignment, yard layout and gate appointments all shift. ML predicts vessel ETAs, container dwell times and pickup modes; mathematical solvers and reinforcement learning then turn those forecasts into berth, crane, stacking, equipment and truck-slot plans that cut waiting time, reshuffles and congestion. Benefits are mostly higher throughput on fixed infrastructure and lower emissions from idling vessels and trucks.

Problem & value

• Today: planners build berth plans days ahead with spreadsheets or rule-based TOS modules, adjust by phone with shipping lines, and stack containers by simple rules (class, weight, destination). Late vessels, bunching of arrivals and unknown pickup times cause idle cranes, yard "reshuffles" (unproductive moves to reach a lower container) and truck queues at the gate.
• AI value: (1) probabilistic ETA and dwell-time forecasts instead of declared times; (2) joint optimisation of berth, cranes and yard under uncertainty; (3) learned stacking policies that anticipate pickup order; (4) truck appointment systems that smooth gate and yard peaks; (5) faster re-planning when disruption hits.
• Evidence: operators and vendors report double-digit-percent reductions in reshuffles or waiting in individual deployments, but these are vendor-reported and terminal-specific; measure on your own baseline rather than quoting them [1][2][3]. Port-call optimisation also supports IMO's just-in-time arrival agenda to reduce fuel burn while waiting at anchor [5].

Variants

• Deep-sea container terminal (TOS-centred): berth + quay crane + yard + horizontal transport (HHLA, PSA, DP World class).
• Port-authority / port-community angle: shared nautical and hinterland view built on AIS and the port community system (PCS) — e.g. Portbase (NL), DAKOSY (Hamburg) — for port-call coordination, pilot/tug/berth slots and hinterland visibility across several terminals [4].
• Inland, barge and rail terminals: train-slot and barge-rotation planning, crane scheduling on rail yards, consolidating barge calls at deep-sea terminals.
• Truck appointment & gate optimisation: slot allocation, dynamic pricing of slots, gate-queue prediction (see OPT-001 for hinterland routing).
• Not in scope: warehouse slotting (OPT-006), bin packing (OPT-012), network-wide disruption recovery (OPT-020), voyage routing (OPT-026).

How it works

1. AIS + PCS + shipping-line schedules + TOS bookings + gate data
2. ETA / dwell-time / pickup-mode forecasts (probabilistic ML)
3. berth allocation (MIP / CP-SAT, rolling horizon)
4. quay-crane assignment & sequencing
5. yard stacking & re-marshalling (heuristic + learned policy)
6. equipment dispatch (AGV / straddle carrier / terminal tractor)
7. truck appointment slots & gate forecast
8. planner review
9. TOS execution
10. feedback to the models

• Forecasting: gradient-boosted trees and time-series models for ETA from AIS track history, port-call messages and weather; survival or quantile models for container dwell time and truck/rail/barge pickup mode.
• Optimisation: berth allocation and quay-crane scheduling as mixed-integer or constraint programs (OR-Tools CP-SAT, HiGHS, commercial solvers), re-solved on a rolling horizon. Container stacking is NP-hard; production systems combine heuristics with learned pickup-order predictions, and research uses deep RL or graph neural networks for stacking and crane-sequencing policies.
• Simulation: discrete-event digital twin to test plans and train RL policies before production use.
• LLM role (auxiliary): natural-language what-if queries and explanation of plan changes to planners (see OPT-018); never the solver itself.
• Human-in-the-loop: the berth/vessel planner approves the berth plan and commercial commitments to shipping lines; yard planners can override stacking rules; automated equipment stays under the TOS/safety layer.

Data preparation

The data is mostly structured but spread across systems: TOS event history (moves, yard inventory, equipment status), gate transactions, port community system (PCS) messages, AIS tracks, shipping-line schedules and crane telemetry. In practice the TOS holds the core, while appointments, customs holds and line schedules sit in separate databases, e-mails and spreadsheets.

Typical gaps: inconsistent vessel and container identifiers across systems, missing or overwritten timestamps, manual planner overrides that are not logged (so the learning signal is lost), declared instead of actual ETAs, and sparse records for rare disruptions. Access rights are often tied to the TOS vendor contract.

Preparation steps: (1) inventory sources and owners and check export or API rights with the TOS vendor (PREP-001, PREP-005); (2) build a clean event store (Postgres/TimescaleDB or Kafka) with harmonised keys and time zones; (3) define KPI and term glossary such as reshuffle, dwell time and gate turn time (PREP-012); (4) harvest labels from history, for example actual pickup mode and dwell (PREP-020); (5) build a replay simulator and test set with planners (PREP-018); (6) pseudonymise driver and plate data (PREP-022). Plan 1 to 3 years of history. Expect roughly 50 to 60 percent of the total effort in data work, which is why this is rated high.

Implementation paths

Which path for whom

• Enterprise (terminal operator): B, because berth and yard planning is the core competitive process, needs custom constraints (customs holds, reefer limits) and must plug into your TOS; off-the-shelf modules rarely cover that alone.
• Developer / integrator: C, because OR-Tools, LightGBM and SimPy give full control and no licence costs for building and testing planners on replayed TOS data.
• Public (port authority / PCS operator): B, because shared port-call and hinterland views are best built on sovereign EU cloud with open interfaces (PCS, AIS) under procurement rules.

Path A — Buy (off-the-shelf)

• TOS and optimisation suites: Navis N4, Kaleris (incl. XVELA vessel-planning collaboration), Tideworks, CyberLogitec OPUS Terminal, TBA (NL, EU), Kalmar (FI, EU) automation software.
• Port-call and ETA platforms: PortXchange (NL, EU), Portbase (NL, EU), DAKOSY (DE, EU) PCS, MarineTraffic / Kpler and Spire for AIS data, project44 for hinterland ETAs.
• Choose A when: you run a standard TOS; optimisation modules or add-ons exist for it, and the vendor can integrate with your equipment control.

Path B — Build on cloud APIs

• Forecasting on managed ML (Vertex AI, Azure ML, AWS SageMaker in EU regions) fed by AIS APIs (Spire, MarineTraffic/Kpler, EU-based Danish Maritime Authority open AIS archive for historical data) and PCS APIs.
• Solvers as services or libraries (OR-Tools in containers, Gurobi/CPLEX licences, Timefold Solver — open core, BE).
• Integrate via TOS APIs/events (N4 web services, message bus). Use an LLM API (Claude, Mistral, Gemini) only for planner Q&A.
• Choose B when: you need custom constraints (e.g. customs holds, reefer plug limits) beyond vendor modules.

Path C — Self-host (open source)

• Solvers: Google OR-Tools (CP-SAT, routing), HiGHS, SCIP, Timefold; forecasting with LightGBM/XGBoost, scikit-survival, Darts/StatsForecast; RL with RLlib, Stable-Baselines3 or CleanRL.
• Simulation: SimPy or AnyLogic (commercial) for digital twin.
• Data: AIS via AISHub or national open archives; Postgres/TimescaleDB, Kafka for TOS events.
• Hardware: HW1 (CPU servers) covers most solving and GBDT work; RL training benefits from one GPU (HW2).

Path D — Custom training

Worth it for large terminals with years of TOS history: train site-specific ETA, dwell-time and pickup-mode models, and RL/GNN stacking or crane-sequencing policies against a calibrated simulator. Needs 1–3 years of TOS event logs, gate and crane telemetry. Shadow-mode evaluation against the incumbent planning rules is essential.

State of the art (2026)

• Hybrid "predict then optimise" is the production pattern: calibrated uncertainty from ML feeds robust or rolling-horizon solvers; pure end-to-end RL is still mostly research and pilot.
• Stacking: learned pickup-order prediction plus heuristic stacking is the most mature gain; deep-RL and GNN-based stacking and crane scheduling show results in simulation and selected pilots but generalise imperfectly across terminal layouts [6].
• Port-call collaboration: standardised port-call messaging (IMO FAL/IMO Single Window, EU Maritime Single Window Regulation 2019/1239, IMO Compendium / ISO 28005 style data models) enables shared ETA and berth-slot negotiation [4][5].
• Automation: automated terminals (e.g. HHLA CTA Hamburg, Rotterdam, PSA Singapore) use TOS-driven AGV/ASC dispatch with optimisation layers; semi-automated and manual terminals are the larger market.
• Limits: ETA error from congestion at the previous port; incomplete shipping-line data; unplanned customs/inspection holds; sparse labels for rare disruptions; models trained on one terminal rarely transfer. Plans must be repairable in minutes.

Shared resources & combinations

• Shared stack: optimization-solver + tabular-ml/time-series + simulation shared with OPT-001 (routing), OPT-002 (scheduling), OPT-006 (warehouse), OPT-019/OPT-020 (dispatch/recovery).
• Upstream: PRED-018 (ETA prediction), DOC-006 (bills of lading, customs documents), OPT-026 (voyage speed and arrival optimisation: just-in-time arrival).
• Downstream: OPT-001 and OPT-033 (drayage and freight matching), OPT-028 (demand-responsive dispatch ideas), OPT-021 (electrified yard fleets), OPT-018 (LLM-to-solver what-if copilot).
• One CPU/GPU optimisation cluster (HW1–HW2) can serve several of these.

Effort, cost & KPIs

• Path A: months for module roll-out plus change management; licence-based. Path B: 6–12 months for first production module (e.g. truck slots or ETA). Path C/D: 12+ months, specialist OR/ML team, simulator build.
• Cost drivers: data integration (TOS, PCS, AIS licences), simulator calibration, equipment integration, planner training.
• KPIs: berth productivity and vessel waiting time, crane moves per hour (gross/net), reshuffle ratio, yard occupancy and dwell time, truck turn time and gate queue, ETA error (MAE), plan stability, energy and fuel per move, CO2 per container.

People & change

Start with management and the head of terminal operations (process owner) to agree scope, budget and an override policy. Involve IT and IT security early, since TOS integration and NIS2 duties apply, and the data owners of TOS, PCS and gate systems. Berth, yard and crane planners are the key end users: co-design with them, run the models in shadow mode first and let them judge the plans.

Works council: yes. Gate and yard data, planner overrides and equipment telemetry can reveal individual behaviour or performance, so §87(1) no. 6 BetrVG applies as soon as the system logs user or driver activity; §90(1) no. 3 requires timely information when work processes are planned with AI, and §80(3) allows an AI expert. In public bodies the staff council (Personalrat) is responsible. Avoid individual performance scoring of dockworkers. Involve the DPO and run a DPIA check for truck driver and plate data, with AVV for each processor (GUIDE-005).

AI literacy: support staff with short role-based training on forecasts, uncertainty and when to override (Art. 4 AI Act, GUIDE-006). Communicate that the planner stays the decision maker and that plans are proposals. Pick one terminal or one berth as pilot group. Typical fears are job loss and loss of planning skill; address them with transparent KPIs and a visible override and rollback rule. See GUIDE-004, GUIDE-008 and GUIDE-009.

Risks, regulation & compliance

• EU AI Act: typically minimal risk for planning/optimisation. High risk (Annex III point 2) only if the AI is a safety component in the management/operation of critical digital or physical infrastructure (e.g. safety control of road traffic, energy), which terminal planning usually is not; autonomous equipment is governed by Machinery Regulation 2023/1230 safety rules. Worker-allocation or performance-scoring features for dockworkers can fall under Annex III employment (high risk) — avoid individual monitoring. No Art. 5 issue expected; do not repurpose AIS/camera data for biometric identification of crews.
• Cybersecurity: ports are essential/important entities under NIS2; OT/IT segregation, supplier security and incident reporting apply [7]. Optimisation outputs must not directly actuate equipment without TOS safety layers.
• GDPR: truck driver and vehicle plate data at gates and in appointment systems are personal data; minimise, set retention, DPAs with vendors; AIS data of ships is mostly non-personal.
• Competition and data sharing: sharing berth and ETA data among competing terminals/lines needs antitrust review and data-sharing agreements (EU Data Act relevant for connected equipment data).
• Business risks: vendor lock-in with the TOS, over-reliance on forecasts, plan instability. Mitigate with shadow mode, fallback rules, and planner override with logging.

Getting started

1. Baseline the terminal: vessel waiting time, crane utilisation, reshuffle ratio, gate turn time, ETA error.
2. Audit data: TOS event history, AIS access, PCS interface, quality of vessel and pickup data.
3. Start with a bounded forecast (vessel ETA or container dwell/pickup mode) and run it in shadow mode.
4. Add one optimiser (truck slot smoothing or berth planning on OR-Tools CP-SAT) using a replay simulator.
5. Pilot with planners in the loop, then extend to yard stacking; agree override and rollback rules.

Sources

1. Navis — N4 terminal operating system — https://www.navis.com
2. Kaleris — terminal and supply-chain software incl. appointment and XVELA — https://kaleris.com
3. HHLA — Container Terminal Altenwerder / Hamburg port automation — https://hhla.de
4. Portbase — port community system Netherlands — https://www.portbase.com
5. IMO — Just-in-time arrival / port call optimisation (GloMEEP) — https://www.imo.org
6. Google OR-Tools — CP-SAT scheduling documentation — https://developers.google.com/optimization
7. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
8. Regulation (EU) 2019/1239 European Maritime Single Window — https://eur-lex.europa.eu/eli/reg/2019/1239/oj
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
10. PortXchange — port call optimisation platform — https://portxchange.com