Digital Twin Modelling

Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.

1. 01Enquiry and requirement assessment
2. 02Technical scoping and proposal
3. 03Execution
4. 04Quality review and delivery, with an agreed round of revisions

Read the full project workflow.

In depth: how the work is done

1. Defining purpose and fidelity

   We begin with the decision the twin supports, for instance scheduling maintenance, detecting abnormal behaviour or exploring operating alternatives. The decision determines the required quantities, accuracy, update frequency and latency. Fidelity is chosen to be sufficient, not maximal: a simple physics-based or data-driven model that runs in real time may serve better than a detailed model that cannot be updated. The requirements are written down and used later to judge whether the twin is fit for purpose.

2. State estimation and data assimilation

   Sensors provide partial and noisy measurements, while the model describes how states evolve. State estimation techniques, from Kalman-type filters for linear or mildly nonlinear systems to particle and ensemble methods for strongly nonlinear ones, combine the two to estimate states and, when needed, parameters. Observability analysis checks whether the available sensors make the quantities of interest estimable at all. Sensor faults and communication gaps are anticipated in the design.

3. Reduced-order and hybrid models

   High-fidelity simulations are rarely fast enough for continuous updating. Reduced-order models derived from simulations or data capture dominant behaviour at low cost. Hybrid approaches combine physics-based models with data-driven corrections that learn residual discrepancies. Each approach has a domain of validity, and the twin should monitor whether operating conditions have drifted outside it. We help select and validate the approximations in light of the required accuracy.

4. Validation, drift and lifecycle

   A twin is validated by comparing its estimates with independent measurements across the range of operating conditions, including unusual ones. Over time, asset wear, repairs and changes in operation can make the model drift from reality, so monitoring of residuals and re-calibration procedures are part of the design. Governance matters too: version control for models and data, records of assumptions and clear statements about who may act on twin outputs and under what conditions.

5. Governance, data and ethics

   Digital twins depend on continuous data, which raises questions of ownership, security and access. We recommend documenting who owns the data and models, how access is controlled, how sensor data are validated and how the twin's outputs are to be used in decisions. For safety-relevant applications, clear boundaries on the use of twin outputs and a human-in-the-loop requirement are advisable. These considerations are best settled early, because they affect architecture as well as policy.

Common pitfalls this service helps avoid

• Starting with technology, not purpose. A twin without a decision to support accumulates data and cost without value.
• Unobservable states. If sensors cannot reveal the quantity of interest, no estimator can recover it reliably.
• Ignoring model drift. As assets change, a once-accurate model can quietly become misleading.
• Overstating autonomy. Twin outputs are estimates with uncertainty and should support, not replace, engineering judgement.

What good reporting looks like

A digital-twin design report states the purpose and requirements, system description, available data and sensors, modelling approach, estimation method with observability analysis, validation against operating data, performance measures, monitoring and update strategy and limitations. It describes data flows and assumptions in enough detail for implementation by an engineering or software team. It does not claim capabilities that have not been validated, and it distinguishes proposed design from demonstrated performance.

An illustrative scenario

Hypothetical example written for explanation. It is not a client case, a result or a testimonial.

Imagine a team that wants a model of a pump station to support maintenance planning. The requirements state that bearing temperature and vibration trends must be tracked hourly. A reduced thermal model is driven by measured flow and ambient temperature, a filter estimates unmeasured heat generation, and the residual between model and sensor flags unusual behaviour. Validation against a year of data shows good tracking in normal operation and poorer performance during start-up transients, which the report records as a limitation.

Questions to settle before you begin

• What decision will the twin support, and how fast must it respond?
• Which states matter, and can sensors observe them?
• How will model and sensor errors be separated?
• What independent data will validate the twin?
• How will I detect and correct model drift over time?

Key terms

Digital twin

A model kept synchronised with a physical asset using data.

State estimation

Inferring system states from a model and noisy measurements.

Observability

Whether measurements allow system states to be determined.

Data assimilation

Combining models with observations to update estimates.

Reduced-order model

A simplified model capturing the dominant behaviour at lower cost.

Working together on Computational Engineering & Modelling projects

Computational engagements begin by agreeing the question, the quantities of interest and the accuracy that matters, so that modelling effort goes where it changes the answer. We ask for geometry or system descriptions, operating conditions, material or property data and any measurements for validation. Early on, a small pilot case often checks feasibility and cost. Models are verified and, where data allow, validated before parametric results are produced. Software, versions and settings are recorded so results can be reproduced. Where inputs are missing, assumptions are listed and agreed rather than quietly filled in.

Few projects need a single service in isolation. These are the services most often combined with this one.

• Multiphysics Modelling

  Coupled simulation of interacting physical phenomena, such as fluid-structure, thermal-structural, electro-thermal or thermo-chemical problems, where one-way or two-way coupling must be chosen deliberately.

• Predictive Maintenance

  Development of condition-based and predictive maintenance analytics: health indicators, anomaly and degradation models, and remaining-useful-life estimation where failure data allow.

• Industrial IoT Analytics

  Analytics for data streams from connected industrial equipment, including data-quality assessment, aggregation, monitoring indicators and architecture considerations for analysis.

• AI & Machine Learning for Engineering

  Machine-learning methods for engineering problems with physical data, designed around data quality, leakage-free validation and a clear account of when the model should not be trusted.