How Universal Scene Description Fuses Our Entire Product Pipeline Into One Editor

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, a control and I/O layer for automation, and a monitoring layer for live IoT state.

Because these are layers over the same underlying scene rather than separate files, a change to the base geometry does not require re-authoring the simulation or automation layers by hand. The composition resolves automatically, and every product sees the update.

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 propagate in both directions

Because every product reads from and writes to the same underlying USD stage, 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 becomes available to every client running on the platform.

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. The same is true when MetroSea captures an as-built survey offshore and corrects a component's real-world position or geometry. It carries through their entire pipeline automatically: the same edit that updates their visual twin is already 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, we can expose a single editor surface where mechanical, controls, and simulation engineers work against the same scene rather than handing files between tools.

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, that integration risk moves earlier and becomes largely automatic. A single authoritative scene graph means the digital twin, the training simulator, and the automation logic are never validated against three different versions of the same vessel.

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 in sync as the project evolves, in both directions, for the life of the asset.