Service Layer Optimization
The most operationally critical layer. Minimize berth service duration through coordinated STS crane scheduling, AGV dispatch, and yard-side flow absorption.
What This Layer Solves
The Service Layer controls the dominant term in total vessel turnaround: the time between berth start and work completion. It unifies what were previously separate STS/AGV and Yard optimization scopes into a single coordinated domain.
In most container terminals, berth service time is the single largest component of total vessel turnaround. Reducing Tworkdonev - Tberthstartv by even a few percent often yields greater throughput gains than optimizing any other layer in isolation.
- --STS crane allocation to berthed vessels (count, identity, time windows)
- --Crane task assignment and sequencing per vessel work profile
- --Crane-to-AGV handoff structure at WORK_POINT interfaces
- --AGV / truck dispatch: job assignment, route selection, timing
- --Yard-side flow absorption: yard crane priorities and buffer management
- --Local resynchronization actions under disturbance
- --Resource exclusivity: each STS crane, AGV, and yard crane serves one job at a time
- --Handoff timing tolerance: arrival-ready mismatch within window
- --Route feasibility: AGV lane capacity, conflict-free pathing
- --Yard capacity: stack height, reefer capability, block occupancy limits
- --Crane physical reach and interference zones between adjacent STS
- --Primary: minimize weighted vessel completion time sum
- --Penalty 1: STS crane interference cost
- --Penalty 2: transport mismatch (starvation / blocking at handoff)
- --Penalty 3: yard congestion spillback onto quay operations
- --NEVER optimize equipment utilization for its own sake
- --Input: BerthPlan (vessel_id, berth_id, planned_berth_start, priority_weight, work_profile)
- --Output: ServiceEvaluation (projected_work_done_time, resource requirements, congestion_penalty)
- --Output: feasible_flag, fragility_score, explanatory_tags per vessel
- --Graph nodes: STS_CRANE, AGV, JOB, ROUTE, WORK_POINT, YARD_BLOCK, YARD_SLOT, YARD_CRANE, CONTAINER
Vessel Completion Speed
The core objective minimizes weighted berth service time with explicit penalty terms for each solver sub-module.
where: w_v = priority weight for vessel v T^done_v = time all work on vessel v is complete T^berth_v = time vessel v begins berth service μ_1, μ_2, μ_3 = penalty multipliers
The weighted sum of berth service durations is the dominant term. Penalty terms prevent the optimizer from shifting costs between sub-domains without reducing total service time.
interference(c_i, c_j) = max(0, overlap_duration(work_zone(c_i), work_zone(c_j)) )
Counts the total time adjacent STS cranes are in overlapping work zones. Physical interference halts crane operations and directly extends vessel service time.
Starvation: arrival(a,j) > ready(j) + tolerance Blocking: arrival(a,j) < ready(j) - tolerance
Measures the total timing violation at handoff points. Every second of mismatch is a second of crane idle time (starvation) or queue congestion (blocking).
Yard congestion that exceeds block-level thresholds spills back to quay operations through AGV delays.
Captures the cost of yard congestion propagating upstream. When yard blocks are saturated, AGV discharge rates drop and crane starvation increases.
Rolling horizon every 2-5 minutes, event-triggered micro-adjustments
T^workdone_v -- vessel work completion time
T^berthstart_v -- berth service start time
C^STS_interference -- crane interference cost
C^transport_mismatch -- handoff timing cost
C^yard_spillback -- yard congestion cost
BerthPlan
vessel_id, berth_id,
planned_berth_start,
priority_weight, work_profile
ServiceEvaluation
vessel_id, feasible_flag,
projected_work_done_time,
congestion_penalty,
fragility_score, tags[]
Hard & Soft Boundaries
Hard constraints define physical and operational feasibility. Soft constraints refine solution quality without compromising safety.
Hard Constraints
Each STS crane, AGV, and yard crane can serve at most one job in any time slice. No double-allocation across the entire equipment fleet.
AGV arrival at WORK_POINT must fall within the crane-ready tolerance window. Violations cause either starvation (late) or blocking (early).
Every dispatched AGV must follow a conflict-free, lane-capacity-respecting route. No phantom shortcuts or infinite lane capacity.
Stack height limits, reefer plug availability, and block occupancy ceilings are inviolable physical constraints.
Adjacent STS cranes have minimum separation requirements. Overlapping work zones cause physical interference and must be prevented.
Soft Constraints
Prefer yard block assignments that reduce AGV travel distance from quay to storage, but never at the expense of vessel completion speed.
Spread crane and AGV utilization to reduce maintenance clustering, subordinate to vessel service objectives.
Maintain handoff buffer levels within target bands to absorb short-term variance without triggering replan cascades.
Minimize dispatch churn versus the previous rolling-horizon commit, as long as vessel completion targets are not compromised.
Three Solver Sub-Modules
The Service Layer decomposes berth service into three MECE solver sub-modules. Each owns a distinct operational domain with its own decision variables, but all three coordinate through a shared execution timeline.
3A. Crane Scheduling
SOLVER: STS crane allocation, sequencing & interference avoidance
Crane ready to work but no AGV arrives within the tolerance window. Direct idle time on the critical path.
Adjacent cranes enter overlapping work zones or AGVs queue at congested handoff points, creating cascading delays.
Crane repositioning between non-adjacent bays or task reordering that breaks optimal pick-and-place rhythm.
Unplanned crane failures or maintenance windows that reduce available service capacity mid-operation.
3B. Transport Dispatch
SOLVER: AGV/vehicle routing, job assignment & handoff synchronization
Wrong vehicle dispatched, wrong timing, or wrong route -- any breaks the handoff contract with the STS crane.
Vehicles queuing at quay-side transfer points because arrival and crane readiness are not synchronized.
Handoff buffers either saturate (causing upstream blocking) or drain (causing downstream starvation).
For each job j with assigned AGV a:
arrival(a, j) = dispatch_time(a)
+ travel_time(route(a, j))
+ queue_wait(work_point(j))
ready(j) = crane_ready_time(j)
Violation cost added to C^transport_mismatchThe synchronization equation defines the timing contract between transport and crane sub-domains. Every violation directly degrades vessel service time.
3C. Yard Allocation
SOLVER: Block selection, slot assignment & yard crane sequencing
Too many concurrent operations in a single block create yard-crane queuing and spill back to quay throughput.
Multiple jobs compete for the same yard crane, and the resulting queue delay propagates upstream to AGV schedules.
Bad placement decisions create future rehandle work that consumes yard-crane time during ship-critical retrieval windows.
Containers placed far from optimal retrieval paths, adding travel time during departure sequences.
When yard_queue_delay(b) > threshold(b): AGV discharge rate at block b drops -> STS starvation risk at linked berths rises -> Vessel completion time extends
Yard congestion is not a local problem. Through the AGV link, it propagates directly to quay-side crane productivity and vessel service duration.
Closing the Coordination Loop
The Service Layer does not just consume berth plans -- it evaluates them and sends structured feedback that makes Pre-Berth globally aware of operational reality.
When a berth plan creates a service configuration that cannot meet vessel completion targets, Service Layer sends a formal infeasibility signal to Pre-Berth.
Projected yard and quay congestion costs are propagated upstream so Pre-Berth can avoid creating plans that overload specific zones.
Each service evaluation includes a fragility score indicating how sensitive the projected completion time is to disturbances.
Machine-readable tags identifying which sub-module (crane, transport, yard) is the binding bottleneck for each vessel.
Rolling-Horizon Solve Loop
The Service Layer runs continuously on a short rolling horizon, using the freeze-and-delta pattern to maintain execution stability while adapting to real-time disturbances.
Read crane positions, AGV locations, handoff queues, yard occupancy, and active job statuses from the graph.
Lock all currently-executing handoffs, in-transit AGVs, and committed yard crane moves. Only future horizon is re-optimizable.
Optimize crane allocation, dispatch, and yard absorption for the next rolling window using the appropriate solver tier.
Project vessel completion times, resource requirements, congestion penalties, and fragility scores for upstream feedback.
Emit only changed dispatch decisions. Unchanged assignments are not re-communicated to avoid execution churn.
Mixed-Integer Linear Programming for crane allocation and sequencing over 1-4 hour windows.
Constraint Programming with SAT solving for task assignment with intricate precedence and interference constraints.
Large Neighborhood Search with domain-specific destroy/repair operators for fast re-optimization under disturbance.
Rule-based dispatch with learned priority functions for sub-second response to individual job events.
Freeze: Currently-executing actions are locked. The solver cannot retroactively change dispatched AGVs or active crane moves.
Delta: Only changed decisions are published. Unchanged assignments remain stable, reducing execution churn and operator confusion.
Warm-start: Each solve iteration warm-starts from the previous solution, preserving solution quality and reducing compute time.