Maritime Digital Twin architecture

4.1 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 un-connected data sets are generated in the conceptual de-sign 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]).

4.2 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]).

4.3 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]).

4.4 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]).

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]).

4.5 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.

4.6 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]).

5.1 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 environmental 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.

5.2 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. Co-simulation 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 executed 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 co-simulation 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]).

5.3 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 grid-type 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.

5.4 Cyber-Physical Coupling

The Cyber-Physical Coupling (CC) functions as the two-way interface between the Physical Reality and the rest of the DT architecture. The Physical Reality provides real-time 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-to-physical 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 ship-shore 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]).

5.5 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 manage 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]).

5.6 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 higher-level 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 investigation in practical implementation and usage for maritime purposes will be necessary.

5.7 DT Security

Even though the generic domain of cyber-security is a well-established 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]).

5.8 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 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]).