A task for the model

A digital twin connects a model of an asset with data about its condition. It may help choose maintenance timing, calculate a heating setting or compare equipment operating modes. That question determines the model, required measurements and how the result is checked.

Imagine heating a teaching building

Imagine a fictional building where heating should follow class schedules. The model must describe how rooms cool, warm-up time and the effect of outside temperature. Detailed furniture imagery does not answer those questions when thermal relationships and actual measurements are missing.

The pilot gains a testable task: compare predicted temperatures with observations after an agreed operating change. This limits the project to one decision instead of trying to reproduce every building property immediately.

Make the connection with reality visible

Establish which information arrives automatically, which is updated manually and which is assumed constant. Replaced windows, timetable changes or equipment repairs may make the previous model less suitable. Users should see input status and understand when a calculation relies on an outdated assumption.

Keep model versions separately from current measurements. This allows the rules behind a particular prediction to be explained. If a model changes retrospectively without history, a good match is hard to distinguish from fitting the result, and comparisons between periods lose meaning.

Validation includes applicability

NIST's work on digital-twin credibility discusses model verification, comparison with reality and uncertainty assessment throughout the lifecycle. A practical pilot should define test conditions and acceptable discrepancy in advance. One match on an uneventful day is insufficient.

For heating, separately test occupied and empty rooms, mild weather and colder conditions. Without severe-frost data, the model should not present such a forecast with the same confidence. Applicability limits are part of the result that decision-makers need to receive.

Prediction is another step away from control

An acceptable forecast does not automatically justify letting the model change equipment. Calculation and automatic control have different error consequences. Initially, an employee may compare recommendations with normal settings and approve action; the team can then assess where autonomy is justified.

Discuss lost connections, unusual readings and conflicting sources. Who notices, which mode remains active and who can stop a change? Answers must concern the specific installation. A general twin demonstration cannot replace tests of the connected system under those conditions.

Maintaining the model

Models need maintenance: updating object descriptions, checking sensors, investigating discrepancies and revisiting assumptions. If nobody owns this work, accuracy gradually becomes unknown. Include operation and verification time alongside visualisation creation and data connection.

Sources