System Module Active

Service Layer Optimization

The most operationally critical layer. Minimize berth service duration through coordinated STS crane scheduling, AGV dispatch, and yard-side flow absorption.

Scope & Impact

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.

Highest Performance Impact

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.

Decision Variables
  • --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
Hard Constraints
  • --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
Objective Function
  • --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
Ontology Inputs / Outputs
  • --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
Ontology Graph Nodes Involved
STS_CRANEAGVJOBROUTEWORK_POINTYARD_BLOCKYARD_SLOTYARD_CRANECONTAINER
Objective Function

Vessel Completion Speed

The core objective minimizes weighted berth service time with explicit penalty terms for each solver sub-module.

Primary Objective
minvVwv(TvdoneTvberth)+μ1CSTS+μ2Ctransport+μ3Cyard\min \sum_{v \in \mathcal{V}} w_v \big( T^{\text{done}}_v - T^{\text{berth}}_v \big) + \mu_1 C^{\text{STS}} + \mu_2 C^{\text{transport}} + \mu_3 C^{\text{yard}}
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.

STS Interference Penalty
CSTS=(i,j)adjinterference(ci,cj)C^{\text{STS}} = \sum_{(i,j) \in \text{adj}} \text{interference}(c_i, c_j)
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.

Transport Mismatch Penalty
Ctransport=jJarrival(a,j)ready(j)when arrival(a,j)ready(j)>tol(j)C^{\text{transport}} = \sum_{j \in J} \big\lvert \text{arrival}(a,j) - \text{ready}(j) \big\rvert \quad \text{when } \lvert \text{arrival}(a,j) - \text{ready}(j) \rvert > \text{tol}(j)
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 Spillback Penalty
Cyard=bBmax ⁣(0,  yard_queue_delay(b)threshold(b))C^{\text{yard}} = \sum_{b \in B} \max\!\big(0,\; \text{yard\_queue\_delay}(b) - \text{threshold}(b)\big)
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.

Service Quick Reference
Cadence

Rolling horizon every 2-5 minutes, event-triggered micro-adjustments

Key Variables

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

Graph Nodes
STS_CRANEAGVJOBROUTEWORK_POINTYARD_BLOCKYARD_SLOTYARD_CRANECONTAINER
Input Schema

BerthPlan

vessel_id, berth_id,

planned_berth_start,

priority_weight, work_profile

Output Schema

ServiceEvaluation

vessel_id, feasible_flag,

projected_work_done_time,

congestion_penalty,

fragility_score, tags[]

IMPORTANT
Equipment utilization (crane utilization, AGV utilization, distance minimization) should never be optimized for its own sake. These metrics are only relevant when they demonstrably improve vessel completion time.
Constraints

Hard & Soft Boundaries

Hard constraints define physical and operational feasibility. Soft constraints refine solution quality without compromising safety.

Hard Constraints

H1
Resource Exclusivity

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.

H2
Handoff Timing Tolerance

AGV arrival at WORK_POINT must fall within the crane-ready tolerance window. Violations cause either starvation (late) or blocking (early).

H3
Route Feasibility

Every dispatched AGV must follow a conflict-free, lane-capacity-respecting route. No phantom shortcuts or infinite lane capacity.

H4
Yard Capacity

Stack height limits, reefer plug availability, and block occupancy ceilings are inviolable physical constraints.

H5
Crane Interference Zones

Adjacent STS cranes have minimum separation requirements. Overlapping work zones cause physical interference and must be prevented.

Soft Constraints

S1
Yard Proximity Preference

Prefer yard block assignments that reduce AGV travel distance from quay to storage, but never at the expense of vessel completion speed.

S2
Equipment Wear Balancing

Spread crane and AGV utilization to reduce maintenance clustering, subordinate to vessel service objectives.

S3
Buffer Smoothing

Maintain handoff buffer levels within target bands to absorb short-term variance without triggering replan cascades.

S4
Plan Stability

Minimize dispatch churn versus the previous rolling-horizon commit, as long as vessel completion targets are not compromised.

Internal Decomposition

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

Starvation

Crane ready to work but no AGV arrives within the tolerance window. Direct idle time on the critical path.

Blocking / Interference

Adjacent cranes enter overlapping work zones or AGVs queue at congested handoff points, creating cascading delays.

Travel & Resequence Loss

Crane repositioning between non-adjacent bays or task reordering that breaks optimal pick-and-place rhythm.

Equipment Downtime

Unplanned crane failures or maintenance windows that reduce available service capacity mid-operation.

3B. Transport Dispatch

SOLVER: AGV/vehicle routing, job assignment & handoff synchronization

AGV/Truck Dispatch Mismatch

Wrong vehicle dispatched, wrong timing, or wrong route -- any breaks the handoff contract with the STS crane.

Quay Transfer Waiting

Vehicles queuing at quay-side transfer points because arrival and crane readiness are not synchronized.

Buffer Overflow / Underflow

Handoff buffers either saturate (causing upstream blocking) or drain (causing downstream starvation).

Handoff Synchronization Equation
arrival(a,j)ready(j)tolerance(j)\lvert \text{arrival}(a, j) - \text{ready}(j) \rvert \leq \text{tolerance}(j)
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_mismatch

The 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

Yard Block Congestion

Too many concurrent operations in a single block create yard-crane queuing and spill back to quay throughput.

Yard Crane Conflict / Waiting

Multiple jobs compete for the same yard crane, and the resulting queue delay propagates upstream to AGV schedules.

Rehandle / Remarshalling

Bad placement decisions create future rehandle work that consumes yard-crane time during ship-critical retrieval windows.

Poor Stack Positioning

Containers placed far from optimal retrieval paths, adding travel time during departure sequences.

Yard Spillback Propagation
yard_queue_delay(b)=f ⁣(util(b),  yc_queue(b),  ship_crit(b),  rehandle(b))\text{yard\_queue\_delay}(b) = f\!\big(\text{util}(b),\; \text{yc\_queue}(b),\; \text{ship\_crit}(b),\; \text{rehandle}(b)\big)
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.

CRITICAL
These three sub-modules are not independent solvers. Crane Scheduling produces transport demand that Transport Dispatch must satisfy in sync; Transport Dispatch depends on Yard Allocation for feasible destinations. They share a single execution timeline and coordinate through the freeze-and-delta loop — not through separate optimization layers.
Upstream Feedback

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.

Pre-Berth Layer
BerthPlan
input
feedback
Service Layer
ServiceEvaluation
01
Infeasibility Cuts

When a berth plan creates a service configuration that cannot meet vessel completion targets, Service Layer sends a formal infeasibility signal to Pre-Berth.

02
Congestion Penalties

Projected yard and quay congestion costs are propagated upstream so Pre-Berth can avoid creating plans that overload specific zones.

03
Fragility Scores

Each service evaluation includes a fragility score indicating how sensitive the projected completion time is to disturbances.

04
Explanatory Tags

Machine-readable tags identifying which sub-module (crane, transport, yard) is the binding bottleneck for each vessel.

KEY INSIGHT
This feedback loop is what makes the AINOS architecture globally coherent. Without it, Pre-Berth would be planning blind -- making berth assignments without knowing whether the resulting service configuration is feasible. The Service Layer closes this gap by providing structured, quantitative evaluations that Pre-Berth can use as constraints and penalty signals.
Execution

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.

1. Ingest live state

Read crane positions, AGV locations, handoff queues, yard occupancy, and active job statuses from the graph.

2. Freeze executing actions

Lock all currently-executing handoffs, in-transit AGVs, and committed yard crane moves. Only future horizon is re-optimizable.

3. Re-solve active horizon

Optimize crane allocation, dispatch, and yard absorption for the next rolling window using the appropriate solver tier.

4. Compute service evaluation

Project vessel completion times, resource requirements, congestion penalties, and fragility scores for upstream feedback.

5. Publish minimal deltas

Emit only changed dispatch decisions. Unchanged assignments are not re-communicated to avoid execution churn.

Solver Stack
MILP--Medium horizon scheduling

Mixed-Integer Linear Programming for crane allocation and sequencing over 1-4 hour windows.

CP-SAT--Complex sequencing

Constraint Programming with SAT solving for task assignment with intricate precedence and interference constraints.

LNS / Hybrid--Large-scale real-time

Large Neighborhood Search with domain-specific destroy/repair operators for fast re-optimization under disturbance.

Dispatch Policy--Fast reaction

Rule-based dispatch with learned priority functions for sub-second response to individual job events.

Freeze-and-Delta Pattern

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.

KEY INSIGHT
The Service Layer succeeds when it simultaneously achieves fast vessel completion and stable, executable plans. A mathematically optimal dispatch that changes every 30 seconds is worse than a slightly sub-optimal plan that equipment controllers can actually follow.
AINOS Smart Port -- Central Brain Documentation
Service Layer: STS + Transport + Yard Coordination