Lifecycle continuity or bridges of meaningful data use cases

Most naval architects will recognize this story. The design office produces rich, validated 3D models for various purposes. The yard builds the vessel using the data extracted from it. Then the vessel leaves the quay, and nearly all of that engineering knowledge stays behind. What the operator receives is a stack of drawings, a few PDFs, and a loading computer that somebody configured by typing in numbers from the general arrangement. 

For years the promised fix has been a single PLM platform covering design, construction and operation. One environment, end-to-end continuity. It sounds sensible, and in other industries it sometimes works. In shipping it tends not to, and the reasons are worth spelling out, because they point to a better approach. 

Why the single platform approach may not be suitable

The first problem is the long lifecycle. A vessel is in service for 25 or 30 years, while authoring software likely runs in cycles of 1-2 new releases per year, and seldom supports legacy systems more than 3-5 years, reflecting regulations for cybersecurity and business cycles. A hull designed in one CAD generation will be operated through three or four more. Whatever platform holds the data today will have been superseded long before the ship is scrapped. 

The second problem is people. Designers, yards, owners, managers, charterers, class societies and regulators all need to read the same ship data, and they never share one platform. They rarely even share one taxonomy. So the limitation is not really technical. It is temporal and organizational, and the only thing that survives both is an open, governed standard. The PLM literature in other sectors reached that conclusion a long time ago, and it applies with extra force to shipping. 

There is a third problem that is easy to overlook, and it is commercial. Shipyards regard their 3D models as proprietary intellectual property. Unless there is a governed framework for sharing them securely and distributing the value fairly, a yard has no reason to release its authoritative model to anyone downstream. The data exists, but the business models to extract value from it over the lifecycle are lagging behind. 

Turning the question around

The conventional approach asks how the entire lifecycle dataset might be made continuous, and only then what might be done with it. This is open-ended and expensive, and it tends to produce large volumes of data recorded, which then never get connected to the engineering models that would make them useful. 

Our suggestion is to reverse the order. Start by asking which operational decisions create the most value, and then build only the bridges those decisions require. A bridge, in this sense, is a defined and maintained connection that exposes a specific slice of an authoritative design model, at a specified fidelity and configuration, to a specific operational application. 

Framed this way, three things fall into place. Benefits support ROI early, because each bridge is justified by a use case with an owner and a value statement. Governance becomes explicit, because each bridge has a defined source of truth, a defined consumer and a defined configuration-control regime. And the work accumulates, because bridges built for separate purposes gradually assemble into a layered, multidimensional digital twin without anyone ever having to build a monolithic model. The engineering effort stays proportional to the value realized. 

Four bridges converted into solutions 

We looked at four groups of use cases where design data delivers direct operational value today. 

The first is stability and loading-condition management. Intact and damage stability are safety-critical functions performed continuously for the whole service life. They depend directly on the hull form, the compartment and tank definition, and the class-approved hydrostatic model, all of which already exist in the design office. Even so, onboard loading instruments are still routinely configured by re-deriving this data from drawings, a process that is laborious and error-prone.  

A stability-and-loading bridge instead exposes the approved hydrostatic model and compartment definition directly to the loading computer, kept consistent with the as-built and, where relevant, as-converted configuration. The benefit is measurable: in a recent RoRo deployment with Stena Line, booking and cargo data flow automatically into the onboard loading computer and stability is recalculated in real time as cargo is planned. Officer planning time per departure fell from around an hour and a half to roughly ten minutes, presenting an immediate increase in operational efficiency. 

The second is performance modeling for voyage optimization and fleet management. A calibrated model relating speed, power, draft, trim and weather to fuel consumption is the engineering core of routing, speed guidance, charter-party management and hull and propeller condition monitoring in line with ISO 19030. When that model originates in design hydrodynamics and is then tuned with measured data, it becomes a durable operational asset reused across thousands of voyages and across retrofits. Commercial weather-routing services pairing vessel-specific models with high-resolution forecasts report fuel savings of several per cent per voyage. Recent reinforcement-learning work reports double-digit improvements against a distance-based baseline while still meeting an arrival window. 

The third is operational simulation for validation and design feedback, which closes the loop. Running a simulation-grade design model against measured conditions lets owners and yards verify that the vessel performs as designed, and lets them assess the real effect of weather routing, wind-assisted propulsion or batteries on cargo capacity and energy efficiency, both before and after installation. Energy-saving devices can be judged against an evidence-based baseline rather than a brochure figure, and against optimized routing rather than a theoretical profile. The value of such a data bridge flows back into the design knowledge base and improves the next ship. What matters most here is provenance and configuration control, so that every result can be tied to a known design state. 

The fourth is 3D model-based classification approval. Hull structure approval has traditionally meant passing 2D drawings between the yard’s CAD system and the class society’s rule-check tools. A model-based bridge exposes the idealised structural geometry and its metadata directly, using the open OCX format so that the exchange does not depend on any one CAD vendor. Pilot work between a class society, a yard and a software provider reported substantial reductions in basic-design time through earlier class engagement. More significantly for the lifecycle argument, the approved 3D model becomes the authoritative structural record that downstream bridges can reuse, including the stability layer described above.  

The precondition for all uses of data 

All four bridges depend on the yard being willing to expose its model, and that willingness cannot be taken for granted. It is worth treating as a use case in its own right, because its value is the feasibility of everything else. 

The cross-industry Digital Twin Project, which began in 2023 with shipping companies, shipyards and ClassNK and now involves 14 organizations, has identified three conditions a yard needs before it will take part. Data security, so that the model is protected against misappropriation. Access rights, so that the provider keeps control over who uses the model and for what. And benefit sharing, so that model providers and service providers receive compensation proportionate to what they contribute. 

All of these are business model cases, where technology plays an enabling role. The constraints are commercial and governance conditions, and once they are met, more than thirty identified use cases become available. 

A digital twin made of layers 

Put the four bridges together, and a reference architecture emerges. The operational digital twin is not one model but a set of layered lifecycle datasets, each contributed by a use-case-justified bridge and each governed at its own level. There is a geometric and structural layer of hull form, compartments, and structure, which is the same model exchanged for class approval and which also underpins stability and loading. There is a behavioral layer, the calibrated performance model. And there is a measured-state layer of operational time series, linked back to both for monitoring and validation. 

Calling this multidimensional is a way of saying that the layers carry different kinds of information, linked rather than merged: geometry, behavior, configuration history and measured state. Each layer remains independently meaningful, independently owned and independently replaceable as software evolves, provided the connections between them are expressed in governed, standardized terms. 

This is also what makes the business model workable. Because each layer maps to a use case and a stakeholder, digital handover from yard to owner can be priced and contracted layer by layer. The cross-industry project has settled on a three-party structure to make that concrete: a Model Provider, typically the yard, owning the design model; a Service Provider building an application on top of it; and a Service User, usually the owner or operator, consuming the result for a specific decision. Pilot trials have confirmed the feasibility of these scenarios, although contract structures, platform fees and business-model clarity still need to be worked out. 

Data and standards before AI 

Two enablers sit underneath every bridge. One is governed standards and configuration control, for example, OCX for hull structure. The other is AI, and specifically semantic mapping. Operational data is mostly unstructured and lacks unified description standards, which has always made it hard to relate to the engineering model. Large language models combined with knowledge graphs can now pull entities and relationships out of heterogeneous maritime documents and map them onto structured representations, and that lowers the cost of building and maintaining data bridges considerably. 

AI can make building connections and bridges cheaper and faster. It does not remove the need for an authoritative source of truth. If anything, it amplifies that need, because automatically inferred links are only safe when they are anchored to governed standards and disciplined configuration control. AI is best understood as an accelerator of the bridge-building described here, not a replacement for it. 

Roadmap ahead 

It is no coincidence that the strongest standardization cases are stability and loading conditions and model-based class approval; these are the areas where safety and class already impose rigor. 

Identifying more of the use cases,building the business models to support them, and applying existing standards or making new ones, and gradually creating layer by layer digital twin is a practical approach to the digital threat for maritime industry. 

This post is based on a paper presented at the ICCAS 2026 conference.. The full paper includes the complete use-case classification framework and layered-dataset architecture discussed above.