Abstract

Reliable evaluation of ship-maneuvering controllers requires more than a dynamically plausible vessel trajectory. For example the maneuvering model, geographically defined scenario, controller interface, and performance evidence must be connected through a reproducible workflow. This study develops a geographically referenced simulator that integrates a Maneuvering Modeling Group (MMG) representation of the full-scale and L7 KVLCC2 model with waypoint guidance, heading and speed control, synchronized data logging, and post-run assessment for an archived route segment in the İstanbul Strait. A dual-loop proportional-integral-derivative (PID) controller, a fuzzy-logic controller, and a neural-network controller are implemented through a common heading-control interface. The recorded signals are evaluated using peak overshoot, median settling time, heading root-mean-square error, rudder-saturation ratio, and maximum speed-loss ratio, with user-defined PASS/WARN/FAIL thresholds. Model-scale and full-scale cases demonstrate the end-to-end route, control, MMG state-propagation, visualization, and diagnostic chain and expose controller-dependent differences in transient response and actuator use. The main contribution is therefore a traceable experimental environment for implementing and examining alternative ship-control strategies within geographically meaningful scenarios.

1. Introduction

Reliable ship maneuvering is central to safe and efficient operation in ports, narrow channels, and congested waterways, where small heading errors or delayed actuator responses can compromise route keeping and increase rudder activity and speed loss. The problem is consequential for a transport system that carries more than 80% of international trade by volume [1]. The broader economic role of maritime transport is also extensively discussed in maritime economics literature [2]. Additionally, shipping also accounted for 2.89% of global anthropogenic CO₂ emissions in 2018 [3]. Although a simulator alone cannot establish an environmental benefit, this scale motivates methods that support safer and more efficient controller development. From a control perspective, the difficulty arises from nonlinear, strongly coupled surge-sway-yaw dynamics, actuator constraints, and environmental loads. Controller development must therefore be supported by evidence that is physically meaningful, repeatable, and directly related to operational performance.

Physical model experiments and sea trials are still essential for validating maneuvering predictions. However, their high cost, safety requirements, and limited repeatability make them impractical at every stage of controller development. Numerical simulation offers a useful intermediate step, allowing control laws to be implemented, tested under challenging conditions, and compared before moving to physical trials [4]. Nevertheless, the strength of simulation-based evidence depends on the accuracy of the maneuvering equations, hydrodynamic coefficients, numerical solver, actuator model, and selected scenarios. Simulation should therefore be viewed as a tool for guiding and reducing the need for physical experiments rather than replacing experimental validation [5].

Among physics-based modeling approaches, the Maneuvering Modeling Group (MMG) framework is particularly suitable for controller-oriented simulation because it separates the contributions of the hull, propeller, and rudder while retaining variables with clear engineering meaning [6, 7]. However, model fidelity alone is not enough to ensure a reproducible controller evaluation. A geographically defined route must be converted consistently into the local coordinate frame used by the guidance and control algorithms. Competing controllers must also be tested using equivalent references, constraints, and operating conditions, while reference commands, vessel states, and actuator responses must remain properly synchronized. Without this consistency throughout the simulation process, a trajectory that appears successful offers limited evidence of either prediction accuracy or controller performance.

Previous studies have advanced several elements of this workflow, including MMG-based maneuvering prediction, path-following control, autonomous-navigation test environments, and mission-level simulation [8-12]. However, methodological weakness remains at the interfaces between these elements. When vessel dynamics, geographic visualization, controller implementation, and post-processing are handled in separate tools, it becomes difficult to trace model assumptions and signal definitions across the full workflow. As a result, observed differences in performance may arise from inconsistent scenarios, reference signals, or evaluation metrics rather than from the controllers themselves. An integrated simulator becomes scientifically valuable only when it maintains a clear and traceable connection between route definition, dynamic response, and quantitative evaluation.

Against this background, this study develops and evaluates an MMG simulation environment designed to support repeatable controller implementation and post-simulation assessment. The platform combines the full-scale and L7 KVLCC2 vessel models with waypoint-based guidance and a geographic representation of an archived route through the İstanbul Strait. It also maintains a consistent exchange of heading references, vessel states, and actuator commands throughout the simulation workflow. Manual control, dual-loop proportional-integral-derivative (PID) heading and speed control, fuzzy-logic (FL) heading control, and neural-network (NN) heading control are implemented as representative case studies.

This study examines whether route definition, maneuvering dynamics, controller implementation, and performance evaluation can be combined within a single traceable workflow without obscuring the assumptions that shape the results. To investigate this issue, the simulator records synchronized reference commands, vessel states, and actuator responses throughout each run. Completed simulations are then assessed using measures of transient response, tracking error, rudder activity, and speed loss. The same signal and data-processing structure is applied to all controller modes, allowing their performance to be compared within a consistent experimental framework.

This work does not propose a new MMG force formulation or controller-synthesis method. Instead, its contribution is the organization of the simulation chain into a coherent and traceable experimental workflow. This distinction is important because the scientific value of the platform is determined not by the number of software functions it includes, but by the extent to which route, model, controller, and diagnostic information remain connected and interpretable throughout each simulation run.

Within this scope, the study makes three related contributions:

(i) A unified architecture that ensures consistent data exchange among geographic route definition, waypoint guidance, controller calculations, and MMG state propagation.

(ii) An interchangeable controller interface that provides a common structure for reference signals, vessel states, actuator commands, and logged data across PID, FL, and NN implementations.

(iii) A traceable assessment layer that connects geographic route execution with heading transients, root-mean-square tracking error, rudder saturation, speed loss, and user-defined diagnostic thresholds.

Full-scale and L7 KVLCC2 model cases are presented to demonstrate the complete workflow and show how different controller configurations lead to different recorded responses. These cases are not intended as a controlled benchmark and therefore cannot be used to establish hydrodynamic prediction accuracy or controller superiority. The study is consequently positioned as a contribution to simulator workflow development. Stronger performance claims would require benchmark maneuver validation, standardized controller-tuning procedures, environmental-disturbance scenarios, and repeated quantitative experiments. The remainder of the paper reviews related studies, describes the simulator architecture and MMG formulation, presents the control and assessment modules, examines the demonstration cases, and discusses the main limitations and future validation needs.

2. Related Work and Research Gap

2.1. Ship Maneuvering Simulators for Control Testing

Ship maneuvering simulators have become an important tool for the development and validation of maritime control systems. Compared with physical sea trials, simulation-based testing provides a repeatable and low-risk environment in which different control strategies can be evaluated before implementation on real vessels. This is especially important for autonomous and semi-autonomous ship applications, where controller behavior must be examined under various operating conditions, including waypoint tracking, restricted-water navigation, and maneuvering in the presence of other vessels.

Recent studies increasingly treat maritime simulators as engineering platforms for autonomy development rather than solely as training tools [8, 9]. A preliminary MMG-based ship simulator integrating autonomous PID control, manual operation, geographic visualization, and real-time vessel-state monitoring was presented in [13]. Dai et al. [10] developed an immersive virtual reality-based testing method and performance indicator system for autonomous navigation. Hinostroza and Lekkas [11] combined temporal mission planning with a guidance, navigation, and control framework in a realistic marine environment. Together, these studies highlight the importance of linking scenario definition, vessel dynamics, autonomy functions, and performance evaluation within a consistent simulation framework.

The review by Xu and Guedes Soares [12] organizes maritime autonomous surface-ship path-following research around guidance, control, vessel dynamics, stability, and environmental disturbances. For simulator-based assessment, these elements imply that reference generation, tracking error, control action, and maneuvering-model assumptions should be recorded together with the vessel trajectory. Robust-control studies have additionally considered the effect of hydrodynamic-parameter uncertainty on nonlinear surface-vessel control [14].

2.2. Data-Driven Modeling and Maneuver Prediction

In addition to model-based simulation, data-driven techniques have been investigated for ship maneuvering prediction and modeling. Long Short-Term Memory networks have been applied to identify and predict ship maneuvering motion by learning nonlinear time-dependent behavior from maneuvering data [15]. Sensor-data-based identification has also been combined with modular autopilot instrumentation and PID heading control [16]. Artificial Neural Networks have also been widely reviewed and applied in maritime applications, including modeling, prediction, and decision-making tasks [17]. These methods are useful because ship maneuvering dynamics are nonlinear and can be difficult to describe accurately under all operating conditions using only analytical models.

Other studies focus on maneuvering prediction, navigation decision-making, or route generation rather than on simulator validation itself [18]. Their relevance to the present study is therefore indirect. Although they help identify the information that a simulation platform should provide, they do not verify the accuracy of the MMG implementation or ensure that controller comparisons are conducted under equivalent conditions.

MMG-based simulation is particularly useful when controller assessment requires physically interpretable surge, sway, yaw, rudder, and propeller variables. Mitsuyuki et al. [19] demonstrated uncertainty-aware identification of MMG hydrodynamic maneuvering coefficients from observed motion and control data. Liu et al. [20] combined an MMG model with event-triggered predictive path-following control and evaluated tracking performance together with steering activity. These studies motivate an assessment structure that links model assumptions, controller computation, and actuator-level measurements.

Taken together, recent studies address model identification, guidance and control, autonomous-navigation testing, and mission planning at different levels of the simulation chain. The present study focuses on their implementation interface by combining geographic route execution, MMG state propagation, interchangeable heading-control modules, synchronized logging of vessel and actuator variables, and post-run diagnostic calculation in one simulator. The contribution is the integrated and traceable assessment process rather than a new MMG formulation or control law.

2.3. Route Optimization and Maritime Decision Support

Another relevant research direction is maritime route optimization and decision support. Route optimization studies aim to improve navigation safety and efficiency while considering geographical constraints, traffic density, and port-area characteristics. For example, ship path optimization methods that account for geographical traffic characteristics have been proposed to improve maritime port safety [21]. More recently, model-based predictive path planning has incorporated MMG vessel dynamics directly into constrained-environment path generation [22]. Such studies are relevant to maneuvering simulator development because route planning and path-following performance are strongly connected to the vessel’s control capability. Model-based navigation and control have also been investigated for tankship operation in narrow waterways [23].

Nevertheless, many route optimization and decision-support studies focus mainly on path generation or safety evaluation. In contrast, a control-testing simulator must also evaluate whether a particular vessel model and controller can physically follow the generated path with acceptable heading error, overshoot, settling behavior, actuator usage, and speed response. This distinction is important because a geometrically feasible path may still be difficult for a real ship to follow due to hydrodynamic limitations and actuator constraints. Feasibility can also depend on the propulsion mechanism. For autonomous sailing vehicles, geometrically safe avoidance headings may become unsailable when they enter the wind no-go zone [24].

2.4. Industrial Simulator and Navigation Platforms

Industrial developers have also made significant progress in maritime simulators, navigation-support systems, and autonomous-vessel technologies. Kongsberg has developed advanced maritime simulation platforms, including systems used for training and the evaluation of autonomous ship operations [25]. Furuno has introduced navigation-support technologies such as augmented-reality navigation and autonomous marine solutions, where radar, AIS, camera information, and visualization tools are integrated to improve situational awareness [26-28]. JRC has focused on simulator systems that support maritime pilot training and environmental-condition representation [29].

Other industrial platforms emphasize training, traffic simulation, and operational decision support. Wärtsilä provides navigation simulation systems with functions for user-performance evaluation during training scenarios [30]. Transas has contributed to maritime traffic simulation and full-mission bridge simulators, supporting traffic management and risk-analysis applications [31]. Siemens has investigated autonomous navigation and intelligent co-pilot concepts for supporting operational decisions [32]. Rolls-Royce has also worked on autonomous ship concepts and simulation-supported development for future remote-controlled and autonomous vessels [33].

Commercial platforms demonstrate the practical importance of maritime simulation, training, and navigation support. However, publicly available product material generally does not disclose model equations, controller source code, parameter files, or reproducible benchmark data. Table 1 therefore compares documented functional emphasis rather than making claims about unreported cost, performance, or internal architecture.

On this basis, the study examines whether a geographically referenced MMG simulator can provide a coherent path from controller implementation to post-run maneuver assessment. The platform is assessed in terms of:

(i) Integration of guidance, control, vessel dynamics, visualization, and logging.

(ii) Execution of interchangeable heading-control implementations.

(iii) Calculation of maneuver-quality indicators from a saved route run.

Controller plots are used to demonstrate platform operation, whereas quantitative interpretation is restricted to cases for which compatible raw logs are available.

3. Simulator Framework

3.1. Overall Architecture

The simulator is structured as an interactive control-development environment composed of five tightly connected layers: waypoint guidance, heading and speed control, MMG-based maneuvering dynamics, geographic conversion and visualization, and post-run data analytics. Figure 1 summarizes this organization.

The guidance layer interprets user-defined waypoints and transforms them into sequential maneuvering objectives. The control layer generates rudder and propulsion commands either autonomously or through manual intervention. The plant layer propagates vessel motion using the MMG model. The visualization layer converts Cartesian states back to geographic coordinates for map-based display. Finally, simulation logs are stored for offline analysis, replay, and automatic quality assessment. More detailed descriptions of each layer are presented in Table 2.

3.2. MMG-Based Maneuvering Model

The ship model employed in this study adheres to the standardized MMG (Maneuvering Mathematical Group) ship modeling framework [6, 7]. Ship maneuvering in still water involves three primary motions: surge, sway, and yaw. These can be described by the following equations of motion:

where ​u​, ​v​, and ​r​ are the surge velocity, sway velocity, and yaw rate, respectively. For practical purposes, the coupling terms involving added mass in ​​v​ m​​​ and ​r​ are neglected. The total hydrodynamic forces can be decomposed as follows:

Here, the subscripts ​H​, ​R​, and ​P​ refer to contributions from the hull, rudder, and propeller, respectively. The hydrodynamic forces on the hull, ​​X_​ H​​​, ​​Y​ _H​​​, and ​​N​ _H​​​, can be modeled as:

where ​​v​ m​ ′ ​​ and ​r′​ are the non-dimensional lateral velocity and yaw rate, defined as ​​ ​v​ _m​​ _ U ​​ and ​r ​ ​L​ _pp​​ _ U ​​. These coefficients are expanded into polynomial forms:

The surge force generated by the propeller is expressed as:

where the propeller thrust ​T​ is given by:

with the thrust coefficient ​​K​ _T​​​(​J​_P​​)​​ modeled as a second-order polynomial:

and the advance ratio defined as:

The wake fraction ​​w​ _P​​​ depends on the flow conditions and is approximated by:

where ​​β​ _P​​ = β -  ​x​ _P​ ′ ​ r′​ is the inflow angle at the propeller. The forces and moment due to steering are given by:

where the rudder normal force ​​F​ _N ​​​ is defined as:

The rudder inflow velocity ​​U​ _R​​​ and inflow angle ​​α​ _R​​  ​ are given by:

The lateral velocity at the rudder, ​​v​ R​​​, is influenced by flow straightening and is modeled as:

where ​​β​ R​​  =β - ​l​ R​​ r′​ and ​​γ​ R​​​ accounts for the flow alignment effect.

The physical and hydrodynamic parameters used for the full-scale and L7 KVLCC2 models were obtained from [6, 7]. The present implementation was not independently validated against experimental or published turning-circle and zig-zag benchmark results. Therefore, the simulations reported here are not intended to establish maneuvering-prediction accuracy.

3.3. Waypoint Guidance and Reference Generation

Although the user interacts with waypoints in latitude and longitude, control calculations are performed in a local Cartesian frame for numerical simplicity. Let ​​(​x​ i​ wp​, ​y​ i​ wp​)​​ denote the current target waypoint and ​​(x, y)​​ the ship position. The commanded heading is then obtained from.

where ​ψ​ is the current vessel heading. Figure 2 shows the resulting closed-loop information flow.

4. Simulator Product Layout and Interaction Design

4.1. Product-Oriented Design Philosophy

The simulator exposes the maneuvering workflow through an operator-facing interface rather than running the equations as an isolated numerical backend. Parameter initialization, controller selection, real-time visualization, signal logging, and post-run analysis are therefore treated as connected stages of a controller-development process.

The implemented software uses a tabbed desktop interface for configuration, execution, inspection, and evaluation. Table 3 summarizes the capability groups and their role in the workflow.

4.2. Tab-Based Workspace Architecture

The interface is divided into four functional tabs. Table 4 summarizes the responsibilities of each tab. The tabbed structure separates scenario initialization, run-time operation, data inspection, and post-run assessment. The implementation is described as following a Model-View-Controller organization with asynchronous controller execution and coordinate-conversion services.

4.2.1. Initialization Tab

According to the project reports, the initialization tab was designed around four core responsibilities:

• waypoint CSV import and automatic geographic calculations,

• ship-model and parameter loading,

• dynamic validation of parameters,

• multi-column organization of configuration fields.

The waypoint-import path is especially important because the simulator operates visually in geographic space but computes control actions in a local Cartesian frame. Once a CSV route containing latitude and longitude values is loaded, the software transforms the route relative to the selected starting point, thereby preparing the waypoints for the guidance and control layers. The reports emphasize that this transformation is automatic, which reduces operator workload and helps maintain consistency between the visual map and the control-side geometry.

The ship-model panel plays an equally important role. It allows the user to inject or edit dimensions, mass properties, and maneuvering coefficients directly from the Graphical User Interface (GUI). In a product paper this is worth emphasizing because it moves the simulator away from being a hard-coded demonstrator and toward being a reusable vessel-testing platform.

Figure 3 summarizes the initialization workspace, including route loading, initial-state specification, disturbance configuration, controller setup, and vessel-parameter editing. Table 5 lists the corresponding functional groups.

4.2.2. Simulation Tab

The simulation tab is the visual core of the simulator. Figure 4 summarizes the principal regions of the runtime window schematically.

The top band contains run-time controls, the center-left region displays the geographic trajectory, the right column presents context and instrumentation views, and the lower status strip reports numerical telemetry. Tables 6 and 7 summarize these regions and variables.

During a run, the map displays the route, waypoints, vessel marker, and trajectory, while adjacent plots and telemetry panels expose selected state and actuator variables. Pause, restart, and stop functions support interactive testing.

4.2.3. Data Analysis Tab

The data-analysis tab loads completed simulation datasets and supports signal selection, overlay plots, table inspection, figure export, and numerical-data export (Table 8).

Keeping these operations within the simulator allows reference, state, and actuator histories to be inspected without rerunning the model. The workflow places dataset management on the left, signal selection at the top, numerical inspection in the center, and plots in the lower workspace. Figure 5 summarizes the data-analysis workspace and separates run management, plotting controls, numerical data, and the plot canvas.

4.2.4. Post-run Analyzer Tab

The post-run analyzer organizes completed-run assessment. The arrangement allows the user to inspect the detected context and thresholds before comparing the radar chart with the textual metric summary and recommendations. Figure 6 summarizes the post-run analyzer and separates context detection, action controls, threshold editing, radar-chart visualization, and the textual report.

5. Control and Intelligence Modules

5.1. Controller Exposure Through the GUI

The controller modules are presented primarily as replaceable implementations that exercise the simulator workflow. Formal controller synthesis, gain optimization, robustness analysis, and statistically controlled benchmarking are outside the scope of the current evidence. Table 9 summarizes the control-related inputs exposed through the interface.

5.2. Dual-Loop PID Control

Control-oriented ship models have also been used with cascade-control architectures for vessel motion control [34]. PID control is retained as the main reference controller because of its interpretability and tuning transparency. The heading-control command is,

subject to actuator saturation, typically within +/-30 deg. Where the speed error is defined as the difference between the reference speed and the measured surge speed. This dual-loop structure allows heading and forward-speed regulation to be studied independently and jointly. The heading and speed loops operate independently, although their responses remain coupled through the MMG vessel dynamics. The parameter configurations used to demonstrate the controller workspace for the PID controller are summarized in Table 10.

The gains reported in Table 10 were selected through limited exploratory simulation to produce bounded and visibly distinguishable responses within the configured actuator limits. For the full-scale heading example, a proportional gain of K_p=4 was first retained after it produced a usable closed-loop response. Small integral and derivative terms were then varied to demonstrate how changes in the entered parameters are reflected in the simulated response and subsequent analysis. The corresponding L7 and speed-control configurations were prepared for the same software-demonstration purpose. Therefore, these values should not be interpreted as optimal, generally applicable, or recommended controller gains. Configuration A and B were selected to produce different response characteristics for demonstration of the tuning and analysis functions.

5.3. FL Heading Control

A fuzzy-logic (FL) heading controller is included as a rule-based nonlinear alternative. The implementation maps heading-error information to a bounded rudder command using configurable membership functions, inference rules, and centroid defuzzification. A representative triangular membership function is,

while the crisp rudder command is obtained by centroid defuzzification,

The interface uses a heading-error range of ​± 40​ deg and a rudder-command range of ​± 30​ deg. Five linguistic sets are defined for both the heading-error input and rudder-angle output. The input sets are left large, left small, center, right small, and right large, while the corresponding output sets are hard left, soft left, neutral, soft right, and hard right.

The implemented rule base maps these sets directly as summarized in Table 11. The GUI also allows the membership-function type and control ranges to be configured. These settings are provided to demonstrate the fuzzy-controller implementation within the simulator rather than an optimized fuzzy-control design.

The fuzzy controller therefore contains five rules, five input linguistic sets, and five output linguistic sets. The heading-error and rudder universes of discourse are [-40,40] deg and [-30,30] deg, respectively. Centroid defuzzification is used, and a 50-point precomputed input-output map with linear interpolation is employed for faster execution during simulation.

5.4. NN Heading Control

The neural-network (NN) controller is introduced as a data-driven alternative for mapping maneuvering error to control action. Training data were generated by repeatedly simulating the ship under constant rudder commands. Each sample covered a 10 s interval, and a dataset of 1000 samples was reported. The training input is the heading discrepancy,

where ​​ψ​ d​​​ is the desired final heading and ​​ψ​ init​​​ is a randomly selected initial heading. The network output is the rudder demand. The model was trained with a mean-squared-error objective,

using the Adam optimizer. The generic Adam update can be written as,

where ​​​ m̂ ​​ k​​​ and v̂ ​​ k​​​ are the bias-corrected first and second moment estimates. The specific NN configurations used for the reported L7 and full-scale demonstrations are summarized in Table 12. Each network uses ReLU activation in the hidden layers and a single linear output neuron representing rudder demand. Adam optimization and a mean-squared-error objective are used for all configurations. Training data consist of 1000 simulated samples with a 10 s maneuver interval per sample, and no explicit validation split is used in the implemented training call.

5.5. Automatic Post-Run Evaluation Logic

The simulator includes an automatic post-run analyzer intended to classify the quality of a completed maneuver. Instead of acting online, this module consumes simulation logs after execution and produces a structured diagnostic outcome. Figure 7 summarizes the logic.

The metrics are defined in a segment-aware manner so that major heading changes can be evaluated separately before being aggregated. Table 13 summarizes the diagnostic measures used by the analyzer and the engineering meaning attached to each on.

6. Simulator Interface and Experimental Results

6.1. Implemented GUI Views

Figures 8-11 show the implemented interface across the four main tabs: initialization, simulation, data analysis, and post-run analysis. Together they demonstrate that the simulator operates as a continuous engineering workflow rather than a single visualization screen. Route preparation, live maneuvering, result inspection, and performance diagnosis are all handled inside the same environment, which makes repeated controller tuning and comparison considerably easier.

6.2. Controller-Comparison Results

Figures 12-19 demonstrate that changes in the controller configurations entered through the simulator are reflected in the recorded heading, rudder, and speed responses for both the L7 and full-scale models. Differences in transient behavior and actuator demand are visible among the demonstrated configurations. These cases are intended to demonstrate the controller-testing and analysis workflow rather than to establish the relative performance or superiority of the implemented control methods.

6.3. Full-Scale Simulation on a Selected İstanbul Strait Route Segment

Figures 20-25 demonstrate the complete software workflow using an archived full-scale vessel simulation conducted on a geographically referenced route segment of the İstanbul Strait. The simulated route covers only a limited section of the Strait near a navigationally constrained area and does not represent a complete İstanbul Strait transit. In this subsection, the term full-scale refers to the vessel dimensions and model parameters rather than the geographic extent of the simulated route. The purpose of this case is to demonstrate the integration of geographic visualization, closed-loop control, signal recording, data inspection, and post-run assessment within the developed software. It is not intended to establish an optimal controller design.

Figure 20 shows the Simulation tab during execution of the selected route. The central map displays the geographically referenced waypoints, the prescribed route, the current vessel position, and the trajectory generated during the maneuver. The surrounding interface panels provide the instantaneous vessel states, actuator values, simulation parameters, and active controller settings. The time-history panels on the right provide live visualization of selected motion and control variables. This arrangement allows the user to observe the spatial vessel motion and the corresponding dynamic response within the same software environment.

Figure 21 presents the recorded vessel heading together with the reference heading generated by the waypoint-guidance module. The reference changes as the active waypoint is updated, producing several distinct turning segments along the route. The vessel follows the general sequence of commanded headings, although overshoot and oscillatory recovery are visible after some reference changes. These results are not presented as evidence of optimized heading control. Instead, they demonstrate that the Data Analysis tab can load an archived simulation, display recorded variables, overlay related signals, and reveal transient characteristics that are not immediately apparent from the geographic trajectory alone.

Figure 22 compares the vessel speed with the commanded reference speed. The measured speed remains relatively close to the reference, with temporary reductions occurring during the more demanding turning sections. The limited speed reduction should not be interpreted as an inconsistency with the heading oscillations shown in Figure 21. Heading and speed are regulated by separate closed-loop controllers. The heading controller generates the rudder command, whereas the speed controller modifies the propeller rotational speed according to the difference between the measured and commanded surge speeds. Their effects remain coupled through the MMG vessel dynamics, but the propulsion controller actively compensates for maneuver-induced changes in resistance and surge speed.

The rudder-angle history in Figure 23 provides the actuator-level information associated with the heading response. Large positive and negative rudder commands occur after several changes in the reference heading, and the rudder reaches its imposed limits during some portions of the maneuver. These periods correspond to the stronger heading corrections visible in Figure 21. The figure therefore demonstrates why route completion alone is insufficient for assessing controller behavior. A vessel may continue along the intended geographic route while requiring substantial steering activity or exhibiting weakly damped heading recovery.

Figure 24 shows that the propulsion input is not held constant during the maneuver. The propeller rotational speed changes throughout the simulation as the speed controller responds to deviations from the reference speed. Increases in propeller command occur around several turning events, indicating active compensation for transient speed loss and additional hydrodynamic resistance. This response explains why the vessel speed in Figure 22 remains comparatively close to its reference despite the pronounced rudder activity and heading oscillations. Figures 21-24 together provide a more complete interpretation of the maneuver by relating heading tracking, speed regulation, steering demand, and propulsion activity.

Figure 25 presents the same simulation in the Post-Run Analyzer tab. The module processes the recorded signals and reports overall and segment-level indicators, including peak overshoot, median settling time, heading RMS error, rudder-saturation ratio, and maximum speed-loss ratio. The calculated values are compared with user-defined preferred and acceptable limits and are displayed through both a normalized radar chart and a textual diagnostic report. Under the limits configured for this demonstration, the run is classified as FAIL because selected heading-tracking and actuator-use measures exceed the acceptable ranges, even though the speed-loss measure remains comparatively small.

This result illustrates the intended function of the post-run module. The simulator does not treat geometric route execution as sufficient evidence of acceptable maneuver quality. Instead, it preserves the complete state and actuator histories and converts them into structured engineering information that can support controller adjustment, comparison between archived runs, and subsequent software-based testing.

6.4. Limitations and Software Availability

The present study has several limitations. The implemented MMG model has not yet been independently evaluated against experimental maneuvering benchmarks, and the PID, FL, and NN configurations were not obtained through a common formal tuning or optimization procedure. Consequently, the demonstrated cases should not be interpreted as validation of hydrodynamic prediction accuracy or as a controlled comparison of controller superiority. The current experiments also do not systematically address environmental disturbances, parameter uncertainty, or robustness across different operating conditions. In addition, the geographically referenced full-scale case is limited to the selected İstanbul Strait route segment described in Section 6.3. These limitations define the scope of the present software demonstration and motivate future benchmark validation, disturbance-rich testing, and controlled controller comparisons. The current research implementation is not publicly distributed as an open-source software package.

7. Conclusion

This paper presented a ship simulator for control testing that combines MMG-based vessel dynamics, waypoint guidance, autonomous and manual control modes, İstanbul Strait-centered visualization, controller comparison, post-processing, and automatic maneuver-quality evaluation. The resulting platform goes beyond a simple route-following demonstrator and functions as a reusable environment for iterative maritime control development.

The reported cases demonstrate that the simulator can connect geographically defined routes, MMG-based vessel dynamics, interchangeable controller implementations, synchronized signal recording, and post-run assessment within a common workflow. The PID, FL, and NN examples further show that changes in controller configuration can be examined through the same visualization and analysis structure, although the present demonstrations are not intended to establish controller superiority. The data-analysis and post-run evaluation modules provide quantitative information on tracking response, actuator activity, and speed loss that complements the geographic trajectory. Future work should focus on benchmark validation of the maneuvering model, disturbance-rich scenarios, systematically tuned controller comparisons, and hardware-oriented validation.