Digital Twin for Autonomous Surface Vessels: Enabler for Safe Maritime Navigation

In plain words

A digital twin is a software copy of a real machine that is kept in step with it. For a ship that can steer itself, the copy lets engineers test decisions in simulation before the real vessel acts on them. This paper asks what such a copy needs for a self-driving boat and sorts the answer into six levels, from a copy that is only a 3D model to one that closes the loop and steers the boat.

Each level adds a capability. The lower levels need sensors, models and condition checks. The higher levels predict what will happen, test "what if" options and finally control the vessel. The authors then list the technologies that already exist for each level: ship simulators, radar and camera sensors, filters that combine sensor readings, engine health monitoring, route forecasting, and the controllers used on boats.

The paper does not build a digital twin and does not test one. It is a map of the field, with recommendations for industry, regulators, classification societies, researchers and the public.

TL;DR

• The paper adopts a definition of a digital twin as a virtual representation for real-time prediction, optimization, monitoring, control and decisions, and sorts autonomous surface vessel (ASV) digital twins into capability levels 0 to 5 §1 §2.
• For each level it surveys enabling technologies in prose, with citations to other work §4.1 to §4.6.
• It runs no experiments and reports no new numbers. Figures quoted in the paper come from the cited works §4 §1.
• Its literature-search method names four databases and keyword groups, but not the date range, hit counts or inclusion rules §3 tab. 1.
• Use it as a checklist of enabling technologies per level. Do not treat it as a validated architecture, because it gives none.

Problem

Autonomous ships can cut fuel use and emissions and reduce accidents caused by human error §1. Testing them at sea is risky, so the authors propose a digital twin as a safe place to test operations before they run on the real vessel §1.

They argue that a digital twin should not be only a CAD model or a basic simulator. It needs live data, prediction and control to support autonomy §1 §2. The paper says there is no single framework for this in the maritime field and sets out to define one by levels §1 §5.

Assumptions and limits stated in the paper:

• Autonomous ships are described mainly through the public sector, with private operators mostly running human-driven ships §4.1.3.
• The level scheme is adapted from earlier work from DNV and from Stadtmann et al. §2.
• The authors state that the enabling technologies exist at every level but vary in maturity §5.

Method

The paper is a narrative review with a capability-level taxonomy. It has no algorithm, model, training procedure or equation. Section numbers below follow the LaTeX section order, since the source has no printed section labels.

Definition and levels §2. The authors adopt the digital-twin definition given by Rasheed et al. (2020): a virtual representation of an asset or process, enabled by data and simulators, for real-time prediction, optimization, monitoring, control and decisions §2. The six levels are:

1. Level 0, standalone: a 3D geometric model and simulations, possibly with no data link to the asset §2.1.
2. Level 1, descriptive: a one-way data stream from the asset to the twin. Models refine and fuse the data and estimate quantities that are hard to measure directly §2.2.
3. Level 2, diagnostic: condition monitoring and cybersecurity monitoring of the asset and its network §2.3.
4. Level 3, predictive: forecasts of future states for maintenance and process optimization §2.4.
5. Level 4, prescriptive: "what-if" simulation of operating strategies to pick the one with the lowest risk or highest efficiency §2.5.
6. Level 5, autonomous: a two-way link in which the twin both receives data and controls the asset in a closed loop §2.6.

The levels are drawn in fig. 1 §2.

Literature search §3. The authors describe a three-step process:

1. Define search queries from keyword groups. The core keywords are the digital twin term and the vessel and autonomy terms. Alternative keywords add topics in control, data volume, security, navigation tasks, sensing and tracking, health checks, the collision rules, standards, sea conditions, forecasting and model types §3.
2. Search four databases: Scopus, Web of Science, ScienceDirect and IEEE Xplore. The paper compares them in tab. 1 §3.
3. Remove duplicates and off-topic items by reading titles, abstracts and keywords, then review full texts §3.

Survey by level §4. The authors organise the survey by the six levels:

• Level 0 §4.1: 3D modelling with B-splines and CAD §4.1.1; physics-based simulation, including finite elements, hydrodynamics, manoeuvring, weather routing, fuel-speed optimisation, collision risk, port operations, emergency response, oil-spill and emissions models, and training simulators §4.1.2; and maritime standards, namely IMO MASS work and COLREG §4.1.3.
• Level 1 §4.2: sensors, namely GNSS, AIS, IMU, cameras, radar, LiDAR, sonar, weather sensors, microphone arrays and infrared cameras §4.2.1; sensor fusion with Kalman, extended Kalman, unscented Kalman, interacting-multiple-model and factor-graph methods fig. 2 §4.2.1; situational awareness, covering target tracking, state estimation, and estimation of waves and wind fig. 3 §4.2.2; and hybrid physics and data-driven modelling fig. 4 §4.2.3.
• Level 2 §4.3: condition monitoring for vibration, lubricant, temperature, structural health, acoustic emission, performance, IoT and corrosion, plus data-analytic methods §4.3.1; and cybersecurity threats and mitigation §4.3.2.
• Level 3 §4.4: predictive models for voyage time, fuel, emissions, equipment failure, weather routing, cargo arrival, demand, port congestion, crew, market trends and cyber threats. Each is named with citations and no equations §4.4.
• Level 4 §4.5: prescriptive uses for route optimisation, maintenance scheduling, crew management and regulatory compliance. Section 4.5 has no citations §4.5.
• Level 5 §4.6: a conceptual diagram of an autonomous twin, with real-time and offline links fig. 5 §4.6; path following and collision avoidance with MPC, reinforcement learning and hybrid MPC-RL methods §4.6.1; and control families: PID, LQR, backstepping, sliding mode, adaptive, MPC, learning-based, fuzzy and swarm control §4.6.2.

Conclusions and recommendations §5. The authors argue that the technologies for every level exist §5. They list opportunities in safety, cost and sustainability §5.1, and challenges in data and communication, security, modelling, regulation and industrial acceptance §5.1. They end with recommendations for six stakeholder groups fig. 6 §5.2. These recommendations are the authors' opinion and carry no citations.

Literature-search query (paper's keywords, our reading) §3. The paper gives no exact query string. The sketch below turns the keyword groups into one boolean query per alternative group. The combination rule is our reading: the paper says the core keywords were "primarily combined" with the alternative keywords and does not say how.

# Literature search queries  [§3]
# Input:  core topic term, vessel terms, autonomy terms, alternative groups
# Output: one boolean query string per alternative group

def build_queries(core_topic, vessel_terms, autonomy_terms, alternatives):
    # Core keyword pair: the topic, and the vessel-and-autonomy phrase  [§3]
    vessel_phrase = join_or(vessel_terms)
    autonomy_phrase = join_or(autonomy_terms)
    queries = []
    # Each alternative group is paired with the core pair  [§3, our reading]
    for group in alternatives:
        query = (f'"{core_topic}" AND ({vessel_phrase}) AND '
                 f'({autonomy_phrase}) AND ({group})')
        queries.append(query)
    return queries

Hyperparameters

Not applicable: this is a review with no trained or tuned model. The table lists the numeric and procedural settings the paper does state for its review.

Results

Not applicable: no experiments, benchmarks or new measurements are reported. The paper gives its own taxonomy and a literature map instead of results. The table lists the numbers the paper quotes from other works, which are the closest to results. They are not the authors' findings and are not tested here.

Paper vs code

No official code.

I searched in this order. The arXiv abstract and the LaTeX source contain no code, repository or project-page link. The paper is a review and describes no implementation. A GitHub repository search for "digital twin autonomous surface vessel" returned one repository, owned by a third party and not by the authors, so it was not used. A GitHub search for "Menges vessel" returned none.

Pitfalls

• The abstract promises a framework the body does not give. The abstract says the paper "introduces a comprehensive methodology for establishing a digital twin framework". The body gives a taxonomy and a survey, with no architecture, data flow, interfaces or validation §1 §2. Do not implement a framework from this paper alone.
• Dimension count is inconsistent. The data challenge is called the "5Vs" in the level-1 section (volume, velocity, veracity, variety, validation) and the "4Vs" in the conclusion (volume, velocity, variety, veracity) §2.2 §5.1.
• A typo in a method name. The text names "scale-invariant feature transform (SWIFT)"; the usual name is SIFT. The cited work may use either name, so check the source before using the term §4.2.2.
• The search method is incomplete. The paper gives no date range, hit counts, screening rules or number of reviewers. The survey cannot be reproduced from the text, and the coverage is unknown §3.
• The search string is not given. The paper gives keyword groups and a generic Boolean example, not the query run in each database. The sketch above is our reading and not the authors' query §3.
• Several claims lack citations. The prescriptive level §4.5, parts of the Level 3 list, the Level 5 conceptual figure fig. 5, and the stakeholder recommendations §5.2 carry no citation. Treat them as the authors' opinion.
• The level scheme is adapted, not standard. The authors state they adapt the levels from DNV and from Stadtmann et al. §2. The level boundaries are judgement calls, and a single system may fit more than one level.
• Level 3 has a conceptual gap. The text says a predictive twin focuses on future states "since no data exists beyond the current time" §2.4. This describes forecasting but does not explain what data a predictive twin uses.
• Some numbers are old or from other domains. The fuel saving and sensor counts come from older or other-domain works, and the paper does not state the conditions under which they hold §4.1.2 §4.3.1.
• Safety claims are argued, not measured. Statements that the twin reduces accidents, cost and emissions §5.1 are not backed by any experiment in the paper.
• Level 5 control methods are listed, not compared. The control families in §4.6.2 are named with citations but no performance comparison is given.
• Figure-number cross-references use the LaTeX order. The figures are cited here by their order of appearance in the source fig. 1 to fig. 6. Check the rendered paper before quoting a figure number to a reader.

Lineage

• Builds on: the digital-twin definition of Rasheed et al. (2020) and the capability-level scheme from DNV-RP-A204 as refined by Stadtmann et al. (2023) §2.
• Compared against: other maritime and marine digital-twin and simulation work, cited inside each survey section §4. The paper does not compare its own taxonomy with any alternative taxonomy.
• Superseded by: none known from this wiki.