Similar But Not Identical: How Digital Twins Can Serve Class And Designers

Demand for data that can inform strategies for asset management and performance monitoring is driving the wider adoption of digital tools in shipbuilding. Vessel designers are increasingly able to employ a software-driven approach that creates efficiencies and satisfies compliance.

Shipowners want visibility on assets over their lifecycle, and as the era of planned maintenance routines gives way to predictive interventions, shipyards are turning to 3D models to create digital twins to support decision-making.

This transition also reflects growing demand for review and approval of the design by class, using a common standard for data exchange.

Managing these complimentary demands requires a detailed understanding of the process for both vessel design and class review – and the differences that can leverage maximum functionality for designers while also simplifying approvals. What shipyards and design offices tell us, is that they need simple tools to manage the digital information and digital twin as a 3D model.

However, since the type and detail of information required depends on what stage of the vessel’s design, build or operations is in focus, there is a need to work with all assets and information types – 3D or otherwise.

(Image: SSI)

The growing use of 3D digital twins, coupled with a Product Lifecycle Management (PLM) approach to safety, efficiency and sustainably, gives shipyards the ability to manage sophisticated data models. These same models can initially be based on a shared 3D model for functional design and class approvals. That model can then evolve over the build cycle to suit the purpose of fabrication of the vessel and also provide class with an ‘as-built’ baseline.

Both class and the shipyard need to inspect assets prior to final delivery to ensure they conform to the original design. A 3D model supports that workflow, using software to more quickly and efficiently verify whether what was designed is what has been built.

But not all twins are the same. The options range from a completely identical twin to one that only shares some of the genetics. Certain static components that are critical to the structure are important to class but may not mean anything to the operator data which could be removed from one view and enabled on another, depending on the needs of the user.

The need of the operator for example to track efficiencies of the vessel in operations may not require a 3D model at all, but a good understanding of the sensors on the vessel and the data they provide in real time is useful. Those sensors can be associated back to 3D modeled parts using a PLM system, building the digital thread - but they do not need the heavy 3D data.

Likewise, there is far more data and information contained in 3D plans created in SSI ShipConstructor than class requires for approval, but this is data core to the shipyard. For example, during initial functional design approvals, class will scrutinize the asset’s safety and strength, but that strength is a result of the vessel’s design, not its construction processes.

Later build stages such as detail design and the shipyard’s build strategy and fabrication capabilities will provide the information for ensuring the strength of what actually gets built. That early Digital Twin information and DNA can be built upon but is not needed in the earlier functional design stages.

Of growing importance to the 3D class approval process is the common standard developed by the OCX Consortium for exchange of data required for class approval. By creating conformity around data standards, the OCX Consortium approach simplifies the exchange of data between class and designers alike and promotes the use of 3D data that can be used across the lifecycle of the vessel.

The Consortium has continued to build momentum over the last six months, with a membership that represents a cross section of stakeholders and promotes the collaboration needed to further develop the standard in future. Greater interoperability enables shipbuilders and class societies to engage in a fully digital workflow and share the designer’s 3D model using a common specification.

(Image: SSI)

Beyond this, the use of 3D models can be incrementally extended into the process of design, production and asset operations. Adopting a product lifecycle management (PLM) approach to this process means that shipyards can create, store and transport all the data and metadata they need to support virtual workflows between departments and users.

All of that information can be sliced and diced to suit the purpose of vessel operations as well as training, monitoring, repair and potentially even recommission or decommission of the asset.

In building a virtual model, the designer can control which aspects of the twin they need to see and which elements are carried forward into the construction process and taken into vessel operations.

Employing a 3D model also enables the designer or yard to push the digital twin concept to an earlier stage of the design process - to conceptual and functional design - so that the model can be used through all the stages of the design and production process, including training the people that will work on the asset. It also delivers the ability to more easily re-use information generated through the design workflows in related projects.

The differences between the demands of class approval, shipyard production and vessel operations are not in conflict, but they do represent different applications. The model produced and the digital thread supported by PLM therefore needs to be suited for the purpose at hand. The reality of working with a digital twin is that greater complexity does not necessarily deliver better functionality. The ability to design a flexible model that can efficiently serve different tasks at different stages of design and vessel operations is the future for shipbuilding.