Maritime Digital Twin architecture A concept for holistic Digital Twin application for shipbuilding and shipping holistischer

: Digital Twins (DTs) play an important role in current digitalization trends across industries. As maritime markets are particularly affected by recent global tenden-cies such as increasing delivery costs or political pressure for decarbonization, DT solutions could provide important support for shipbuilding and shipping companies to master recent and upcoming challenges. This paper provides a brief insight into the current state of the maritime industry and shows possible use-cases for DT Ship applications throughout the entire product lifecycle. To further advance the general understanding of DTs and their implementation, the concept of a Maritime Digital Twin Architecture (MDTA) is proposed to structure practical DT features.


Introduction
The globally growing digitalization and interconnection of processes and businesses is leading towards a closer gearing of companies, suppliers and customers. As the maritime industry is already confronted with extraordinary complexities present in products and business structures, as well as with increasing delivery costs or pressure for decarbonization, it struggles with widespread digitalization attempts compared to other fields such as the automotive industry or manufacturing (Ludvigsen and Smogeli [17]). Holistic Digital Twin applications can become important tools to tackle these issues and to support digitalization measures significantly (Ludvigsen and Smogeli [17]).
This paper first provides a general insight into the current state of the maritime industry in Section 2 and identifies the challenges it is facing. Section 3 then first gives a brief overview on the current state of scientific debate on the general definition of Digital Twins and proposes one for maritime application. Then, it justifies DTs as solutions for the challenges previously mentioned and gives an overview of related recent development. In order to further incorporate the circumstances of shipbuilding and shipping companies into the ongoing cross-industrial debate about Digital Twins, specific DT concepts for application throughout a vessel's full lifecycle are then distinguished and examples are given in Section 4. Further conceptualization of DT applications is then provided within Section 5 by introducing a new modular and feature-based Maritime Digital Twin Architecture (MDTA). Finally, important research measures are identified in Section 6 that will be necessary to make feasible DT applications and the digitalization of the maritime industry possible.

The maritime industry
With a steady increase of its share in the total value of world trade over the last century, maritime transport remains as a backbone of globalization by serving around 90 % of world trade in goods. With global shipbuilding growing to record highs in recent years, it remains highly competitive compared to other modes of transport with relatively low transportation costs, and continuous improvements in technology and fleet efficiency (Hasanspahić et al. [13]).
Shipbuilding itself on the other hand is one of the most complex processes that can be found among all industries. Projects are scattered throughout many different technical systems, software applications and information silos (Stachowski and Kjeilen [28]). Further, complications can occur from an organizational point of view, manifesting themselves in outsourcing of technical management, manning and complicated ownership structures (Ludvigsen and Smogeli [17]). In combination with low volume serial or one-off productions, this leads to high value-added ratios throughout product development and high losses in case of inefficient design. In addition, increasingly dynamic and unpredictable global markets clash with overall long service times of up to 25 years (Sánchez-Sotano et al. [25]).
Nowadays, shipping is considered as one of the biggest sources of global air pollution with further negative impacts on the environment through discharges of hazardous substances, noise pollution, ship-strikes on sea life and more. With climate change being recognized as the most serious environmental challenge of today, global political pressure on international shipping increases, as it accounts for 2.4 % of global GHG 1 emissions (Hasanspahić et al. [13]).
Such issues lead to increasing competitiveness within the shipbuilding industry on product quality, cost, and delivery, while maintaining flexibility during product development (Sánchez-Sotanoet al. [25]).
With increasing technical requirements, modern ship systems are getting more complex and integrated as well.
Cheaper sensors, increasing data storage and computational power, combined with increased connectivity lead to highly integrated management systems for safety and performance. A vessel's optimal performance depends on all subsystems to work optimally, both individually and aggregated. Maintaining a full overview of all subsystems is becoming increasingly difficult. At the same time, developing an understanding of how these interact and influence the overall system behavior is getting increasingly crucial for a project's success (Ludvigsen and Smogeli [17]). The amount of data already involved in designing, constructing, and operating ships is enormous. The increasing number of parameters involved, with increasing complexity of the subsystems, will further complicate data management and distribution between departments, phases and project partners (Andrade et al. [3]).
The globally ubiquitous trend towards digitalization has long reached the maritime industry as well. As pointed out by Gausdal et al., this digital transformation is driven by the intention to reduce costs and to increase the business effectiveness, as well as by increasing regulation in the maritime industry and the large quantity of data that is already processed. At the same time, they identify high implementation costs, low quality offshore connections, aging decision-makers, an overly technology-oriented culture and lack of investment initiatives, as well as a low level of modern diffusion of digital technology through the supply chain as main barriers for implementation (Gausdal et al. [10]). With this, the long-term digital strategies are generally clear, but the concrete steps required to reach the strategic goals and to overcome the obstacles are blurred (Låg and Brathagen [16]). The challenge is to develop a general concept leveraging the different levels of system specific services, wherein safety and performance of complex integrated systems can be managed from the very first stages of a new project until the end of a vessel's lifecycle (Ludvigsen et al. [18]).

Digital twin ships
Beyond the maritime sector, the IoT, 2 CPS 3 and Digital Twins (DT) are generally expected to form the next generation of digitalized industry (Autiosalo et al. [4]). A similar digital transformation could potentially revolutionize shipbuilding and shipping operations, as van Os points out: Something that would integrate all stakeholders throughout a vessel's lifecycle, including key suppliers and co-makers of the supply chain, as well as classification societies and ship owners (van Os [34]).
Van der Horn & Mahadevan though identified a general lack of a consistent definition and conceptualization of what such a "Digital Twin" truly is supposed to be and how appropriate methods could be applied practically to support an organization's operations. They state that the various use-cases to which a DT system has been associated with have resulted in a wide variety of detailed definitions and frameworks across industries, causing confusion which weakens the general concept and limits its ability to achieve stated benefits (van der Horn and Mahadevan [32]).
After thorough literature consolidation, van der Walk et al. define a typical DT as an identical model of a physical system that receives constant updates and processes data through a bi-directional data link that physically bounds it to its real-world counterpart. Additionally, an HMI 4 and M2M 5 interfaces are also considered as part of the DT (van der Walk et al. [33]). This aligns with the more generalized definition proposed by van der Horn & Mahadevan: They also describe a DT as the virtual representation of a physical system and its environment, that is updated through information exchange between both instances, but do not provide further clarification on more detailed elements (van der Horn and Mahadevan [32]).
While these definitions both claim that a true DT can only exist if a physical instance is constantly exchanging information with its virtual representation, van der Walk et al. recommend DT development even before the existence of the physical counterpart (van der Walk et al. [33]).
Meyer et al. address this early development by their own definition developed at DLR 6 for aviation research purposes: They propose a DT as the virtual representation of a physical or logical object, while it is irrelevant whether this object will only exist in the future, actually exists or no longer exists. As long as the DT represents a physically existing object though, it is supposed to be continuously updated by the current state of the physical counterpart (Meyer et al. [20]). All these definitions show similarities, but still differ noticeably; even on such a generalized level of conceptualization. Clear and detailed definitions on boundaries, interfaces and functional components are still part of the debate but necessary to provide a 4 Human Machine Interface. 5 Machine to Machine. 6 Deutsches Luft-und Raumfahrtzentrum.
clear classification of what constitutes a Digital Twin and to distinguish one DT application from another, as well as from other similar digital technologies (van der Horn and Mahadevan [32]).
For the purpose of this paper, the general definition of van der Horn & Mahadevan will be followed. As most of the product information necessary for developing DT applications is still generated in the design phase, it is understandable why other definitions like Meyer et al. approach DT in a less limited way. While this opens up the usage of DT to a broader spectrum of applications, it can lead to confusion as mentioned by van der Horn & Mahadevan because purpose and context for DT applications can differ significantly, while this information is important to identify necessary functionalities and to raise acceptance from stakeholders.
To further clarify this, the development and usage of DT applications throughout the whole lifecycle of a vessel will be investigated within Section 4 and a more detailed conceptual definition of DT functionalities will be given in Section 5.
Considering the purpose of DT Ships, van Os sees maritime DT applications as a "single source of truth" for a real-world counterpart for structuring, monitoring, and exploiting data. Such DT systems could provide all parties involved immediate and controlled access to a DT system as the main source of product information that is aligned with all ship requirements and synchronized with latest changes and revisions. Such a DT could be based on a 3D model that shipyards develop and is supposed to contain all drawings, production information, calculations, specifications, and certificates (van Os [34]). This is similar to what Autiosalo et al. propose as the main purpose of DT in general: They claim that DT are supposed to link information from multiple features and sources to provide updates and assistance to users in real-time from a single convenient access point (Autiosalo et al. [4]). Such an approach would be a paradigm shift from traditional PLM systems, where information is still mostly used as documentation of decisions and results of isolated lifecycle process stages, and is handled fragmented in data silos (Pang et al. [21]).
In literature, some DT concepts have recently been actively adapted and tested for different technical domains of the maritime industry. Fonseca & Gaspar identify two main groups in which these Digital Twin Ship implementations can be clustered: The first aims towards the operational phase by providing decision support, with a focus on condition monitoring or system behavior simulations calibrated by operational data (Fonseca and Gaspar [9]). Examples for this group are given by Coraddu et al. who estimated speed loss by marine fouling with neural network based DT simulations (Coraddu et al. [6]), or Schirmann et al. who presented a DT for ship motion and structural fatigue estimation due to wave response with the use of weather forecast data (Schirmann et al. [26]). Another proof of concept was given by Major et al. for remote monitoring and crew assistance for offshore crane operation (Major et al. [19]).
The second group uses maritime DT for system integration and testing, as well as personnel training (Fonseca and Gaspar [9]). Tofte et al. for example link a detailed simulation model of the lay tower clamp of a pipe-laying vessel to controllers for hardware testing and operation planning (Tofte et al. [31]). Further applications for ship power system integration by HIL 7 -testing are presented by Dufour et al. (Dufour et al. [8]) or Perabo et al. (Perabo et al. [22]).
These applications are still mostly limited to pilot projects and demonstrators for specific use-cases without generalized conceptualizations or definitions for broader interoperability (Låg and Brathagen [16]). Compared to the purpose proposed by van Os or Autiosalo et al., the main functionality as a holistic source of product information for broad collaboration has not been addressed. Following Ludvigsen & Smogeli, current development activities therefore should focus on defining proper platforms for connecting functionalities in overall DT ecosystems. This is essential to allow all stakeholders to benefit from the information generated in the product lifecycle (Ludvigsen and Smogeli [17]).
In this regard, some commercial software platforms are already available which could be used for maritime DT development. Examples as noted by Taylor et al. include Siemens MindSphere for IoT 2 applications, as well as DNV Veracity built on Microsoft Azure for information sharing and collaboration (Taylor et al. [30]).
To support further development of DT platforms for broader maritime application, the following chapter will provide a holistic view on DT applications throughout all lifecycle stages with the purpose of a single source of information for all stakeholders involved. and data is already generated in the early design phases (Andrade et al. [3]). To properly make use of that information, DT solutions for maritime applications should accompany and support each vessel throughout its entire product lifecycle.

Holistic vessel support
Following the definition of van der Horn & Mahadevan, a "true" DT ship is only feasible in the operational phase in which real-time process and system behavior data of the vessel can be collected and shared with high fidelity simulations. As the development of DT applications can already start in the early stages, it is beneficial to distinguish different stages of DT development accordingly throughout the lifecycle. For this, Figure 1 provides an approach to relate specific DT concepts to product lifecycle phases.
Jones et al. introduce the "Early Stage Digital Twin" for effective information generation and evaluation of proposed solutions and concepts in the design phase through early simulation and analyses. Even though a physical representation of the asset doesn't exist at this point, a single source of information with later use for DT applications can already be built. With this, workflow can be streamlined by improved revision management and control, as well as by early visualization and use of immersive technologies such as VR 8 or AR. 9 Such an advanced datadriven design approach can potentially even lead to automated evaluation of system design choices (Jones et al. [15]).
Grieves & Vickers followed a similar approach with their concept of a "Digital Twin Prototype" that represents a prototypical physical artifact. It is supposed to contain all product information necessary to fully describe and produce the physical version that will mirror the virtual representation. This can include product data such as requirements, an integrated 3D model, material lists, process plans, as well as bills of service and disposal (Grieves and Vickers [12]).
To distinguish the concept of a DT Prototype from the Early Stage DT, the paper at hand recommends shifting the focus of the DT Prototype towards the manufacturing and testing phase, while the Early Stage DT should mainly support the early design stages. As indicated in Figure 1, the transition between the concept is fluid as both represent different maturity levels of the same DT application.
Schluse & Rossmann similarly introduce the term "Experimentable Digital Twin" as fully functioning interactive virtual prototypes for efficient and goal-oriented development, test and verification on component, as well as on system level. As a combination of DT approaches with Virtual Testbeds, Experimentable DTs are supposed to enable examinations of the entire technical system in its intended environment (Schluse and Rossmann [27]).
As the testing and commissioning phase deserves special attention within a vessel's product lifecycle, the paper at hand recommends refining the concept of Experimentable DTs and use it as the next maturity stage in maritime DT development. Such Experimentable DTs would mainly be used for "in the Loop" testing and virtual commissioning purposes.
With the beginning of the construction phase, the product starts to manifest within the physical realm of the shipyard. As tests on subcomponents or system are executed, first connections between the physical asset and the digital simulations can be established.
Shipyards can be considered as complex construction sites that contain large fabrication areas, warehouses, dry docks, slipways, painting facilities and so forth. Therefore, many moving goods and similar looking parts exist. Considering recent development related to Industry 4.0 for manufacturing, the shipbuilding industry is currently developing a similar paradigm by integrating automated tools and processes and creating new demands for more lean production processes to increase production efficiency, improve ship safety and reduce environmental impacts (Pang et al. [21]). While DT applications mainly focus on single products such as a ship, DT ships could interact with a DT shipyard as much as the physical asset does.
After the asset is built and approved by corresponding classification societies, the product is transferred to the client, thereby allowing generation of real-time information regarding system behavior during operation. If most of an existing Experimentable DT could be provided to the shipping company by contract, the already aggregated information could now be further developed into the "true" form of a DT system.
To continue the concept of different DT maturity stages, additional terminology presented by Grieves & Vickers can be used to differentiate DT applications for design & construction from DT solutions for operation: For them, a "Digital Twin Instance" represents a corresponding physical product that one individual DT remains linked to throughout its product lifecycle. In addition to the concepts of DT Prototypes and Experimentable DT, DT Instances additionally contain past, current, and predicted operational data, as well as records of services (Grieves and Vickers [12]). Following this, the term DT Instance could be used for applications where the physical asset enters the operational stage. This would then resemble the general DT by van der Horn & Mahadevan, but should help to avert confusion in DT discussions.
With complex products such as ships, the whole system is usually a network of linked sub-components. Following the approach of a fully integrated value chain for DT systems, it could be possible for suppliers to offer fully developed DT Instances of their components. With corresponding regulation and standardization, such DT Instances could be linked into a holistic DT system. Such a network of DT Instances is then defined as a DT Aggregate (Grieves and Vickers [12]).
Standards developed for IoT 2 applications such as "eclass" could be used for device description, classification and semantic interoperability (Xiao et al. [35]).
After clear distinctions between the different DT concepts presented in Figure 1 have been provided, the follow-ing sections will focus on the characteristic phases of the maritime product lifecycle, and examples of corresponding DT applications and benefits to the stakeholders will be given.

Conceptual design
Main dimensions and most of a vessel's lifecycle cost are defined in the conceptual design phase. Technical documents are prepared by the ship-building company to support the contract with the client (Andrade et al. [3]).
In conventional design processes, usually unconnected data sets are generated in the conceptual design phase, often by copying information from previous assignments with little adjustments to meet the requirements of the new project while keeping development time and costs low. Elements like machinery schematics, hull lines or general arrangements will mostly be designed independently without proof of overall compatibility (Stachowski and Kjeilen [28]).
Ship designers could utilize an Early Stage Twin as the main source of information for collaborative design alongside this holistic approach. A first 3D master model could provide solid and surface representations for fast design checks, simulations, and visualizations. Early Stage Twins could also enable time efficient changes in the downstream processes. With standardized data management, reusing information gathered from past projects could be supported as well to enable improvement in designs (Stachowski and Kjeilen [28]).

Basic & detailed design
After project approval by the client and signing of the contract, the actual design of the vessel starts with the basic design phase. All characteristics, such as re-quired engine power, minimal plate thickness, as well as overall ship structure stability or subsystem design will be defined. As a final product in conventional basic design, a large number of drawings and documentation is generated and provided for project partners (Andrade et al. [3]). As the basic design also addresses the need for class information, corresponding classification documents are created to assure the design will be in line with latest rules and regulations (Stachowski and Kjeilen [28]).
After basic design of overall ship structure and main systems, a detailed definition of advanced elements such as piping, cabling, and outfitting follows in the detailed design phase. All necessary drawings, specifications, components, parts and processes are defined, as well as corresponding data and documentation is generated. Some detailing can occur in parallel with construction activities, as some outfitting elements are assembled at a late construction stage or even later (Andrade et al. [3]).
In conventional detailed design phases, the use of digital modeling tools is already well established. Hull and structure models are done using CAD 10 tools, vessel behavior analyses are supported by CAE 11 tools such as CFD 12 and FEM 13 applications. Electric systems, hydraulic arrangement and human factor analyses can also be supported by CAD software, though not necessarily all by the same tool (Andrade et al. [3]).
An already established Early Stage Twin from the conceptual design phase could easily be supplemented by additional functionality for the whole design process to mature into a DT prototype. With further collaborative support for the design team, shipyard, client and classification agencies, the DT infrastructure can improve information management and reduce redundancies. For example, penetration management could be embedded for collaboration between piping and structural engineering. With proper integration, de-tailed DT models could contain a virtual representation of every physical component and become the main source of information for construction and commissioning, while conventional 2D drawings could still be easily exported for informative support (Stachowski and Kjeilen [28]).

Construction & assembly
In the construction phase, a vessel is usually divided in so called "mega blocks" to be constructed separately at the shipyard. Data generated in the design phase and managed in a DT system of a ship could be easily reused in the construction & assembly phase to generate material and component lists, the construction workflow in the shipyard, and all necessary drawings (Andrade et al. [3]).
While DT applications for general manufacturing are well developed and great amounts of corresponding scientific literature is available, similar maritime applications are very few (Taylor et al. [30]). In the current state of DT implementations, only some ship components are represented virtually, due to the considerable number of sub- assets included in modern vessels. Therefore, shipyards still rely on additional systems and documentation to support the construction & assembly stage (Pang et al. [21]).
Like DT applications for manufacturing, a DT Shipyard system could be developed. Every facility and every moving part could be represented by a virtual twin so material flow could continuously be analyzed and controlled. DT Shipyards can enable engineer and managerial decision making through just in time information, efficient planning, monitoring, prediction, control and, optimization of material flows/supply chain to tackle changes in demand and unforeseen situations. The Digital Twin of the final asset, i. e., the ship, could even be an exportable product of that virtual manufacturing process. It is obvious that such complex and detailed DT Shipyard would impose great challenges for current implementation attempts, but as cross-industry DT technology continues to mature, and enabling technologies are getting cheaper and becoming easier to access, such systems can soon become reality (Pang et al. [21]).

Testing & commissioning
The objective of the testing & commissioning phase is to verify whether the vessel will be able to perform as designed or not. This is done by a series of standardized testing procedures in order to verify all critical project components, such as instruments and equipment, construction specifications and quality, modules and vessel systems. Some critical performance factors (e. g., vibration, comfort, sea keeping characteristics, maneuvering, etc.) are also supervised by classification societies (Andrade et al. [3]).
Approval by classification societies is generally provided if tested components and systems comply with strongly regulated rules based on 2D-drawings, specifications, and functional descriptions. By enhancing traditional system documentation with simulation models provided by a DT system, the commissioning process can be moved towards a verification of functional requirements through model-based approval, thereby benefitting the equipment manufacturers, shipyard as well as the classification societies. For example, some tests in a traditional FMEA 14 of the dynamic positioning systems could be done virtually and the remaining could be executed without the presence of an official surveyor as sensor data from the trials could be run on the DT system to prove a successful test (Ludvigsen et al. [18]).
14 Failure Mode and Effect Analysis.
A model-based approval regime demands for standardized quality assurance and validation of the simulation models used in a DT system. Such standards on model quality assurance have yet to be defined and established in close cooperation with the classification societies (Ludvigsen and Smogeli [17]).

Operational phase
After final approval of the asset by corresponding classification societies, the ship is transferred to the client. This begins the operational phase, which makes up the largest part of a vessel's product lifecycle. In it, the ship will perform its mission and fulfill its intended purpose (Andrade et al. [3]).
In operation, DT applications can become a platform for continuous integration, processing, and analysis of sensor data. Vessel performance data and simulation results can indicate, to the ship owner, valid changes of operational parameters or ship design by refitting for increased efficiency or overall life extension (Ludvigsen and Smogeli [17]).
Reliability of ship systems can also be improved by DT supported CM 15 and CBM. 16 In CM, real-time sensor data is continuously compared to simulations of the DT. Component responses can be used to predict the remaining life of the component. If process parameters critically divert from predicted simulation behavior, faulty system components can quickly be identified before major system failures. Such analyses could be performed by people located on land. CBM uses the real-time condition monitoring to individually plan maintenance measures for critical system components (Ludvigsen and Smogeli [17]).
The real time monitoring further helps in the reporting of critical issues to authorities thereby reducing the burden on the crew, and also helps the equipment manufacturers to monitor the performance of the components and provides feedback for design improvement (Ludvigsen and Smogeli [17]).
Another current trend in shipping aims for vessel autonomy. With advanced position tracking and navigation technology, first autonomous vessel projects are already being executed. While offshore travel control and collision avoidance can be considered less complex than it is for autonomous cars, the challenges again lie within the international character of shipping and establishing corresponding regulations and responsibilities (van Os [34]).
Transitioning from the design & construction phase to the operational phase, the responsibility for the product transfers from the shipbuilding company to the shipping company or the ship owner, who would benefit from the improvement in operation efficiency, monitoring and predictive maintenance.
In the design phase, the shipyard builds its instance of a DT system for product design support. Important product information is defined as well as data is generated and managed in that DT application. This is where one of the biggest problems in modern DT development for holistic maritime applications lie: In the current state, most of this information gets lost by the time the asset is transferred to the customer, who then would have to start building his own version of a DT for operational support (van Os [34]). On top of that, classification societies are involved throughout the whole lifecycle of a vessel, are in continuous exchange of information with shipyards and ship owners and use their own management systems for the same product data that shipbuilders and ship owners use. This continuous exchange and update of product data leads to additional redundancies and further increases the complexity of communication networks already present (van Os [34]).
Efforts would need to be taken to avoid the formation of such silos, and to improve the efficiency of data communication and resource utilization, potentially by standardizing the DT as a single source of product information for all stakeholders while also considering the data privacy and confidentiality constraints.

Decommissioning
With decommissioning, the product lifecycle comes to its end. Once a vessel reaches its service time, it can be refit and recommissioned, sold or scrapped. The responsibility for this phase lies within the ship owner, who must guarantee that the decommissioning process is in accordance with corresponding regulations. This process is highly dependent on market circumstances at the time of decommissioning and is therefore difficult to predict with high accuracy (Andrade et al. [3]).
The ship owner can be supported during the decommissioning phase by a DT system by providing a systemized documentation of hull structures and all materials and equipment used over a vessel's lifespan. Proper handling of environmental and labor safety issues can hereby be achieved (Ludvigsen and Smogeli [17]). Regarding the sale of an asset, all necessary information is already present and can be passed on to potential buyers.
Refitting and recommissioning measures can also be easily documented and integrated into a DT system (Andrade et al. [3]).

Maritime DT architecture
For as long as the idea of Digital Twins has existed, attempts to conceptualize it have been made to distinguish between necessary components and to support the overall discussion. One of the most basic concepts goes back to Grieves' idea of an "Information Mirroring Model", which only consists of a "real space", a "virtual space" and the connection of data and information between them (Grieves [11]). One of the more recent concepts, which has gained a lot of scientific attention across industries, is the "Five-Dimensional Digital Twin Model" by Tao et al. The authors expand upon the general concept provided by Grieves by including "Digital Twin Data" and a "Service System" to emphasize on practical implementation (Tao et al. [29]). With growing interest, as well as with further research and applications in various fields, the understanding of DTs has quickly diverged and basic concepts such as those mentioned before have become insufficient to support it all (Autiosalo et al. [4]).
From the perspective of mechanical engineering, Autiosalo et al. have reviewed the current state of DT research and have proposed a "Feature Based Digital Twin Framework" (FDTF). They have identified several distinct Digital Twin Features (DTF) that are present in existing implementations and have integrated those into their DT Framework. While features such as "Data Storage" or "Coupling" (of real and virtual space) are identical to the concepts mentioned before, many new components are defined that are more focused on a service level. For example, what was defined by the earlier mentioned "virtual space", is now distinguished as "simulation models", "computation", "analysis", as well as "artificial intelligence". Additional features are defined as "user interface", "security" and "identifier" (Autiosalo et al. [4]).
While all five components are linked to each other by individual connections in the "Five-Dimensional Digital Twin Model" (Tao et al. [29]), such an approach would soon lead to inefficient information networks with a growing number of elements. Therefore, the FDTF supports the idea of a central "data link" as an individual feature, to which all other features connect to. With this, a general framework is presented with which various applications can be modeled on a conceptual level by connecting use- case relevant DTF to that central "data link" in a modular and standardized way (Autiosalo et al. [4]).
Based on these ideas, the paper at hand serves as an attempt to further improve the conceptualization of DTs by designing a "Maritime Digital Twin Architecture" (MDTA) as pictured in Figure 2. This is designed with a clear focus on maritime application but is general enough to easily be transferable to different industries. In the following subsections, all individual components will be described in detail and their role for theoretical DT ship application will be highlighted.

Physical Reality
All understanding of DTs is built upon the duality of something physical linked to something virtual. In this MDTA concept, all that is related to the real world is summarized in the component of "Physical Reality" (PR). This can be seen as similar to the "real space" described by Grieves or the "physical entity" of the "Five-Dimensional Digital Twin Model".
Van der Horn & Mahadevan further distinguish between physical systems, physical processes, and a physical environment in their understanding of a physical reality (van der Horn and Mahadevan [32]).
With special regards to DT Ships, a strong distinction between the "Physical Environment" (PE) and the "Physical Twin" (PT) is made as well within the MDTA, where the PT is the physical asset itself, and PE are the environmen-tal aspects affecting the PT. This is because the physical behavior of a vessel is highly influenced by its surroundings such as wind, waves, and general weather conditions. On a single journey, a vessel can undergo multiple drastic changes in its environmental conditions, which all need to be considered in the design process of a new vessel, as well as in its operational stage. Therefore, a good understanding of the PE is crucial for a holistic lifecycle support of ships. All characteristics of the product itself on the other hand, as well as its overall behavior is summarized in the concept of the PT.
The PR is the space in which necessary information of the physical asset and its environment is collected and provided for other DT components to be used as input for simulations and analyses within the MDTA.

Cyber Reality
As already mentioned, no full DT concept is complete without some sort of virtual counterpart to a physical product. To continue the idea of a "Physical Reality" that consists of a "Physical Environment" and a "Physical Twin", this constellation is directly mirrored in the MDTA in a so called "Cyber Reality" (CR). Like the concept of the "virtual representation" from van der Horn & Mahadevan, the CR consists of a "Cyber Twin" (CT), as well as the "Cyber Environment" as a virtual abstraction of the "Physical Environment" (van der Horn and Mahadevan [32]).
The virtual representation of the physical asset is named "Cyber Twin" in the MDTA to avoid conceptual confusion with the term "Digital Twin". While the virtual representation is often explicitly meant by "Digital Twin" in the literature, the same nomenclature is used for the whole concept as the duality of real and virtual asset as well. Using the term "Cyber Twin", which is directly borrowed from Czwick & Anderl (Czwick and Anderl [7]), a clear distinction between the "Digital Twin" (DT), as the overall concept and the "Cyber Twin" (CT), as the virtual representation of the specific product is made possible.
This "Cyber Reality" (CR) is the space in which virtual models as abstract representations of the real product and the physical environment are defined and built in the early stages of DT development and later used in system behavior simulations. For this, CR components of potential DT solutions could provide additional functionality for system simulation modeling and execution. To distinguish the Cyber Reality from other components of the MDTA, it has to be stated that the main functionality of the CR lies within the virtual representation of dynamic system behavior of the Physical Twin. For this, it will make use of static data provided by the Digital Twin Data component as well as by the Physical Reality, and forwards simulation results back to the DD-component (e. g., in form of newly defined simulation models or simulation outputs) and to the Service System for further analyses and visualization.
It becomes clear that every virtual representation of reality is inevitably a simplification to a certain degree, no matter how detailed it may have been designed to be. Therefore, the level of abstraction urgently needs to be considered in the modeling process and is usually dependent on the intended application of the DT. If the Cyber Twin, as well as its interaction with the Cyber Environment is modeled properly, the behavior within this Cyber Reality can be simulated, thereby forming the foundation for most applications of the DT.
Since products such as ships can be considered overly complex networks of subsystems and subcomponents, the modeling process of the Cyber Twin is no trivial task. Building monolithic or centralized models that represent the full system can quickly lead to performance issues and complicate changes on the system or integrations of additional components in the modeling process. Therefore, the concept of "co-simulation" takes an important part in the development and implementation of DT Ships. Cosimulation is a technological approach, in which complex simulation models are constructed by connecting individual models of sub-systems and/or components that are then simulated in a standardized co-simulation environment. In such a configuration, each model is being exe-cuted independently and shares information only at discrete timepoints. With appropriate standardization, such sub-component models (e. g., thrusters, engines, boilers, etc.) can be developed independently from specific software solutions, as well as model sharing, reusability and a fusion of simulation domains can be encouraged (Hatledal et al. [14]).
There are two notable standards for co-simulation that currently gain cross-industrial interest: HLA 17 that is mainly used for discrete event co-simulation, as well as FMI, 18 which is more focused on continuous time co-simulations (Hatledal et al. [14]). One noteworthy cosimulation environment especially designed for maritime applications is the OSP, 19 which as of June 2021 is still in development since 2019 by a Joint Industrial Initiative consisting of DNV GL, Kongsberg Maritime, SINTEF Ocean and NTNU. 20 Based on the FMI standard, this approach aims to provide a standardized open-source ecosystem for the maritime industry to perform co-simulations, as well as to share models in an efficient and secure way (Hatledal et al. [14]).

Central Information Point
The "Central Information Point" (CI) of the MDTA is mainly based on the "Data Link" concept, first presented by Autiosalo et al. as part of their "Feature Based Digital Twin Framework" (Autiosalo et al. [4]). It provides a star-form communication network by working as a single hub for all information that is shared within the DT application. Based on a product-centric information management concept, it improves DSM 21 by reducing the overall number of necessary data linkages from general unstructured gridtype networks. It also supports the generalization and modularization of DT structures by providing standardized interfaces for DT Features to connect to. It can also provide a list of all connected nodes as it functions as a single access point to the information system. On a bigger scale, this approach can even support the management of multiple DT Instances or even DT networks (Autiosalo et al. [4]).
The concept from Autiosalo et al. was then further developed by Ala-Laurinaho et al. in form of an Application Programming Interface (API) gateway for practical implementation. This gateway simplifies the system communication between DT services by authenticating and forwarding messages to the DT services. Ala-Laurinaho et al. validated their work with an implementation for an industrial overhead crane, connecting operational data, control and CAD-models provided by commercial sources like Siemens "MindSphere" for historical data as well as Siemens "Teamcenter" as a PLM system, "TRUCONNECT" provided by the crane manufacturer as a service for remote monitoring, an OPC UA 22 server for real-time crane monitoring and control, "OSEMA 23 " for retroffited sensor management and "Regatta" as a IoT platform for additional historical sensor data and advanced analyses. With this use-case, the authors compared the performance for reading and writing information through the established Data Link to direct communication with the respective systems. It was shown that the usage of their Data Link solution resulted in a significant latency increase. Because of this, Ala-Laurinaho et al. recommend latency dependant functions like control or monitoring applications to communicate directly with the physical product (Ala-Laurinaho et al. [1]).
This use-case shows that further research on efficient communication management within DT applications is necessary. The potential benefits of DT system modularization, as well as easier component integration and management have to be evaluated compared to resulting added latency. The intended functionality of the Central Information Point within the MDTA is similar to the approach of Ala-Laurinaho et al. Even though a holistic software framework that contains all components of the MDTA is a promising goal, a modularized approach that is able to support systems already implemented by customers will raise general acceptance of the DT solution.

Cyber-Physical Coupling
The Cyber-Physical Coupling (CC) functions as the twoway interface between the Physical Reality and the rest of the DT architecture. The Physical Reality provides realtime sensor data of the current state and behavior of the Physical Twin through this connection. Meanwhile, the simulations within the Cyber Reality and service applications can send control signals to influence the processes of the real asset. This coupling is what distinguishes true DT applications from regular simulation models (Autiosalo et al. [4]). This Cyber-Physical Coupling can further be distinguished in physical-to-virtual connection and virtual-tophysical connection. At the level of raw data collection in the Physical Reality, modern sensor technology as well as the IoT are of interest for DT applications. The raw data is then usually processed, curated, and converted to provide information that is easier to interpret. If the Physical Systems and Processes are complex and extensive, sending all curated sensor data through the CC can quickly lead to performance issues or even data loss. Therefore, depending on the use-case, further information fusion might be necessary so that only a reduced volume of condensed data is provided (van der Horn and Mahadevan [32]). As ships are usually operated far away from data centers on land where the Cyber Reality is simulated, this CC needs special attention in maritime applications. There is always a balance between refining data on board and sending only compressed results to shore, or refining the data on shore, which would require more bandwidth usage but in a more cost-efficient environment (Låg and Brathagen [16]).
While the definition of stringent requirements, performance standards and type approval programs for shipshore communication, which is used for safety purposes (e. g., GMDSS 24 ), are part of current research in the maritime community, very few such protocols exist for other communication purposes. Applications of holistic DTs for shipping purposes will strongly rely on the availability and reliability of a stable and secure broadband Cyber-Physical Coupling, which needs to be addressed by further research as well as regulation and standardization (Låg and Brathagen [16]).

DT Data
All DT applications are based on large amounts of virtual information processing. From the recorded data of the Physical Reality to model and simulation data of the Cyber Reality or results from further analyses, all generated information must be stored, provided, and managed somewhere. Within the MDTA, this functionality is located within the "DT Data" (DD) component. While first preprocessing can be carried out directly at the point of data generation (e. g., onboard), most of DT-related information should be stored and managed centrally to reduce redundancies and to provide fast and easy access for all connected DT Features (Autiosalo et al. [4]). Considering DT as a single source of product information for all stakeholders to access, the DT Data component has to man-age various information types like drawings and design information, hydrodynamic or strength analysis data, tank test measurements or sea trial results, as well as operational, performance or inspection data. For this, Berre & Rødseth presented the "Maritime Data Space" (MDS) as a conceptual model derived from the land-based IDS 25 concept. This MDS consists of three levels of functionality: Trusted service provision, secure and efficient communication, as well as data management and governance (Berre and Rødseth [5]). Compared to the proposed MDTA concept, the MDS already considers promising functionality similar to not only the DT Data component, but also the Cyber-Physical Coupling, DT Security and the Service System. With this, an integration into a broader DT solution might be valuable.
To elevate functionalities beyond the capabilities of available PLM system approaches, Pang et al. propose to apply the concept of the Digital Thread for maritime applications: It describes a data-driven architecture that links all information generated and stored within a DT solution consistently through all lifecycle stages (Pang et al. [21]).

DT Identifier
As every physical asset is a unique entity, it is usually only represented by one individual Cyber Twin as well. The feature of a "DT Identifier" (DI) as proposed by Autiosalo et al. is supposed to unambiguously link a Cyber Twin and its application to the Physical Twin. The concept of a DI can further be divided into two categories: Physical identifier and digital identifier. Physical identifiers represent the DI in the Physical Reality and enable local access to the connected DT system. A digital identifier on the other hand is used to identify a Cyber Twin or DT application in a higherlevel DT network and provides direct access to it (Autiosalo et al. [4]).
As on a conceptual level, the DI component within the MDTA contains both physical and digital identifier, it is supposed to represent the whole DT system, that's why it is called the DT identifier. In maritime applications, this may be of use in fleet orchestration applications to organize multiple assets in a fleet system DT use-case, or could be of importance when suppliers could provide defined and standardized stand-alone DT of system components, that could then be individually identified on-board as well as within a hierarchical DT Ship structure. As this component of the MDTA is still on a more conceptual stage compared to other components presented, additional investi-25 Industrial Data Space. gation in practical implementation and usage for maritime purposes will be necessary.

DT Security
Even though the generic domain of cyber-security is a wellestablished field with good standardization and plenty of literature, Autiosalo et al. state that the cyber-physical security required for DT applications is still a new topic in current research activities. CPS 3 such as DTs are especially vulnerable due to their heterogenic structure. Proper standardization or implementation guidelines are still missing. Safety and consistency are vital requirements when implementing DTs, as they will be deeply integrated into cyberspace networks. For individual DT applications to become truly secure, the security aspects must be embedded into the DT structure itself in the form of a "DT Security" (DS) feature. Appropriate risk analyses can then be performed, and security levels be developed for individual use-cases (Autiosalo et al. [4]).
With the DT system providing all stakeholders access to product information throughout a vessels lifecycle, protecting IP 26 from loss, leak and theft becomes an issue as Pang et al. identify. Therefore, solutions like role-based access control, digital watermarks, Data Leakage Prevention and Enterprise Rights Management have to be considered (Pang et al. [21]). In the Maritime Data Space proposed by Berre & Rødseth for example, data owners directly control access rights independently of where the data is stored (Berre and Rødseth [5]).

Service System
Based on a similar element of the Five-Dimensional Digital Twin Model by Tao et al. [29], the "Service System" (SS) of the MDTA combines all service-related applications of the DT structure and is the only interference point for end-users to access the DT. For this, the SS functions as its own service platform of the application. User input is processed, and relevant information is sent to the Central Information Point to be distributed to the corresponding DT features. In the same way, data from the DT Data component is provided to the end-user through the Service System.
The UI 27 itself is an important sub-component of the Service System feature. It provides the end-user with the 26 Intellectual Property. 27 User Interface. ability to interact with the DT system. The design of a DT UI is always case-specific and personalized for each user group, depending on their needs and permissions. A lot of current DT applications use web-based UIs, as they are easy to access independently from specific terminals (Autiosalo et al. [4]).
Another approach worth mentioning is the usage of already present 3D product representations for UI integration. VR or AR approaches can provide improved functionalities, depending on the specific use-case (e. g., condition monitoring or crew training). An essential service provided by DT systems is based on various analyses of systems and their behavior. Making use of provided data from the Physical Reality, as well as results from Cyber Reality simulations, correlation or sensitivity analyses can provide approaches for decision support or system optimizations as part of the MDTA Service System as well. Depending on the complexity of processes, analyses can also be supported by AI 28 or ML 29 technology. In advanced applications, AI can even enable intelligent DT with the ability to control system behavior of the Physical Twin autonomously (Autiosalo et al. [4]).

Outlook
As shown, DT systems promise great potential for shipbuilding and shipping applications. They could support decision making, lead to reduced production and operation costs, lower risks, as well as improve efficiency, service offerings, security, reliability and resilience (van der Horn and Mahadevan [32]).
They could demonstrate that technologies and processes comply with national, international and industrial regulations and standards and could provide technical assurance of new or modified technologies. DTs are a concept that could enhance information management and improve collaboration to prevent costly mistakes and rework if implemented properly (Ludvigsen and Smogeli [17]).
For the shipbuilding industry specifically, they could integrate and connect domain-specific data from all stakeholders involved in the product lifecycle. Equipment manufacturers for example could make use of such DT systems by facilitating system integration, demonstrating technology performance, perform system quality assurance and promote additional services for standardized monitoring and maintenance (Ludvigsen and Smogeli [17]).
For shipowners, DTs could provide detailed visualizations for ship-and subsystems, qualification and analytics of operational data, optimization algorithms of ship performance, improved communication, safe handling of increased autonomy and safe decommissioning. DTs can also offer a systematic framework to provide live information and required reports to authorities and classification agencies (Ludvigsen and Smogeli [17]).
While benefits of such DT systems for the maritime industry have been identified, many challenges still need to be solved before broader implementations will be profitable. At such a scale, assurance of data quality and data management, as well as data privacy and security are still an issue. Another problem lies within stable real-time data streaming across long distances with low latency (Rasheed et al. [23]). Similar to "smart shipping" approaches, maritime DTs are also prone to vulnerability and instability because of the extreme complexity of the system. Unforeseen internal or external disturbances can lead to a complete collapse of the single source of project information. Reliable and flexible system management of this scope is exceedingly difficult in general. With burdens like these still present within the maritime industry, companies are especially reluctant to accept high-risk innovations such as DTs (Alop [2]).
Accordingly, further essential research measures are necessary before marketable DT solutions can be established for the maritime industry. Besides moving the discussion forward on general DT terminology and conceptualization, great efforts regarding standardization are necessary to develop an environment for all partners involved to further improve work on connected DT solutions (van der Horn and Mahadevan [32]). Rosen et al. draw further attention to necessary definitions for quality and level of detail of simulation models, as well as to standardization on simulation model know-how security and virtual commissioning. Besides that, efficient and reliable co-simulation solutions and simulation model modularity still need further improvement. In terms of technical implementation, further work on generalizing multifunctional simulation platforms is necessary and usage of already generated 3D planning data needs to be improved (Rosen et al. [24]).
In order to achieve this, previously unconnected data sources need to be connected and corresponding data infrastructure and data management needs to be developed (van der Horn and Mahadevan [32]).
But to gain full advantage of future DT solutions, important factors must be in place on the side of customers and the industry in general as well. General competence in terms of digitalization needs to be further developed. Some fundamental changes in organizational culture will be necessary and most companies even need to open up to new business model ideas (Ludvigsen and Smogeli [17]).
With the Maritime Digital Twin Architecture presented by this paper, many issues discussed have been addressed on a conceptual level. With the intention on providing a open-source and modular software framework for broad industrial application, further development of the MDTA, as well as validation through representative use-cases will be part of research activities by the DLR Institute of Maritime Energy Systems within the next years.

Conclusion
While multiple DT applications for different product lifecycle phases either have already been presented or are currently in development, and their benefits for various stakeholders involved are identified, their technological maturity and industrial acceptance still need to be improved fundamentally. With obstacles present within the maritime industry, potential stakeholders are either challenged with or skeptical against expensive and groundbreaking projects like the adaptation of holistic DT solutions.
With this paper, the importance of Digital Twins for the maritime industry is shown and examples for full lifecycle asset support applications are given. To help streamlining the ideas on DT terminology, a concept for a generalized Maritime Digital Twin Architecture is developed and the importance of its features is presented. Also, necessary research activities are identified to help on further improving DT solutions for the maritime market. With this, DT applications can become an important part for transforming traditional maritime businesses and advance them towards a highly connected and digitalized future.