The study integrates four heterogeneous data sources to capture comprehensive vessel operational dynamics.

A rigorous temporal synchronization framework was established using MRV reporting timestamps (denoted as $t_{mrv}$) as primary temporal anchors. AIS position records underwent timezone normalization through removal of UTC offset metadata, with both datasets standardized to Beijing Time (UTC+8). For each vessel (identified by unique MMSI-derived vessel codes), AIS position logs were segmented into voyage periods through dynamic temporal mapping to MRV checkpoints.

A multi-stage alignment protocol was implemented: First, coarse alignment was achieved by joining datasets on calendar date correspondence. Subsequently, fine-grained temporal matching identified the nearest AIS position to each MRV report within a ±30-minute tolerance window ( $\Delta t$ ≤ 1800 seconds), designating these as temporal checkpoints. Consecutive checkpoints were validated to ensure temporal spacing within the 23 - 25 hours range, maintaining alignment with MRV daily reporting cycles.

Voyage segmentation was then performed by partitioning AIS trajectories at checkpoint boundaries, generating chronologically ordered voyage sequences where each segment represented vessel operations between successive MRV reports. This bidirectional temporal validation ensured that: (1) each MRV report corresponded to precisely positioned AIS observations, and (2) voyage durations consistently reflected 24-hour operational cycles. The protocol achieved temporal coherence while accommodating natural variations in reporting schedules and vessel operational patterns.

The feature engineering module systematically transforms raw vessel operational data into multidimensional feature representations through statistical aggregation. This process distills high-frequency AIS records into voyage-level signatures capturing operational patterns, environmental interactions, and vessel states. Key transformations include:

The framework employs a vessel-type-specific parallel processing architecture, generating distinct feature matrices for each vessel category. The transformation follows:

$F=\left\{{\varphi }_k\left(f_i\right)|\forall f_j\in D_{raw},{\varphi }_k\in \Phi \right\}$

where $\Phi$ represents the statistical operator set {mean, std, Q1, Q3, min, max, mode} applied to raw features $D_{raw}$.

Beyond fundamental metrics, advanced derived features provide critical insights into environmental-vessel dynamics:

A multi-stage validation protocol enforces physical plausibility through domain-informed anomaly detection mechanisms.

Speed plausibility constraints maintain operational realism by requiring ${\text{Speed}}_{\text{actual}}<1.2{\text{V}}_{\text{ref}}$, where ${\text{V}}_{\text{ref}}$ represents vessel-specific reference speeds derived from design specifications. The 20% tolerance buffer aligns with standard maritime engineering practices, as operational speeds typically vary within ±20% of design speed to account for favorable currents, wind assistance, or minor fouling effects, as supported by industry guidelines such as ITTC Recommended Procedures. This threshold filters unrealistic speed values that violate hydrodynamic principles while accommodating real-world variability.

Distance agreement validation reconciles discrepancies between AIS-derived distances ( ${\text{D}}_{\text{AIS}}$) and MRV-reported values ( ${\text{D}}_{\text{MRV}}$) through dual-threshold criteria: absolute differences under 2 nautical miles or relative differences below 5%

( $\left|{\text{D}}_{\text{AIS}}-{\text{D}}_{\text{MRV}}\right|<2$ or $\frac{\left|{\text{D}}_{\text{AIS}}-{\text{D}}_{\text{MRV}}\right|}{{\text{D}}_{\text{MRV}}}\le 0.05$). These thresholds reflect common

navigational tolerances, as AIS-GPS accuracy is typically within 1 - 2 nautical miles for daily segments, and MRV reporting allows for minor discrepancies due to manual logging or route deviations, consistent with EU MRV Regulation 2015/757 guidelines.

Daily fuel consumption (daily_fuel_mrv) was summed from component fuels (HFO/LFO/DOGO). Fuel efficiency (tonnes/100 nautical miles) was computed iteratively from cumulative distance (>25 NM thresholds) and consumption.

Emission efficiency validation establishes an upper bound for fuel consumption

intensity with ${\text{EMI}}_{\text{mile}}=\frac{{\text{EMI}}_{\text{HFO}}}{{\text{D}}_{\text{daily}}}<1$, eliminating records showing implausibly

high fuel consumption per nautical mile.

The engine consistency verification ensures propulsion system validity by enforcing operational constraints derived from marine engineering principles, preventing physically impossible scenarios where reported engine parameters violate fundamental mechanical limits. The validation mechanism is systematically examined as follow.

Raw ${\text{RPM}}_{\text{MRV}}$ values were constrained by hydrodynamic principles. The hydrodynamic baseline is derived from screw pitch ( $p$) and vessel design parameters, representing the theoretical rotational speed required for 2-knot speed in calm water:

$RP{M}_{threshold}=\frac{2\times 1852}{60\times p}$

where 1852 converts nautical miles to metres. Reported ${\text{RPM}}_{\text{MRV}}$ is rectified through a segmented regime as shown in the following formula. This ensures compliance with propeller cavitation limits and engine safety margins.

${\text{RPM}}_{\text{corrected}}=\{\begin{array}{c}0,RPM\le {\text{RPM}}_{\text{threshold}},\\ {\text{RPM}}_{\text{min}},{\text{RPM}}_{\text{threshold}}<RPM<{\text{RPM}}_{\text{min}},\\ {\text{RPM}}_{\text{MRV}},{\text{RPM}}_{\text{min}}\le RPM\le {\text{RPM}}_{\text{max}},\\ {\text{RPM}}_{\text{max}},RPM>{\text{RPM}}_{\text{max}}.\end{array}$

Whenever the corrected RPM equals zero, the vessel is assumed to be drifting or at anchor. Hence the effective sailing time is:

$T_{corrected}=\{\begin{array}{c}0,if{\text{RPM}}_{\text{corrected}}=0,\\ T_{raw},otherwise.\end{array}$

with $\text{T}$ denoting the reported duration between consecutive MRV checkpoints (h).

The expected distance under the corrected operational state is computed as follow:

$D_{new}=\frac{{\text{RPM}}_{\text{corrected}}\text{P}\times 60T_{corrected}}{1852\times 3600}$

Next, the final corrected distance $D_{corrected}$ is determined by comparing $D_{new}$with the MRV-reported value $D$ ( Table 1 ).

The final dataset comprised 20130 daily records (2022-2023) stratified by vessel type. Features were categorized hierarchically ( Table 2 ):

Data quality was enforced through:

To address the heterogeneous noise characteristics of maritime telemetry, the framework simultaneously trains LightGBM models with L1 regularization (median) and L2 regularization (mean) to predict vessel RPM. LGBM is selected due to its efficiency in handling heterogeneous maritime features, including temporal, spatial, and operational variables. The model employs Gradient Boosted Decision Trees (GBDT), which iteratively construct an ensemble of weak learners (shallow trees) to minimize a differentiable loss function.

LightGBM’s ability to capture nonlinear interactions stems from its decision tree ensemble structure, which recursively partitions the feature space based on conditional dependencies. Unlike linear models (e.g., MLR), where interactions must be manually specified (e.g., via polynomial terms), LGBM automatically learns these relationships through hierarchical feature splitting.

For a given input feature vector x, the predicted RPM $\hat{y}$ is obtained through an additive model of M regression trees:

$\hat{y}=\underset{m=1}{\overset{M}{{\displaystyle \sum }}}{f}_m\left(x\right),f_m\in F$

where $f_m$ represents a decision tree and $F$ is the space of all possible trees.

Each decision tree in LGBM splits features sequentially, with earlier splits dominating the prediction. For example, a tree might first split on ASOW (adjusted speed over water) calculated by adjusting the vessel’s Speed Over Ground (SOG) to account for current effects, then on Cb (block coefficient) and distance, and finally on relative wind/wave/stream direction, as shown in Figure 1 .

This hierarchy mirrors physical intuition:

Mathematically, this can be represented as a nested nonlinear function:

$\begin{array}{c}RPM=f1\left(ASOW\right)+f2\left(ASOW,Cb,distance\right)\\ +f3\left(ASOW,Cb,distance,wind,wave,stream\right)+ϵ\end{array}$

$ASOW=SOG-V_{current}$

where $f1$, $f2$, $f3$ are submodels learned by the tree ensemble, and $V_{current}$represents the current velocity vector component in the direction of vessel movement.

LGBM_Mean optimizes for mean squared error (MSE) loss, minimizing deviations between predicted and observed RPM values. This model is sensitive to outliers but provides a central tendency estimate aligned with physical RPM expectations. In contrast, LGBM_Median uses quantile regression (alpha = 0.5) to reduce outlier influence, enhancing robustness against outliers prevalent in noisy maritime data. The final prediction is derived from the arithmetic mean of both models, balancing robustness and precision. This simple averaging approach was chosen over other ensemble techniques, such as stacking or weighted averaging, due to its computational efficiency and effectiveness in maritime contexts, where data noise is significant but systematic biases are minimal. Stacking requires additional meta-model training, increasing complexity without substantial accuracy gains given the complementary strengths of L1 and L2 regularization. Weighted averaging was considered but deemed unnecessary, as empirical tests showed equal weighting adequately captured the trade-off between outlier resilience and predictive precision for RPM forecasting.

The model’s performance is governed by the following hyper-parameters ( Table 3 ), tuned via Bayesian optimization, ensuring adaptability across vessel types.

Categorical features (e.g., vessel type) are embedded as category dtype in LGBM. Temporal features (e.g., timestamps) are decomposed into cyclical components to capture seasonal patterns. Training data is partitioned chronologically to prevent leakage, with 80% for training and 20% for validation.

LGBM models are implemented using the LightGBM framework, with early stopping (patience = 50) to prevent overfitting. All computations are executed in a Dockerized environment to ensure reproducibility, with model weights serialized for operational deployment.

The necessary steps and processes to develop the physics-informed LightGBM framework for ship RPM prediction are presented in Figure 2 .