When a ship passes through several companies, the data has to travel with it
A purchase order is signed, and the supplier documentation starts to arrive. Most packages come in several revisions, in different structures and with information missing, and they often land faster than the team has planned for. Some suppliers use SFI codes and some use their own. To find the data for a specific piece of equipment, people have to remember which project it belonged to.
That’s how a European shipyard described its supplier data to researchers at NTNU in Ålesund. Their study, published in the Journal of Ship Production and Design this year, follows design and production data through two companies that share the work on their vessels with other yards and suppliers. It finds that the integration approach behind most published PLM success stories was built for yards that do everything under one roof, and few European yards still work that way.
The research is part of the EU-funded SEUS (Smart European Shipbuilding) project, which Cadmatic also takes part in.
Few European yards still build a whole ship on their own
Europe accounts for about 5.6% of global shipbuilding but holds around 45% of the order book for high-value vessels, according to 2024 EU figures cited in the study. European yards compete on complex, customized ships, and they keep costs under control by spreading the work across yards and countries.
The study uses the build strategies described by Semini and colleagues in earlier research on Norwegian yards. At one end, a single yard builds and outfits the whole ship itself. Other yards have steel blocks built in lower-cost countries and do the block outfitting and assembly at home. Some bring in a complete, launched hull and handle dock and quay outfitting locally. At the far end, a foreign yard delivers a semi-finished ship with most of the outfitting done, and the local yard finishes it at the quay.
Illustration based on Bronson et al. (2026) and Semini et al. (2018).
Between 2010 and 2018, Norwegian yards used that last approach more than any other. Among Europe’s major yards, only a handful, including Meyer Turku, Meyer Werft, Fincantieri and Chantiers de l’Atlantique, still have the facilities to take a ship from design to construction on site.
For most other projects, the design, steel, outfitting and equipment data come from different companies, often in different countries.
The best-known PLM results come from integrated shipbuilders
Centralized product lifecycle management (PLM) has a good track record in the right setting. Dassault Systèmes said in 2004 that Meyer Werft’s PLM implementation could cut design time by 30% and production time by 20%. In 2008, it reported that STX had seen potential for about 15% less engineering work with a PLM backbone linking its yards in Korea, China and Norway.
The NTNU authors point out that these are vendor-reported results, mostly from single-shipyard settings. They also raise the risk of vendor lock-in and the high licensing and implementation costs that smaller firms face. As a software company ourselves, we think that’s a fair challenge.
The industry has been working toward a single, all-encompassing ship product model since the 1980s, through efforts such as STEP, the US Navy and industry program NIDDESC, and the EU project NEUTRABAS. They left useful standards behind, including STEP application protocols for ship arrangements and structures that are still in use. But adoption in Europe was slow, and keeping such models current took constant effort.
A design house and a shipyard asked for different things
The design house in the study (Company A) keeps concept and detailed engineering in-house and contracts out hull construction. Its most pressing problem was tracking changes. Engineers responsible for one ship system had no clear way to see how a change there affected the systems around it, and version numbers and designations weren’t standardized across project types. Sales teams used lead designations to win bids, and those didn’t match the ones the technical team used later.
It also wanted design reviews in one place. Comments and feedback from the client and internal teams are currently merged by hand over several review loops, and the company wants that status and feedback tied to the 3D model of the vessel, since so much of its checking is visual.
The shipyard (Company B) runs facilities for everything from steel production to final assembly. It takes in large volumes of supplier and equipment data, plus design data from outside firms such as Company A, on top of its own design work. Its top priority was connecting ERP and CAD, so the purchasing and operational data held in the ERP could be seen alongside the 3D model. It also asked for supplier documents to be classified into a standard format and traced by equipment, without depending on project or system codes.
Company B stressed one more point that it says users often overlook. An integration that depends on complex workflows comes with heavy maintenance, and that should weigh on the decision from the start.
With only two companies involved, the authors present the differences between them as directional trends. Both put heavy weight on integration with other enterprise systems and on product data management, while Company B gave the most weight of all to converting design data for construction.
When someone else owns the design, the handoff becomes the priority
The study’s main argument is about design ownership. A yard that owns the design can keep refining it throughout the project. A yard building to someone else’s design has to show that the ship matches it, and every handoff between companies becomes a decision about what to share and what to keep back.
Semini’s research on Norwegian offshore vessel production shows how this illustrates this in practice. When only simple steel blocks are built abroad, the foreign yard sees little of the design. When a foreign yard does most of the outfitting, it receives a lot of design and production know-how, which gives the Norwegian yard a reason to keep tighter control of that work.
This is why the authors suggest federation for multiparty projects: each company keeps its own model and systems and shares what each handoff needs. Where a design owner coordinates yards and suppliers, they see a fit for a hub-and-spoke setup. Where several parties work on the same vessel in parallel, they point to peer-to-peer arrangements that keep everyone’s models in sync. The authors are clear that these matches still need testing on real projects.
Illustration based on Bronson et al. (2026).
SEUS is exploring several pieces of this architecture
The two companies in the study already use Cadmatic eShare to view consolidated 3D ship models, and the study places Cadmatic in its highest category for collaboration and exchange, based on its open database architecture and exchange interfaces and APIs. That makes Cadmatic relevant to the discussion, but it does not solve the broader multiparty PLM problem on its own.
The wider context is the SEUS project. It brings together universities, software companies and shipyards to develop and test a more integrated approach to shipbuilding data, design and collaboration. Cadmatic, CONTACT Software and SARC are responsible for software development, with the participating shipyards contributing implementation feedback. Cadmatic Wave is built on CONTACT Software’s CONTACT Elements platform, which provides the underlying PLM and process-management framework, while Wave adapts it for shipbuilding use. The SEUS project has also influenced the way these capabilities are being developed and tested in practice.
The different Cadmatic components cover different parts of the information flow. eShare is mainly used as a shared visual environment for models, documents and review feedback, including markups and assignments connected to the vessel model. Wave deals more with structured product and project information, including documents, workflows, revisions, issues and engineering changes. This maps reasonably well to the needs described in the study: Company A focused on review and change visibility, while Company B put more emphasis on supplier information and traceability.
Integration with enterprise systems is another part of the picture. Cadmatic provides APIs and interfaces for exchanging project data with external PLM, PDM and ERP systems. This can make it possible to keep purchasing, material or status information in the enterprise system while still making it available in the engineering context. That is close to what Company B asked for when it described the need to see ERP information alongside the 3D model. Whether it works well in practice still depends on the data model, interface design and governance agreed for the project.
The same principle applies to the federated approach discussed by the researchers. Different companies can keep their own authoring and enterprise systems while selected models, documents and attributes are exchanged through agreed interfaces. That does not mean a complete federated PLM architecture already exists as an out-of-the-box solution. One of the questions SEUS is still addressing is how these elements can be combined in real shipbuilding projects.
Supplier data shows where the limits remain. Software can help classify, connect and visualize information, but it cannot decide which coding system should be used, who owns a particular data object, what each handoff must contain, or which system is authoritative at a given stage. Those decisions are still contractual and organizational. The maintenance of interfaces and workflows also remains part of the architecture choice.
From that perspective, the Cadmatic-related work is best seen as one practical route being explored within the wider SEUS collaboration. It addresses several of the same issues raised in the study: connecting design and business information, improving traceability, supporting review and change processes, and exchanging information across company boundaries.
Agree the handoffs while the contracts are being written
For companies planning to share the work on a vessel, the study points to decisions that come before any software choice. Map where design ownership sits in the build strategy, and which handoffs cross company lines. Then agree the coding system, SFI or otherwise, and what each handoff must contain, while the contracts are still open.
Read the full study
Bronson, J. A., Fonseca, I. A., Yılmaz, G., Legaz Almanza, M. J., and Gaspar, H. (2026). Industry perspectives on digital tools and integration for multiparty shipbuilding. Journal of Ship Production and Design. doi.org/10.5957/JSPD.08250020
