Digital Twin: What It Is, Architecture, BIM, IoT, and Asset Management

Understand what a Digital Twin is, how it differs from BIM and Digital Shadow, and how data, IoT, OT systems, analytics and asset management fit together.

Check it out!

Digital Twin, or Digital Twin, is a data-driven digital representation of a real entity, system, or process, maintained in a synchronized relationship with what it represents to support monitoring, diagnosis, simulation, forecasting, and decision-making. The concept is not limited to a 3D model and does not depend on specific software: its value lies in connecting information, operational context, and behavioral models to real decisions.

In engineering, a Digital Twin can bring together BIM models, asset registers and hierarchies, sensor data, BMS, SCADA, DCIM, EPMS, historians, CMMS/EAM, technical documents, inspections, time series, engineering rules, and physical and analytical models. This combination can represent anything from a single piece of equipment to systems, buildings, industrial plants, data centers, campuses, infrastructure networks, and entire portfolios.

The term, however, is often overused. A BIM model published in the cloud, a telemetry dashboard, or a supervisory system does not automatically become a Digital Twin. To create technical value, it is necessary to define what is being represented, why, at what fidelity, at what frequency, from which data sources, with what level of confidence, and which decisions the system must support.

Therefore, the most important question is not “which platform creates a Digital Twin?”, but which operational or engineering problem needs to be solved and what information, integration, analytics, and governance architecture is proportional to that objective. A Digital Twin should be designed from use cases and measurable benefits; technology is a consequence.

What is a Digital Twin and what actually characterizes one

The ISO/IEC 30173:2023 establishes Digital Twin concepts and terminology across sectors. It treats the Digital Twin within a system context, including lifecycle, types, functional view, and stakeholders. The Digital Twin Consortium converges on a similar idea by describing a Digital Twin as an integrated, data-driven virtual representation of real entities and processes, with synchronized interaction at specified frequency and fidelity.

This formulation contains five ideas that matter more than the presence of a 3D model:

1. there is a real entity or process with a clearly defined boundary;
2. there is a digital representation with identity and context;
3. there are data that maintain a relationship between the physical and digital domains;
4. frequency and fidelity are defined according to the use case;
5. the representation exists to produce understanding, decision, or action.

A Digital Twin is not synonymous with a 3D model

Geometry can be extremely useful for spatial context, navigation, coordination, and asset association, but a Digital Twin does not necessarily require a 3D interface. For some use cases, a process model, asset graph, mathematical model, or set of contextualized time series may be more important than geometry.

This is especially relevant in asset engineering. A Digital Twin of a substation, HVAC system, or UPS fleet may need to represent topology, dependencies, operating states, constraints, and failure modes with far more rigor than visual detail.

Digital Model, Digital Shadow, and Digital Twin

A useful way to avoid indiscriminate use of the term is to distinguish the nature of the relationship with the asset.

Concept	Relationship with the real world	Update	Typical capability
Digital Model	representation without mandatory operational synchronization	manual or occasional	design, documentation, study, and isolated simulation
Digital Shadow	the physical world automatically updates the digital representation	recurring, predominantly physical → digital	monitoring, history, and diagnosis
Digital Twin	physical and digital domains participate in an integrated information and decision system	synchronization according to required frequency and fidelity	monitor, diagnose, predict, optimize, and support intervention

This distinction should not become an artificial maturity scale. There are situations in which a well-implemented Digital Shadow fully solves the problem. Adding write-back commands, AI, or simulation merely to use the “Digital Twin” label can increase cost and risk without creating value.

Frequency, latency, and fidelity need to be proportional to the decision

“Synchronized” does not necessarily mean “real time.” Frequency should be defined by the observed phenomenon and supported decision. Protection, machine control, and some power systems may require very short times; building energy management may work at minute intervals; structural condition inspection may operate daily, weekly, or by event.

It is also necessary to distinguish collection frequency, processing frequency, integration latency, and decision frequency. A sensor may sample at high frequency and still send only aggregates to the Digital Twin. This architecture reduces data volume while retaining what actually matters for the use case.

Fidelity is also contextual. It may involve geometric accuracy, temporal resolution, sensor accuracy, state representation, physical-model accuracy, or predictive capability. The right question is: how much fidelity is needed for the decision to be reliable?

A Digital Twin also has a lifecycle

The Digital Twin itself needs to be designed, configured, tested, operated, updated, and eventually decommissioned. Sensors are replaced, equipment changes, business rules evolve, systems are migrated, and models lose adherence. Without configuration management, the Digital Twin may continue to function technically while no longer representing the asset it is supposed to represent.

Therefore, version, authorship, validity date, change history, recalibration criteria, and update process need to be part of the architecture from the outset.

Digital Twin, BIM, AIM, IoT, BMS, SCADA, CMMS, and Digital Thread: how they connect

A Digital Twin is rarely an isolated technology. In engineering assets it works as an integration and context layer between systems that already perform specific roles. Confusing these roles leads to expensive and redundant architectures.

Technology / concept	Primary role	What it can provide to the Digital Twin
BIM	design/asset information representation and management	geometry, systems, spaces, properties, classification, and relationships
AIM	asset information model for the operational phase	structured register, requirements, documents, and information needed for operations
IoT / IIoT	field-data acquisition and communication	telemetry, condition, state, environment, and events
BMS	building supervision and control	HVAC states, setpoints, alarms, schedules, and environmental variables
SCADA	industrial-process and infrastructure supervision	states, measurements, commands, alarms, and process events
DCIM / EPMS	data-center capacity and critical infrastructure / power	load, capacity, topology, energy, environment, and alarms
CMMS / EAM	maintenance and asset management	work orders, plans, failures, interventions, costs, and history
Historian / time-series database	time-series persistence	operational history with temporal resolution
CDE	controlled BIM information/document management	statuses, versions, approvals, models, and engineering documents
Digital Twin	integrate context, state, models, and decisions	contextualized view and analytical capabilities over the real asset

BIM can provide the spatial and semantic structure

A well-structured BIM model is an excellent starting point because it organizes what exists, where it is, which system it belongs to, and which properties were defined in design. The article on BIM Modeling in Engineering explains in greater depth how models, objects, and information are structured before any operational application.

During the transition to operations, the BIM Information Management according to ISO 19650 is fundamental. The ABNT NBR ISO 19650-3:2025 specifically addresses the operational phase, PIM → AIM continuity, asset information requirements, trigger events, and integration with enterprise systems.

AIM is not automatically a Digital Twin

The AIM — Asset Information Model can bring together the information required to manage the asset. It can exist without continuous telemetry or simulation. A Digital Twin, in turn, can consume the AIM as a context layer and relate it to dynamic data, analytical models, and operational workflows.

In simple terms:

PIM records and structures design/handover information → AIM consolidates the information needed by the asset → integrations connect operational systems → Digital Twin contextualizes state, behavior, scenarios, and decisions.

This relationship also explains why BIM 7D and Digital Twin are complementary but not synonymous. BIM 7D is a market convention associated with operations and asset management; a Digital Twin is a use-case-oriented representation and synchronization architecture.

IoT is a data source; it is not the Digital Twin

Sensors and connected devices are often necessary, but simply sending data to the cloud does not create context. To interpret temperature, current, vibration, or pressure, it is necessary to know which asset generated the data, where it is, its operating state, the expected range, and what decision will be made when a deviation occurs.

The content on Internet of Things — IoT serves as a complementary technology layer. In a Digital Twin, telemetry needs to be associated with identity, meaning, and quality rules.

BMS, SCADA, DCIM, and EPMS remain specialist systems

It makes no sense to replace mature OT systems with a generic Digital Twin. BMS remains responsible for building automation; SCADA for process supervision; DCIM for data-center capacity and infrastructure operations; EPMS for electrical supervision. The Digital Twin can integrate and contextualize information produced by these systems, adding cross-domain analysis.

In data centers, for example, the article on DCIM, BMS, and EPMS already defines responsibilities. A Digital Twin can relate power, cooling, capacity, occupancy, alarms, and topology to answer questions that no isolated system can answer adequately.

CMMS and EAM close the maintenance loop

Detecting an anomaly creates no value if the information does not enter the maintenance process. A Digital Twin can transform condition and trend into a recommendation, but CMMS/EAM record plans, work orders, execution, parts, costs, and history. This feedback is essential: after intervention, the Twin should know what was done and verify whether expected behavior was restored.

This integration directly connects the Digital Twin to the Engineering Asset Management service.

Digital Thread: continuity and traceability throughout the lifecycle

The concept of Digital Thread is particularly important because it prevents design, construction, handover, and operations from becoming digital silos. ISO 23247-5:2026, although focused on manufacturing, formalizes the role of the digital thread in connecting, managing, and maintaining digital twins throughout the lifecycle.

For the built environment, the analogy is powerful: requirement → design → specification → procured equipment → installed asset → operational tag → automation point → history → maintenance → replacement. The value is not in copying all these data into a single database, but in maintaining identity, relationships, and traceability among them.

This is where solutions for Systems Integration, APIs, and Connectors stop being merely IT and become part of the asset’s information engineering.

Reference architecture: how a Digital Twin works in practice

A robust Digital Twin should be designed as a system of systems. The exact architecture varies, but some layers appear repeatedly because they solve different problems.

1. Physical asset, process, and system boundary

First, the represented object needs to be defined. It may be a chiller, production line, substation, floor, data center, building, or portfolio. The boundary needs to state what is inside and outside the Twin because it determines interfaces, responsibility, and data volume.

Operating states also need to be identified. The same equipment may have different expected behavior during startup, normal operation, standby, maintenance, or degraded conditions.

2. Instrumentation, sensors, and source systems

This layer includes sensors, PLCs, controllers, meters, BMS, SCADA, EPMS, DCIM, security systems, IoT devices, and other sources. Not every data point needs to be created specifically for the Twin; existing instrumentation should first be reused and evaluated for quality, coverage, and suitability.

For each relevant variable, it is important to record:

• authoritative source;
• unit and expected range;
• resolution and collection frequency;
• timestamp and time reference;
• quality and reliability;
• communication status;
• calibration method where applicable;
• maintenance responsibility.

3. Edge, gateways, and OT/IT integration

Between the field and enterprise applications there may be gateways, brokers, edge servers, APIs, and integration services. Industrial and building environments may use protocols such as OPC UA, MQTT, BACnet, Modbus, and proprietary interfaces. The Digital Twin does not need to physically standardize every protocol; it needs to ensure interoperability and consistent meaning above them.

Edge computing can be used for filtering, aggregation, local detection, and continuity when the connection to the central platform fails. This matters when latency, availability, or volume makes it impractical to send all raw data to the cloud.

4. Identity, semantics, and information model

This is one of the most underestimated layers. The point AI_TEMP_204 in the BMS, the object AHU-01 in BIM, and the asset 00018372 in the EAM need to be recognized as representations of the same entity or clearly defined relationships.

Without persistent identity and taxonomy, integrations become fragile pairs of connections. A mature Digital Twin needs rules for IDs, classes, functional hierarchies, locations, system-component relationships, units, names, and mappings between platforms.

Ontologies, knowledge graphs, or semantic models can be useful in complex environments, but they are not mandatory. The real requirement is being able to answer unambiguously: which entity does this data describe, and how does it relate to the others?

5. Current data, historical data, events, and context

Current state is not enough. The Twin needs to distinguish current value, historical series, events, alarms, configuration changes, maintenance interventions, component replacement, software or logic changes, environmental conditions, and operating state.

This history makes it possible to investigate causal sequences. A failure is rarely explained by a single variable; it is usually necessary to reconstruct the context before, during, and after the event.

6. Physical models, rules, analytics, and AI

The Digital Twin can contain more than one “model.” Deterministic engineering rules, mass and energy balance models, thermal or electrical models, discrete simulations, statistical analysis, anomaly detection, prognostics, machine learning, optimization, and risk models may coexist.

AI is a tool, not a requirement. A rule based on a manufacturer curve, operating envelope, or physical principle may be more transparent and reliable than a machine-learning model trained on limited failure data.

7. Applications, visualization, and workflow

Dashboards, 3D interfaces, maps, alarms, and reports belong to this layer. A common mistake is to start here because it is the visible part. Real value, however, depends on the previous layers.

The application should present the information needed for a person or system to make a decision. It may open a work order, record a recommendation, trigger an inspection, compare alternatives, update risk, or initiate a control action.

8. Feedback and action in the physical world

Some Twins remain observational; others may recommend or execute actions. The greater the degree of automation, the stricter the requirements for safety, validation, and authority.

We can think of a progression of autonomy:

1. observe — consolidate state and history;
2. diagnose — explain deviations;
3. predict — estimate future state or failure;
4. recommend — suggest action;
5. orchestrate — initiate workflows in other systems;
6. act — directly alter the physical process within controlled limits.

The architecture should not jump directly to automatic actuation without proving the reliability of the previous stages.

Composition and federation of multiple Digital Twins

In large projects, a single Twin rarely contains everything. There may be one Twin for the electrical system, another for HVAC, another for production, another for security, and a higher operational layer. The ISO 23247-6:2026, in the manufacturing context, formalizes integrated, unified, and federated approaches to composing multiple Twins.

This concept is also relevant to buildings and infrastructure: each domain can retain technical autonomy while sharing an identity model and controlled interfaces. This reduces the risk of creating a monolithic platform that is impossible to evolve.

Use cases: where Digital Twin creates value in engineering and operations

The architecture should originate from use cases. The Digital Twin Consortium uses this logic in its Capabilities Periodic Table: first identify needs and capabilities, then platforms and technologies.

Design and Value Engineering

During design, a Twin can begin as a Digital Twin Prototype, using engineering and simulation data before synchronization with the physical asset exists. This makes it possible to compare alternatives for capacity, consumption, control, layout, redundancy, and behavior.

There is a direct connection with BIM 6D: efficiency and performance goals can originate during design and later be verified in operation.

Construction, As-Built, and digital handover

An operational Digital Twin depends on handover quality. Divergent tags, equipment replaced without documentation updates, and missing serial numbers, manufacturers, or locations create information debt before operations even begin.

Therefore, Engineering As-Built should not be seen merely as final documentation. It is one of the sources used to reconcile what was designed, what was installed, and what will be managed.

Commissioning and baseline validation

The Engineering Commissioning creates an essential opportunity: recording test conditions, sequences, setpoints, results, and expected behavior before permanent operation.

This baseline can feed future Fault Detection and Diagnostics — FDD rules. If the Twin knows the design intent and validated performance, it becomes easier to distinguish real degradation from expected behavior.

Condition monitoring and risk-based maintenance

In maintenance, the flow can be:

1. measure condition and context;
2. validate the data;
3. compare with a limit, baseline, or model;
4. detect deviation;
5. assess criticality and consequence;
6. estimate urgency;
7. recommend inspection or intervention;
8. create a workflow in the CMMS/EAM;
9. record execution;
10. verify whether the intervention corrected the behavior;
11. feed the outcome back into history and the model.

This approach makes it possible to evolve from purely calendar-based maintenance to condition-based maintenance when technically justified. It does not eliminate mandatory preventive maintenance or normative criteria.

Energy efficiency and actual performance

A Twin can correlate consumption, demand, weather, occupancy, setpoints, thermal load, and equipment state to explain performance variations. The value is not simply displaying kWh, but assigning context and probable cause.

For example, increased HVAC energy use may be linked to a dirty filter, leaking valve, uncalibrated sensor, occupancy change, or control strategy. The analysis needs to separate these hypotheses before recommending action.

Fault Detection and Diagnostics and continuous commissioning

Systems change after handover. Setpoints are modified, sensors degrade, valves stick, sequences are changed, and temporary overrides become permanent. FDD uses rules and models to identify conditions that do not appear as explicit faults in BMS or SCADA.

When integrated with the operating process, this can function as a form of continuous commissioning, comparing current behavior with expected criteria.

Capacity management and Data Centers

Data Centers are a particularly rich use case because power, cooling, space, redundancy, and IT load interact continuously. A Twin can relate UPS status, generator sets, PDUs, chillers, CRAC/CRAH units, racks, circuits, temperature, and capacity to support expansion or contingency planning.

The content on DCIM, BMS, and EPMS in Data Centers is a natural path for deeper study of this use case.

Failure, contingency, and resilience simulation

A trustworthy Twin can be used to test scenarios without exposing the real asset: equipment loss, load change, power failure, subsystem unavailability, capacity expansion, or extreme weather conditions.

For this use, it is essential to state model validity. “The software simulated it” does not mean the result is representative. Assumptions, operating range, and uncertainties need to be known.

Asset portfolio and CAPEX planning

A Digital Twin does not always need to operate at the level of seconds. At portfolio level, a Twin can represent condition, criticality, age, risk, costs, maintenance backlog, and performance to prioritize investments.

In this scenario, integration with asset management may be far more valuable than a sophisticated 3D experience. The focus shifts from “what is happening now?” to “where should we invest and what risk do we accept if we defer?”

When NOT to implement a Digital Twin

There are cases in which the term adds unnecessary complexity. A simple dashboard may be sufficient when:

• only a few variables need to be consolidated;
• there is no need for complex semantic context;
• the decision is simple and already well served by the specialist system;
• the cost of maintaining the Twin exceeds the benefit;
• instrumentation is insufficient or unreliable;
• the operating process cannot act on the analyses produced.

The best strategy is to implement the smallest set of capabilities that delivers measurable benefit and expand only after proving value.

Reliability, interoperability, governance, and cybersecurity

A Digital Twin can create an appearance of precision far greater than its actual reliability. When decisions depend on the Twin, the quality of data, models, and integrations needs to be treated as an engineering requirement.

Verification, validation, and uncertainty

NIST highlights the need for Verification, Validation and Uncertainty Quantification — VVUQ for trustworthy Digital Twins.

• Verification: was the model or software implemented correctly according to its specification?
• Validation: does it adequately represent the phenomenon for the intended use?
• Uncertainty: what confidence margin exists in the inputs and outputs?

A model can be mathematically correct and still be unsuitable for a given decision. Validation needs to be use-oriented.

Data quality is not only an IT problem

Operational data may suffer from frozen sensors, drift, communication loss, incorrect timestamps, unit changes, device replacement, or mapping errors. The Twin needs to know data-quality status and should not treat all values as equally reliable.

For each critical variable, it is useful to define the source of truth, unit, valid range, expected frequency, delay tolerance, missing-data rule, outlier detection, calibration, data owner, historical retention, and impact of unavailability on the Twin’s function.

Interoperability without semantics remains fragile

“Having an API” does not solve interoperability. Systems need to agree on identity, units, meaning, version, and status. The service of Systems Integration is directly relevant because integration needs to be designed as architecture rather than a collection of point-to-point scripts.

In composed or federated Twins, this discipline is even more important. Supplier or version changes must not silently break relationships among assets.

Cybersecurity risk grows with IT/OT integration

The ABNT NBR ISO 19650-5:2025 draws attention to cyber-physical systems, sensors, and sensitive operational information. A Digital Twin can concentrate topology, state, location, alarms, operating parameters, and interfaces with critical systems — exactly the kind of context that requires controls proportional to risk.

The architecture should consider segmentation, authentication, authorization, need-to-know, credential management, logs, API security, backups, incident response, and clear separation between read and command functions.

When there is an interface with industrial networks, the content on IEC 62443 and OT cybersecurity is an important cross-cutting reference.

Functional safety and command authority

The ability to write back to the physical world changes the risk profile completely. An incorrect recommendation can be rejected by an operator; an automatic command can produce an immediate consequence.

Therefore, actuation systems need to define authority limits, safe states, interlocks, fallback, human confirmation when necessary, and behavior during communication loss. The Twin should not bypass existing protection or safety logic.

Governance of analytical and AI models

Models also drift. Changes in equipment, process, climate, occupancy, or operating strategy can reduce predictive performance. It is necessary to control model version, dataset used, input variables, physical assumptions, validity range, performance metric, date of last validation, review process, and technical owner.

For AI applications, explainability and the ability to challenge outputs are especially important when decisions affect safety, availability, or significant investments.

Trustworthiness should be an explicit requirement

A useful Twin should allow the user to understand data origin, quality, model version, and limitations. Trust does not mean “believing the platform”; it means having enough evidence to determine whether the result is fit for purpose.

How to structure, procure, implement, and accept a Digital Twin

Implementation should begin with the use case and evolve according to maturity. Platform selection comes after defining the problem, data, and required capabilities.

A practical maturity model

Stage	Characteristic	Outcome
0 — foundation	asset, identity, requirements, and master data defined	reliable information foundation
1 — connected	integrated and contextualized operational data	state and history
2 — diagnostic	rules, baselines, and correlations	explanation of deviations
3 — predictive	models anticipate condition or outcome	forecasting and planning
4 — prescriptive	system compares alternatives and recommends actions	optimized decision support
5 — orchestrated	workflows and, when safe, controlled actuation	closed decision-and-action loop

Not every use case needs to reach Stage 5. The appropriate maturity level is the lowest one that delivers the required benefit with acceptable risk and cost.

12-step implementation process

1. Define the problem and the use-case owner. Specify which decision should improve and who is accountable for it.
2. Define the benefit and KPI. Availability, consumption, MTTR, risk, cost, capacity, quality, or another verifiable indicator.
3. Define the asset and Twin boundary. Identify systems, interfaces, and exclusions.
4. Map required and available data. Assess instrumentation, quality, history, and gaps.
5. Define identity and the information model. Tags, hierarchy, classification, relationships, and sources of truth.
6. Define frequency, fidelity, and latency. Based on the decision, not on the technology’s maximum capability.
7. Design the architecture and integrations. OT, edge, APIs, data platform, models, workflows, and security.
8. Define analytical models and trust criteria. Rules, physics, statistics, AI, and VVUQ as applicable.
9. Implement a vertical pilot. A complete use case, from data to decision, rather than superficial integration of many systems.
10. Test technically and operationally. Data, failures, models, security, workflows, and users.
11. Measure the actual benefit. Compare KPI before/after and the Twin’s total operating cost.
12. Scale modularly. Add use cases, assets, or federated Twins without losing governance.

Requirements that need to be in scope

A technically robust procurement scope should specify objectives and use cases; included assets and systems; stakeholders and responsibilities; data and sources of truth; identity and taxonomy; integration architecture; frequency, fidelity, and quality; retention and history; analytical models; interfaces and workflows; security; service levels; intellectual property; data ownership; portability; documentation; training; testing; updates; and decommissioning.

Minimum deliverables

1. use-case and KPI document;
2. logical and physical architecture;
3. information model and asset identity map;
4. catalog of sources, tags, and variables;
5. interface and API matrix;
6. frequency, fidelity, and quality specification;
7. cybersecurity model and access profiles;
8. analytical-model documentation;
9. operational workflows;
10. test matrix;
11. verification and validation records;
12. operating documentation for the Twin itself;
13. continuity, backup, and recovery plan;
14. maintenance and update plan;
15. portability and decommissioning documentation.

Acceptance criteria should test the entire system

Acceptance cannot be limited to “the dashboard opens.”

Acceptance dimension	Examples of evidence
Identity	correspondence among physical asset, BIM/AIM, automation, and EAM
Data	integrity, unit, timestamp, update, and quality
Integration	normal behavior and behavior during interface unavailability
History	retention, query, traceability, and configuration change
Model	verification, validation, performance, and documented limitations
Workflow	recommendation, approval, opening, and closing of actions
Security	authentication, authorization, logs, segregation, and recovery
Resilience	behavior during loss of communication, sensor, or platform
Operations	training, documentation, and the team’s ability to maintain the Twin
Value	use-case KPI demonstrated under real conditions or a representative test

Avoiding vendor lock-in is part of the design

Digital Twin is a long-term capability. The owner needs to know which data belong to them, which models can be exported, how integrations are documented, which APIs exist, and what happens if the supplier is replaced.

Proprietary formats may be used, but the architecture needs to avoid unnecessary dependence on undocumented knowledge. Exit strategy, configuration backup, history export, and access to model definitions should be addressed contractually.

The expected result is not a “living mockup”

A technically mature Digital Twin is an information and decision system that remains useful as the asset changes. It connects engineering, operations, and management around a trustworthy model of reality without trying to replace every specialist system.

This is also why the topic serves as an entry point to multiple disciplines: BIM structures information; IoT and OT provide state; APIs connect systems; CMMS/EAM turn analysis into maintenance; energy efficiency and FDD measure performance; cybersecurity protects integration; commissioning and As-Built establish the baseline; asset management transforms information into lifecycle decisions.

Technical references

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 30173:2023 — Digital twin — Concepts and terminology. Geneva: ISO, 2023.

[2] DIGITAL TWIN CONSORTIUM. Definition of a Digital Twin. Object Management Group. Current version accessed in 2026.

[3] DIGITAL TWIN CONSORTIUM. Digital Twin Capabilities Periodic Table. Version 1.2. Object Management Group, 2026.

[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 23247-1:2021 — Automation systems and integration — Digital twin framework for manufacturing — Part 1: Overview and general principles. Geneva: ISO, 2021.

[5] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 23247-5:2026 — Automation systems and integration — Digital twin framework for manufacturing — Part 5: Digital thread for digital twin. Geneva: ISO, 2026.

[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 23247-6:2026 — Automation systems and integration — Digital twin framework for manufacturing — Part 6: Digital twin composition. Geneva: ISO, 2026.

[7] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Digital Twins for Advanced Manufacturing. Gaithersburg: NIST. Updated 2026.

[8] SHAO, G.; HIGHTOWER, J.; SCHINDEL, W. Credibility consideration for digital twins in manufacturing. Manufacturing Letters, 2023.

[9] UNITED KINGDOM. National Digital Twin Programme (NDTP) principles. GOV.UK, 2024.

[10] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. ABNT NBR ISO 19650-3:2025 — Information management using building information modelling — Part 3: Operational phase of assets. Rio de Janeiro: ABNT, 2025. International counterpart: ISO 19650-3:2020.

[11] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. ABNT NBR ISO 19650-5:2025 — Security-minded approach to information management. Rio de Janeiro: ABNT, 2025. International counterpart: ISO 19650-5:2020.

[12] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55000:2024 — Asset management — Vocabulary, overview and principles. Geneva: ISO, 2024.

Frequently asked questions

What is a Digital Twin?

A Digital Twin is a data-driven digital representation of a real entity, system, or process, maintained in a synchronized relationship with what it represents to support monitoring, diagnosis, simulation, forecasting, and decision-making.

Does a Digital Twin need a 3D model?

No. Geometry can help with spatial context, but a Digital Twin may be based on process models, time series, asset graphs, physical models, or other representations appropriate to the use case.

Are Digital Twin and BIM the same thing?

No. BIM organizes models and information for design, construction, and assets. A Digital Twin can use BIM or AIM as one of its layers and add synchronization with operational data, analytical models, and decision workflows.

What is the difference between a Digital Twin and a Digital Shadow?

A Digital Shadow usually describes a representation automatically updated by the asset, predominantly from physical to digital. In a Digital Twin, the representation integrates data, models, and decisions within a broader system and may include recommendations, workflows, or return interaction.

Does a Digital Twin need to operate in real time?

No. Frequency, latency, and fidelity should be proportional to the use case. Some decisions require seconds or less; others can work with minutes, hours, days, or events.

What is the relationship between Digital Twin and BIM 7D?

BIM 7D is a market convention associated with operations, maintenance, and asset management. A Digital Twin can complement this ecosystem by integrating operational data, sensors, systems, analytics, and workflows, but the concepts are not equivalent.

Which systems can be part of a Digital Twin?

Depending on the use case, BIM/AIM, IoT, BMS, SCADA, DCIM, EPMS, CMMS, EAM, historians, meters, enterprise systems, APIs, analytical models, and databases may participate.

Does a Digital Twin need to use artificial intelligence?

No. Deterministic rules, physical models, statistics, and simulation can solve many cases. AI should be used when it adds value and when its results can be validated and governed.

How can you determine whether a Digital Twin is trustworthy?

It is necessary to assess data quality and provenance, implementation verification, model validation for the intended use, uncertainty, version history, security, and performance under normal and degraded conditions.

How should a Digital Twin project begin?

Start with the operational problem and KPI. Then define the asset boundary, map data and identity, define frequency and fidelity, design integrations, establish models and trust criteria, implement a complete use case, and validate the benefit before scaling.

Additional technical materials

BIM and information management

• BIM 7D: operations, maintenance, Facility Management, and asset management
• BIM Information Management: how to apply ISO 19650
• BIM Modeling in Engineering

Data, automation, and integration

• Internet of Things (IoT)
• DCIM, BMS, and EPMS in Data Centers
• Systems Integration, APIs, and Enterprise Connectors

Operations and lifecycle

• Engineering Asset Management
• Engineering As-Built
• Engineering Commissioning

Performance and reliability

• BIM 6D: sustainability and performance
• IEC 62443 and OT cybersecurity

Guides and references

• Complete Guide to BIM and Design Coordination
• BIM Design Coordination: technical framework