What is a digital twin?

Ask two questions of any system sold as a digital twin: when was each element last checked against the physical world, and to what accuracy? Many cannot answer either. They are 3D models, sometimes excellent ones, with no defined data path back to reality. The Digital Twin Consortium definition makes that path the core of the concept: synchronisation at a specified frequency and fidelity. This guide uses that test to set out the components, types, data sources and documented examples of digital twin technology.

What a digital twin is, precisely

The Digital Twin Consortium defines a digital twin as "an integrated data-driven virtual representation of real-world entities and processes, with synchronized interaction at a specified frequency and fidelity". Two terms carry the weight. Fidelity is how closely the model matches reality: geometric accuracy, semantic detail and the attributes captured. Frequency is how often the twin is brought back into agreement with the physical world. If neither is stated, the twin cannot be tested, because nobody can say whether it is current or correct.

Manufacturing has its own standard. The ISO 23247 series, Digital twin framework for manufacturing, was published from 2021 in four parts: overview and general principles, reference architecture, digital representation, and information exchange. NIST's use case scenarios for ISO 23247 summarise the framework's definition: a fit-for-purpose digital representation of an observable manufacturing element, synchronised with that element. Observable elements include personnel, equipment, materials, processes, facilities, the environment, products and supporting documents.

"Fit for purpose" is the practical part. A twin built for shadow analysis needs accurate building heights and roof geometry, but nothing about lifts or ventilation. A twin built for predictive maintenance on a pump needs vibration and temperature data at high frequency, but only rough geometry. There is no universal twin of a place, only a twin for a defined set of questions. Fidelity and frequency follow from those questions, and setting them is the first engineering decision on any project.

A simple test follows. If there is no physical counterpart, no defined data path from it, or no schedule for running that path, the object is a model or a visualisation, not a twin. A good static model is often the starting geometry for a twin, but calling it one hides the cost of keeping it current, usually the larger cost over the asset's life.

The five components of a digital twin

The first component is geometry: a 3D representation of the physical entity. For a factory cell it may be a CAD assembly. For a building it is usually a BIM model. For a city it is a mix of building footprints, extruded or modelled volumes, a digital terrain model (DTM) of the bare ground and a digital surface model (DSM) of the top surfaces, including buildings and vegetation. Geometry carries a coordinate reference system (CRS), which is what lets data from different sensors be placed in the same space.

The second is data integration. A twin takes in CAD and BIM files, lidar point clouds, photogrammetric meshes, satellite rasters, asset registers and sensor telemetry, each with its own format, resolution and CRS. Integration means transforming these into a common reference frame, linking each record to the right object and recording where every value came from. Most of the real work in a twin project sits here, not in the 3D rendering.

The third is the update loop, which keeps the twin synchronised. It can be a scheduled satellite ingest, a repeat drone survey, a message queue receiving telemetry, or a change detection job that compares a new scan with the existing model. The loop has to define what triggers an update, how changes are validated, how conflicts between sources are resolved and how the previous state is kept, so that the history of the asset can be queried later. This is the component that turns a model into a twin.

The fourth is analytics and simulation. A current twin can answer questions: which roof faces receive the most sunlight, which bridge bearings show abnormal movement, how a flood would spread across a district. Some analytics are descriptive, such as measuring and counting. Others are predictive and use physics-based simulation or machine learning models trained on the twin's history. The fifth component is the interface: visualisation for people and APIs for software. Without APIs, the twin cannot feed maintenance planning tools, energy models or robot fleets.

Levels of twin: component to city

Twins are usually grouped by the scale of the entity they represent. A component twin represents a single part, such as a bearing, a turbine blade or a valve. It is usually built from CAD geometry and a physics model, updated with sensor data from that part, and used to study behaviour under load, heat or wear. An asset twin represents a complete machine or structure: a pump, a crane, a robot arm or a single bridge. It links the components so that the behaviour of the whole can be studied.

A system twin represents several assets working together, such as a production line, a water distribution network or a container terminal. At this level the interest shifts from the condition of individual assets to flows, capacity and dependencies between them. A site or city twin represents a whole environment: a campus, an industrial site, an airport or a city. These twins are dominated by geospatial data, because the main questions concern location, terrain, buildings and networks.

A city twin may hold millions of objects, from buildings to street trees and utility lines. At this scale, data volume, level of detail and update cost become the main engineering problems. Levels of detail are usually tiered, so that a district can be streamed as simple block volumes while a single street loads full roof shapes and facades.

The levels nest. A site twin can contain asset twins, which in turn contain component twins, provided the data model supports links between them. A municipality may start with a city-scale 3D model for planning and add asset twins of bridges or pumping stations later. The data model and coordinate framework should allow for that growth from the start, because changing the CRS or object identifiers after years of updates is expensive.

Descriptive, predictive, static and living twins

Twins can also be classified by what they do. A descriptive twin shows the current or recorded state of the entity: geometry, condition, sensor values and history. Most operational twins in infrastructure are descriptive first. A predictive twin estimates future states, for example the remaining useful life of a component, the load on a network next week or the effect of a new building on wind and daylight in a street.

Prediction needs a model of how the system behaves. That model can be physics-based, such as finite element analysis for a bridge deck or hydraulic modelling for a sewer network, or data-driven, such as a neural network trained on the twin's sensor history. Either way, a predictive twin is only as reliable as the descriptive layer underneath it. If the input data are out of date, the forecast inherits the error.

A static twin is a snapshot: a survey, a scan or a BIM model captured once and rarely updated, often for design, construction handover or a one-off study. A living twin, also called an operational twin, is updated continuously or on a regular schedule and records how the entity changes. Strictly, a static twin does not meet the synchronisation part of the definition, which is why many engineers prefer to call it a digital model.

The categories combine. A city twin used for solar studies may be descriptive and refreshed once a year, while a pump twin used for maintenance may be predictive and updated every few seconds. Type, fidelity and update frequency belong in the project specification.

Data sources and update frequencies

Digital twin data comes from five main families, each with its own resolution, accuracy and refresh pattern. CAD and BIM files provide design geometry and object semantics. The open BIM exchange format is IFC, standardised as ISO 16739-1:2024, and the 2024 edition added coverage for infrastructure such as bridges, roads, railways, waterways and port facilities. BIM tells a twin what should be there. It does not confirm what was actually built.

Airborne and terrestrial lidar provide measured geometry as point clouds, and point density limits what can be extracted. The USGS 3D Elevation Program sets lidar quality levels where QL2 requires at least 2 points per square metre and QL1 at least 8, both with a vertical accuracy of 10 cm RMSEz. That is enough for terrain and building heights. Bridge bearings or pipe racks need far denser terrestrial or mobile scans. Drone photogrammetry produces textured meshes and orthophotos, with ground sample distance (GSD) set by flying height, focal length and sensor pixel size.

Satellite imagery gives wide coverage and a regular revisit. The Copernicus Sentinel-2 mission samples 13 spectral bands, four of them (blue, green, red and near-infrared) at 10 m, with a 290 km swath and a five-day revisit at the equator from two satellites. That is too coarse for building geometry but well suited to monitoring vegetation, water, land cover and large-scale change around a site. IoT telemetry, the fifth family, provides time series from strain gauges, accelerometers, flow meters, weather stations and machine controllers.

A twin is therefore always multi-rate. Geometry is refreshed by surveys while telemetry streams in. A well-designed twin keeps each layer at its own frequency and records the capture date of every element, so that a two-year-old scan is never mistaken for current conditions.

Digital twin examples by industry

At the largest scale, the European Commission's Destination Earth initiative is building a digital model of the Earth system. ECMWF develops the twins, ESA runs the core service platform and EUMETSAT operates the data lake that brings Copernicus and other data together. The system launched in June 2024 with its first two twins, one for extreme events and one for climate change adaptation, which combine real-time observations with high-resolution modelling.

At airports, the Airport Authority Hong Kong described in 2019 a digital twin developed with CHAIN Technology that collects real-time data from IoT devices deployed across the airport. Using predictive analytics, it provides alerts to the airport community so that resources can be deployed more effectively.

In cities, Virtual Singapore is one of the best documented programmes. Run by the National Research Foundation with the Singapore Land Authority and GovTech, it is a semantic 3D model of Singapore linked to environmental data. Because the model knows which surfaces are roofs, walls and windows, it can select surfaces of a given height or orientation and calculate the sunlight they receive, to estimate solar energy potential. The platform was also designed for flood, wind flow and pollution modelling.

Shadow and solar analysis in a city twin works by computing the sun's position for each time step from date, time and location, then casting rays from that position against the DSM or the 3D building model. Each surface is marked lit or shaded, and accumulating results across a day or a year gives hours of direct sun and solar exposure per roof face. Planners use this to test the shadow impact of proposed buildings. Solar engineers combine it with roof tilt and orientation to decide where panels will perform and where obstructions will cut yield.

Utilities and infrastructure owners build twins of networks and structures. A water utility twin typically combines network geometry from a GIS with pipe attributes, pressure and flow telemetry and a hydraulic model, so that operators can locate leaks and test the effect of closing a valve. A bridge twin combines as-built geometry from BIM or lidar, inspection records, photogrammetric meshes of the deck and piers, and structural health monitoring data from strain gauges, accelerometers and displacement sensors, so that maintenance can follow measured behaviour rather than fixed intervals.

Forestry twins are almost entirely geospatial. Airborne lidar gives a DTM and a DSM, and subtracting one from the other produces a canopy height model, from which tree heights and crown extents are derived. Multispectral imagery adds indices such as NDVI, computed from the red and near-infrared bands, to track canopy health and disturbance between surveys. In factories, ISO 23247 applies directly: equipment, materials and processes are the observable elements, and the twin is used to monitor production and test changes to a line before making them.

Digital twin vs operational digital twin

The terms are often used interchangeably. A digital twin, in the sense used through most of this guide, is the environment model: the integrated geometry, semantics and data that describe a place or asset at a given fidelity. An operational digital twin is the software system that keeps that model current and usable in daily work. It is the difference between a good map and the service that maintains it and hands it to other systems.

An operational twin adds four capabilities a model does not have. Spatial queries, such as all assets within 50 m of a pipeline or all south-facing roofs with no obstruction. Roles and permissions, so a maintenance contractor sees different layers from a planning officer. A change history, so users can compare a site today with its state last quarter. And APIs, so other software can read from and write to the twin without exporting files.

History matters because owners need to know when a crack first appeared or when vegetation began to encroach on a power line, not only the current state. An operational twin stores each update as a versioned change with its source and capture date, so every value can be traced back to a survey, a sensor or a manual edit.

The operational layer is also what makes live data and automation possible. Telemetry needs an object with a stable identifier to attach to, and robots need a current shared map. Without it, each new sensor or machine creates its own isolated model, and the organisation ends up with several partial twins that disagree. This shared, queryable model of real places is the basis of what we describe as spatial intelligence.

Why robots need digital twins

Robots do not load a BIM model. They load a robot-ready map: a representation in the format their navigation stack expects. For many mobile robots that is a 2D occupancy grid in which each cell is free, occupied or unknown. In ROS, for example, the map server reads an image file plus a YAML file giving the resolution in metres per cell and the map origin. Other stacks use 3D point cloud or voxel maps. A twin can generate these from as-built geometry, cut at the height band the robot's sensors see, in a frame with a defined transform to the site CRS.

The same export serves as a localisation prior. Many industrial robots localise against a prior map rather than mapping continuously, for example with a particle filter matching 2D lidar scans to the grid, or with ICP or NDT scan matching against a 3D point cloud. A prior taken from a current survey gives the robot an accurate reference from its first run. SLAM still matters, but it only knows what the robot has already seen. It cannot know about an aisle blocked beyond sensor range or a bay that was rebuilt last week.

Simulation is the third use. Testing in the real world is slow, expensive and sometimes unsafe, so teams import the twin's meshes into a simulator such as Gazebo or Isaac Sim and run robots on the real layout first. The twin fixes the geometry. Domain randomisation then varies textures, lighting, object placement and sensor noise around it. Work on domain randomisation for transferring networks from simulation to the real world trained an object detector only on simulated images with non-realistic random textures and localised real objects to within 1.5 cm. The two approaches are complementary: accurate site geometry plus randomised appearance.

Keep-out zones and site rules belong in the twin's semantic layer. Restricted areas, speed-limited zones, one-way aisles and charging bays can be stored as versioned polygons and exported as map masks. ROS 2 Nav2, for instance, supports keep-out and speed filters driven by such masks. Defining these rules once in the twin means every robot, drone and human-facing system works from the same boundaries, and the change history shows when each zone changed.

Change triggers close the loop. When a robot's scans repeatedly disagree with the twin, for example cells observed as occupied over several passes where the twin says free, the discrepancy is flagged as a candidate change. Once validated, the change updates the twin and triggers a fresh map export to every robot on the site. The fleet becomes a set of mobile sensors that keep the twin current, and the twin keeps each robot aware of changes it has not seen itself.

A twin supplies maps, context and a place to test. It does not replace a robot's onboard perception, safety-rated systems or motion planning, and it does not take driving decisions. Our robotics solutions page shows where the twin fits in a robot programme. The next layer we are building towards in Smartout is a robot perception engine that generates robot-ready twins from CAD and BIM, syncs them to robots and uses their camera and lidar feeds to update the shared twin in near real time.

How Kaiinos builds digital twins

Kaiinos brings more than a decade of geospatial delivery to its twin work, including municipal mapping, utilities, forest and wildlife conservation and waterbody mapping. Two projects show the range. The first is a city digital twin used for shadow analysis and for the engineering design of solar panel installations. It models buildings and surfaces so that sun exposure and shading can be computed per roof face, the mechanism described in the examples above.

The second is a set of digital twins of four bridges. Each twin brings a bridge's geometry and associated data into one model that engineers can inspect and query, instead of working from separate drawings, survey files and inspection reports. Bridges show why measured geometry matters: the as-built structure often differs from the design drawings, and maintenance decisions depend on what is actually there.

Both projects run on the same operational layer. Our Smartout platform creates and maintains digital views of environments from CAD and BIM, lidar and drone surveys and satellite data, fuses multiple sensors into one reference frame, and provides visualisation, spatial queries, change history and APIs. The technology behind Smartout covers how these data are processed and aligned, and our use cases page shows the approach across warehouses, manufacturing sites, municipalities, forest departments, solar parks, fisheries and maritime sites.

Our method follows the definition at the top of this guide. Each project starts by agreeing the questions the twin must answer, then sets the fidelity and update frequency those questions require, then selects the data sources that can deliver them at a sensible cost.

Frequently asked questions

What is the difference between a digital twin and a 3D model?

A 3D model is a geometric representation that may never change after it is created. A digital twin is linked to its physical counterpart by a data connection and is updated at a defined frequency and fidelity. A twin also usually carries semantics, history, analytics and APIs. A 3D model is often one component of a twin, but on its own it does not meet the definition.

What are the main types of digital twin?

By scale, twins are grouped into component, asset, system and site or city twins. By function, they are descriptive, showing current and past state, or predictive, estimating future states through simulation or machine learning. By update pattern, they are static snapshots or living operational twins refreshed continuously or on a schedule. Most real projects combine several of these types.

What data is needed to build a digital twin?

It depends on the questions the twin must answer. Common sources are CAD and BIM files for design geometry, lidar point clouds for measured geometry, photogrammetric meshes from drone imagery, satellite imagery for wide-area monitoring and IoT telemetry for live state. Each source must be transformed into a shared coordinate reference system and linked to the right objects in the twin.

How often should a digital twin be updated?

Update frequency should match the rate at which the relevant part of the physical world changes and the decisions the twin supports. Machine telemetry may update every few seconds, satellite layers every few days, and building geometry once a year or after construction work. A good twin records the capture date of each layer so users always know how current it is.

Is a digital twin the same as a simulation?

No. A simulation is a model run to explore how a system behaves under given conditions. A digital twin is a synchronised representation of a specific physical entity. Twins often host simulations, for example shadow, flood or structural studies, and supply the current, real-world starting conditions. A simulation with no link to a physical counterpart is not a twin.

Start with the questions it must answer

If you are planning a digital twin of a site, a structure or a city, the most useful first step is to define its fidelity, update frequency and users. Book a technical call to discuss your data and use case.