Simulation-Based Evaluation of AI-Orchestrated Port–City Logistics

Abstract

AI technologies are increasingly applied to optimize operations in both port and urban logistics systems, yet integration across the full maritime city chain remains limited. The objective of this study is to assess, using a simulation-based experiment, the impact of an AI-orchestrated control policy on the performance of port–city logistics relative to a baseline scheduler. The study proposes an AI-orchestrated approach that connects autonomous ships, smart ports, central warehouses, and multimodal urban networks via a shared cloud control layer. This approach is designed to enable real-time, cross-domain coordination using federated sensing and adaptive control policies. To evaluate its impact, a simulation-based experiment was conducted comparing a traditional scheduler with an AI-orchestrated policy across 20 paired runs under identical conditions. The orchestrator dynamically coordinated container dispatching, vehicle assignment, and gate operations based on capacity-aware logic. Results show that the AI policy substantially reduced the total completion time, lowered truck idle time and estimated emissions, and improved system throughput and predictability without modifying physical resources. These findings support the expectation that integrated, data-driven decision-making can significantly enhance logistics performance and sustainability in port–city contexts. The study provides a replicable pathway from conceptual architecture to quantifiable evidence and lays the groundwork for future extensions involving learning controllers, richer environmental modeling, and real-world deployment in digitally connected logistics corridors.

1. Introduction

Recent advances in artificial intelligence (AI) have reshaped both maritime and urban logistics systems, with applications ranging from traffic prediction and emissions forecasting to adaptive signal control and multimodal freight optimization [1,2,3]. Over the past five years, the use of AI techniques has expanded rapidly across port terminals, urban road networks, and hinterland corridors, reflecting growing recognition of AI’s potential to improve efficiency, reduce emissions, and support responsive coordination in complex supply chains [2,4]. However, existing research also highlights important limitations: most implementations remain confined to individual subsystems, data interoperability between port and city infrastructures is often limited, and integrated, simulation-backed demonstrations of AI control spanning from ship to city remain scarce [1,5].

In particular, while prior studies demonstrate the effectiveness of AI methods within ports, urban traffic systems, or hinterland logistics in isolation, there is limited empirical evidence on the system-level performance gains that are achievable through coordinated control across the full port–city chain. To contextualize this gap, the following section reviews recent AI applications in port, urban, and hinterland logistics, with a focus on how these approaches are evaluated and where integration across domains remains limited.

1.1. Review of the Current State of the Research

Recent studies show increasing adoption of AI-driven decision support across port operations, urban freight transport, and hinterland logistics, where such methods are used to support prediction, optimization, and real-time control tasks [1,3,6,7]. Recent integrative studies from adjacent domains, such as source-to-pay and enterprise coordination frameworks, further highlight AI’s role in aligning decision-making across traditionally siloed processes, reinforcing the relevance of end-to-end orchestration approaches in logistics and supply chains [8].

Early AI approaches in logistics relied on expert systems and agent-based models to capture human reasoning and distributed decision-making [3]. These have been applied to planning and monitoring tasks in urban freight and can be integrated with agent-based digital twin simulations of logistic flows [3,6]. Multi-agent frameworks are particularly useful for simulating interactions among port stakeholders, such as trucks, terminal operators, and city traffic controllers, under various scenarios [7]. These approaches are well suited for analyzing localized interactions and emergent behavior, but they are typically evaluated within bounded subsystems rather than as part of an end-to-end port–city coordination problem.

Machine learning (ML) has become the most widespread AI approach in logistics, enabling systems to learn from data and improve over time [3,9]. In port city contexts, ML models are used for predicting traffic volumes, travel times, and freight demand, which aids in proactive congestion management [2]. Deep learning (DL) techniques (e.g., neural networks) have been utilized for complex pattern recognition, such as classifying shipment types or forecasting port throughput. Deep learning has also been applied to estimate and forecast greenhouse gas emissions in port and urban freight contexts, supporting environmental assessment and planning [10,11]. Together, these approaches primarily support forecasting and decision at specific stages of the logistics chain, without explicitly coordinating actions across domains.

Reinforcement learning (RL) is increasingly explored for dynamic decision problems like vehicle dispatching and traffic signal optimization. Advanced frameworks integrate deep RL with Internet of Things (IoT) sensor data to generate adaptive policies for scheduling and routing under uncertainty [4]. By learning through trial and error in simulations or digital twins, RL agents can optimize sequential decisions to minimize delays and improve system resilience [4,12,13,14]. Despite their potential for dynamic optimization, most RL-based solutions are evaluated in isolation and do not address how decisions at one layer propagate impacts across port and city logistic operations.

Digital twin technology, defined as virtual replicas of physical systems, has gained traction as an enabling tool for port–urban integration. Modern ports with complex operations are well suited to digital twin implementations [15]. Researchers have developed digital twin models of terminals to simulate real-time operations and test control strategies [15,16,17,18]. Importantly, these simulation-based environments provide a controlled and reproductible means of evaluating coordination strategies before real-world deployment, making them a common evidence vehicle for assessing system-level impacts.

These high-fidelity simulations, often fed by real-time IoT data, provide a safe sandbox to evaluate how port decisions, such as gate schedules and yard operations, affect urban traffic and vice versa. Digital twins are increasingly recognized as key for planning resilient and sustainable port operations by offering greater transparency and data-driven decision support [15]. However, studies note that many current efforts focus on specific components (berths, yards, hinterland legs) rather than a fully integrated twin of the entire port–city ecosystem [15,16,18]. Bridging these segmented models into a cohesive framework remains an open challenge [1,5].

AI frameworks are increasingly applied at the port–urban interface, especially to manage road traffic linking port gates and city networks. Adaptive AI-based traffic signal control can adjust timings in response to port truck queues and ship schedules, as illustrated by a Baltic port city case study [5]. While such measures can reduce queues near the port, they might create congestion elsewhere in the urban network, highlighting the difficulty of balancing port flows with general traffic demands [5]. These findings illustrate that localized AI optimizations at the port–city interface can generate unintended system-wide effects when broader coordination mechanisms are absent.

Beyond the port gates, AI is also used to optimize routing and scheduling across hinterland and urban logistics networks, including multimodal coordination, dynamic mode selection (synchromodality) and real-time re-routing [2,14,19]. Recent work has integrated digital twin simulations of hinterland networks with AI optimizers to evaluate scenarios like shifting more cargo to off-peak trains or optimizing the timing of truck trips to avoid urban rush hours [2,3].

Despite these advances, practical deployment of such AI-driven coordination is still in the developing phase. Institutional barriers (different stakeholders for port, rail, highway) and data silos make real-world integration difficult. Case studies show that even when both ports and cities develop digital twins, interfaces between them are often missing, preventing end-to-end visibility and coordinated control [20].

Several challenges limit the full integration of AI frameworks into port logistics and urban systems. One major issue is fragmentation of data and systems between port authorities and city agencies. Often, ports and cities maintain separate digital platforms (e.g., independent traffic management centers, standalone port community systems) with little interoperability. An illustrative finding comes from a smart port city case study: the port authority was developing a digital twin of the port, and the city had its own urban digital twin, but no clear interfaces had been established between them [5]. This lack of seamless data sharing constrains AI applications that require end-to-end visibility across port, hinterland, and urban domains. Progress will require creating unified data spaces or interface standards so that AI systems can draw on both port and urban datasets in real time.

Another important limitation concerns the gap between simulation-based validation and real-world deployment. Many AI-based logistics solutions have only been tested in controlled simulations or pilot programs. For example, giving traffic signal priority to port trucks is promising in theory, but in practice it requires robust and fail-safe mechanisms and continuous calibration as traffic conditions evolve. Unintended consequences, like queue spillbacks and secondary congestion, can emerge if AI control policies are not carefully managed [1]. This points to the need for more research on human-in-the-loop AI and resilient AI systems that can handle the stochastic nature of urban logistics. Additional challenges relate to data quality and availability: while ports generate detailed operational data, real-time data on city streets and trucking operations can be sparse or inaccessible [15]. One way to address this is using synthetic data or estimations to fill gaps, but more comprehensive IoT deployment in both port and city domains would greatly enhance AI’s capabilities.

Finally, there remains a fundamental gap in how port–city coordination strategies are evaluated. City and port authorities typically rely on different performance indicators, such as throughput and turn-time for ports versus congestion and emissions for cities, resulting in fragmented assessments. Studies report that port and city officials might perform separate environmental impact calculations using similar methods, yet they lack a unified view of the combined impact [5]. As a result, there is limited empirical evidence, grounded in controlled simulation, on how coordinated AI-driven control across the full port–city chain affects shared system-level performance indicators.

To address these limitations, this study proposes an AI-orchestrated approach for coordinating logistics flows across the port–city chain. The approach integrates maritime operations, port activities, and urban freight distribution through a shared control layer, enabling coordinated decision-making across traditionally siloed domains. The proposed framework is evaluated through a controlled simulation experiment to assess its impact on system-level performance indicators.

1.2. Problem Statement and Study Objectives

Across the analyzed literature, several recurring observations emerge: (i) effective port–city integration depends on shared digital infrastructure and coordinated governance; (ii) operational AI techniques, including capacity-aware control, federated sensing, and synchromodality, are sufficiently mature for targeted deployments; and (iii) agent-based simulation and digital twin environments are widely used as evidence vehicles to assess logistics coordination strategies before real-world deployment. However, end-to-end demonstrations that trace operational decision-making from ship or port activities through to urban networks, with measurable system-level performance indicators, remain scarce.

This article aims to fill this gap by (i) defining an AI-orchestrated coordination approach that aligns port and urban logistics operations, (ii) instantiating the proposed control logic within a simulation environment, and (iii) evaluating its system-level effects using shared performance indicators that are consistent with digital twin and governance paradigms. In doing so, the study aims to provide empirical evidence on the potential benefits and limitations of coordinated AI-driven control across the full port–city logistics chain.

2. Materials and Methods

To address the lack of empirical evidence on end-to-end AI coordination across the port–city logistics chain identified in Section 1.2, this study adopts a controlled, simulation-based experimental design. The objective is to evaluate the system-level effects of an AI-orchestrated coordination policy relative to a conventional scheduling baseline under identical operating conditions. The simulation environment represents key stages of the logistics chain, from maritime arrival and port operations to hinterland transfer and urban distribution, and enables repeatable experimentation using shared performance indicators.

Although learning-based AI techniques, such as reinforcement learning or supervised predictive models, are increasingly applied in logistics optimization, their effective deployment requires access to large volumes of representative operational data for training, calibration, and validation. In real-world port–city systems, such data are often available through port community systems, traffic management centers, and fleet telematics, making learning-based controllers feasible in deployed environments. However, incorporating learning-based algorithms in a simulation-only study would require either extensive real-world datasets or strong assumptions about data generation and reward structures, which would introduce additional sources of uncertainty beyond the scope of the present work.

For this reason, the current study adopts a rule-based, capacity-aware AI orchestration policy that operates directly on observable system state variables. This choice enables controlled experimentation, transparency of the decision logic, and unambiguous attribution of performance differences to coordination mechanisms rather than to training dynamics or data availability. The proposed framework is explicitly designed to accommodate learning-based controllers in future extensions, once suitable real-world data or validated training environments are available.

2.1. Reference Architecture and Control Scope

This study adopts a reference architecture to define the structural and functional scope of the port–city logistics system evaluated in the simulation. The architecture specifies the main subsystems involved in end-to-end freight flows, the information interfaces between them, and the role of a centralized orchestration layer that is responsible for coordinated decision-making across domains. Figure 1 illustrates this reference architecture and delineates the boundaries of the system considered in the experimental evaluation.

The architecture spans four interconnected domains: maritime operations, port and terminal processes, intermediate consolidation facilities, and urban freight distribution networks. Maritime operations represent vessel arrivals and container discharge decisions at the port interface. The port domain includes terminal handling, gate operations, and short-term capacity management. The urban domain comprises a multimodal distribution network, including road-based freight transport interacting with general urban traffic. These domains are treated as interdependent subsystems whose local decisions can propagate impacts across the wider port–city chain.

Coordination across these subsystems is achieved through a cloud-based orchestration layer that aggregates system state information and issues control decisions affecting multiple domains. The orchestrator operates on shared state variables, such as resource availability, queue lengths, and demand levels, and applies capacity-aware coordination logic to align actions across the port and urban networks. In the present study, the orchestrator represents the operational coordination component under evaluation, replacing isolated, subsystem-level scheduling with coordinated control.

The reference architecture also includes supporting digital infrastructure elements related to sensing, data exchange, and governance. Federated sensing mechanisms represent the collection of operational data from heterogeneous actors, including terminals, vehicles, and traffic systems. In addition, blockchain-based components are included as part of the architectural layer that is responsible for trusted data sharing, access control, and auditability among independent stakeholders. These elements reflect the realities of multi-actor logistics ecosystems, where coordination depends not only on optimization logic but also on data integrity and institutional trust.

It is important to note that blockchain mechanisms are treated as architectural enablers rather than performance drivers in this study. No blockchain protocols, consensus mechanisms, or transaction processes are instantiated or simulated. Instead, blockchain is represented abstractly as a governance layer that enables reliable information exchange across organizational boundaries. The simulation therefore focuses on the effects of coordinated decision-making under the assumption that required information is available through trusted interfaces, rather than on the technical performance of blockchain technologies themselves.

Accordingly, the scope of the experimental evaluation is limited to the coordination logic that is implemented by the orchestration layer and its impact on system-level performance. The physical infrastructure, sensing availability, and governance mechanisms are assumed to be in place and operational. This scoping choice allows the study to isolate the effects of coordinated control on key performance indicators while remaining consistent with realistic digital infrastructure assumptions discussed in the port and urban logistics literature.

The reference architecture was developed as a design synthesis of recurring requirements identified in prior work on port operations, urban freight management, and digital-twin-enabled logistics coordination. Three considerations guided its composition. First, end-to-end coordination across the port–city chain requires a common control point that is capable of observing cross-domain bottlenecks and aligning actions across subsystems that are typically optimized independently; this motivated the explicit orchestration layer. Second, the architecture is organized as modular domain blocks (maritime interface, terminal and gate operations, intermediate consolidation, and urban distribution) to reflect the operational reality that each block can be modeled, instrumented, and upgraded independently while still contributing to shared system-level objectives. Third, because port–city logistics is inherently multi-stakeholder, the architecture includes governance-oriented digital infrastructure for trusted information sharing and auditability; blockchain is included in this role to represent integrity and access control mechanisms across organizational boundaries, even though blockchain protocols are not instantiated in the present simulation.

Overall, the architecture is intended to be general-purpose and interoperable: it specifies functional interfaces and information dependencies that enable simulation-based evaluation of coordinated control policies while remaining compatible with heterogeneous implementation choices in real deployments.

Table 1. Mapping between reference architecture components and their representation in the simulation.

Reference Architecture Component	Representation in Simulation	Scope and Notes
Autonomous maritime vessels	Abstracted	Vessel arrivals are represented implicitly through container availability at the port interface. Detailed vessel navigation, autonomy, and berth-level decision-making are outside the scope of the present simulation and are addressed in complementary work on autonomous maritime logistics.
Smart port and terminal operations	Implemented	Terminal handling processes, gate operations, crane allocation, and capacity constraints are explicitly modeled. These elements form the core interface between maritime arrivals and hinterland transport.
Central warehouse/consolidation hub	Implemented	The warehouse is modeled as an intermediate buffer between port and urban logistics, enabling consolidation, temporary storage, and controlled release of containers toward city distribution.
Multimodal urban logistics network	Partially implemented	Urban freight transport is represented through road-based truck movements interacting with capacity-limited distribution processes. Detailed passenger traffic dynamics and signal-level urban control are abstracted.
Adaptive AI traffic control	Abstracted	Traffic control effects are represented indirectly through capacity constraints, travel time penalties, and queue dynamics rather than explicit signal phase modeling.
Cloud-based orchestration layer	Implemented	The orchestrator is instantiated as a centralized control policy that observes global system state and coordinates decisions across port, warehouse, and urban domains at each simulation step.
Federated sensing and data collection	Abstracted	State information (queues, capacities, resource utilization) is assumed to be available to the orchestrator through idealized sensing interfaces. Sensor failures and communication delays are not modeled.
Blockchain-based governance layer	Conceptual only	Blockchain is included in the reference architecture to represent trusted data sharing, access control, and auditability among stakeholders. No blockchain protocols or transaction mechanisms are instantiated or simulated.
Digital twin environment	Implemented (simulation-level)	The simulation serves as a functional digital twin for evaluating coordination policies under controlled conditions. High-fidelity physical modeling and real-time synchronization with operational systems are outside the scope.

Detailed modeling of autonomous maritime operations and their integration with downstream logistics is discussed in related work [7] and is not repeated here.

summarizes how the components of the reference architecture map to the elements instantiated in the simulation.

2.2. Simulation-Based Experimental Setup

A controlled, simulation-based evaluation was conducted to assess an AI framework that coordinates port and urban logistics through a centralized orchestrator. The experiment compares two policies under matched stochastic conditions: (i) a baseline run that uses the model’s native scheduler, and (ii) an AI-orchestrated run that applies a capacity-aware coordination policy at every simulation step. Each pair of runs shares the same random seed so that observed differences in key performance indicators (KPIs) can be attributed to the control policy rather than to random variation. The study reports per-run KPIs, aggregated statistics across repeated trials, and per-step logs of orchestration decisions.

All code, configuration files, and experiment scripts are publicly available at https://github.com/mapenthusiast/frameworksim (accessed on 19 December 2025). The repository contains the simulation engine, experiment harness, and utilities for exporting KPIs and computing statistics. Simulation runs are deterministic given a fixed random seed, which is explicitly set by the experiment driver. A Jupyter notebook provided in the repository is used to configure and execute experiments under different scenarios. Configuration flags control the number of paired runs, the initial random seed, scenario size, a hard cap on simulation steps, and output naming. All outputs are written to the data/directory.

2.2.1. Simulation Environment and System Representation

The simulation engine is implemented as a discrete-time transport model representing the flow of standardized containers from a marine terminal through a central warehouse toward urban distribution. It advances in discrete time steps and models the flow of standardized containers from a marine terminal through a central warehouse toward city distribution. The model includes autonomous agents representing containers, trucks, and quay or yard cranes. The simulation supports two execution modes within the experiment harness. In the baseline mode, the model advances using its native scheduler only, with agents acting independently and without any external coordination. In the orchestrated mode, the simulation advances step-wise, and after each step, a centralized capacity-aware orchestrator computes and applies coordinated assignments for trucks, cranes, and staging resources, augmenting the native agent behavior. Both modes operate on identical system dynamics and stochastic inputs; the only difference between them is the presence or absence of the orchestration layer.

State variables track the location and status of each agent, resource capacities, and queues at operational bottlenecks. The built-in scheduler implements standard rules for gate releases, truck dispatch, and crane allocation. These rules provide a realistic reference baseline for terminal-to-hinterland operations under capacity constraints.

Table 2. Simulation parameters and scenario scale.

Category	Parameter	Value/Description	Notes and Justification
Simulation paradigm	Time advancement	Discrete time steps	Enables synchronized coordination decisions and reproducible paired-run evaluation.
	Simulation horizon	max_steps (user-defined cap)	Upper bound prevents unbounded runs; simulations terminate earlier if all containers are delivered.
Scenario generation	Scenario type	Synthetic	Synthetic scenarios allow for controlled experimentation and isolation of coordination effects without dependence on proprietary operational data.
	Randomness control	Explicit random seed	Identical seeds are used for paired baseline and orchestrated runs to ensure comparability.
Scale parameters	Number of containers	Scenario-dependent (configurable)	Container volume is defined by scenario configuration files in the repository.
	Number of trucks	Scenario-dependent (configurable)	Truck fleet size is fixed per scenario and held constant across paired runs.
	Number of cranes	Scenario-dependent (configurable)	Crane resources constrain terminal throughput and interact with orchestrator decisions.
System representation	Logistics stages	Port → warehouse → urban distribution	Represents a simplified but end-to-end port–city logistics chain.
	Spatial modeling	Abstracted	Explicit geographic distances are not modeled; travel times and congestion effects are represented through capacity limits and queue dynamics.
Queue modeling	Queue type	Capacity-limited FIFO queues	Applied at gates, cranes, and warehouse interfaces to represent operational bottlenecks.
	Service logic	Rule-based	Service rates are constrained by available resources and scheduling rules.
Control execution	Baseline policy	Built-in scheduler	Represents conventional, subsystem-level scheduling without cross-domain coordination.
	Orchestrated policy	Capacity-aware rule-based controller	Coordinates gate releases, container-to-truck assignment, and resource allocation.
Stochastic elements	Source of stochasticity	Arrival order, processing times (seeded)	All stochastic elements are governed by the random seed to ensure determinism under repetition.
Outputs	KPIs exported	Delay, throughput, resource utilization, emissions proxies (if enabled)	KPIs are written to CSV files for each run and aggregated post-simulation.
Repetitions	Number of paired runs	20	Selected to balance statistical robustness with computational cost; paired design reduces variance across comparisons.

summarizes the main simulation parameters and scenario characteristics used in the evaluation.

2.2.2. AI-Orchestrated Control Policy

The AI-orchestrated control policy is implemented as a deterministic, rule-based decision process that executes once per simulation time step. Its purpose is to replace isolated, subsystem-level scheduling with coordinated actions informed by global system state. Algorithm 1 summarizes the capacity-aware decision logic executed by the orchestrator at each simulation step. The orchestrator observes current resource utilization and demand conditions, identifies capacity bottlenecks, and applies a hierarchy of coordination rules governing gate releases, container–truck assignments, and crane allocation. All decisions are derived from observable state variables and predefined constraints rather than from learned models, enabling transparent attribution of performance effects. The orchestrator is implemented as a rule-based, capacity-aware decision layer, serving as an AI-ready control scaffold rather than a trained learning model. This choice reflects the absence of real-world operational data in a simulation-only setting and allows the framework to accommodate learning-based controllers in future deployments.

Algorithm 1: Rule-based capacity-aware orchestration logic, in pseudocode

function orchestrate(port_state, demand_forecast, constraints, policies):   # (1) Observe current state   vessels = port_state.vessels   containers = port_state.containers   trucks = port_state.trucks   cranes = port_state.cranes   yard = port_state.yard   time_now = port_state.clock   # (2) Compute bottlenecks (capacity vs. load)   quay_capacity = cranes.available_quay_capacity()   gate_capacity = trucks.available_gate_capacity()   yard_capacity = yard.free_slots()   dwell_risk = yard.estimate_dwell_risk(containers)   bottlenecks = detect_bottlenecks(quay_capacity, gate_capacity, yard_capacity, dwell_risk)   # (3) Apply gate throttling rule (smooth arrivals if gate is a bottleneck)   if bottlenecks.includes("gate") or dwell_risk.high():     gate_release_rate = policies.gate.smoothing_rate (time_now, demand_forecast)   else:     gate_release_rate = policies.gate.max_rate   trucks_to_release = select_trucks (trucks.waiting, gate_release_rate)   # (4) Assign containers to trucks given constraints   # Constraints: time windows, weight, pairing with destination, customs hold, FIFO/priority   feasible_pairs = []   for c in containers.ready_for_gate():     for t in trucks_to_release:       if is_feasible(c, t, constraints.truck):         score = score_assignment(c, t, policies.priorities)         feasible_pairs.append((score, c, t))   assignments_trucks = greedy_match(feasible_pairs, objective = "maximize priority + throughput")   # (5) Allocate cranes given utilization (balance load across quay cranes)   crane_jobs = []   for v in vessels:     if v.has_pending_moves():       job_size = v.next_batch_size()       if cranes.has_available_quay():         chosen_crane = select_crane(v, cranes, objective = "balance_utilization")         crane_jobs.append((chosen_crane, v, job_size))   apply_crane_allocations(crane_jobs)   # (6) Enforce feasibility constraints   # - Skip assignment if a truck has already been assigned in the current step   # - Assign a truck only if container.state == "unloaded" and both are co-located   # - Assign a crane only if crane.state == "idle" and container.state ∈ {"in_port", "at_port"}   # - No global conflict detection or post-hoc repair is performed   # (7) Commit actions and log   dispatch_trucks(assignments_trucks)   dispatch_cranes(crane_jobs)   log_plan(time_now, bottlenecks, gate_release_rate, assignments_trucks, crane_jobs, feasibility_checks)   # (8) Next step (advance simulation clock/reschedule)   port_state.advance_clock(policies.simulation_step)   return port_state

The orchestrated controller is implemented in scripts/ai_orchestrator.py as CapacityConstrainedOrchestrator. At each simulation step, the orchestrator receives the current model state, computes actions with decide(), and applies them through apply_actions(). The controller enforces resource and capacity constraints and coordinates decisions such as container-to-vehicle assignment, gate throttling, and equipment allocation. In the present study, the policy is rules-based and capacity-aware, which allows for transparent ablation against the baseline. The class and the driver are designed so that learning policies, for example reinforcement learning, can be swapped in without changing the experimental protocol.

The container–truck assignment step selects dispatch matches from the set of feasible container–truck pairings that satisfy operational constraints such as compatibility rules, holds, and priority restrictions. In the evaluated implementation, assignments are computed using a fast greedy heuristic: feasible pairs are scored using a combined priority-and-throughput objective, sorted in descending order, and selected sequentially while enforcing one-to-one matching between containers and trucks within each simulation step. This approach is computationally lightweight and supports step-wise orchestration under repeated simulation. An exact formulation, based on mixed-integer programming, is conceptually compatible with the same interface and is left for future work. Figure 2 illustrates the closed-loop control structure of the orchestrator and its repeated execution across simulation steps.

The driver script scripts/run_experiments.py creates paired runs for each seed: a baseline simulation and an orchestrated one. The orchestrated run writes a per-decision NDJSON log that records sim_step, decision_time_s (wall-clock time for decide plus apply), the actions payload, the applied result, and wall_time. To ensure isolation between runs, the log file is opened in truncate mode at the start of each orchestrated run.

All runs stop when the model signals completion or when max_steps is reached. Per-run KPIs are exported via model.kpis.export(...). The exact CSV tables are documented in the repository and include, at minimum, measures of delay and throughput, together with counts or utilization rates of key resources. If available in the configured model, emissions proxies are exported from time-in-state summaries.

A per-run summary row is appended to data/experiment_summary.csv with the following fields: policy, seed, final_step, finished, num_containers, num_trucks, num_cranes, kpi_prefix, and for orchestrated runs ai_log.

After all runs are complete, the driver aggregates KPIs and computes descriptive statistics (mean and standard deviation) by policy. When SciPy is available, an optional paired t-test is applied to the pairwise results to assess differences in means. The analysis script preserves the random seeds and the file prefixes so that each statistic can be traced back to the underlying run and its exported KPIs.

2.2.3. Experimental Design and Performance Indicators

To replicate the results, the following steps can be performed: clone the repository and create the documented Python environment (Python 3.13.5 version was used during the simulation); run the experiment command from the notebook with the reported parameters; run the inspection code over data/experiment_summary.csv for run-level outcomes; use the per-run KPI CSVs and the NDJSON action logs to reproduce tables and figures; and verify determinism by repeating a run with the same seed and parameters.

The evaluation uses synthetic scenarios generated by the simulation. No third-party operational data are required to execute the experiments as presented. The key performance indicators (KPIs) used in the evaluation are detailed in

Table 3. Key performance indicators used in the evaluation.

Name	Definition	Unit
Throughput	Number of containers completed (delivered or unloaded) per simulation run or per time unit	containers/run or containers/step
Cycle time	Average time from container arrival to completion	simulation steps
Crane utilization	Fraction of time cranes are actively unloading relative to total available time	percent
Truck utilization	Fraction of time trucks are loading, in transit, or unloading relative to idle time	percent
Gate flow	Number of containers released through the gate per unit time	containers/step
Dwell time	Time containers spend in port or yard before completion	simulation steps
Crane queue length	Average and peak number of containers waiting for crane service	containers
Gate/truck queue length	Average and peak number of containers waiting for truck pickup	containers
Crane idle time	Total idle time accumulated by cranes	simulation steps
Truck idle time	Total idle time accumulated by trucks	simulation steps
Missed SLA/late pickups	Number or share of containers exceeding a dwell-time or cutoff threshold	count or percent

.

All KPI CSV files, experiment summaries, and decision logs produced for the paper are available in the repository, except for large files, which are excluded due to size limits. These files are available upon request.

Emissions are approximated using a simplified idle time proxy of the form idle time × emission rate per simulation step. This proxy assumes a linear relationship between time spent idling and tailpipe emissions and applies a constant per-step emission factor. The purpose of this approximation is not to produce an absolute emissions inventory, but to provide a coarse, comparative indicator of how different control policies affect idle-related inefficiencies under identical operating conditions.

Because the proxy aggregates idle time independently of spatial routing, vehicle load, or transient driving behavior, it can exhibit counterintuitive behavior at the level of individual runs, particularly when a policy substantially accelerates system convergence. In such cases, idle periods may be temporally concentrated into a shorter simulation horizon, which can increase the cumulative proxy value, even as the total completion time and resource idle durations decrease. For this reason, emissions-related results are interpreted only in relative terms and across paired runs, rather than as definitive estimates of real-world environmental impact.

Accordingly, emissions outcomes in this study should be understood as indicative of directional trends in idle-related efficiency rather than precise measures of energy use or greenhouse gas output. More detailed emissions modeling, incorporating vehicle dynamics, routing, and technology heterogeneity, is left to future work and does not affect the validity of the primary coordination-related findings reported here.

The evaluation uses 20 paired simulation runs to reduce variance and improve sensitivity to policy effects. Each orchestrated run is paired with a baseline run executed under the same random seed, ensuring that observed differences reflect the intervention rather than stochastic variation. Statistical analysis is performed on within-pair differences using descriptive statistics and a paired t-test. In plain terms, the paired test assesses whether the average difference between paired outcomes is likely to reflect a systematic effect rather than random variation. Descriptive results are emphasized and statistical tests are used as a complementary tool rather than a substitute for substantive interpretation.

3. Results

This section reports the outcomes of the simulation-based evaluation described in Section 2. Performance is assessed primarily using the final simulation step, defined as the number of discrete time steps that are required to complete all container movements from port arrival to urban delivery under a given control policy. Because each simulation step corresponds to a synchronized decision–execution cycle involving gate releases, vehicle dispatching, and resource allocation, a lower final step indicates faster system-wide convergence under identical physical and demand conditions.

3.1. Throughput Dynamics

Figure 3 presents the cumulative number of containers completed over the simulation time for a representative paired run under the baseline and orchestrated policies. The orchestrated policy consistently completes container movements more quickly, as indicated by its steeper cumulative curve. In this example, the orchestrated policy completes all container movements by collection index 26, whereas the baseline policy requires over 50 steps to reach the same cumulative throughput. This result highlights the AI framework’s ability to accelerate system throughput by coordinating loading, transport, and distribution decisions guided by a capacity-aware logic.

The collection index denotes sequential aggregation points corresponding to simulation steps. The steeper slope of the orchestrated curve indicates faster system-wide throughput under coordinated control. This visualization illustrates how coordinated decision-making accelerates container flow by aligning gate operations, truck dispatching, and crane allocation in response to capacity constraints.

3.2. Completion Time Across Paired Runs

The final step (defined as simulation steps to completion) was collected across all 20 paired runs. The orchestrated policy achieved a mean final step of 264, in contrast to the baseline’s 513 steps. The deterministic behavior observed per seed further underscores the robustness and repeatability of the AI framework’s control dynamics.

Because runs are paired using random seeds, differences were analyzed on a per-pair basis. The distribution of paired differences shows consistently lower completion times for the orchestrated policy across all seeds, indicating that the observed improvement is not driven by stochastic variation in individual scenarios. A paired t-test confirms that the reduction in completion steps is statistically significant (p < 0.01), and the mean paired difference is accompanied by a narrow confidence interval, underscoring the robustness of the effect.

For the representative paired run corresponding to seed 19, the baseline policy completes all container movements after 513 simulation steps, whereas the orchestrated policy converges after 260 steps, corresponding to a 49% reduction in system-wide completion time under identical conditions. The mean container completion time decreases from 264 to 139.5 steps, indicating not only faster convergence but also a compression of the delivery timeline across containers. Resource utilization metrics show consistent improvements: the mean truck idle time is reduced by approximately 66%, and the mean vessel idle time is reduced by 50%, reflecting improved synchronization between terminal operations and downstream transport. These paired differences, as highlighted in

Table 4. Paired KPI comparison for seed 19.

KPI	Baseline (Seed 19)	Orchestrated (Seed 19)	Paired Difference (Orch − Base)	Relative Change
Final completion step	513.0	260.0	−253.0	−49.3%
Mean container completion time (steps)	264.0	139.5	−124.5	−47.2%
Mean truck idle time (steps)	194.28	66.48	−127.80	−65.8%
Mean vessel idle time (steps)	259.45	129.70	−129.75	−50.0%
Mean idle time emissions proxy	1.70	3.33	+1.63	+95.8%

, confirm that the gains observed at the aggregate level are already evident in individual scenario realizations and are not driven by stochastic outliers. The idle-time-based emissions proxy should be interpreted cautiously at the single-run level, as faster convergence can concentrate idle periods into shorter horizons, affecting cumulative proxy values despite overall efficiency gains; aggregate trends across paired runs provide a more reliable indicator.

Importantly, the deterministic behavior observed for each seed reinforces the repeatability of the results: for a given scenario realization, the orchestrated policy consistently converges faster than the baseline.

3.3. Secondary Performance Indicators

In addition to time savings, the orchestrated policy demonstrates superior performance across all tracked KPIs:

• Truck idle time was significantly reduced due to better alignment of container dispatching and vehicle movement, improving fleet utilization.
• Estimated emissions decreased, as fewer simulation steps and idle periods were required to complete container delivery cycles.
• Container completion times were lower and more tightly clustered, indicating improved predictability and system reliability.
• Crane and gate utilization showed smoother load curves with less congestion and wait time under the AI policy.

These improvements were consistently observed across all 20 paired runs, reinforcing the robustness of the results and the system-wide benefits of AI-driven logistics coordination.

3.4. Interpretation

The results suggest that the AI orchestrator substantially improves logistics coordination, cutting completion times by nearly half. This gain is achieved without altering physical constraints (the number of trucks, cranes, or containers is the same), indicating that smarter decision-making alone can unlock major efficiency improvements. While the baseline policy follows standard scheduling logic, the AI orchestrator dynamically adapts to congestion and capacity conditions at each step, reducing idle time and improving resource utilization.

These findings validate the working assumption of the study: that an AI-based control layer can significantly outperform traditional dispatch and scheduling policies, even in complex, capacity-constrained logistics systems. By integrating decision logic across port and urban layers, the AI policy achieves faster system-wide convergence and lower latency in freight delivery.

While the results demonstrate substantial performance improvements under coordinated control, they should be interpreted in light of the model’s abstraction level. The simulation does not explicitly represent several real-world constraints, including detailed maritime arrival uncertainty, heterogeneous vehicle fleets, human operational behavior, labor availability, regulatory restrictions, and fine-grained urban traffic dynamics. In addition, sensing and communication are assumed to be reliable and instantaneous, and the emissions proxy used provides only a coarse, directional indicator rather than an absolute environmental assessment. As a result, the magnitude of the observed improvements should not be interpreted as a direct forecast of real-world gains. Instead, the results indicate the potential efficiency that can be unlocked by cross-domain coordination under controlled conditions, establishing an upper-bound benchmark and a motivation for future studies that integrate richer physical, institutional, and behavioral constraints.

4. Discussion

The simulation tested the working expectation that an AI control layer coordinating decisions across the port–city chain would outperform a traditional scheduler. The results support this expectation. Across 20 paired runs with identical seeds, the orchestrated policy completed the process in about half the simulated time compared with the baseline and delivered consistent gains in all tracked KPIs, including cumulative throughput, truck idle time, and container completion times, with corresponding reductions in estimated emissions. These effects are large and repeatable and arise without changing any physical capacities. The improvement comes from synchronizing actions that are usually decided locally, such as gate releases, equipment assignment, and truck dispatch. By removing avoidable waiting and pacing flows between terminal, warehouse, and city network better, the orchestrator reduces congestion formation and keeps resources productive.

These findings are consistent with recent studies that treat ports and cities as digitally connected systems rather than separate infrastructures. Prior work has shown benefits from AI at individual layers, such as reinforcement learning for urban traffic control [14] or machine learning for port demand prediction [2], but end-to-end evaluations remain rare. These results add evidence that when the control layer is aligned across layers, the benefits are substantial. Coordinated decisions upstream shorten bottleneck queues downstream, and the whole system converges faster. This is in line with the view that shared digital infrastructure and governance are needed for port–city integration and that agent-based simulation is a suitable vehicle for de-risking such interventions before deployment.

The results also speak to practical questions for port authorities and city agencies. First, measurable gains were achieved with a transparent, capacity-aware policy. This lowers the barrier for adoption, since the policy is auditable and can be tuned with operational rules. Second, the per-step decision logs provide traceability from individual actions to system-level outcomes. This addresses a common concern in multi-stakeholder environments, where accountability and the ability to explain interventions are important. Third, improvements in emissions proxies and idle time suggest that coordination can advance sustainability targets without new infrastructure, which is relevant for cities that face space and budget constraints.

Several limitations impact the interpretation. The simulation uses synthetic scenarios and fixed capacities. Disturbances such as weather, labor variability, unplanned incidents, and demand shocks were not modeled. Emissions were estimated from operational states rather than measured with full physics-based models. The orchestrator used rule-based logic. This choice improves interpretability but may understate the potential of learning controllers in more turbulent settings. Finally, the experiment optimized a single objective at a time. Real deployments balance multiple goals, including port throughput, urban delay, reliability for time-critical flows, and equity impacts across neighborhoods.

These limitations point to clear directions for future research. First, research could couple the orchestrator with learning methods that adapt to non-stationary conditions while enforcing safety and capacity constraints. Second, it can run co-simulations that integrate detailed maritime arrival processes, terminal yard dynamics, and city traffic assignment to study how schedule uncertainty propagates from ship to intersection. Third, it can embed richer environmental models and energy use to quantify air quality and greenhouse gas outcomes more faithfully. Fourth, future research could focus on evaluation of governance and data-sharing designs in the loop, for example by simulating limited data visibility or delayed information to test how data spaces and interface standards affect performance. Fifth, the KPI set can be extended to include reliability metrics, access impacts on surrounding neighborhoods, and cost-to-serve for carriers. Finally, field pilots can be planned that start with narrow corridors or peak-hour windows, using the decision logs and KPI definitions from this study to support monitoring and audit.

The simulation demonstrates that an AI-based control layer aligned across port and city subsystems can deliver large, system-level improvements that are visible in both operational and environmental indicators. Accordingly, the contribution of this work lies not in the training of a learning-based AI model, but in the definition and validation of an orchestration layer that is structurally compatible with future data-driven and learning-based extensions.

The work provides a replicable pathway from concept to evidence by linking a general framework, a simulation implementation, and auditable outputs. With further development in learning policies, uncertainty modeling, and data governance, the same approach can be extended to real corridors and scaled to full port–city ecosystems.

5. Conclusions

This study proposed and evaluated an AI-based framework for integrated urban logistics that connects autonomous maritime transport, intelligent ports, centralized warehousing, and multimodal urban distribution under a shared cloud orchestration layer. The architecture was designed to support continuous monitoring, cross-domain coordination, and operational decision-making across the full port-to-city logistics chain.

To assess its impact, a modular simulation environment was implemented to compare two policies: a conventional built-in scheduler and a centralized orchestrator guided by capacity-aware logic. Across 20 paired runs, the orchestrated policy outperformed the baseline in all key performance indicators. It reduced system completion time by nearly 50%, improved container throughput, minimized truck idle time, and lowered estimated emissions (without changes to physical infrastructure).

These results validate the premise that coordinated AI decision-making across traditionally siloed logistics domains can unlock significant performance and sustainability gains. By aligning upstream and downstream flows, the proposed framework demonstrates how ports and cities can operate as a digitally integrated system. Future work will extend the framework to learning-based control, more realistic disturbances, and richer environmental and equity indicators, with the goal of supporting real-world deployment in port–city corridors.