Digital Twin Framework for Predictive Simulation and Decision Support in Ship Damage Control

Abstract

Ship damage control (DC) is pivotal to platform survivability in the face of battle damage and severe accidents. The DC context features multi-hazard coupling among flooding, fire, and smoke, as well as fast system dynamics and intensive human–machine collaboration, demanding real-time predictive simulation and decision support. Conventional DC simulations fall short in multiphysics fidelity, predictive speed, and integration with onboard sensing and control. A digital twin (DT) framework for predictive shipboard DC is introduced with an explicit capability envelope, observability, and latency requirements, and a cyber-physical mapping to ship systems. Building on this foundation, a three-stage/four-level maturity model charts progression from L1 monitoring, through L2 prediction and L3 human-in-the-loop, override-enabled plan generation, to L4 closed-loop decision control, specifying capability milestones and evaluation metrics. Guided by this model, a four-layer architecture and an end-to-end roadmap are formulated, spanning multi-domain modeling, multi-source sensing and fusion, surrogate-accelerated multiphysics simulation, assisted plan generation with human approval/override, and cyber-physical closed-loop control. The framework aligns interfaces, performance targets, and verification pathways, providing actionable guidance to upgrade shipboard DC toward resilient, efficient, and human-centric operation under multi-hazard coupling.

1. Introduction

Ship survivability, especially under battle damage and accident conditions, is fundamental to sustained maritime missions, and an effective damage control (DC) system is a core enabler of that survivability [1]. As maritime threats become more integrated, intelligent, and high-intensity, multiple hazards—such as hull-breach flooding, onboard fires, and smoke propagation—often exhibit spatiotemporal coupling, rapid evolution, and mutually reinforcing effects. This places higher demands on the real-time sensing, situation prediction, and intelligent decision-making capabilities of DC systems [2]. However, existing shipboard DC practices still rely predominantly on offline simulation and predefined static contingency plans. Significant limitations persist in multiphysics modeling fidelity, simulation speed and timeliness, and human–machine collaboration effectiveness, making them inadequate for sudden, dynamic, and highly adversarial scenarios [3].

Digital Twin (DT) technology offers a new paradigm by establishing a bidirectional, data-driven interaction between a physical asset and its virtual counterpart [4,5]. It has demonstrated effectiveness in condition monitoring, prognostics, and operational optimization across domains such as aerospace, smart manufacturing, and complex equipment maintenance [6,7]. Applied to shipboard DC, a DT enables integrated state sensing/mapping, real-time hazard-evolution simulation, and intelligent human-in-the-loop decision support. In this way, DC can shift from experience- or plan-driven practice to data- and model-driven, closed-loop operation, a direction increasingly recognized as a research focus in naval digitalization and intelligentization programs [8].

Nevertheless, engineering a DT solution for shipboard DC still faces at least four challenges: (1) insufficient integration, spatiotemporal alignment, and trustworthy fusion of heterogeneous onboard data (where “trustworthy fusion” denotes the principled integration of multi-source shipboard measurements into a coherent, uncertainty-quantified estimate of system state under explicit assumptions and quality controls), which impairs continuous feeding of the DT; (2) weak capabilities in multiphysics coupled modeling, model calibration, and verification and validation (V&V, i.e., calibration–verification–validation, C-V-V), limiting the reuse of simulation results in real-ship scenarios [9]; (3) limited human–machine collaboration and explainable intelligent decision-making under time pressure; and (4) incomplete cyber-physical closed loops, preventing timely actuation of twin simulation/optimization outcomes in the physical system [10].

To address these issues, this paper develops a DT-driven shipboard DC simulation and decision-support system and presents an end-to-end framework spanning sensing, modeling, prediction/prognostics [11], decision-making, and closed-loop control. The main contributions are (i) multi-scale twin modeling for multi-hazard coupling scenarios; (ii) surrogate-accelerated, near-real-time predictive simulation of multiphysics processes; (iii) an explainable, human-in-the-loop decision mechanism tailored to onboard operators; and (iv) framework-level interfaces, performance metrics, and validation pathways that support the intelligent and operational upgrading of shipboard DC systems. The primary objective of this study is to establish a unified, verifiable DT foundation that enables near-real-time predictive simulation and decision support, advancing shipboard damage control toward closed-loop operation under multi-hazard coupling.

2. State of the Art

2.1. Digital Twin and Related Concepts: A Clarification

Since Professor Grieves first introduced the concept of Digital Twins (DTs) in 2002 [12], their scope has continually expanded. At its core, DTs construct a high-fidelity digital representation of a physical entity and maintain a bidirectional connection between the physical and virtual domains throughout the entire lifecycle. Compared with modeling and simulation (M&S), cyber-physical systems (CPS), and parallel systems (PS) (see

Table 1. Comparison of Digital Twin (DT) with Modeling and Simulation (M&S), Cyber-Physical Systems (CPS), and Parallel Systems (PS).

Dimension	Digital Twins (DTs)	Modeling and Simulation (M&S)	Cyber-Physical Systems (CPS)	Parallel Systems (PS)
Core idea	Bidirectional mapping; online data assimilation; closed-loop optimization/control	Model abstraction; behavioral simulation; plan verification (mostly offline)	Integrated sensing-computing-control; process-level monitoring/control	Artificial systems + computational experiments + parallel execution (ACP); policy co-evolution
Data Integration Fidelity	High (continuous multi-source alignment; full cyber-physical fidelity)	Low (discrete model-centric input; limited physical fidelity)	Medium (device/process-level fusion; partial subsystem fidelity)	Medium (artificial-computational interaction; policy-validation focused fidelity)
Real-time capability	High (continuous data streams)	Low-medium (mostly offline)	High (device/process level)	Medium (parallel interaction; not hard real-time)
Suitability for ship DC	High (state mapping, evolution, closed-loop decisions)	Medium (plan selection, validation)	Medium (subsystem control/alarms)	Medium (policy-level parallel experimentation/optimization)

Note: These paradigms are complementary, not mutually exclusive. A DT can incorporate multiphysics M&S, leverage CPS for real-time actuation, and adopt PS for strategy-level parallel experimentation.

), DTs are particularly well suited to shipboard DC scenarios, which are highly dynamic, tightly coupled, and impose stringent requirements on real-time decision-making and verifiability [13].

2.2. Recent Advances in Digital-Twin Applications for Shipboard Damage Control

DT applications in maritime systems have expanded from single-equipment monitoring to integrated, whole-ship management (Figure 1).

Architecture and lifecycle: Madusanka et al. outlined a four-layer maritime DT architecture and prospects for smart shipping [2]. Mauro and Kana identified gaps from design to retirement and called for lifecycle-wide DT frameworks [3].

Condition monitoring and hazard response: Lee et al. developed a real-time DT for ships in waves to enhance navigational safety [4]. Avazov et al. achieved ~92% shipboard fire detection with YOLOv7 (You Only Look Once version 7) [14]. Sun et al. predicted motor faults with ≤2 s latency by coupling multiphysics with O&M data [15]. While these efforts advance sensing and prediction, end-to-end integration for multi-hazard coupling, in-the-loop control, and cyber-physical closure remains limited.

Propulsion and structures: Zhou et al. proposed a shaftline-centric DT framework with standardized modeling workflows [16]. Zhang et al. reported 98.5% online fault-detection accuracy with a 3% false-alarm rate for the shafting system [17]. Ding et al. improved stern-bearing load balance by >20%, supporting lifecycle dynamic alignment [18].

Shipboard DC: Lee et al. built a performance-oriented onboard DC system integrating multisource sensing and time-domain fire/flooding databases with ship-shore drills [19]; Braidotti et al. introduced a unified linearized progressive-flooding solver (DAEs, adaptive step, free-outflow correction) enabling minute-scale onboard assessment [20]; Louvros et al. fused Case-Based Reasoning and Machine Learning (CBR+ML) with a precomputed time-domain library and live data to rapidly estimate survivability [21]; Tunçel et al. applied fuzzy fault trees with CS-I to quantify fire/explosion risk (9.27 × 10⁻²) and prioritize controls [22]. Limitation: most solutions target single hazards or offline libraries, lacking integrated validation that couples multi-hazard progression with in-the-loop control and equipment-level closed-loop actuation.

Command and Control (C2) and Training: Chen et al. explored DT-enabled naval C2 with emphasis on real-time interaction [13], and Sheng et al. proposed a seven-layer DT architecture for simulation-based training and tactic validation [23]; real-time linkage to physical DC equipment has yet to be demonstrated.

Collectively, these studies demonstrate significant progress in component-level monitoring and prediction, yet they predominantly operate in isolation, limiting their ability to provide holistic, integrated solutions.

2.3. Challenges and Limitations of Current Research

Although DT technology has been applied in the marine field, its systematic application to ship DC simulation still faces the following four challenges

(1)

Insufficient access and fusion of multi-source heterogeneous data. Multi-modal data from sensors, subsystems, and historical cases lack unified specifications in terms of sampling frequency, quality control, semantic consistency, and spatiotemporal registration. Uncertainty characterization, data incompleteness, and low reliability weaken the effectiveness of online calibration and decision update of the DT model, increasing the cost of cross-scenario adaptation.

(2)

Lack of multiphysics field coupling mechanisms. Most current achievements are “point-like” breakthroughs, focusing either on water ingress processes or fire and smoke monitoring. There is still a lack of a high-fidelity unified model that can simultaneously characterize the coupled evolution of multi-fields such as breach water ingress, in-cabin fires, and smoke diffusion. The isolation and fragmentation among models limit the ability to characterize and map complex DC scenarios.

(3)

Weak closed-loop decision-making and control, as well as human–machine collaboration. Many studies stop at “monitoring–alarming” or “deduction–display”, and no mechanism has been formed to safely and controllably close the loop from virtual-space decisions to onboard actuators such as pumps and valves. Meanwhile, there is a lack of quantitative evidence and strategy design for “human-in-the-loop” collaborative decision-making (e.g., trust calibration, authority switching, intervention triggering) and an evaluation framework supported by standardized indicators and near-real-ship tests. Specifically, the evaluation should report standardized indicators such as operator intervention time, decision accuracy, and subjective trust ratings; where appropriate, these can be complemented by established human-automation interaction (HAI) measures—situational awareness (Situation Awareness Global Assessment Technique, SAGAT; Situation Awareness Rating Technique, SART), workload (NASA Task Load Index, NASA-TLX)—and Levels of Automation (LOA)–based interaction parameters (authority allocation, handoff latency, override rate).

(4)

Imperfect verification and calibration system. Insufficient standardized benchmark scenarios and evaluation protocols, limited access to real-ship/near-real-ship data, and an incomplete C-V-V process for parameters and boundary conditions make it difficult to form comparable and reproducible empirical results, affecting the credibility and transferability of engineering applications.

3. Properties and Core Requirements

Building on the preceding problem definition and status review, and aligned with subsequent scenario assumptions and method design, this section specifies the core requirements of a DT-based DC simulation system to provide constraints and reference metrics for experiments and evaluation (see Figure 2).

3.1. Intrinsic Properties

(1)

Strongly coupled multiphysics: Represents hull-breach flooding, compartment fires, and smoke dispersion with their interactions (e.g., trim/heel effects on spread pathways), employing numerical acceleration and model-reduction techniques (e.g., reduced-order and surrogate models) to preserve physical consistency and achieve timeliness. Timeliness is quantified by the real-time factor (RTF = simulated duration/wall-clock time; target RTF > 1), and computational cost is evaluated by per-step runtime and peak memory usage. Evaluation is conducted via RTF (>1 target) and error relative to high-fidelity Computational Fluid Dynamics (CFD).

(2)

Human-in-the-loop decision primacy: DC operates in a human-in-the-loop regime. The HMI provides one-click override/abort, a mode switch (manual/assist/autonomy), and bounded parameter sliders with reset. The operating doctrine is “assist by default”: the AI suggests, and the human approves/executes; in autonomy, the human may preempt at any time. Evaluation is based on operator-intervention frequency, decision-correction rate, and task-completion time across manual/autonomy/assist on the same tasks.

(3)

Cross-subsystem interdependence: DC effectiveness is constrained by propulsion, power, ventilation, and piping states; the system should interoperate with key shipboard subsystems for data exchange and coordinated control. Evaluation by comparing outcomes (e.g., time to control fires, heel angle) to verify interoperability.

3.2. Core Capability Requirements

(1)

Fast multi-hazard evolution simulation. Provide near-real-time predictions for three core hazard states—flooding rate, fire extent, and smoke concentration—with a user-facing latency budget ≤ 3 s. For situational awareness, aim to refresh mapped fire-spread boundaries at an interval ≤ 2 s, and accompany smoke concentration with rolling 5 min trend forecasts to support planning.

(2)

Scheme generation and collaborative optimization. Under declared resource constraints, generate and rank 2–3 executable DC action sequences within the response-time budget; revise plans when trigger conditions are met (e.g., flooding rate > 0.5 m³/s). The HMI provides auditable rationale (key-parameter impact) and editable constraints. The end-to-end decision pathway (from fused frame to final command set) has a budget ≤ 5 s (solver ≤ 2 s; plan generation/ranking ≤ 3 s).

(3)

Cyber-physical closed loop and feedback. Dispatch device/actuator commands (pumps, valves, ventilation, compartmentalization) with dispatch-to-acknowledgment latency ≤ 2 s. Adopt a 5-min online calibration policy that updates model parameters/boundaries using feedback; the performance objective is a ≥ 10% median reduction per calibration cycle in the relevant prediction error under comparable conditions (this value is an engineering acceptance target, not a measured result in this study).

The mapping from these core capabilities to their enabling baselines is summarized in

Table 2. Capability–baseline mapping (3.2 → 3.3).

Core Capability	Enabling Baselines
CR-1 fast multi-hazard simulation (≤3 s; fire ≤ 2 s; smoke 5 min trend)	BR-01 5–10 Hz and time-aligned fusion; BR-02 unified model and error budgets; BR-04 OPC UA/MQTT/NMEA 2000, HIL traceability
CR-2 scheme generation and collaborative optimization (3 plans; trigger-based revision; auditable HMI)	BR-02 param. interfaces for optimization; BR-03 HMI explainability and audit; BR-04 command/telemetry QoS (≤2 s ack); BR-01 stable state inputs
CR-3 cyber-physical closed loop and feedback (dispatch ≤ 2 s; 5 min calibration; ≥10% error reduction)	BR-04 dispatch → ack ≤ 2 s, end-to-end traceability; BR-01 feedback signals; BR-02 calibration hooks/versioning; BR-03 human-in-the-loop safeguards

.

3.3. Baseline Technical Requirements

(1)

Multi-source sensing and data fusion: Deploy pressure, temperature, smoke concentration, and attitude sensors to achieve 5–10 Hz sampling; perform time alignment, semantic harmonization, denoising, quality control, and uncertainty characterization; and fuse at the state layer with propulsion and navigation to form stable, coherent observations.

(2)

Unified multiphysics modeling and C-V-V: Build a unified model that simultaneously captures breach flooding, compartment fire dynamics, and smoke dispersion, with explicit error budgets and applicability; provide parameterized interfaces supporting the C-V-V process and model versioning.

(3)

Human–machine collaboration and explainable decisions: Design task-oriented interactions and information presentation with explicit constraints and assumptions; support human intervention, trace-back, and audit; and evaluate collaboration via efficiency, accuracy, and workload to ensure safe, controllable human-in-the-loop operation.

(4)

Standardized data/control interfaces and protocols: Provide hierarchical standardized interfaces and protocols for functional adaptation—Open Platform Communications Unified Architecture (OPC UA) for data interaction (supporting bidirectional mapping of multi-source heterogeneous data to ensure the integrity of simulation-model and equipment-status data), Message Queuing Telemetry Transport (MQTT) for real-time control-command delivery (configured with Quality of Service (QoS) level 1/2 to prevent command loss for equipment such as pumps and valves, with end-to-end latency from command dispatch to execution acknowledgment ≤ 2 s), and the National Marine Electronics Association 2000 (NMEA 2000) maritime standard for shipboard hardware access (e.g., attitude sensors, pump controllers; based on the Controller Area Network (CAN) bus). Through these interfaces and protocols, end-to-end traceability is achieved, covering command dispatch, execution acknowledgment, and telemetry readback; meanwhile, hardware-in-the-loop (HIL) testing and multi-scenario validation are supported to ensure digital-physical state consistency and operational-safety bounds.

4. System Architecture, Maturity Model, and Core Technologies

4.1. System Architecture

Guided by the DT paradigm and the functional requirements of the shipboard DC simulation system, the DT-DC framework is organized into a four-layer architecture—Physical, Data, Model, and Application (Figure 3).

The Physical layer focuses on onboard platform and equipment states and sensing. The Data layer cleans, aligns, and persists multi-source heterogeneous data, providing unified time-series and knowledge interfaces. The Model layer integrates multi-hazard coupled solvers and reduced-order surrogates tailored to ship damage control: a finite volume method (FVM) solver for breach-induced, multi-compartment flooding and free-surface internal flows (strict mass/pressure conservation; robust under high-velocity jets and pressure transients), coupled with a lattice Boltzmann method (LBM) solver for low-Mach fire/smoke transport in complex compartments, plus a proper orthogonal decomposition–convolutional neural network (POD-CNN) reduced-order model (ROM) that compresses dynamics to deliver seconds-scale forecasts under explicit error budgets with online calibration [24,25,26,27]. The layer also exposes explainable application programming interfaces (APIs) for decision support (audit trails and parameter-impact reports) to close the sense–simulate–decide loop. The Application layer serves command-and-control, integrating visualization, course-of-action recommendation, and optional equipment control. Data flows bottom-up through standardized interfaces, while decisions and control commands close the loop top-down.

4.2. Three-Stage/Four-Level Maturity Model

Drawing on the technological evolution and application needs of DT-enabled shipboard DC, a three-stage/four-level maturity model is proposed (Figure 4) that specifies the core tasks and technical objectives at each stage.

4.2.1. Three Stages

Digital Shadow: Static mapping and offline validation. Digitizes the geometry and physical parameters of the ship and DC elements and establishes a single-hazard static-simulation baseline. Inputs include structural/material/compartment data and steady-state operating conditions. Outputs are experiment-aligned, reproducible static quantities (e.g., liquid level, temperature, pressure).

DT: Online simulation with a semi-closed loop. Integrates real-time sensor and industrial-control data to conduct dynamic, multi-hazard simulations (e.g., breach-induced flooding and fires), forming a sense-simulate-feedback semi-loop. Inputs are real-time data and disturbance events. Outputs include online situational awareness, risk assessment, and candidate response plans.

Digital Intelligence: Closed-loop intelligent control. Plans are executed automatically under human-in-the-loop supervision; policy requires human-in-the-loop confirmation only for safety-critical actuations, and operators may override at any time. Device/actuator commands are issued accordingly, and feedback continuously self-calibrates model parameters and boundary conditions, forming a full sense–simulate–decide–control–feedback loop [28]. Outputs include execution traces and rollback/provenance records.

4.2.2. Four Levels and Mapping

L1—Static mapping: Geometry/physics modeling and single-hazard static simulation; target static error ≤ 15%.

L2—Dynamic co-simulation: Real-time, multiphysics-coupled solving; target dynamic error ≤ 12%; provides situational-awareness display to assist human judgment.

L3—Assisted Plan Generation: Builds on L1–L2 to automatically produce and rank 2–3 feasible response plans (rule/search-based); end-to-end (stimulus → ranked plans) ≤ 5 s, comprising simulation (budget ≤ 2 s; measured ≤1.8 s) and plan generation + ranking (budget ≤ 3 s).

L4—Closed-loop intelligent control: Converts plans into device/actuator commands and realizes model self-calibration using feedback data; decision accuracy ≥ 90% (stage target). Here, “decision accuracy” specifically refers to the alignment between actual hazard parameters (e.g., reduction in flooding rate, shrinkage of fire spread area) and the system’s preset mitigation targets (e.g., if the preset target is a 50% reduction in flooding rate, an actual reduction of 45–55% is deemed an accurate decision).

The mapping between stages and levels is shown in

Table 3. Mapping between autonomy levels (L1–L4) and maturity stages (I–III).

Level	Stage	Definition (Human Role)
L1	Digital Shadow	Monitoring only; no control; human-in-the-loop for interpretation.
L2	Digital Twin	What-if simulation; human approves actions.
L3	Digital Twin	Assisted plan generation; human-in-the-loop with override.
L4	Digital Intelligence	Closed-loop control; safety-critical actions require confirmation.

:

4.3. Core Technologies and Implementation Path

Centered on the “sense-simulate-decide-control-feedback” intelligent closed loop, this section delineates five core technologies (sensing, simulation, decision-making, control, and feedback) that span the entire workflow. None of these technologies are dispensable—removing one will break the closed loop—and there is no redundant design (the existing technology combination fully covers core requirements without the need for additional supplements). Working in concert, these technologies constitute the key technical backbone of the DT-based simulation system (see Figure 5 and

Table 4. Core technologies and roles across the closed loop.

Process Stage	Core Technology	Technical Role
Modeling Foundation	Multi-domain, multi-scale DC twin modeling	Provide high-fidelity models for sensing, simulation, and decision-making
Sensing	Multi-source sensing and data fusion	Accurate state acquisition and data preprocessing
Simulation	Real-time coupled multiphysics simulation	Reconstruct the multi-hazard evolution and produce state predictions
Decision	Human-in-the-loop DC decision-making	Generate interpretable action plans
Control and Feedback	Cyber-physical closed-loop control and evaluation	Execute plans, assess performance, and calibrate the DT

).

4.3.1. Multi-Domain, Multi-Scale Twin Modeling

As the modeling foundation across the workflow, the goal is to build a unified virtual representation covering micro-level equipment, meso-scale hazards, and the macro hull. By integrating Building Information Modeling (BIM) with multiphysics simulation via an IFC-based common schema and a unified platform, high-fidelity flooding/fire models are seamlessly coupled. These models provide calibration references for sensing, embed the physics engine for simulation, and offer an a priori testbed for control commands, forming the basis for L1 static mapping and L2 dynamic simulation capabilities.

4.3.2. Multi-Source Sensing and Data Fusion

This technology serves the sensing stage, enabling accurate state acquisition and preprocessing. Networks of pressure, temperature, smoke concentration, and attitude sensors sample system states at 5–10 Hz. A sliding-window scheme and Kalman filtering clean and denoise the raw data, which are fused with information from power, navigation, and other subsystems to ensure completeness and reliability. The processed data are streamed in real time to the simulation stage, accomplishing the first step of mapping physical states into the DT.

4.3.3. Real-Time Coupled Multiphysics Simulation

This is the core of the simulation stage, converting sensed data into future hazard states. Using a hybrid finite-volume–lattice-Boltzmann (FVM–LBM) solver, real-time measurements drive coupled multiphysics calculations for flooding, fire, and smoke; feasibility is supported by established FVM–LBM coupling frameworks and real-time LBM implementations [29,30,31,32]. To meet second-level response requirements, GPU parallelization and reduced-order modeling via POD-CNN are employed, keeping latency within 1.8 s in typical scenarios. The predicted situation provides direct and reliable inputs to decision-making.

4.3.4. Human-in-the-Loop Damage Control Decision-Making

This module supports decision-making by transforming simulated scenarios into executable plans. A hybrid policy pairs hard rule constraints with a Deep Q-Network (DQN) [33]. The DQN is pre-trained on historical incident logs and then fine-tuned with reinforcement learning (RL) in a physics-consistent, randomized flooding/fire/smoke simulator coupled to our solver.

To improve sample efficiency and reduce reliance on large-scale real-world data, the proposed method employs offline data augmentation (scenario–parameter interpolation; fault-mode combinations) and transfer learning to initialize network weights, enabling convergence with only ~1000 core samples while avoiding the memory overhead of massive replay buffers.

Feasibility (alignment with safety rules) is enforced via action masking and penalty shaping. Generalization is promoted by extensive domain randomization (e.g., breach location/extent, equipment failures, loads, sensor dropout) and a curriculum progressing from single- to multi-fault scenarios, with evaluation on held-out out-of-distribution (OOD) cases.

Robustness of the learned policy is assessed through fault-injection tests (e.g., sensor dropout, actuator malfunction) and extreme-scenario simulations (e.g., simultaneous multi-breach flooding), following the classical fault–error–failure cycle to gauge fault tolerance and recovery.

To enable effective human–machine collaboration, Shapley additive explanations (SHAP)-based explainability [34] quantifies the contribution of each input feature (e.g., sensor data, risk indicators) to plan selection, and a manual-override channel allows domain experts to adjust plans when necessary. The finalized command set is then dispatched to trigger control actions.

4.3.5. Cyber-Physical Closed-Loop Control and Evaluation

This module integrates control and feedback to close the loop. On the control side, decision plans are compiled into device-level commands and delivered via reliable links (e.g., 5G/fiber) to physical actuators (pumps, valves, vents, and compartmentalization devices). End-to-end command-delivery latency is maintained below 2 s to track hazard evolution in real time.

On the feedback side, a multi-dimensional evaluation index system—covering hull attitude, hazard mitigation effectiveness (e.g., reduction in flooding rate, containment of fire spread), and resource consumption—quantifies execution performance in real time. Specifically, the hull attitude indicators include heel angle, trim angle, and draft depth, which are quantified as the “deviation rate between actual measured values and safety thresholds”; the hazard mitigation effectiveness indicators comprise reduction in flooding rate, shrinkage of fire spread area, and smoke concentration decrease rate, quantified as the “coincidence degree between actual mitigation values and target values”; the resource consumption indicators cover energy consumption of pumps/valves and spare part loss, quantified as the “ratio of hourly consumption to rated values”. The overall execution performance is quantified via a “weighted comprehensive score” (weights are set based on maritime safety standards: 0.5 for hazard mitigation effectiveness, 0.3 for hull attitude, and 0.2 for resource consumption). The score results are directly used for model parameter calibration (e.g., adjusting pump flow model coefficients according to the energy consumption ratio), ensuring the practicality and operability of the evaluation. The evaluation results and measured states are fed back to the DT to calibrate model parameters (e.g., actual pump flow rate, valve actuation efficiency), narrowing the reality–twin gap and enabling continual optimization across subsequent “sense–simulate–decide–control–feedback” cycles.

5. Experiments and Results

This study validates the framework using simulation experiments on a mid-size vessel (displacement 5000 t; 30 compartments) under a coupled hull-breach flooding and fire scenario. Multiphysics models are developed with MATLAB and the Fire Dynamics Simulator (FDS), with a breach area of 0.5 m² and a fire heat-release rate of 2 MW. The experiments evaluate prediction accuracy, real-time capability, and decision-making effectiveness.

5.1. Numerical-Simulation Experiments: Platform and Setup

5.1.1. Scenario and Sensor Configuration

A BIM/mesh model is built from the ship’s design drawings, retaining five main compartments: accommodation, control room, power compartment, engine room, and stores. A hull breach is placed on the port side beneath the power compartment (x = 25 m, y = −3 m, z = 1 m) with an area of 0.5 m². A fire occurs in the adjacent engine room with a heat-release rate of 2 MW; smoke is expected to spread across two to three compartments (see Figure 6).

To capture the physical state accurately, a sensor-network model is instantiated in the DT environment following real-ship interfaces and parameter conventions. Sensor types, ranges, accuracies, sampling rates, and communication protocols follow the installed-equipment specifications (

Table 5. Sensor configuration list.

Sensor Type	Sampling Rate (Hz)	Measured Parameters (Range, Accuracy)	Primary Role
Pressure sensor	10	flooding rate 0–0.5 m3/s (±0.01 m3/s)	drives flooding simulation
Temperature sensor	5	compartment temperature 20–800 °C (±1 °C)	drives fire simulation
Smoke concentration (CO) sensor	5	0–1000 ppm (±5 ppm)	drives smoke-dispersion simulation
Inclinometer	10	hull attitude 0–15° (±0.1°)	survivability assessment

).

5.1.2. Algorithmic Implementation

Multiphysics simulation: A coupled FVM-LBM solver performs real-time updates on a 100 × 50 × 30 mesh (Δx = 0.1 m) with CUDA acceleration. Governing equations are as follows:

$${\displaystyle \frac{\partial \rho }{\partial t}}+\mathsf{\nabla }·\left(\rho u\right)=0$$

(1)

$${\displaystyle \frac{\partial T}{\partial t}}+u·\mathsf{\nabla }T=\alpha {\mathsf{\nabla }}^{2}T+S_h$$

(2)

$${\displaystyle \frac{\partial c}{\partial t}}+\mathsf{\nabla }·\left(cu\right)=\mathsf{\nabla }·\left(D\mathsf{\nabla }c\right)$$

(3)

where $\rho$ is fluid density, $\mathrm{u}$ velocity, T temperature, $c$ smoke concentration, $S_h$ the heat source term, $\alpha$ = 2.2 × 10⁻⁵ m²/s (thermal diffusivity of air at 25 °C, [35]), and $D=$ 1.1 × 10⁻⁵ m²/s (smoke diffusivity of typical ship compartment mixtures, [36]).

Initial conditions: At the simulation start, the vessel is at rest on Beaufort Sea State 0 calm water. Compartments have no flooding, the initial temperature is 25 °C, smoke volume fraction $c$ = 0, and both heel and trim are 0°. The mesh has zero initial velocity $u$ = 0 m/s.

Intelligent decision-making: A DQN (TensorFlow; learning rate 0.001; discount factor 0.9; 5000 training episodes) produces joint sealing-firefighting actions. The reward targets ship survivability:

$$R={\omega }_1\left(-{\theta }_{\mathrm{t}\mathrm{i}\mathrm{l}\mathrm{t}}\right)+{\omega }_2\left(-{∆t}_{\mathrm{f}\mathrm{i}\mathrm{r}\mathrm{e}}\right)+{\omega }_3\left(-E\right)$$

(4)

with initial weights ${\omega }_1$ = 0.4, ${\omega }_2$ = 0.4, ${\omega }_3$ = 0.2. Here ${\theta }_{\mathrm{t}\mathrm{i}\mathrm{l}\mathrm{t}}$ is the heel angle, ${∆t}_{\mathrm{f}\mathrm{i}\mathrm{r}\mathrm{e}}$ the time to control the fire, and $E$ the equipment energy use.

5.1.3. Evaluation Metrics and Measurement Protocol

Simulation error (target ≤ 10%): Core metric is the prediction accuracy of the breach inflow rate, measured by time-averaged Mean Absolute Percentage Error (MAPE):

$$\mathrm{MAPE} = {\displaystyle \frac{1}{\mathrm{N}}}{\displaystyle {\sum }_{\mathrm{k}=1}^{\mathrm{N}}}{\displaystyle \frac{\left|Q_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{d}}\left(t_k\right)-Q_{\mathrm{t}\mathrm{r}\mathrm{u}\mathrm{e}}\left(t_k\right)\right|}{\max \left(Q_{\mathrm{t}\mathrm{r}\mathrm{u}\mathrm{e}}\left(t_k\right),0.02{\mathrm{m}}^3/\mathrm{s}\right)}}\times 100\mathrm{\%}$$

(5)

where $Q_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{d}}$ and $Q_{\mathrm{t}\mathrm{r}\mathrm{u}\mathrm{e}}$ are the predicted and reference inflow at sample $\mathrm{k}$.

The reference comes from a high-fidelity CFD model calibrated with full-scale ship data and validated on independent cases; the model follows the geometry and boundary conditions of the medium-displacement vessel used in this study (~5000 t, 30 compartments). To avoid instability at very low flows, a 0.02 m³/s floor is applied in the denominator. Test duration is 800 s at 10 Hz (N = 8000).

Fire control time (target ≤ 10 min): Start when any sensor continuously reports “T > 80 °C” or “CO > 50 ppm” for 10 s. End when any two of the following are simultaneously met and remain stable for 60 s: (i) Heat Release Rate (HRR) < 0.1 MW; (ii) compartment temperature < 80 °C; (iii) CO concentration < 50 ppm.

Maximum heel angle (target ≤ 5°): Maximum absolute heel within [$t_{\mathrm{d}\mathrm{e}\mathrm{t}}$, $t_{\mathrm{e}\mathrm{x}\mathrm{t}}$+ 60 s], where $t_{\mathrm{d}\mathrm{e}\mathrm{t}}$ is the formal detection time and $t_{\mathrm{e}\mathrm{x}\mathrm{t}}$ is the fire-controlled time defined above.

Decision response time (target ≤ 3 s): End-to-end latency from the completion of a fused sensor frame write to the issuance of the final control command set by the decision module.

Resource consumption: Pump energy E and agent usage M, with unit-consistent conversion to kWh and kg:

$$\mathit{E} =\sum \left(\mathsf{\rho }\mathrm{g}\mathrm{Q}\mathrm{H}/\mathsf{\eta }\right)·∆\mathrm{t}$$

(6)

$$M=\int {\dot{\mathrm{m}}}_{\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}dt$$

(7)

Symbols: $\mathsf{\rho }$ fluid density, $\mathrm{g}$ gravity, $Q$ pump flow, H head, $\eta$ efficiency, ${\dot{m}}_{\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}$ discharge rate.

Composite performance score: A three-dimensional score covering ship survivability, hazard control, and resource consumption. Weights are obtained by Analytic Hierarchy Process (AHP) [19] with the judgment matrix:

$$\mathrm{A} = \left[\begin{array}{ccc}1& 3\hfill & 5^{1/3}\\ 1/3\hfill & 1\hfill & 3^{1/5}\hfill \\ 5^{-1/3}& 3^{-1/5}& \hfill 1\end{array}\right]$$

(8)

The rows, in order, are ship survivability, hazard control, and resource consumption.

This yields the weight vector ω = [0.637, 0.258, 0.105]^T and a consistency ratio CR = 0.046 < 0.1, indicating acceptable consistency. The exact vector is retained for all computations, whereas the rounded vector ω ≈ [0.6, 0.3, 0.1]^T is provided only for readability and quick field verification; sensitivity analysis indicates no change in plan rankings. The final score is

$$S=\sum _{\mathrm{i}=1}^3{\mathsf{\omega }}_{\mathrm{i}}·{\mathsf{\nu }}_{\mathrm{i}}$$

(9)

where ${\mathsf{\nu }}_{\mathrm{i}}$ are normalized indicators within each dimension.

Statistics and uncertainty: Each method is independently run 10 times under perturbed sea states and sensor noise. All metrics are reported as mean ± standard deviation (SD).

Specifically, the generation of perturbed conditions for the 10 independent robustness test runs is detailed as follows:

Generation of Perturbed Conditions (for 10 independent robustness test runs):

Perturbed sea states: Randomly sampled from the International Sea State Scale (Grades 0–4, typical for nearshore ship operations), with each run assigned an independent sea state grade to cover light to moderate wave conditions;

Sensor noise: Simulated using a Gaussian distribution (mean = 0) to match real industrial sensor characteristics;

For pressure sensors (used to calculate breach inflow rate): Standard deviation = 0.002 m³/s, derived from the general precision range of industrial differential pressure sensors (0.1–0.5% FS) and the experiment’s inflow rate full scale (1 m³/s), corresponding to 0.2% FS error;

For temperature sensors (PT100-type): Standard deviation = 0.2 °C, a conservative value below the maximum error of industrial PT100 sensors (Class A precision: ±(0.15 °C + 0.002 × |t|), where t is the measured temperature), ensuring noise levels align with practical equipment performance.

5.1.4. Experimental Platform and Environment

All results reported in this paper are derived from numerical simulation experiments on a virtual ship model; to support the multiphysics-coupled simulations and intelligent decision-making tasks described above, all experiments were conducted on the following platforms.

Hardware: A workstation with an Intel Core i9-12900K CPU and 64 GB RAM (Intel Corporation, Santa Clara, CA, USA); an NVIDIA GeForce RTX 3090 graphics processing unit (GPU) provided parallel acceleration to meet real-time simulation requirements (NVIDIA Corporation, Santa Clara, CA, USA).

Software: Hydrodynamic modeling and core solvers were implemented in MATLAB R2023a (MathWorks Inc., Natick, MA, USA) [37]; fire and smoke simulations were performed using the Fire Dynamics Simulator (FDS) version 6.7.9 (National Institute of Standards and Technology (NIST) [38], Gaithersburg, MD, USA); the deep reinforcement learning decision model was built and trained with TensorFlow 2.10 (Google LLC, Mountain View, CA, USA) [39]. All software ran on a 64-bit Windows 11 operating system.

5.1.5. Model Coupling, Runtime Workflow, and Baseline Model

Within each shared time step, all modules advance in a fixed sequence to ensure non-overlapping numerical computation and deterministic data exchange:

(1)

Fire Dynamics Simulator (FDS) runs with the current actuation setpoints to simulate fire combustion processes (e.g., fuel combustion, heat release), outputting the heat source term ${\mathrm{S}}_{\mathrm{h}}$ and qualitative fire intensity indicators (sampled at the end of the step).

(2)

The MATLAB hydrodynamics module takes $S_h$ and fire-intensity indicators from FDS as inputs, updates breach-induced progressive flooding and global hull attitude (heel/trim) using the FVM solver via mass- and momentum-conservation relations, and advances temperature T and smoke concentration $c$ using the LBM solver for low-Mach fire/smoke transport in complex compartments.

(3)

Based on MATLAB’s solved states (breach inflow indicator, temperature/smoke levels, hull attitude) and the previous step’s action states (pump/valve/vent/suppressant status), per-step summaries are concatenated to form the observation vector for the TensorFlow DQN. The policy outputs joint discrete actions across pumps (off/half/full), valves (open/close), ventilation (on/off), and suppressant dosing (e.g., 0/5/10). A safety mask filters infeasible or unsafe combinations, and the valid actions are latched as the actuation setpoints for the next time step.

Data exchange between FDS and MATLAB is implemented via a lightweight file-based interface (time-stamped text/CSV records), ensuring deterministic synchronization, alignment of simulation time, and full traceability of inputs/outputs.

Empirical-Formula Baseline: This baseline is a deterministic rule set derived from standard ship damage control handbook relations, operating under the same actuator constraints as the DQN (e.g., pump displacement limits, valve switching thresholds) with no additional parameter tuning, and outputting damage control actions solely through preset logic.

5.2. Experimental Results and Analysis

A traditional empirical-formula baseline is compared against the proposed three-stage/four-level framework under coupled breach-induced flooding-fire scenarios; results are summarized in

Table 6. Performance comparison between the proposed framework and the traditional method.

Process Stage	Proposed	Traditional	Improvement
Hull heel angle (°)	4.8 ± 0.3	6.2 ± 0.4	22.6%
Simulation error (breach inflow rate, %)	8.7 ± 0.8	12.2 ± 1.3	28.7%
Fire control time (min)	9.2 ± 0.6	12.5 ± 0.9	26.4%
Decision response time (s)	2.6 ± 0.2	4.8 ± 0.5	45.8%
Pump energy consumption (kWh)	18.4 ± 0.9	22.4 ± 1.1	17.9%
Extinguishing agent consumption (kg)	125 ± 6	150 ± 8	16.7%

Note: Values are mean ± standard deviation. “Relative improvement (%)” = (traditional − proposed)/traditional × 100 and denotes percentage reduction relative to the traditional method.

and Figure 7.

Detailed Results Analysis:

(i)

Heel angle. With real-time pump scheduling, the proposed framework maintains the heel angle at 4.8° (target ≤ 5°), outperforming the conventional method (6.2°). The improved attitude stability results from the multiphysics model that couples floodwater ingress with the vessel’s center-of-gravity dynamics (Figure 8a).

(ii)

Prediction error. Using an FVM-LBM coupled solver for multiphysics co-modeling, the predicted inflow rate (mean 0.42 m³/s) differs from the measured value (0.46 m³/s) by 8.7%, better than the conventional 12.2% (Figure 8b).

Figure 8. Comparison between the proposed (digital-twin-based) control and the conventional method. (a) Hull heel angle. (b) Breach inflow rate. Shaded regions denote error bands. Vertical dashed lines mark key events: breach initiation, detection/alarm, control engaged, proposed/traditional peak inflow, steady-state onset, closed-loop stabilization, and recovery complete.

Figure 8. Comparison between the proposed (digital-twin-based) control and the conventional method. (a) Hull heel angle. (b) Breach inflow rate. Shaded regions denote error bands. Vertical dashed lines mark key events: breach initiation, detection/alarm, control engaged, proposed/traditional peak inflow, steady-state onset, closed-loop stabilization, and recovery complete.

(iii)

Fire suppression time. With a DQN-optimized suppression policy, the average control time is 9.2 min, satisfying the ≤10 min target. The conventional baseline is longer (12.5 min) due to the lack of dynamic adaptation (Figure 9).

(iv)

Decision response time. The DQN model with CUDA acceleration achieves a mean response time of 2.6 s, outperforming the conventional 4.8 s and meeting the ≤3 s target. The reduction is attributable to efficient feature extraction and parallel computation (Figure 10).

(v)

Resource consumption. With optimized pump scheduling and agent dosing, the mean pumping energy consumption is 18.4 kWh and the mean extinguishing-agent usage is 125 kg, corresponding to reductions of 17.9% and 16.7%, respectively (Figure 11).

5.3. Decision-Support Case Walk-Through

Decision support within a human–machine teaming setting is illustrated by revisiting the catastrophic scenario from Section 5.1 (Figure 12).

At t = 180 s, the system automatically generates multiple response options against a global objective and assigns composite performance scores. Option A—prioritizing the starboard pump and concentrated firefighting—achieves the highest score (88), while Option B—balancing dewatering and firefighting—scores 80. SHAP analysis indicates that Option A has marked advantages in maintaining vessel stability (+0.35) and limiting incident propagation (+0.41); therefore, the system recommends Option A.

After reviewing the recommendation, the commander incorporates a field report that “a person is trapped in Port Compartment No. 3,” rejects the preset options, and submits a revised Plan C centered on rescue (prioritizing the port-side pump and dispatching the DC team). The system rapidly simulates the revised plan: although the heel angle temporarily increases from 4.8° to 5.2°, personnel safety is ensured. The human decision is archived in the case base to provide real samples for subsequent reinforcement-learning updates.

This case shows a shift from “machine-assisted human judgment” to human–machine symbiosis. The framework not only delivers quantitative, data-driven decision support but also closes the loop between human intervention and model evolution. When the machine’s efficiency-optimal solution conflicts with human value judgments, the system respects and integrates human decisions, enhancing adaptability and robustness in complex, real-world operations.

5.4. Discussion

Guided by a three-stage/four-level maturity model, the proposed four-layer DT architecture outperforms the baseline in coupled multi-hazard simulation accuracy (8.7% ≤ 10%), real-time response (2.6 s ≤ 3 s), and decision effectiveness (9.2 min ≤ 10 min). The FVM-LBM coupled solver, aided by efficient meshing and parallelization, cuts computational latency by ≈35% (single re-simulation ≈ 1.8 s). The DQN model improves decision efficiency under dynamic conditions—especially for resource allocation (pump power, extinguishing agent)—compared with fixed rules.

Further analysis, limitations, and scalability: Experiments used a simplified, medium-sized vessel (30 compartments) and a single coupled scenario (breach flooding + fire). To gauge scalability without altering the underlying physics, hazard mix, or algorithms, the study increases only the spatial grid to emulate larger structures (≈50 and 100 compartments). As summarized in

Table 7. Key performance metrics under different model complexities.

Scenario Type	Equivalent Number of Compartments	Number of Computational Cells	Coupled Simulation Latency (s)	Flooding-Rate MAPE (%)
Current case	30	150,000	1.8	8.7
Extended case 1	50	250,000	2.5	9.1
Extended case 2	100	500,000	3.8	9.5

and Figure 13, when grid counts grow from 150k → 250k → 500k, end-to-end multiphysics latency increases 1.8 s → 2.5 s → 3.8 s with sub-linear growth, while flooding-rate MAPE remains stable (8.7% → 9.1% → 9.5%, variation < 0.5%). These results indicate computational scalability of the current POD-CNN surrogate and GPU parallelism to geometrically larger meshes. However, they do not establish scalability to fundamentally different ship architectures or to full-scale multi-hazard concurrency and extreme conditions, which may involve different structural/fluid responses and require algorithmic adjustments. Achieving real-time guarantees at full scale will likely require dynamic load balancing, hierarchical decision-making, and hardware upgrades (e.g., multi-GPU clusters).

Human–machine teaming and evaluation: The core mechanism—explicit recommendation–rationale–constraints triplets—aligns system suggestions with operator intent and mitigates automation overreach. In practice, it shortens time-to-consensus, increases adoption and consistency of intelligent recommendations, and preserves traceability without altering existing command procedures.

This study primarily validates end-to-end feasibility and real-time performance in controllable simulation; comprehensive at-sea trials are reserved for engineering follow-up. Additionally, we plan to increase hydrodynamic fidelity by incorporating external wave–ship interactions and more detailed free-surface modeling where warranted. Future work will focus on the following:

(i)

Physical consistency and calibration: use full-scale measurements to calibrate key parameters/boundaries; conduct scaled-platform or pier-side shadow runs to quantify and close the sim-to-real gap.

(ii)

Complex multi-hazard coupling: extend the framework to extreme and concurrent hazards, such as typhoons, explosions, multi-point fires, multi-breach flooding/immersion, smoke spread, and coupled power–structural effects; incorporate co-simulation and coordinated control strategies, together with safety-constrained optimization under common-cause failure conditions.

(iii)

Scenario generalization and robustness: improve generalization across vessel classes, compartment layouts, and operating/sea-state conditions; develop uncertainty-aware sim-to-real transfer with out-of-distribution (OOD) detection; apply parameter perturbation, domain randomization, and fault injection for rigorous uncertainty propagation and robustness assessment.

(iv)

Credible human–machine teaming evaluation and mechanism optimization: introduce objective metrics—time-to-decision, recommendation adoption/coverage, override frequency, and Cohen’s κ—and run controlled experiments in near-ship environments to quantify effectiveness and refine interaction/governance strategies.

(v)

Real-time optimization and deployment: employ model distillation and pruning, upgraded POD-CNN with mixed-precision, and more efficient decision optimizers (e.g., Proximal Policy Optimization, PPO); architect heterogeneous GPU + edge compute with dynamic scheduling, fault tolerance, and graceful degradation; and assess multi-GPU benefits for full-scale inference and multi-source fusion.

6. Conclusions

This study establishes a practical digital-twin pathway for maritime damage control. It delineates the application boundary and capability targets, introduces a three-stage/four-level maturity model to guide deployment, and assembles an implementable stack and workflow spanning modeling, perception, rollout, decision-making, and control—combining GPU-accelerated multiphysics with machine learning/near-real-time optimization—filling the gap of systematic technical solutions for intelligent ship safety deployment.

In representative cases with 30–100 equivalent compartments (150 k–500 k cells), the end-to-end coupled rollout latency is 1.8–3.8 s and the flooding-rate MAPE is 8.7–9.5%. Relative to single-physics modeling, error is reduced by ≈28.7% (from 12.2% to 8.7%), validating the technology’s real-time performance and accuracy in practical-scale scenarios, meeting the timeliness and precision requirements of damage control decisions, and demonstrating engineering deployment potential.

For stakeholders in the marine field, particularly those involved in ship damage control, the findings offer actionable value for risk mitigation: shipyards and naval architects can leverage the framework for design-stage layout optimization to enhance vessel damage resistance from the outset; ship operators and crews gain access to policy-consistent, real-time decision support to formulate scientific response plans swiftly during emergencies; navies and regulators benefit from the maturity model and human–machine teaming practices to standardize the deployment and evaluation of intelligent damage control systems; R&D teams can adapt the lightweight, file-based coupling/data-exchange path to other maritime assets (e.g., offshore platforms) to accelerate the iteration of safety-related technologies.

Next steps follow a cohesive roadmap centered on narrowing the simulation-reality gap, expanding scenario adaptability, and advancing engineering deployment: rigorous calibration and full-scale/HIL validation with quantified uncertainty and parameter assimilation; integrated multi-hazard co-simulation and coordinated control; robustness to condition shifts, sensor dropouts, and noise; trustworthy human–AI teaming with interpretable rationales and operator-in-the-loop evaluation; and real-time, fault-tolerant edge–cloud execution enabling multi-vessel collaborative DTs.

Together, these advances not only endow maritime DTs with fleet-level safety impact but also drive their deep integration with broader maritime safety systems. To accelerate community adoption and reproducibility, key interfaces and data schemas will be released, providing key support for safety technology upgrades in the ocean engineering field.