Digital Twin
Bản sao số (Digital Twin)
A digital model continuously updated with real-time IoT sensor data, reflecting the current state of the building and supporting predictive, optimized operations.
Common tools
Bentley iTwin, Autodesk Tandem, Azure Digital Twins
Value delivered
Early stage in Vietnam — early adoption in transport infrastructure and large smart city developments
Adoption in Vietnam
Ministry of Construction studying national Digital Twin framework in the Smart City roadmap 2025–2030.
Level of Information Need (LOIN)
G = Geometry · A = Alphanumeric · D = Documentation (ISO 7817-1:2024 method). A blank cell means this use sets no specific requirement for that discipline/stage.
| Discipline | Concept | Schematic | Developed | Technical | As-built / Operation |
|---|---|---|---|---|---|
| Architecture | — | — | — | — | G3·A3·D3 |
| Structure | — | — | — | — | G3·A3·D2 |
| Mechanical | — | — | — | — | G4·A3·D3 |
| Electrical | — | — | — | — | G4·A3·D3 |
| Plumbing | — | — | — | — | G4·A3·D3 |
Critical stages: As-built / Operation
Rationale: Requires A3 + D3 at ST5 for IoT sensor binding to asset GUIDs and live data feed connectivity. ARCH/STRU spatial geometry at G3 is sufficient for digital-twin visualisation; critical MEP / life-safety systems need G4 for sensor-to-component mapping. STRU has D2 (structural documentation) rather than D3 as it is generally less IoT-instrumented. Second ST5 ceiling-setter alongside record_modelling.
What it really is
A genuine digital twin is a digital model kept continuously, near-real-time synchronised with a building's actual operating data — IoT sensors, BMS/BAS systems, energy meters — and capable of two-way feedback: it does not just display status, it uses the resulting analysis to adjust operations or update the model itself. That is the core difference from a static BIM model or a 3D model with a dashboard bolted on: a static model is a snapshot at one point in time, while a digital twin is a data stream that never stops. Much of what the market calls a "digital twin" is in fact just an as-built BIM model with a few static-number widgets added — no live sensor connection, no feedback loop, and it goes stale the moment handover ends because nobody keeps updating it. A real digital twin needs three things at once: near-real-time operational data connection, a two-way feedback mechanism linking data to operating decisions, and an organisation committed to running it continuously through the asset's operational life, not launching it once and walking away.
When to use
Only worth the investment when a clean as-built AIM already exists, the operational systems (BMS/BAS, IoT, CMMS) are genuinely connectable, and one or a few concrete operating questions need answering — energy optimisation, predictive maintenance — for large, operationally complex assets: airports, hospitals, mixed-use districts, data centres, large commercial real estate. Missing any one of those three conditions — a clean model, connectable systems, someone who actually uses the data to decide — turns a digital twin into a cost that is never recovered; stopping at record_modelling and asset_management_fm is enough for most projects.
Prerequisites
- •As-built AIM completed and quality-accepted — a digital twin built on bad data only amplifies the error, it cannot fix it
- •Existing operational systems (BMS/BAS, IoT, CMMS) with an API or open protocol that is genuinely connectable — not a closed system with no external data log
- •A concrete use case and operating KPI agreed before investing in the platform — not building a digital twin simply because it is new technology
- •The operating organisation commits budget and staff to run the platform continuously after launch, not just the initial deployment budget
- •The operating contract states data ownership, access rights and information-security responsibility (Art. 8(6))
Inputs
Lead appointed party → operating unit · IFC / .rvt / COBie .xlsx
Operating unit · BMS system provider · API / BACnet / MQTT stream
Appointing party · operating unit · .pdf / .docx
Appointing party · IT lead · .pdf
MEP contractor · .pdf / .dwg
Operating unit · .xlsx / CMMS export
Outputs
Operating digital twin platform (model linked to live data)
nền tảng số + xuất IFC định kỳ → Operating unit
Accepted when: Sensor data synced to the correct objects, latency within the agreed threshold, and still updating after handover — not only correct at acceptance
Operational alerts and predictions
dashboard / API cảnh báo → Operating unit
Accepted when: Alerts fire at the agreed thresholds, with a false-alarm rate that is tracked and falls over time
Periodic operating-performance report
.pdf / dashboard → Appointing party
Accepted when: Tied to the KPIs agreed at the use-case stage, not presentation figures
Operating or maintenance scenario updated through the feedback loop
.xlsx / cập nhật trong CMMS → Operating unit
Accepted when: Traceable to the specific data insight that triggered the change
General workflow
Prepare the AIM to be connection-ready
Review the as-built AIM and assign an Asset ID to every object matching the real device codes in the BMS/CMMS before connecting live data. One object with the wrong Asset ID misattributes the entire data stream.
BIM/FM Manager · Revit · Autodesk Tandem (Asset ID reconciliation) → AIM with Asset IDs matching the operating systems
Define the use case and operating KPIs
Agree the concrete operating questions to answer — energy optimisation, predictive maintenance, space management — and measurable KPIs for each, before investing in data connections. Without a clear use case, the incoming data stream is just something to look at.
Appointing party · operating unit · Operating-requirements workshop, no dedicated software → Agreed list of use cases and operating KPIs
Set up the IoT/BMS data connection
Connect the API or protocol (BACnet, MQTT, OPC UA) from the BMS, IoT sensors and energy meters into the digital twin platform; verify the sync frequency and latency meet the agreed threshold.
Systems integrator · IT/OT · Autodesk Tandem · Azure Digital Twins (a non-Autodesk IoT connection platform) → Live sensor data stream feeding the platform
Sync the model with real-time operational data
Map sensor data to the correct model objects by Asset ID, validate data quality — plausible values, no prolonged connection loss — before it reaches the operating dashboard.
BIM/FM Manager · Autodesk Tandem → A model continuously updated to the asset's actual state
Build analytics, alerts and predictions
Set alert thresholds and predictive-maintenance or energy-optimisation models based on historical and real-time data, tied directly to the KPIs agreed at the use-case stage.
Operating unit · data analytics team · Autodesk Tandem (rules & alerts) · a non-Autodesk analytics platform for deeper machine-learning models → Operational alerts and predictions
Close the feedback loop back to the AIM and operating practice
Analytics insight must feed back into a changed maintenance scenario, operating parameters, or the AIM itself — a replaced component, a new setpoint. This is what separates a real digital twin from a one-way display dashboard.
Operating unit · Autodesk Tandem · the existing CMMS/BMS → Operating or maintenance scenario updated from real data
Maintain continuous data governance and security
Maintain access control, IT/OT network segmentation, data backup, and periodic review of the platform operating contract — a digital twin only retains value while it keeps being run and maintained past launch day.
Appointing party · operating unit · information-security lead · Forma Data Management (CDE) storing the source data → A stable, governed operating digital twin platform
Diagram
- 1. Physical asset + IoT sensors — BMS/BAS, energy meters, environmental sensors
- 2. Data ingestion & sync — API/BACnet/MQTT feeding the platform near real time
- 3. Continuously updated digital model — Data mapped to the correct Asset ID in the AIM
- 4. Analytics & prediction — Anomaly alerts, maintenance prediction, energy optimisation
- 5. Operating decision & adjustment — Insight feeds back to change operations or the AIM itself
If this loop stops — nobody keeps the sensors current, nobody reads the alerts — the digital twin degrades back into nothing more than a static BIM model with a few useless widgets.
Common pitfalls
The project calls itself a "digital twin" but is really just a 3D model with a static dashboard bolted on, nothing self-updating
Cause: No real-time sensor connection; data was loaded once at launch purely for demonstration
Fix: Write the criteria for a genuine digital twin into the contract — live sensor connection, sync frequency, feedback loop — and accept against those criteria, not the demo visuals
The platform stops updating within a few months of operation and reverts to a static model
Cause: Nobody owns continuous data operations, or the maintenance budget was cut after the launch phase
Fix: Name the long-term operating unit and its maintenance budget in the operating contract, separate from the initial deployment budget
Sensor data streams in continuously but nobody uses it to change any operating decision
Cause: The digital twin was built before a specific use case and operating question was defined
Fix: Agree the use case and operating KPI to answer before investing in the platform — not investing simply because it is new technology
Sensor data attaches to the wrong location or the wrong model object
Cause: The base AIM was not properly as-built; Asset IDs did not match real device codes before the digital twin was built
Fix: Only start the digital twin after the as-built AIM has passed quality acceptance and full Asset ID reconciliation
Disputes over ownership and access to operating data between the appointing party, an outsourced operator and the platform vendor
Cause: The contract did not state data ownership, access rights or IT/OT network segmentation for the two-way data flow
Fix: State in the operating contract who owns the sensor data, who may access it, IT/OT network segmentation, and compliance with information-security law (Art. 8(6))
Measuring effectiveness
Measure the % of time sensor data syncs within the agreed latency threshold
Benchmark: no independent benchmark — set an internal target
Compare energy cost or consumption before and after digital twin operation on the same building
Benchmark: Case studies compiled in a systematic review report highly variable improvements — roughly 15–38% energy cost reduction in some buildings, only about 1% in others, and one case where chiller coefficient of performance (COP) rose about 40% with optimisation active. Read this as a range shaped by use case and implementation quality, not a single figure transferable to any building
Count the times feedback-loop data actually led to a changed operating scenario, traceable to a specific insight
Benchmark: no independent benchmark — set an internal target
Count alerts with a recorded response action against total alerts raised
Benchmark: no independent benchmark — set an internal target
Legal basis
There is NO specific requirement for a digital twin (real-time operational digital twin) in Decree 217/2026/NĐ-CP — the decree governs producing and exchanging the BIM model, not connecting that model to real-time sensor/IoT operational data. Specifically: Art. 8(1)(a) makes BIM mandatory for new-build works Grade II and above — the model foundation a genuine digital twin must sit on, but the law stops at the model and does not mandate a digital twin. Art. 8(5)(đ) requires the appointing party to update the as-built model and hand over all BIM data to the operating unit after completion — the basis for the AIM a digital twin is built on, but the statutory duty stops at HANDING OVER the data, not building and running a digital twin from it. Art. 8(6) assigns management, exploitation and storage of BIM data and the CDE to information-security, data-protection and intellectual-property law — directly applicable to the two-way data flow with a digital twin's operating systems, where cybersecurity risk and operating-data ownership disputes run far higher than for a static model. At the urban-policy level, the Ministry of Construction is only at the research and discussion stage on a national Digital Twin framework within the 2025–2030 Smart City roadmap — this IS policy research, NOT an issued regulation. The practical consequence: wanting a digital twin means writing it explicitly into the EIR/BEP and the operating contract — the law does not mandate it automatically.
Sources
Only official sources (legislation, standards) and peer-reviewed academic work are cited. No vendor marketing figures or press sources. Reference only — does not replace legal advice.