Siemens Digital Twin Composer: OpenUSD, Omniverse and the Industrial Twin Stack

Most factory “digital twins” are really three separate things wearing one name: a CAD model in a PLM vault, a simulation model in an engineer’s laptop, and a dashboard fed by a historian. The hard part has never been drawing any of them. It has been putting all three into one scene, keeping them consistent, and letting someone scrub through time to ask what would change if a conveyor moved two metres.

Siemens Digital Twin Composer, unveiled at CES on 6 January 2026, is Siemens’ answer to that assembly problem. It fuses 2D and 3D twin data with real-time operational data in a managed, photorealistic scene built on NVIDIA Omniverse libraries.

This post separates what Siemens has actually published from what the market has inferred. You will leave with a layered reference architecture, a clear view of where OpenUSD, ISO 23247 and the Asset Administration Shell (AAS) fit, and a list of failure modes to plan for.

What this covers: what was announced and its status, the four-layer reference architecture, how OpenUSD composition works in a twin, live data binding, cost and lock-in, failure modes and a decision matrix.

Context and Background

Industrial visualisation has been split for two decades. PLM systems such as Teamcenter hold the authoritative product structure. Simulation tools hold behaviour. Manufacturing execution systems (MES) and quality systems hold what actually happened on the line. Each has its own viewer, its own identifiers and its own idea of “the current state”.

Siemens has been closing this gap in pieces. Its Teamcenter Digital Reality Viewer embeds NVIDIA Omniverse libraries for real-time ray tracing of bill-of-materials-driven, multi-CAD visualisation in the browser, according to NVIDIA’s Siemens case study. Digital Twin Composer extends that idea from a product view to a plant-and-process scene that also carries live data.

NVIDIA is the other half of the story. Omniverse is a collection of libraries and microservices for building physically based, real-time 3D applications, and its scene model is OpenUSD, the Universal Scene Description format that originated at Pixar and was open-sourced in 2016. The Alliance for OpenUSD announced Core Specification 1.0 on 17 December 2025, with Siemens listed among industry adopters. For a comparison of Omniverse against game engines as twin runtimes, see our analysis of Omniverse vs Unreal vs Unity for digital twins.

The standards picture matters because none of the twin standards cover the same ground. ISO 23247 defines a reference architecture for manufacturing twins. The AAS defines a vendor-neutral information model for assets. OpenUSD defines how a 3D scene is layered and composed. Composer sits where these meet, but Siemens has not published a mapping to any of them, and this post treats that gap honestly. Our overview of ISO 23247, ISO/IEC 30173 and the DTC framework covers the standards side in detail.

What Siemens has actually said

The primary sources are Siemens’ CES announcement, its product page and the CES press release. Together they establish six things.

Composer combines 2D and 3D twin data with real-time operational data in a managed, secure, photorealistic scene.
Rendering is accelerated by NVIDIA Omniverse libraries.
It connects to data sources including MES, quality management systems (QMS), PLC code and industrial IoT data, and works with Siemens data-science and AI software.
It belongs to the Siemens Xcelerator portfolio, alongside tools such as Teamcenter, Tecnomatix and Simcenter.
At launch it was described as in early access with select customers, with availability on the Siemens Xcelerator Marketplace planned for mid-2026.
PepsiCo is the named reference customer.

What Siemens has not said

Three gaps deserve flagging before we build an architecture on top of them.

First, the Siemens materials reviewed for this post do not name OpenUSD as Composer’s scene format, and do not name NX or specific Teamcenter connectors. OpenUSD is the native model of Omniverse, so USD-based composition is a reasonable engineering inference, and the rest of this post treats it as one. It is not a published Composer specification.

Second, no pricing or licensing model has been published. Third, I could not find a Siemens announcement confirming general availability, or the mid-2026 Marketplace listing actually going live, as of 29 September 2026. Check the Xcelerator Marketplace and your Siemens account team before planning around a GA date.

Digital Twin Composer Reference Architecture

Direct answer: Siemens Digital Twin Composer is best understood as a composition layer. It pulls engineering data (PLM, CAD, plant simulation) and operational data (MES, QMS, PLC, IIoT) into one Omniverse-rendered 3D scene, then lets users navigate that scene through time. It does not replace the systems of record beneath it.

That framing drives the architecture below. Four layers are visible from the outside, even though Siemens has not published an internal design.

Figure 1: Four-layer reference architecture for a Composer-style industrial twin. Source systems feed a composition layer, which feeds rendering and simulation, which feeds operational views.

The figure shows a strictly one-directional flow at the data level. Engineering and operational systems remain the source of truth, the composition layer assembles them, Omniverse libraries render and simulate the result, and users consume it as a live view or as a time-scrubbing what-if tool. Write-back to source systems, when it exists, is a separate governed path and is deliberately not drawn.

Layer 1: source systems stay authoritative

The bottom layer is everything that already exists. A typical brownfield plant has a PLM instance with product and factory structures, plant-simulation models of material flow, an MES recording work-in-progress, a QMS recording inspection results, PLC programs running the machines, and IIoT platforms streaming vibration, temperature and energy.

Siemens’ own list matters here: MES, QMS, PLC code and IIoT. Notice that PLC code is treated as a data source. That suggests the twin can reason about control logic and not only about sensor values, which is what virtual commissioning requires.

The design rule for this layer is to never copy authority into the twin. If the scene holds the only copy of a machine’s position, then a layout change in PLM and a layout change in the scene will diverge within weeks. The scene should reference, not own.

Layer 2: composition is where the twin gets built

Composition is the layer that makes Composer a product rather than a viewer. It resolves the question of which geometry, which version, which layout and which live values belong in the same scene.

In an Omniverse-based stack that job is naturally expressed in OpenUSD. A USD stage is assembled from layers, references and variants, and it supports non-destructive overrides. That maps neatly onto industrial needs: a plant layer, a machine asset per equipment class, a variant per design option, and an override layer for live state. We walk through that mechanism in the next major section.

The composition layer also has to resolve identity. A conveyor has a PLM item ID, an asset tag in the maintenance system, a PLC symbol name and a prim path in the scene. Somebody has to own the mapping. This is the single most under-discussed problem in twin projects, and it is where the AAS earns its place, as discussed later.

Layer 3: rendering and simulation

Omniverse libraries provide RTX-based real-time rendering and physics-capable simulation. Siemens describes the scene as photorealistic and physically accurate, and PepsiCo’s reported use involves physics-level recreation of machines, conveyors and operator paths, with computer vision and AI agents testing changes.

Two workloads share this layer and they behave differently. Rendering is interactive, GPU-bound and latency-sensitive. Simulation is throughput-bound and may run faster or slower than real time. A well-built stack keeps them decoupled, so a heavy Monte Carlo layout study does not stutter the operator’s viewport.

NVIDIA’s public factory digital twin blueprint shows the same pattern from the NVIDIA side. Composer is Siemens’ PLM-anchored counterpart.

Layer 4: consumption

The top layer is where value is claimed. Siemens describes creating a virtual 3D model of a product, process or plant, placing it in a chosen 3D scene, and moving back and forth through time. Two consumption modes follow from that.

Live operational view: a dashboard-as-scene for day-to-day plant management once a facility is running. Siemens’ Tecnomatix blog describes connecting to real-world sensors to turn the twin into a live operational dashboard.
What-if and design validation: an offline or replayed scene for testing layout, flow and automation before physical change. This is the mode the PepsiCo results describe.

These two modes have different data requirements. Design validation needs high-fidelity geometry and trustworthy simulation but little telemetry. The live view needs modest geometry and excellent telemetry hygiene. Teams that try to build one scene that excels at both tend to under-deliver on each.

The PepsiCo reference: what it does and does not prove

PepsiCo is the only named deployment. According to Siemens and PepsiCo’s joint announcement, PepsiCo is converting select US manufacturing and warehouse facilities into high-fidelity 3D digital twins, testing upgrades with physics-based simulation, and using AI agents as co-designers. The reported results are a 20% throughput increase on initial deployment, identification of up to 90% of potential issues before physical modification, nearly 100% design validation, and 10-15% lower capital expenditure by uncovering hidden capacity.

Read those numbers carefully. They are vendor and customer claims from the launch announcement, not independently audited results. The number of facilities was not disclosed, the baseline for the 20% throughput gain was not published, and “up to 90%” is a ceiling rather than an average. They show the approach can work in a favourable case. They do not give you a planning number for your plant.

A Siemens-published claim that it identified issues “within weeks” also says little about the total effort. Building the underlying model, cleaning identifiers and calibrating simulation are the slow part, and none of that effort is in the headline.

How a USD-Based Twin Is Assembled: Composition, Binding and Standards

This section describes how an OpenUSD-based industrial twin is normally built. It is an engineering walk-through of the mechanism, not a description of Composer internals, which Siemens has not published.

Composition: layers, references and variants

OpenUSD’s core idea is that a scene is not one file. It is a stage composed at load time from many layers, using arcs such as sublayers, references, variants and payloads. Opinions from stronger layers override weaker ones without editing the originals. That is exactly the property an industrial twin needs, because the engineering data and the operational data have different owners and different change rates.

Figure 2: A USD composition pipeline. PLM data is converted into asset layers, combined with a layout layer on a root stage, and live values arrive as overrides in a session layer.

The figure shows three separations worth defending. Geometry and materials live in asset layers that change when engineering releases a revision. Placement lives in a layout layer that changes when the plant is reconfigured. Live state lives in a session or override layer that changes many times per second and is never written back into the engineering layers.

Variants handle design options. A packaging line with two candidate conveyor layouts becomes one stage with a layout variant set, so you can flip between options in the same session. Payloads let the renderer defer loading heavy assets until they are in view, which matters when a plant scene has thousands of machines.

Where conversion hurts

The conversion step from PLM and CAD into USD is where projects lose weeks. CAD kernels store exact parametric surfaces. USD stores tessellated meshes and material bindings. Converting means choosing tessellation tolerances, deciding how to preserve assembly hierarchy, and mapping PLM metadata onto USD attributes.

Teamcenter’s Digital Reality Viewer shows Siemens has already solved BOM-driven multi-CAD visualisation for the product view. Whether Composer reuses that pipeline is unpublished. What is knowable is the cost structure: conversion is a batch job that must be triggered by engineering change, or the twin silently drifts.

A rough, illustrative sizing helps. Suppose a plant model has 2,000 equipment items at an average of 400,000 triangles after decimation. That is 800 million triangles if all are resident, far beyond what a single workstation renders interactively. Level-of-detail variants, instancing of repeated machines and payload streaming turn that into a scene that fits, but only if the pipeline generates those variants. Budget for it.

Live data binding

Real-time overlays are the second half of the product promise. The mechanism is a binding service that maps an incoming signal to an attribute on a specific prim in the scene.

Figure 3: Telemetry binding. Signals are normalised at the edge, published to a broker or unified namespace, resolved to a prim path by an identity map, and written as attribute overrides. Time scrubbing replays from a historian.

Three design decisions matter in that sequence. The first is where normalisation happens. Do it at the edge or in the unified namespace, not in the scene, because every viewer should see the same engineering units and quality flags. Our comparison of OPC UA FX, MQTT Sparkplug B and the unified namespace covers the options.

The second is the identity map. Resolving an asset ID to a prim path is a lookup that has to be versioned with the layout. If the layout layer moves a machine or renames a prim, the binding must follow, or values land on the wrong object.

The third is time. “Move back and forth through time” implies the scene can be rendered from historical state. That needs a historian or event store behind the binding service, and the layout and geometry layers must themselves be versioned. Scrubbing to last March only means something if the twin can also recover last March’s layout.

Where the standards fit

No single standard covers the whole stack, so the useful question is which layer each one governs.

Layer	Standard or spec	What it governs	Published Composer mapping
Scene composition	OpenUSD, AOUSD Core Spec 1.0	Layered 3D scene description and composition	Not published by Siemens
Twin architecture	ISO 23247 series	Reference architecture and information exchange for manufacturing twins	Not published
Asset identity and data	IDTA Asset Administration Shell	Vendor-neutral asset information model and submodels	Not published
Field data	OPC UA, MQTT Sparkplug	Transport and semantics of machine data	Siemens lists IIoT and PLC sources, protocols unspecified
Product structure	Teamcenter and PLM data	Authoritative BOM and structure	Xcelerator portfolio member

Two cautions apply. OpenUSD Core Spec 1.0 standardises the data model and composition logic. The AOUSD announcement states that domain areas such as geometry, materials and physics are still under development, and a Core Spec 1.1 was planned for 2026. So “OpenUSD-compliant” does not yet guarantee that a material or physics property means the same thing in two tools.

Also, ISO standardisation of OpenUSD is an intended future step, not a completed one. Treat OpenUSD as a strong de facto industry standard governed by the Linux Foundation-hosted Alliance, not as an ISO standard.

AAS as the identity backbone

The AAS is the natural answer to the identity problem in Layer 2. An AAS gives each asset a globally unique identifier and a set of submodels for nameplate, documentation, technical data and more. If every machine in the plant has an AAS, the binding service can key on the AAS identifier rather than on a PLC tag name or a prim path, and both of those become attributes of the same asset record.

This is a design recommendation, not a Composer feature. Our AAS reference architecture describes how to structure that record, and the ISO 23247-6 composition guide explains how several twins can be combined without a single monolithic model.

The payoff is portability. If the identity map lives in AAS submodels rather than inside one vendor’s scene database, moving from one visualisation runtime to another means rebuilding the scene, not re-deriving the identity of 2,000 assets.

The digital thread underneath

Composition only stays honest if engineering change flows into it. That is a digital thread problem: a traceable link from requirement to design to plant configuration to operation. Our digital thread PLM architecture guide covers how to build that link. A Composer-style scene is one consumer of the thread, not a substitute for it.

For teams weighing PLM platforms as the anchor, the Aras, Teamcenter and Windchill comparison frames the lock-in question at the PLM layer, which is where the largest switching cost usually sits.

Cost, Lock-In and Build-Versus-Buy

Siemens has not published pricing, so nothing here is a quote. What can be reasoned about is the cost structure and where dependency accumulates.

The cost structure

A composed industrial twin has five cost buckets. The licence is the one buyers ask about first and often the smallest over a five-year horizon.

Licence and marketplace fees: unpublished for Composer. Expect some combination of platform subscription and per-seat or per-scene charges, but that is an assumption.
GPU infrastructure: interactive RTX rendering needs datacentre or workstation GPUs, on premises or in the cloud. Streaming a photorealistic scene to browsers shifts cost to server GPU-hours.
Data engineering: conversion pipelines, identity mapping and telemetry normalisation. This is labour-heavy and usually dominates.
Model calibration: tuning simulation against measured throughput until the twin’s predictions can be trusted.
Ongoing synchronisation: every engineering change and layout move needs to propagate.

An illustrative worked example, with all numbers assumed for the sake of arithmetic and not taken from Siemens: suppose a pilot covers one plant with 2,000 assets. If mapping and validating each asset takes an average of four engineer-hours, that is 8,000 hours, or about 4.5 person-years at 1,800 productive hours a year. Even at a modest loaded rate, that data engineering can exceed a first-year licence for a mid-size deployment. The point is the ratio, not the figure: the asset count times the per-asset effort is the cost driver you control, and AAS-based identity is one way to shrink the per-asset effort on the second plant.

Where lock-in accumulates

Lock-in in this stack is layered, and the layers differ in how hard they are to escape.

Dependency	Lock-in strength	Why	Mitigation
Scene format (OpenUSD)	Low	Open, multi-vendor, Alliance-governed	Keep the canonical scene in USD you own
Rendering runtime (Omniverse libraries)	Medium	NVIDIA GPUs and libraries; alternatives exist	Isolate rendering behind a viewer interface
Composition logic and connectors	Medium to high	Proprietary product logic, unpublished	Keep identity and layout in open models
PLM anchor (Teamcenter)	High	Data model, workflows, integrations	Standardise exports and use the digital thread
Live data connectors	Medium	Depends on how bindings are stored	Store bindings in AAS or a neutral registry

The strongest lock-in is not the visualisation. It is the accumulated mapping between your assets, your PLM structure and your live tags. If that mapping lives only in the vendor tool, it is the hardest asset to rebuild.

Build versus buy

Building a similar stack from OpenUSD, Omniverse and your own connectors is possible and NVIDIA’s blueprints show the pattern. It gives control and avoids a product dependency, but you own the conversion pipelines, the binding service and the change synchronisation. For most manufacturers that is a multi-year engineering programme.

Buying Composer trades that effort for a dependency on Siemens’ roadmap and, per the CES announcements, on NVIDIA. The trade is more attractive if you already run Teamcenter and Tecnomatix, because Composer sits inside the portfolio you already integrate. It is less attractive for a heterogeneous plant with mixed PLM vendors, where a vendor-neutral composition layer may serve better.

A middle path is common in practice: adopt the commercial composition product, but insist that the scene, the identity map and the telemetry bindings remain in open, exportable formats.

Decision matrix: which twin approach fits which situation

The right choice depends on your PLM estate, your fidelity needs and your appetite for engineering work. The matrix below compares three approaches on the criteria that usually decide these projects. It is a judgment framework, not a benchmark.

Criterion	Composer-style commercial composition	DIY OpenUSD and Omniverse stack	Game-engine twin (Unreal or Unity)
Fit with existing Teamcenter and Tecnomatix	Strong, same portfolio	Manual connectors	Manual connectors
Time to first scene	Shortest if PLM is Siemens	Long, you build pipelines	Medium, strong tooling for visuals
Physics and simulation depth	Omniverse-backed, per Siemens	Omniverse-backed, your models	Engine physics, less industrial
Control over identity and bindings	Limited by product	Full	Full
Vendor dependency	Siemens and NVIDIA	NVIDIA	Engine vendor
Published pricing and GA clarity	None as of this writing	Open-source USD, paid GPU stack	Public licence terms
Best for	Siemens-centric manufacturers	Teams with strong 3D and data engineering	Visualisation-first, marketing or training twins

Use the commercial route when your PLM is already Teamcenter, your team lacks 3D pipeline engineers and you can tolerate an early-access product. Use the DIY route when you run mixed PLM vendors, need to own the scene and can staff the pipeline work. Use a game engine when visual polish and cross-platform reach matter more than engineering traceability.

Trade-offs, Gotchas, and What Goes Wrong

A composed twin fails in quieter ways than a broken dashboard. The scene keeps rendering, it looks convincing, and it is wrong. Photorealism raises the risk because it lends unearned credibility to the data.

Figure 4: Five failure modes of a composed industrial twin, each paired with the guard that limits the damage.

The figure pairs each failure with a guard, and the pairings are worth reading as a checklist.

Stale geometry

If engineering releases a new revision and the conversion job does not run, the scene shows last quarter’s layout. Nothing in the picture warns you. The guard is change-triggered rebuilds tied to PLM release events, plus a visible revision stamp in the scene itself.

Identity mismatch

A telemetry value bound to the wrong prim is worse than no value. It looks plausible and directs a technician to the wrong machine. Guard with stable asset identifiers such as AAS IDs, validate every binding against the PLM structure on each layout change, and alert on orphaned tags.

Heavy scenes and low frame rates

Photorealistic plants are expensive. Frame-rate collapse pushes users back to spreadsheets. Guard with level-of-detail variants, instancing, payload streaming and a defined performance budget per view. Decide early whether users get a streamed GPU session or a local client, because that choice sets the infrastructure bill.

Telemetry lag and gaps

A live view that lags by 30 seconds looks live. Guard by rendering data age and quality flags next to values, dimming stale signals and never smoothing over gaps. Timestamps should come from the source, not from arrival time at the scene.

The fidelity gap

A simulation that predicted a 20% throughput improvement in the virtual plant can still miss in the real one if the model omits operator behaviour, changeovers or maintenance stops. PepsiCo’s “nearly 100% design validation” is a claim about the modelled scenarios. Guard by calibrating simulation against measured line performance before trusting what-if results, and by keeping a residual-error record for each validated model.

Product maturity risk

Composer was in early access at launch, and I could not verify general availability as of late September 2026. Early-access products change interfaces, connectors and licensing. Contract for a pilot with exit criteria, not a plant-wide rollout, and keep your source data and identity maps in formats you can take elsewhere.

The claim most likely to mislead

The most repeated framing is that a twin lets you find 90% of issues before building. The published claim is that up to 90% of potential issues were identified in a specific deployment. Without the denominator, meaning how many issues existed and how many were found only after construction, the figure cannot be compared against your own baseline.

Practical Recommendations

Start from the outcome, not the scene. A twin that answers one costly question, such as whether a proposed line change will hit target throughput, beats a plant-wide model with no owner.

First, pick a bounded pilot: one line or one warehouse zone with a decision attached and a measurable baseline. Capture that baseline before the twin exists, so the result can be judged against it and not against a vendor headline.

Second, invest in identity before visuals. Assign stable IDs to assets, store them in an AAS or a neutral registry, and treat the mapping from ID to PLM item, PLC tag and scene path as a governed dataset.

Third, keep the scene reproducible. The USD layers should be buildable from source by a pipeline, not hand-edited, so you can rebuild after every engineering change and, if needed, on another runtime.

Fourth, separate design mode from operations mode. They need different fidelity and different data quality, and mixing them inflates cost for both.

Fifth, insist on transparency from the vendor about availability, licensing, exportability and connectors before you sign. For the agentic side of this story, where AI agents propose and test layout changes inside a twin, see our analysis of agentic digital twins for industrial analysis.

A short checklist before you commit:

Availability status and support terms confirmed in writing, not inferred from CES material.
Pilot scope, baseline metric and exit criteria defined up front.
Identity mapping stored outside the visualisation tool.
PLM change events wired to scene rebuilds.
Telemetry shows source timestamps and quality flags.
Simulation calibrated against measured data before what-if results are used.
GPU sizing and streaming approach costed for peak concurrent users.

Frequently Asked Questions

What is Siemens Digital Twin Composer?

It is a Siemens software product announced at CES on 6 January 2026. It combines 2D and 3D digital twin data with real-time operational data in a managed, photorealistic 3D scene powered by NVIDIA Omniverse libraries. Users can build a model of a product, process or plant, place it in a scene and move through time to test changes. It belongs to the Siemens Xcelerator portfolio.

Is Digital Twin Composer generally available?

At launch Siemens described it as in early access with select customers, with availability on the Siemens Xcelerator Marketplace planned for mid-2026. I could not find a Siemens announcement confirming general availability as of 29 September 2026. Confirm current status, pricing and support terms with Siemens or the Marketplace listing before planning a deployment around it.

Does Digital Twin Composer use OpenUSD?

Siemens states that Composer uses NVIDIA Omniverse libraries, whose scene model is OpenUSD. The Siemens materials reviewed for this post do not explicitly name OpenUSD as Composer’s data format. USD-based composition is therefore a reasonable inference from the Omniverse foundation, not a published specification. Ask Siemens for export formats and interoperability details during evaluation.

What results did PepsiCo report with Digital Twin Composer?

PepsiCo and Siemens reported a 20% throughput increase on initial deployment, identification of up to 90% of potential issues before physical modification, nearly 100% design validation and 10 to 15% lower capital expenditure. These are launch-announcement claims for select US facilities. The number of sites and baselines were not disclosed, and the figures have not been independently audited.

How does Digital Twin Composer relate to ISO 23247 and the Asset Administration Shell?

Siemens has not published a mapping to either. ISO 23247 offers a reference architecture for manufacturing twins, and the AAS offers a vendor-neutral asset information model. In practice you can align a Composer deployment with both by using AAS identifiers for asset identity and ISO 23247 layers as an architectural check. Treat that as your design choice, not a certified feature.

Is Digital Twin Composer a replacement for Teamcenter or a PLM system?

No. It consumes engineering and operational data rather than replacing systems of record. Teamcenter and similar PLM systems remain the authority for product and factory structure, and MES and QMS remain the authority for production and quality. Composer’s role is to assemble that data into a navigable, time-aware 3D scene for validation and operations.