The Green AI for Sustainable Shipping (GASS) project aims to accelerate the maritime industry’s green transition by leveraging AI and data-driven technologies to optimise vessel and voyage energy efficiency. A cornerstone of this ambition is Work Package 2 (WP2), which focuses on developing high-fidelity Digital Twin (DT) models of vessels and voyages. These models will serve as a foundation for advanced analytics, enabling dynamic optimisation and predictive insights that reduce fuel consumption and greenhouse gas (GHG) emissions.

Why Digital Twins?

Traditional voyage planning relies on sparse data and static assumptions, often resulting in suboptimal energy usage. Digital Twins revolutionise this approach by creating virtual replicas of physical assets and processes, continuously updated with real-time data. For shipping, this means:

• Holistic modelling of vessel performance and operating environment.

• Dynamic simulations that account for time-varying factors such as weather, traffic, and port conditions.

• Scalable analytics for predicting the impact of operational decisions on energy efficiency and emissions.

Overview

This section describes the status of each sub-element of the Digital Twin. At the current stage of the project, the Digital Twin can be described by the figure below.

The figure illustrates that the Digital Twin consists of four main elements:

1. Machine learning methods

2. Vessel model

3. Weather routing

4. UX layer – NavStation / NavFleet

And four interfaces:

1. Data → Machine learning methods

2. Machine learning methods → Vessel models

3. Vessel models → Weather routing

4. Weather routing → UX layer

All elements and interfaces have been built and tested in a prototype form.

Status

 For the delivery related to T2.2, the following will be handed over from Simula to NAVTOR.

Main elements

1: Machine learning methods

Five different machine learning (ML) methods have been developed. Each method is specifically suited to one of NAVTOR’s three main client scenarios:

• The ship has no historical data

• The ship has noon report data

• The ship has high-frequency sensor data

A recommendation for which method to use in each of the three cases will follow.

A handover plan is currently being carried out, including method documentation and code reviews, with the aim that NAVTOR can reconstruct and integrate the methods within its own architecture.

2: Vessel model

Vessel models are currently stored as lookup tables. This approach was sufficient for research purposes; however, work has now commenced at NAVTOR to store the models in a format more suitable for a production environment.

3: Weather routing

Weather routing software that identifies the optimal (minimum fuel consumption) route between two points has been developed. The software is currently being deployed to a cloud-based solution and is being further improved with respect to speed and scalability.

4: UX layer

This deliverable does not include any contributions to the UX layer.

Interfaces

a: Data → Machine learning methods

Simula has researched and developed code to preprocess, merge, and enhance the data required to train the ML models. At the current stage, the code includes:

• Static data: Forms have improved data completeness from approximately 57% to approximately 89%.

• Noon data: Code to merge noon reports with AIS and weather data, including a simple up-sampling scheme to align noon data frequency with weather data.

• Sensor data: Code to merge and cross-validate sensor, noon, AIS, and weather data.

A handover plan describing how NAVTOR will incorporate this code will follow next year.

b: Machine learning methods → Vessel models

The initiation and updating of vessel models have not been refined as part of this deliverable. To date, both processes must be invoked manually.

c: Vessel models → Weather routing

A first prototype of this interface, using vessel lookup tables, has been completed. The lookup function handles approximately 200,000 evaluations per second. While this is sufficiently fast, it is not considered scalable. Alternative architectures, including the use of ONNX, are currently under development and testing.

d: Weather routing → UX layer

This deliverable does not include any new developments related to the interface between the weather routing component and the UX layer. Existing NAVTOR technology is currently reused. Once new features are added to the weather routing software, this interface will need to be upgraded.

Conclusion

All components needed for a digital twin system for weather routing have been developed in a prototype state.

Actions to migrate from the prototype platform to NAVTOR's production architecture have started. Meanwhile, each element in the system is being further developed to meet the minimum viable product to enter the market.