Commissioning problems are discovered late by design: the sequences cannot be properly tested until the equipment is installed, the graphics cannot be validated until there is data, and by then the schedule has no slack left. Everyone knows the sequence should have been reviewed earlier; nobody has an environment in which to do it.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- BIM and CAD ingestion — start from the model that already exists.
- Asset and point mapping — connect geometry to the points that will control it.
- Equipment animation and state models — see the plant respond.
- Control-sequence simulation — test the sequence of operations before commissioning.
- Alarm and operator graphic validation — check what the operator will actually see.
- Commissioning issue tracking — findings become tracked work with evidence.
- Live Niagara data connection — the twin follows the real station once it exists.
- Historical playback and acceptance evidence — replay what happened, and prove acceptance.
Shift the Discovery Earlier
The value is entirely in timing. A sequence error found in simulation costs an afternoon; the same error found during commissioning costs a site visit, a schedule slip and an uncomfortable conversation. Connecting the twin to live Niagara data afterwards means the same model keeps earning through handover and into operations.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- 3D Visualization and Digital Twin Services — Digital twin work we deliver today: 3D visualization and digital twin services.
What the Design Assumes About a Project
The concept is scoped around one particular shape of commissioning problem, and it is worth being explicit about which one, because building a twin is not free. The design assumes a building where the logic was written for this specific site, where equipment in one system depends on state held in another, and where the operator graphics are extensive enough that reading them screen by screen is slow work. Under those conditions there is more to verify than a written test script can hold in order, and that verification load is what the twin is meant to absorb.
The design is not aimed at the opposite case. A packaged unit running a manufacturer's standard logic, a short point list, nothing interlocked across systems: a point-to-point check sheet and a functional test script already cover that, and putting it in 3D adds effort without adding certainty. Nothing here is intended to displace that approach where it is sufficient.
It is also worth stating what the design cannot do. A simulated air handler behaves exactly the way its behavior model says it behaves. If that model is wrong, the sequence passes in simulation and fails on the floor, and it fails in precisely the way the model got wrong. The intent is to move logic errors into a place where they are cheap to find, not to make physical testing unnecessary.
- The design assumes projects where the sequence is written for the site, equipment is interlocked across systems, the graphics package is large, or the access window on site is narrow and fixed.
- The design is not aimed at manufacturer-standard sequences, small point counts, systems with no cross-dependency, or jobs where a written functional test script already answers the question.
What the Model Has to Carry
Everything downstream depends on what arrives in the model, so it is worth saying what makes a model usable. Geometry authored for coordination usually works, because coordination requires equipment to exist as discrete objects with identifiers attached to them. Geometry exported for presentation often does not, because the export flattens an air handler and the wall behind it into a single mesh. There is nothing to attach a point to in that case, and the first task on any such file is rebuilding the objects the export dissolved.
The point list is the second dependency, and the usual failure there is naming rather than completeness. Two contractors naming the same fan differently, or a tag scheme that shifted between design and installation, produces a correspondence that only a person who knows the job can resolve. The design treats that correspondence as an artifact to be reviewed and kept, not as something inferred quietly in the background where nobody sees the guesses.
The third dependency is the sequence itself, in whatever form it exists. Sequences are written in prose for human readers, and prose leaves gaps a simulation has to close: what holds between two stated conditions, how long a state persists before the next transition, what is intended when two conditions become true at once. Those gaps are usually the interesting part of the job. Someone on the customer's side has to be able to say what was meant, because closing a gap is a design decision and not something to assume.
Why a Real-Time Engine Underneath
Sequence checking could be done in a logic harness with no visualization at all, and for some checks that is the right tool. The argument for a real-time 3D environment is that the questions hardest to settle on paper are spatial and temporal at the same time: which dampers moved, in what order, while the discharge temperature was doing what, and whether the operator screen reflected any of it while it happened.
Running on a game engine also separates simulated time from wall-clock time. A daily schedule can be stepped through faster than it would occur, and a transition that resolves in a few seconds can be slowed and replayed until the ordering is unambiguous. The engine work that makes a training simulation legible, state made visible, timing put under the operator's control, and the whole run repeatable on demand, is the same work that makes a commissioning rehearsal worth sitting through.
This is also where the concept borrows from work already in our wheelhouse. Equipment state models are behavior models, structurally the same thing a simulation build needs for a vehicle or a machine tool, and validating operator graphics is an interface problem being exercised inside a simulated environment. The domain is unfamiliar to a games studio; the engineering underneath is not.
Living With the Twin After Handover
The live data connection and historical playback are the parts of the concept meant to outlast the commissioning window, and they are also the parts most likely to decay if the design is careless about it. A twin that was accurate on the day of acceptance and never touched again becomes a picture of a building that no longer exists, and a stale picture is worse than no picture, because people believe it.
The design response is to keep the binding layer thin and explicit. Geometry, point mapping, and behavior models stay separate, so that a station change means editing a mapping rather than rebuilding a scene, and so that a mapping which no longer resolves can be surfaced as a fault instead of silently rendering a value that stopped updating. Drift between a building and its model is not preventable. It is only detectable, and detectability is what the design is aimed at.
Playback raises a separate question, which is retention. Evidence is only evidence while the underlying data still exists, and a continuously sampled station accumulates faster than people expect. What gets kept at full resolution, what gets thinned, and how long acceptance records are held are customer decisions with real storage cost behind them, and they need answering before recording starts rather than after someone asks for a run that was already discarded.
Frequently Asked Questions
What is the Digital Twin Commissioning Studio, concretely?
It is designed as a real-time 3D environment in which equipment is represented as objects that behave, rather than as geometry that merely looks right. Each modeled unit carries a behavior model so it responds to a command the way the real unit would, the control logic under test drives those models, and the operator interface is exercised against the same run. The purpose is to make a sequence observable before there is a building in which to observe it. It is a product concept in active development, so everything described here is design intent rather than a capability you can use.
What does it run on, and what has to already exist?
The design targets desktop-class machines with a real GPU, since this is a rendered real-time environment rather than a page in a browser. On the project side, three inputs have to exist: a 3D model in which equipment is identifiable as separate objects, a point list, and a written sequence of operations. A commissioned Niagara station is not required for the simulation work, because logic can be exercised against modeled equipment long before any station is live. The station becomes relevant in the later phase, when real values rather than a simulated schedule are what drive the model.
How is rollout designed to proceed, in what order?
Model ingestion first, then asset and point mapping, then behavior models for the equipment the sequence under test actually touches, then the sequence, then graphics. Each stage is designed to be useful before the next one exists, so a model that has mapping and no behavior models is still a navigable, correctly tagged model. The ordering exists because each stage rests on the one before it, and an error is cheapest to correct at the stage that introduced it. To be clear, none of this can be deployed today; this describes how the rollout is being designed to work.
How would it integrate with the systems we already run?
The intended integration points are the systems that already hold the data: the BIM or CAD tool as the source of geometry, the control system as the source of point definitions and later of live values, and whatever issue tracker the project already uses for findings. The design preference is to read from those systems rather than become a second place where the same information has to be maintained, because a duplicated point list will drift from the original. Where a write back is involved, such as raising an issue in a tracker, the intent is that it is explicit and logged rather than automatic. Which specific connectors get built first is part of what is still being scoped.
Where does the data live, and what stays under our control?
The design assumption is that the model, the point list, the sequence, and any recorded run remain the customer's, held where the customer chooses. Building geometry and control logic are sensitive on their own terms: a floor plan with equipment locations plus a complete point list describes a facility in more detail than most owners want circulating. The design is being written so it can run inside an environment the customer already controls rather than requiring that material to leave it. Retention of recorded runs is likewise a customer decision, because the evidence belongs to the customer.
Does this replace functional performance testing?
No. Simulation tests logic against a model of equipment; functional testing tests the equipment. A sequence that behaves correctly against a modeled valve tells you the logic is internally consistent, not that the valve strokes, that the sensor reads true, or that the wiring landed where the drawings say it did. The design intent is to reduce how many of the problems found on site turn out to be logic problems, so that time on site goes to the physical ones.
What would we have to provide or decide?
Provide the model, the point list, the written sequence, and access to someone who can answer intent questions when the sequence is ambiguous. Decide which equipment is worth a behavior model, since not everything in a building needs to respond in simulation, and how much fidelity those models need. Decide as well what counts as a passing run, because a simulated test only proves something if there is prior agreement on what passing looks like. That last decision is the one most easily deferred, and deferring it removes most of the reason for testing early.
Can we plan a project around this?
No. It is a product concept in active development, there is no release date, and there are no installations. What we deliver today is 3D visualization and digital twin services, which is a different scope of work. If you want the roadmap shaped by a real job, the details that actually help are the type of sequence involved, the rough size of the point list, and how much of the equipment is interlocked across systems.