Datacenter
Digital twin for facility operations field guide
What an operations digital twin actually is, why it has to be connected to live data and used for a decision, and how it is born from the commissioning handover, not a static 3D model nobody updates.
Direct answer
A digital twin for facility operations is a living digital model of a building tied to live data and used to operate and maintain it over its life. It pays off only when connected to that data, kept current, and used for a real decision. A static handover model nobody updates is a 3D picture, not a twin.
Key takeaways
- A facility operations digital twin is the model plus live data plus a use; remove any one and it is a drawing, screensaver, or pile of orphaned trends.
- A static handover model with no live feed that nobody opens is a 3D picture, not a twin.
- The twin is only as good as the as-built and the data kept current; garbage as-built equals garbage twin, and stale data that looks live is worse than no data.
- The twin is born at commissioning handover, not launched years later; write it and its data standard into the owner's requirements before the first system is modeled.
- Start with one use case (asset management or energy), prove it, then scale; COBie under ISO 19650 delivers structured handover asset data, but verify contents not just columns.
The operations twin, and why connected and used is the whole point
A digital twin for facility operations is a living digital model of a building tied to live data and used to run and maintain the place over its life. The model carries the geometry and the equipment. The live feed carries what the building is doing right now, the temperatures, the flows, the alarms, the energy. A person uses the combination to make a call: find a unit, close a work order, chase an energy drift, walk a responder through the floor. That last part is the entire reason it exists.
The word gets stuck on anything three-dimensional, and that is where most of the confusion starts. A static model handed over at the end of a job, parked on a server, never connected to anything and never opened, is a 3D picture of the building. It is not a twin. The twin is the model plus the live data plus a use. Take out the live data and you have a drawing. Take out the use and you have a screensaver with a license fee.
This is the operations twin, the one that lives after the ribbon is cut, and it is a different animal from the construction model that designed and built the place, even though it is fed by it. The BIM and VDC coordination work produces the geometry. The commissioning handover is where the twin is born or stillborn. Both siblings are worth reading next to this guide. What follows is what the twin is, what feeds it, what it is good for, and the unglamorous work of keeping it alive long enough to pay for itself.
What makes a model an actual digital twin?
A digital twin is the model plus live data plus a use. Take any one of the three away and you do not have a twin. You have something less that someone is calling a twin to sound current.
Drop the live data and the model is a static record. It is fine for finding a valve and useless for telling you the valve is stuck open right now. Drop the use and it does not matter how live the data is, because a twin nobody opens to make a decision is dead weight on a subscription. Drop the accurate model and the live data has nothing to hang on, no geometry, no equipment, no place to land.
The hard truth owners learn a year in is that the twin is worth the money only when somebody is making a real operational decision with it. Not a demo on a screen in the lobby. A decision. The facility manager finds the air handler, reads its trend, and sends the right tech with the right part. The energy lead spots the chiller running off its design curve and corrects it before the bill does. If you cannot name the decision the twin supports, you have bought a 3D picture with a recurring charge. Match the ambition to the use you can actually keep alive.
What is a digital twin for facility operations?
A digital twin for facility operations is a living digital model of the building connected to live data and used to operate and maintain it across its service life. The accepted shorthand is a virtual replica that mirrors what the physical building is doing, with a two-way relationship between the model and the real systems so the model reflects current conditions rather than a moment frozen at handover.
The distinction from the construction model is the whole game. The construction BIM exists to design and build the facility, and it is largely done when the building opens. The operations twin exists to run the facility, and it only starts working when the building opens. One is a snapshot of what the building looks like. The other is a continuously updated picture of what the building is doing.
It is worth being plain that the term is loose in the market, and vendors stretch it to cover anything from a navigable 3D scan to a full physics simulation. For an owner the useful definition is narrow and demanding: a model, fed by live data, kept current, and opened to make operational decisions. The platform and the data standards that get you there vary by vendor and by the owner's requirements, so treat the definition as the bar and the product as the means.
What are the levels of digital twin maturity?
Digital twins sit on a maturity spectrum, sorted by how live and how smart the model is. The common framing runs from a static 3D record, to a connected twin pulling live data, to a predictive twin that simulates and forecasts. The numbering and the labels shift between sources, so read the level by what it does, not by the marketing tier a vendor assigns it.
The honest read for most buildings is that they live at the connected and descriptive end, with live status and trends, and that this is where the early value is. The predictive and autonomous tiers get the headlines and the conference demos. Few facilities have the data quality and the discipline to run them well, and fewer still need to before the connected twin has paid off. Climb the spectrum when the use case and the data justify the next rung, not because a slide says you should.
Data centers are the exception that proves the rule. The predictive layer earns its place faster there, because airflow, power, and cooling are tightly coupled and a what-if simulation against the live load answers a real capacity question. Match the level to the need and the data you can keep current, and hedge the ambition to the platform and the owner's requirements.
| Level | What it is | What it does | Typical state |
|---|---|---|---|
| Static / 3D record | As-built model or scan, no live feed | Find and view geometry and equipment | A record, not yet a twin |
| Connected / descriptive | Model tied to live BAS, IoT, and asset data | Mirror current conditions, status, alarms, trends | Where most facilities operate |
| Informative / analytic | Connected twin plus analytics and dashboards | Spot patterns, anomalies, and drift; trigger work | Mature facility teams |
| Predictive / simulation | Twin plus physics or ML simulation | Forecast failures, run what-if, optimize capacity | Data centers, advanced owners |
What is the difference between BIM and a digital twin?
BIM is the construction model, built to design, coordinate, and build the project. The digital twin is the operations model, built to run and maintain the building after it opens. The BIM feeds the twin, but they have different jobs and different lifespans, and confusing them is how owners end up with a handover model they think is a twin and is not.
Think of it as a relay. The design and construction teams build the project virtually first, coordinate the trades, resolve the clashes in the model before the field finds them, and that work is covered in the BIM and VDC coordination guide. When the building opens, the construction model has done its job. The as-built version of it then becomes the geometric foundation the twin is built on, the asset information model the live data attaches to.
The lifespan is the tell. The BIM is busiest during design and construction and largely finished at handover. The twin is born at handover and works for the next twenty or thirty years, as long as somebody keeps it current. A construction model that gets dumped on a server at closeout and never connected or updated is not a twin. It is the raw material a twin could have been made from, and usually was not.
Where the two genuinely meet is data discipline. A twin built on a sloppy, untagged construction model inherits every gap. The cleaner the as-built and the better the equipment is tagged at handover, the cheaper the twin is to stand up and the longer it stays honest.
What data feeds a digital twin?
A facility twin is fed from a short list of sources, and the value comes from joining them on one model. The as-built BIM gives geometry and equipment. The building automation system and controls give live status. The IoT sensors give conditions the controls do not see. The CMMS and asset records give history, manuals, and warranty. The space and occupancy data give who is using what.
No single feed makes a twin. The model alone is a drawing. The live data alone is a pile of trends with no place to land. Joining them is the work, and it is mostly integration plumbing, mapping a sensor point or an equipment tag in the controls to the right object in the model so the temperature shows up on the actual air handler and not in a spreadsheet. That mapping is also the part that breaks when the building changes and nobody updates it.
| Source | What it provides | Why the twin needs it |
|---|---|---|
| As-built BIM / asset information model | Geometry, equipment, locations, attributes | The foundation the live data attaches to |
| BAS / building controls | Live setpoints, status, alarms, run state | Tells you what the building is doing now |
| IoT sensors | Temperature, humidity, power, vibration, occupancy | Fills gaps the controls do not cover |
| CMMS / asset data | Work history, manuals, warranty, spares | Turns a found asset into an actionable one |
| Space / occupancy | Floor use, moves, headcount, capacity | Drives space, moves, and capacity decisions |
The as-built model is the foundation
The as-built model is the accurate digital record of what was actually built, and it is the foundation the whole twin stands on. Garbage as-built equals garbage twin. There is no software trick that recovers from a model that does not match the floor, because the live data and the work orders all hang on the geometry and the equipment in that model.
Two things matter most in the as-built: the geometry is right, and the equipment is tagged. The geometry being right means the model reflects what got installed, not what was drawn before the field made its changes. Equipment being tagged means each asset you intend to operate carries an identity that ties back to the controls point, the work order, and the manual. An air handler with no tag is a box in the model that the live feed cannot find.
On a re-coordinated build the gap between the design model and the as-built is wide, because the field moved things to make them fit. If nobody captures those changes, the twin is born wrong and the operations team stops trusting it inside a month. The as-built has to come out of the close-out and commissioning process accurate, or the twin starts from a deficit it rarely climbs out of.
The live data is what makes it breathe
Live data is what separates the twin from the drawing. The model is the body. The feed from the building automation system and the IoT sensors is the pulse, the temperatures, the flows, the equipment status, the alarms, the energy draw, updating as the building runs. With it, the twin breathes with the building. Without it, the twin is a 3D picture wearing a name it did not earn.
The connection is the work, and it is rarely tidy. The BAS speaks its protocols, the sensors speak theirs, and each point has to be mapped to the right object in the model so the reading lands on the actual equipment. A useful twin also runs the relationship both ways where it is safe, reflecting changes and, in some platforms, sending commands back, though most owners start read-only and earn the write path.
The failure mode to watch is a feed that quietly dies. A controls upgrade re-points half the tags, the integration breaks, and the twin keeps showing yesterday's numbers as if they were live. Stale data that looks live is worse than no data, because somebody makes a decision on it. Monitor the feed health, not just the model, and treat a dead point as a defect, not a cosmetic gap.
What is a digital twin used for in operations?
A twin earns its keep on a handful of operational uses, and they sort by the decision they support. Asset management, finding the equipment and its history. Maintenance, putting the work orders on the model. Energy and performance, comparing live behavior to the design intent. Space management, tracking use and moves. Emergency response and training, walking the building before you have to. And what-if simulation, testing a change before you make it.
The discipline is to pick the use that pays for your building and build that first. The everything-twin that does all of these on day one is the most common way the project dies, because it is expensive, slow, and never quite finished. The platform you choose and the owner's information requirements shape which uses come easily and which fight you, so weigh the use case against the tool before you commit.
| Use | The decision it supports | Related practice |
|---|---|---|
| Asset management | Find the equipment, its history, manuals, warranty | Closeout and asset data |
| Maintenance | Dispatch the right tech, part, and access | Predictive maintenance, visual CMMS |
| Energy and performance | Correct drift from design, optimize operation | Retro-commissioning, energy |
| Space management | Plan moves, track occupancy and capacity | Workplace and capacity planning |
| Emergency and training | Walk responders and new techs through the floor | Life-safety and onboarding |
| What-if simulation | Test a change before making it | Capacity and densification (data centers) |
Asset management: where is it and what is it
The first use most owners get value from is asset management, the plain question of where is the equipment and what is it. A facility tech standing in a mechanical room asking what serves this zone, or an operator trying to find every unit on a recalled model, is the daily case the twin answers fastest. Click the air handler in the model and you get its make, its serial, its install date, its manuals, its warranty status, and its maintenance history.
This is the use that turns the close-out package from a graveyard of PDFs into something a person actually opens. The data that makes it work, the equipment list, the attributes, the documents, comes out of the handover, which is why the twin and the close-out record are the same fight. If the asset data never got captured in a structured form, the twin shows you a box you can find and nothing you can act on.
It sounds modest next to predictive simulation, and it is the use that pays back first and complains least. Find the asset, read its history, act. The rest of the twin builds on that foundation being right.
Maintenance: the work orders on the model
The maintenance use puts the work on the model. A work order is no longer a line in a spreadsheet that references a room number. It is attached to the actual unit in the twin, with its location, its access path, and its history right there. The tech sees what they are walking to before they walk to it, which cuts the second trip for the part they did not know they needed.
Tie the twin to the live data and the maintenance use sharpens. A unit trending toward failure, a bearing warming, a filter loading, a pump drawing more than its curve, can raise a flag against the model and generate the order before the failure, which is the predictive-maintenance play covered in the PdM material. The twin becomes a visual CMMS, where the condition data and the work history live on the same object you can see and locate.
The honest limit is that this only works if the asset tagging is clean and the CMMS is connected. A twin with beautiful geometry and no link to the work-order system is a viewer, not a maintenance tool. Hedge the maintenance ambition to the integration you can actually stand up and keep current.
Energy and performance: live versus design
The energy use compares what the building is doing to what it was designed to do, and flags the gap. Buildings drift. A chiller that ran at its design efficiency at commissioning is running off the curve two years later, an economizer is stuck, a schedule got overridden and never put back, a zone fights itself with simultaneous heating and cooling. The twin makes the drift visible by showing live performance against the design intent on the same model.
This is the operational version of retro-commissioning, and it pairs with the retro-commissioning and energy practice rather than replacing it. The twin does not fix the chiller. It tells you the chiller is the problem and roughly what it is costing, which is the hard part on a building with hundreds of pieces of equipment and no obvious place to look.
Data centers push this furthest, because energy is the dominant operating cost and small efficiency gains are large dollars. A twin that ties live power and cooling data to the model lets the operator see where energy is going and test a setpoint change against the real load before committing it. The payoff scales with the energy intensity of the building, so the case is strongest exactly where the loads are heaviest.
Space, emergency response, and training
Beyond the mechanical uses, the twin earns its place on space, safety, and people. Space management uses the model and the occupancy data to plan moves, track who is where, and right-size the floor, which matters most in offices and labs where churn is constant and in data centers where every rack position is capacity.
Emergency response is the use that justifies the twin to people who never open it day to day. A responder who can see the floor plan, the shutoffs, the egress, and the hazardous spaces before entering the building is safer and faster than one reading a paper plan in a stairwell. The same model trains new operators on a plant they have not learned yet, walking the systems and the failure scenarios in the model instead of on the live floor where mistakes are expensive.
These uses lean on the geometry being right more than on the live feed, which is part of why they are reachable early. A static but accurate model already does a lot for emergency planning and training. Add the live data and the responder also sees what is alarming right now.
The twin starts at the commissioning handover
A useful twin starts at commissioning and handover, not as a project somebody launches three years into operations after the as-built has already rotted. The cheapest, cleanest twin is the one built into the job from the start, where the as-built model, the structured equipment data, and the O&M information are handed to the owner as a working twin instead of a pile of PDFs and a hard drive of drawings.
This ties the twin directly to the commissioning levels and process, the sibling guide worth reading alongside this one. Commissioning is where the equipment gets verified, tagged, and documented, which is exactly the data the twin needs. If the commissioning agent is capturing equipment data into a structured format as each system is proven, the twin is most of the way built by the time the building opens. If that data lives only in test scripts and PDFs, somebody pays later to dig it back out.
The move that makes this happen is writing the twin into the owner's requirements at the front of the project, so the deliverable is a usable twin and the data standard is specified, not assumed. An owner who asks for a twin at closeout, with no requirement set during the job, gets a model and a shrug. The requirement has to land before the trades model the first pipe.
COBie and structured handover data
COBie is the common way the structured handover data gets delivered, a non-proprietary standard for handing over the equipment, the assets, their attributes, warranties, and spare parts in a defined format instead of loose documents. It is the data layer of the handover, not the geometry. The model carries the shapes. COBie carries the facts a computer can read and load into the twin and the CMMS.
The reason it matters for the twin is simple. A twin needs its equipment tagged and described in a form software can ingest, and a stack of PDF cut sheets is not that. COBie, or whatever structured equivalent the owner specifies, is how the asset data arrives ready to use. Under the ISO 19650 information-management framework, the operations side of this is the asset information model, the verified data set the twin is built on.
Be realistic about the standard. COBie is widely referenced and unevenly delivered, and a COBie file full of blank fields is its own kind of garbage data. The format is only as good as the discipline filling it in during the job. Specify the data standard, then verify the data, because the standard names the columns and does not guarantee the contents.
Is a digital twin only as good as its data?
Yes, and it is the single fact that decides whether a twin program lives or dies. The twin is only as good as the data behind it, the accurate as-built, the equipment tagged and described, and the live feed that stays connected. Garbage data makes a useless twin, no matter how good the platform looks in the demo.
The trap is that a twin with bad data still looks impressive. The geometry renders, the dashboard fills, the colors move. Underneath, the air handler in the model is the wrong unit, half the sensor points are mapped to the wrong objects, and the asset records are blank. An operator who acts on it once and gets burned stops trusting it, and a twin nobody trusts is abandoned faster than one that is plainly incomplete.
So the work is data hygiene, and it is unglamorous and continuous. Verify the as-built against the floor. Confirm the tags map to real points. Fill the asset attributes, not just the columns. Watch the live feeds for the ones that quietly died. This is the part vendors gloss over and owners underfund, and it is the part that determines whether the twin is worth its license. Spend on the data before you spend on the visualization.
The twin needs maintenance or it goes stale
A twin is not a deliverable you finish. It is a system you maintain, and a twin that is not maintained goes stale and starts to lie. The building changes, a chiller gets replaced, a riser gets re-piped, a floor gets re-fit, and if the model and the data are not updated to match, the twin diverges from reality a little more with every change order.
A stale twin is worse than no twin, for the same reason stale live data is worse than none. People make decisions on it. The tech walks to the unit the model shows and finds a different one. The energy lead chases a setpoint on equipment that was swapped out last spring. Each time the twin is wrong, the team trusts it less, until they stop opening it and the program quietly dies while the license keeps renewing.
Keeping it alive means folding the twin into the change process. When a renovation happens, updating the model and the data is part of the job, not an afterthought somebody might get to. That requires an owner, a budget, and a workflow, which is why the next two sections, the platform and the people, decide whether the twin survives its first year.
The platform: integration, viewer, and openness
The platform is the software that holds the twin together, integrates the data sources, and gives a person a way to see and use the model. The market is crowded and the products differ in what they do well, some strong on the 3D viewer, some on the analytics, some on the integration layer that connects the BAS and the CMMS. There is no single right answer, and the fit depends on your uses and your existing systems.
The question that bites later is open versus proprietary. A twin locked inside one vendor's closed format is a twin you cannot move, and the data you spent years curating becomes a hostage when the contract comes up or the product gets discontinued. Favor platforms with real APIs and open or exportable data, so the model and the asset data remain yours. The viewer is replaceable. The data is not.
Weigh the platform against the data standards and the owner's requirements rather than the demo. A slick interface over a closed silo is a worse bet than a plainer tool that ingests open data and lets you get it back out. Pick the tech for the integration and the openness first, the visuals second.
The people: a twin nobody opens is dead
A twin is only as alive as the people who use it. The most accurate, best-connected twin in the world is dead the day the operations team stops opening it, and that day comes fast if nobody owns it and nobody is trained on it. The technology is the easy part. Adoption is where these programs actually fail.
Somebody has to own the twin, the way somebody owns the BAS or the CMMS. That owner keeps the data current, fixes the broken feeds, trains the new techs, and answers for whether the thing is trusted. Without that role the twin drifts, because no shared tool survives without a person responsible for it. The facility manager and the operations team have to find it faster and easier than their old way, or they go back to the old way the first busy week.
This is the quiet reason expensive twins sit unused. The project bought a platform and a model and never funded the person or the habit. Budget for the people and the workflow as seriously as the software, because a twin nobody opens is a line item, not an asset.
Start with one use case
Start with one use case, prove the value, then scale. The asset-management twin or the energy twin returns value early and is achievable with data you can actually assemble. The everything-twin that does asset, maintenance, energy, space, emergency, and prediction on day one is the most reliable way to spend a large budget and have nothing working at the end.
Picking the first use case is a real decision, not a default. Choose the one that answers a question your building asks often and answers badly today. For a maintenance-heavy plant that is finding equipment and its history. For an energy-intensive site, including most data centers, it is performance against design. Build that one well, get the operations team using it, and let the win fund the next layer.
Do not over-build. A focused twin that does one thing the team relies on every week beats a sprawling twin that does ten things nobody trusts. Scope to the use and the data you can keep current, and add capability when a real need and real data push you up the maturity spectrum, not because the platform supports it.
Is a digital twin worth it?
A digital twin is worth it when it is connected, kept current, and used for a real decision, and not worth it as a static model nobody opens. The return shows up as faster O&M, lower energy, fewer truck rolls, smarter capital planning, and safer emergency response, and the published figures land in meaningful ranges, double-digit cuts in downtime and energy where a connected twin is genuinely used. Treat any single vendor number as directional, not a guarantee for your building.
Where it pays cleanest is the high-value, high-cost decision. A truck roll avoided because the tech saw the problem on the model and arrived with the part. An energy drift caught before it ran for a season. In a data center, stranded capacity recovered because the twin showed real headroom and let the team densify with confidence instead of leaving racks empty out of caution. Those are concrete dollars, and they are the cases to build the business case on.
The hype runs ahead of the average result, so anchor the ROI to the use case you will actually run, not the brochure. A connected asset and maintenance twin that the team opens daily beats a predictive twin that impresses in a demo and sits idle. The value is the operational decision, and the cost is the data and the people to keep it honest. Size the investment to the decision.
The honest framing on the hype
Digital twins are over-hyped, and saying so out loud saves owners money. The conference version is a glowing predictive model that simulates everything and runs the building on its own. The version most owners need is a connected twin that finds the asset, shows its condition, and supports maintenance and energy decisions. The gap between those two is where budgets go to die.
Match the ambition to the use and the data you can keep current. Most facilities do not need the predictive simulation layer to get most of the value, and they cannot feed it well anyway. The connected asset and maintenance twin pays back long before the AI forecasting does, and it builds the data discipline that the predictive layer would require if you ever add it.
None of this means the twin is hollow. It means the value is specific and the marketing is broad. A twin tied to live data and used for a real decision is a genuine operational tool. A 3D model with a twin label and no live feed is a sales prop. Know which one you are buying, and hold the vendor to the demanding definition, not the loose one.
What to record for the twin
The twin runs on records, and the records are what keep it honest as the building changes. Capture the as-built source and its accuracy, the data sources connected and their state, the use case the twin is built for, the data standard the handover followed, and the maintenance plan that keeps it current. A field tool such as FieldOS is where the equipment data, the conditions, and the work history get captured in the field and tied back to the asset, which is the same data the twin lives on.
The point of writing it down is the handoff and the audit a year later, when someone asks whether the twin still matches the floor and who is responsible for it. When a twin carries no record of what feeds it, what standard it followed, and who maintains it, it has no answer the day it drifts from the floor.
| Item | Requirement | Note |
|---|---|---|
| As-built model | Accurate to what was installed, equipment tagged | Verify against the floor at handover |
| Data sources | BAS, IoT, CMMS, space feeds mapped to objects | Record point mapping and feed health |
| Use case | The decision the twin is built to support | One to start, named, not the everything-twin |
| Data standard | COBie or owner-specified structured format | Verify contents, not just the columns |
| Maintenance plan | Who updates the model and data, and when | Tie to the change-management process |
| Owner / users | Named owner and trained operations team | A twin nobody opens is dead |
Common mistakes
- Calling a static handover model a digital twin when it has no live data and nobody opens it.
- Never connecting the model to the BAS, IoT, or CMMS, so it stays a 3D picture.
- Building on a garbage as-built or untagged equipment, so the live data has nothing reliable to attach to.
- No plan or budget to keep the twin current as the building changes, so it goes stale and starts to lie.
- No clear use case, so the twin does a little of everything and nothing the team relies on.
- Over-building an everything-twin instead of proving one valuable use case first.
- Buying a closed, proprietary platform that holds the data hostage with no real export path.
- Funding the software but not the person who owns and maintains the twin.
Field checklist
Want this checklist to run itself on every job — with photo proof and a signed record crews can hand the customer? That's FieldOS.
Standards and references
The framework for a facility twin draws on a few reference points, and the platform and the owner's requirements sit on top of them. For the information management and the handover, ISO 19650 covers the project and asset information models, with ISO 19650-3 addressing the operational phase. COBie, published through the National Institute of Building Sciences, is the common structured format for delivering the equipment and asset data at handover. The owner's information requirements are the document that turns these standards into a specific deliverable for your project.
For data centers specifically, the operational context overlaps with the Uptime Institute Tier framework, ASHRAE TC 9.9 thermal guidelines, and DCIM practice, and the predictive twin often leans on CFD for airflow and thermal what-if work. Cite the standard that governs the point, and remember that the standards name the structure while the platform and the data discipline determine whether the twin actually works.
Three things hold across every reference. A twin is the model plus live data plus a use, not a static picture. It is only as good as the as-built and the data kept current. And it should start with one use case, built from the commissioning handover, with the data standard, the platform, and the use hedged to the owner's requirements rather than assumed from the last job.
Terms and definitions
The vocabulary around twins is loose and contested, which is part of why owners get sold a 3D model as a twin. These are the working definitions used in this guide, stated plainly so a passage stands on its own.
The distinctions that matter most are twin versus BIM, and connected versus static versus predictive, because those are the two places the term gets stretched to cover things it should not.
- Digital twin
- A living digital model of a building tied to live data and used to operate and maintain it over its life
- BIM
- Building information modeling, the construction model used to design, coordinate, and build the project, which feeds the twin
- Static twin
- A 3D model or scan with no live data, a record rather than a true twin
- Connected twin
- A model tied to live BAS, IoT, and asset data that mirrors current conditions
- Predictive twin
- A connected twin plus simulation that forecasts behavior and runs what-if scenarios
- As-built model
- The accurate digital record of what was actually built, the foundation the twin stands on
- COBie / structured data
- A non-proprietary format for delivering equipment and asset data at handover in a form software can read
- Live data feed
- The real-time stream from the BAS and sensors, status, alarms, conditions, and energy
- Data hygiene
- The ongoing work of keeping the model and data accurate, mapped, and current
- Use case
- The specific operational decision the twin is built to support
- Facility operations
- Running and maintaining the building over its service life, the job the twin serves
FAQ
What is a digital twin for a building?
A digital twin for a building is a living digital model tied to live data and used to operate and maintain the facility over its life. It combines the as-built geometry, the equipment data, and a live feed from the building systems, and a person uses that combination to make a real operational decision.
What is the difference between BIM and a digital twin?
BIM is the construction model that designs, coordinates, and builds the project, then hands over an as-built record. A digital twin is the operations model that lives afterward, tied to live data and used to run the building. The BIM feeds the twin, but their purpose and their lifespan differ.
What data does a digital twin need?
A facility twin needs the as-built model for geometry, the building automation and controls for live status, IoT sensors for conditions the controls miss, the CMMS and asset records for equipment history, and the space and occupancy data. The twin is only as good as the accuracy of those feeds.
Is a digital twin worth it?
A digital twin pays off when it is connected to live data, kept current, and used for a real decision, usually faster O&M, lower energy, fewer truck rolls, and better capital planning. It is not worth it as a static model nobody opens. Start with one use case and prove it first.
When does a digital twin start?
A useful twin starts at commissioning and handover, not as an afterthought years later. The as-built model, the structured equipment data, and the O&M information are handed to the owner as a working twin, not a pile of PDFs. Build the requirement into the project so the data arrives tagged and usable.
Why does a digital twin go stale?
A twin goes stale when nobody keeps the model and data current as the building changes. A renovation, a new chiller, a re-piped riser, and the model no longer matches the floor. A stale twin lies, and a twin that lies gets abandoned. Budget for the upkeep, or do not start.
What is COBie?
COBie is a non-proprietary standard for delivering structured asset data at handover, the equipment, the assets, their attributes, warranties, and spares in a defined format instead of loose PDFs. It feeds the twin and the CMMS with data a computer can read. It is the data layer, not the geometry.
What is a data center digital twin used for?
A data center twin models airflow, power, and cooling, often with CFD, tied to live DCIM and sensor data. Teams use it to find deployable rack capacity, quantify headroom, and test densification before hardware ships. It reduces stranded capacity and lets operators run what-if scenarios against the real load.
How accurate does the as-built model need to be?
Accurate enough that the equipment in the model matches the equipment on the floor, tagged and located. Garbage as-built data makes a garbage twin, because the live feed has nothing reliable to attach to. The model does not need every screw, but it needs the assets you will operate, found where they actually sit.
Do I need a predictive digital twin?
Most owners do not, at least not first. The connected asset and maintenance twin returns value long before the predictive simulation layer does. Match the ambition to the use you can support and the data you can keep current. Build the connected twin, prove it on one use case, then add prediction if the data earns it.
People also ask
Codes cited in this guide
This guide is written and reviewed against the published standards below. Always confirm the current adopted edition with the authority having jurisdiction.