What a Digital Twin Review Actually Asks of the Headset.

A plain definition first

A digital twin does not require a headset. Most twins are viewed on screens. A headset becomes useful when people need to understand the asset at its real scale and in three dimensions: walking a plant layout before it is built, checking whether a maintenance technician can reach a valve, or reviewing a modification with people who are not CAD specialists.

What the twin needs from hardware is simple to state and hard to deliver: enough performance to show the model at a useful level of detail, smoothly enough to be comfortable; interaction that lets people inspect, measure and comment; and a way for several people to look at the same thing together. The rest of this paper turns those needs into questions.

Review use cases and what each asks of the hardware

"Digital twin review" covers several different activities. Each places different weight on the hardware.

Design and layout review. Engineers and operators walk through a planned facility or modification at full scale, looking for clashes, access problems and layout issues. This needs good visual fidelity and comfortable movement.

Maintenance access and ergonomics. Checking whether a person can physically reach, remove or replace a component. This needs accurate scale and positional tracking, so a reviewer can crouch, reach and lean.

Operational review. Viewing live or recent data on the model: which pumps are running, where temperatures are high, which assets are due for maintenance. This needs data overlays to be legible and the device to connect to the data source.

Training on the twin. Using the model as a training environment, for familiarisation or procedures. This overlaps with the requirements covered in the companion paper Which Safety Modules Need Which Headset.

Stakeholder review. Showing a design to people who do not read drawings: management, clients, regulators, the operators who will work there. This needs the experience to be simple and reliable rather than technically impressive.

Identify which of these matter most before choosing hardware, because the trade-offs differ.

Performance and model constraints

Why models built for screens often need optimisation

Engineering models are built for accuracy, not for real-time display. A plant model may contain every bolt, every pipe support and every internal component, often in far more geometric detail than a headset can render smoothly.

On a desktop workstation, a heavy model can still be viewed, slowly. In a headset, slowness is not acceptable. If the display falls behind the user's head movement, the experience becomes uncomfortable and can cause motion sickness. Headsets need to maintain a high, steady frame rate in a way that screens do not.

That means most engineering models need to be prepared for headset viewing: simplified where detail does not matter, split into sections loaded as needed, and converted into formats suitable for real-time engines. The companion paper From Revit to Headset walks through this for building models. The same principles apply to plant and equipment models.

What to ask. - How large are your models, and how much detail do reviewers actually need? - Who will optimise models for headset viewing, and how often will that need repeating as the design changes? - Does the review software handle model simplification automatically, or does it require manual work?

Standalone versus tethered

Standalone headsets contain their own processor, battery and storage. They are portable, quick to set up and suit reviews in meeting rooms, on site or with stakeholders. Their processing power is limited, so they need more model optimisation.

Tethered headsets connect to a workstation that does the rendering. They can display much heavier models at higher fidelity, but they are tied to the workstation and its location.

Some setups stream rendering from a workstation or server to a standalone headset over a network, combining portability with more computing power, at the cost of depending on network quality.

What to ask. - Will reviews happen in a fixed room or in many places? - How much model detail is essential to the decision being made? - Is the network in review locations good enough for streamed rendering?

QWR's paper on how to read an XR spec sheet explains why sustained performance under real conditions matters more than peak figures.

Display fidelity

For design review, reviewers need to read labels, see pipe routings clearly and judge clearances. Display resolution and lens clarity determine how far a reviewer must lean in to read something.

What to ask. Can reviewers read the text and labels that matter at a natural viewing distance? Test with your own models, not a vendor's demonstration scene.

Interaction and collaboration

Inspecting, measuring and commenting

A review is only useful if its findings are captured. Reviewers need to select components, see their properties, measure distances and leave comments or markups tied to a location in the model.

What to ask. - Can reviewers select an object and see its metadata (tag number, specification, maintenance history)? - Can they measure distances and clearances? - Can they leave annotations that flow back into the engineering system?

Most of this is software. The hardware requirement is input that makes it practical: controllers for precise selection and measurement, hand tracking for natural pointing, or both.

Multi-user sessions

Reviews are usually meetings. Several people, sometimes in different locations, need to see the same model and point things out to each other.

What to ask. - How many people can join one session? - Can some join from screens while others use headsets? - What network capacity does a multi-user session require? - Can a session leader guide others to a location in the model?

Comfort for long sessions

Design reviews can run for an hour or more. Headset weight, balance, heat and fit all affect how long people can participate usefully. QWR's paper on the battery, weight and thermal trilemma explains the trade-offs.

On-site and mixed-reality review

Some reviews are most useful at the real asset: comparing the twin against what was actually built, or planning a modification in place.

Passthrough on a headset shows the real environment through cameras, with the model overlaid.

See-through AR glasses show the model over the real world directly.

Both need the model aligned accurately with the real asset, which depends on tracking quality and on how the alignment is set up. Both also face the usual site constraints: protective equipment, lighting, connectivity and, in some facilities, hazardous-area restrictions. The companion paper When Standard XR Hardware Can't Enter the Zone covers the last point.

What to ask. How accurately can the model be aligned with the real asset, and how is alignment set up? How does the device perform in site lighting? Can it be worn with required protective equipment?

Connecting to live data

An operational twin shows live or recent data. The headset must reach that data securely.

What to ask. - Does the twin platform deliver data to the headset directly, or through a workstation? - Does the headset support the network and security configuration needed to reach operational data? - If the data is sensitive, is anything stored on the headset, and how is it protected if the device is lost?

QWR's paper on physical loss and recovery questions treats a lost device as a data question first.

Typical pattern: matching hardware to review type

Typical pattern. An engineering team runs two kinds of twin review.

• Weekly design reviews happen in a dedicated room, using tethered headsets connected to a workstation. Models are heavy, reviewers need to read labels, and the room never moves.
• Stakeholder and site reviews use standalone headsets with optimised models. They travel to client offices and site cabins, and set up in minutes.

The team accepts that the standalone headsets show less detail, because their purpose is shared understanding rather than engineering sign-off.

Where to go next

For building and infrastructure models, see the AEC hardware requirements paper. To match review types to a device class, start with the Platform Finder.