Digitalisation is a hot topic today in ship design and operation. For ship owners and operators in general, monitoring ship performance and learning from past behaviour can result in direct savings in fuel costs or anywhere else in the logistics chain.

Once the necessary data gathering for this has been automated and digitised, this presents huge possibilities for improving ship systems further. This is where a digital twin comes in the picture. Digital twins are also an important topic in the joint industry research project INTENS in which we are currently participating in Finland together with several research and maritime industry partners.

Last spring at our home university, Aalto University, my colleague and I were participating in a research seminar related to digital twins. We were all presenting to each other our own research and how it was related to this interesting buzzword of today. My presentation was more about explaining our new ship heat utilisation efficiency analysis method but, in this context, I also discussed also our energy modelling methods during ship concept design. During the discussions, I realised that our intention was never to build a digital twin in the sense that many seem to understand the concept.

What is a digital twin anyway?

To my knowledge, there exists no exact definition of a digital twin, but during our seminar week I came across a few quite good definitions for it: it is a virtual entity that has a link to a real-world entity such as a ship. Also, the digital twin is one entity that can be a combination of several systems linked together. Since the digital twin is a virtual counterpart of a real-life object, it must be constantly available to ensure a constant flow of data. The added value of a digital twin lies in the fact that it provides a single point of access to a system that can be very complicated, and it enables various types of analysis.

A ship’s digital twin can be utilised, for instance, for designing autonomous ships, analysing the quality of the processes for predictive maintenance or analysing the potential for retrofits. Also, the ship operation could be optimised in various environments, pretty much in the same way as holistic ship simulators are used for training captains. A ship’s digital twin can also help to develop even better ships in the future, once operating patterns and interactions are handily available for the next-generation ship design. It is thus easy to understand why there has been such a fuss about digital twins, even in our domain of work. They might be very useful for various stakeholders during ship design, building and operating phases.

Why don’t we then have ship digital twins available from the start if they are so great?

First of all, to create a real-time holistic model of even a ship engine – not to mention the whole ship – is a huge effort. Also, the availability and ownership of the necessary details and data for the model are divided between various parties during the lifetime of a ship. This alone leads one to a conclusion that, since both the benefits and “building blocks” of digital twin are scattered among many players, compiling the digital twin should also be a common effort.

Furthermore, for me, the real issue from the ship design perspective is that if we wait to be able to build our digital twin until the operational phase, we are running late. The reason is that if we want to make the largest possible impact on a ship regarding her environmental performance, energy efficiency or total costs, the key decisions are made long before the ship or her digital twin are born, during the early concept design phase. During concept design, we make decisions within a short time that ultimately determine how good the ship can perform. Basically, we should harvest many of the above-mentioned potential benefits of the digital twin before we can compile it.

What does this mean in practice for ship design?

In a successful concept design process, we should utilise all information we can get regarding the ship’s intended operation, predicted performance and various other aspects such as available fuels and equipment. Looking back, it is nothing new to utilise existing reference data as a starting point for conceptual design, but what is new is that the world and the entire shipbuilding industry around us are digitalising. This means, for example, that the same measurement data and digital models of equipment or processes that could be part of an existing digital twin, can also be utilised to support the conceptual design phase of a new ship.

Having read some recent articles, blog posts and newsletters, it is not just we who have realised that we should look beyond (or perhaps before?) the digital twin to make the most of the whole thing. There is even a name for a concept where digital twins, their real-life twins and the digital models existing before them are connected during the product life cycle. The holistic view provided by the information connecting these items is called a digital thread, so it is actually the digital thread that we should aim for, not necessarily the digital twin in the first place.

Digital thread for ship design

Everything starts with understanding the requirements set for the new ship project, which are usually related to maximising the number of cargo units to be transported within the operating area. In the light of the current and future targets for ship environmental performance and other elements of the regulatory landscape, the requirement set can be a rather complex one. This is what my colleague was referring to when he was discussing future-proofing the ship. In simple terms, the ships designed today should be excellent at good performance, not only today but also in selected, alternative operating scenarios in the future.

To realise this, we need to be able to design the ship from the start with a “toolbox” where we can digest the available data for the ship and analyse the variations efficiently and quickly. Interactivity with the customer is a very important aspect since we should together decide on the design basis and the most relevant focus areas. For example, this can mean the fuel and technology choices for the ship. Another key area to keep control over is the total costs of a ship. For example, preparing for future fuels or operating scenarios does not have to generate great additional costs during ship-building, but evaluating this is an important part of the process.

For the past three years, our development team at Deltamarin has focused on solving these challenges. What we have found is that an efficient process does not consist of one single program or tool but of layers. The digital model of the ship that can ultimately evolve into its digital twin consists of the early design phases of the most relevant areas of ship design. We have been focusing on three main topics during concept design: energy and environmental performance simulations, the ship’s volume and structural model and the data layer where we combine the wind-, wave- and other measured data into the ship model to estimate its lifetime propulsion power profile. You can read more about that here.

To conclude, I am confident that the future of ship design is in the data-driven design process, where we can form a digital thread between the early demands and targets for the project and the real operating ship. Even though a ship and her systems are dimensioned to certain design conditions such as “extreme” climate and seaway conditions and to a certain maximum speed, the system optimisation should be done for the most common conditions.

And this takes me back to our seminar on digital twins… Now I have a name for the work that I was presenting in the first place. It would be the early phase of forming a ship’s digital thread. We haven’t been consciously aiming to build a ship’s digital twin but were rather searching for solutions to deal with the possibilities of digitalisation and the simultaneous challenges of handling complex entities and large amounts of data. Even though we have already been creating a strong base in this field, I feel that we have only scratched the surface… Later this spring I will also let my development colleagues share a bit more of our experience in this field and about our new ideas. Welcome aboard!

Want to read more? See also our other published blogs.