How Universal Scene Description Gives Our Product Families One Shared Vessel Definition

August 2026

Maritime and offshore projects typically pass through several disconnected tools on their way from concept to commissioning: CAD for mechanical design, a separate authoring tool for the visual twin, another for physics and training simulation, and yet another for automation and control logic. Every handoff between these tools is a place where data drifts, geometry gets re-exported, and updates stop propagating.

We build our product family, MetroSea, TwinSea, SimSea, AutoSea, and NoeSea, on Universal Scene Description (USD) as the common data layer underneath all of them. Instead of each product keeping its own copy of the vessel, equipment, and scenario data, they all read and write the same scene graph.

One scene graph, not five exports

USD was designed to describe complex scenes as layered, composable data rather than a single monolithic file. That composition model maps directly onto how a vessel or platform is actually built up: a base equipment layer from CAD, a survey and metrology layer with as-built positions and calibrated sensor geometry, a kinematics and physics layer for simulation, and a control and I/O layer for automation. USD describes what the vessel is and how it is wired. Live state, such as sensor readings and positions during an operation, sits on top of it in the platform core and is never written back into the USD files.

Because these are layers over the same underlying scene rather than separate files, a change in one layer does not mean re-authoring the others by hand. The composition resolves the change and every product sees it. Some changes still trigger engineering work: a new hull shape, for example, needs its hydrodynamic coefficients recomputed before the simulation reflects it.

Build once, deploy across every product

A winch, gearbox, or thruster modelled once in the shared USD equipment library is immediately available to:

• MetroSea, for survey and metrology data that positions the equipment accurately in the real world
• TwinSea, for real-time digital twin visualisation and HIL-connected control validation
• SimSea, for physics-based training and procedure rehearsal
• AutoSea, for control logic and I/O mapping against the same equipment definition
• NoeSea, for live sensor and telemetry overlays on the same 3D model

Engineers author the equipment and vessel definition once. There is no separate re-export step for each downstream tool, and no risk that the version used for training drifts from the version used for control validation.

Updates flow both ways, on your schedule

Because every product reads the same vessel definition, changes are not one-way. If our team refines a component in the shared library, whether that is improved cable dynamics, a corrected gearbox model, or a new sensor type, that improvement is released as a new version. Each vessel pins the library version it runs, so clients adopt updates on their own schedule, and a fix for one client never silently changes another.

The same holds in reverse. When a client customises their vessel model, adjusts equipment parameters, or adds site-specific configuration inside their editor, that change is captured as a layer in their USD stage. When a MetroSea as-built survey shows that a component sits somewhere other than the design says, the correction can be committed as a layer too. Either way, the same edit that updates their visual twin is reflected in their simulation scenarios and automation I/O mapping, without a manual re-sync step.

One editor across engineering disciplines

Because the underlying data model is shared, mechanical, controls, and simulation engineers work against the same scene definition rather than handing files between tools, whichever of our tools they use to edit it.

This has practical effects on how teams collaborate:

• A controls engineer wiring I/O sees the exact geometry and kinematics the simulation team is testing against
• A training scenario author works with equipment behaviour that matches what the HIL rig validates
• Non-destructive layering means client customisations sit on top of the base library without forking it, so vendor updates keep merging cleanly
• Versioning and review happen at the level of the scene graph, not scattered across per-tool file formats

Why this matters for delivery timelines

The traditional alternative, separate authoring pipelines per discipline, creates integration risk at every boundary. Geometry changes late in a project historically meant re-exporting to three or four downstream tools and manually checking each one for consistency.

With a shared USD foundation, much of that integration risk moves earlier in the project. A single authoritative scene graph means the digital twin, the training simulator, and the automation logic are validated against one version of the vessel, not three.

A common language across our product family

USD gives us a common, open, and composable format instead of a set of proprietary per-product data models. That is what lets MetroSea, TwinSea, SimSea, AutoSea, and NoeSea function as one connected pipeline rather than five separate tools that happen to share a brand.

For our clients, the outcome is straightforward: build the vessel and equipment model once, and every capability, from visualisation to simulation to automation to monitoring, stays consistent as the project evolves, for the life of the asset.