A digital twin is a living digital copy of a physical building, fed by its sensors and records, that lets an operator see, question and manage the real asset through the model. For construction the promise is continuity: the information created while building becomes the instrument for operating, but only if it was structured to survive the handover. That structuring is a governance problem, and it is decided years before the twin exists.
The problem
The operational case for digital twins is strong and increasingly well evidenced: condition monitoring, energy performance, space utilisation, predictive maintenance, and lifecycle capital planning all improve when the asset has a reliable digital representation that stays current. The technology to build one is mature and commercially available.
What remains unresolved is continuity. The model that supports construction is not structured for operations; the parties who hold the information demobilise at handover; and the operator, who bears the cost of every gap for the life of the asset, is usually not under contract when the decisions that determine data structure are made. That sequencing problem belongs to procurement, and naming it as such is often the most useful contribution an information manager makes.
What governs this area
- COBie 2.4Handover data structure for operations and maintenance.
- ISO 19650-3:2020Information management during the operational phase.
- Autodesk TandemCommercial digital twin platform for facility operations.
- IoT & sensor networksLive condition, occupancy and consumption telemetry.
- CMMS integrationThe system that actually consumes handover data.
- GHG Protocol Scope 2Purchased-energy emissions accounting for built assets.
The decisions it comes down to
- What operational questions must the twin answer? Everything else is decoration.
- Which asset attributes are required at handover, and who verifies them?
- How does the twin stay current after the first year?
- Who owns the twin, its data, and the obligation to maintain it?
- What integrates with the maintenance management system, and by what interface?
- What is the cost of the twin against the cost of the information failure it prevents?
The work behind this area
A Digital Twin for an Airport Parking Deck
A parking deck is an unglamorous building with an awkward energy problem: it is lit and ventilated around the clock for a population that arrives in waves, and it is quietly becoming one of the largest concentrations of electric-vehicle charging load an airport owns. This is what it took to make one of them legible to the people who operate it: the model, the data architecture on top of it, and the interface the operator actually sees.
1. Why this asset is a hard case
Hartsfield-Jackson is the world’s busiest passenger airport and an FAA-regulated transportation asset. Its parking structures run continuously, they cannot be closed for retrofit, and their occupancy is not random: it follows flight banks. That last property is what makes the building interesting. Demand is not noise to be smoothed. It is a schedule that is already known hours in advance.
Three things follow. Lighting and ventilation run at full output on floors that are empty for most of the day. Elevators and escalators run to fixed schedules rather than to demand. And electric-vehicle chargers, which are the fastest-growing load in the building, can be pulled into the same hour by a single arrival bank, producing a peak the local grid connection has to absorb whether or not anything is done to anticipate it.
The airport’s own targets set the frame for the work: one hundred percent clean energy by 2035 and net zero by 2050, as presented by the airport’s sustainability leadership. Those commitments are the reason the exercise had a client question at all, and they determine which questions are worth answering.
2. The three questions the twin was built to answer
A digital twin that is not built to answer a specific question becomes an expensive three-dimensional viewer. Three were defined before any modelling began, each tied to a named operator rather than to a capability:
- Charging load, forecast against the ceilingPredict the demand a flight bank will create and shift it before it arrives, rather than metering it afterwards. Operator: the facility manager.
- Energy driven by actual occupancyDim, throttle and idle by zone according to what is measurably in the building. Operator: the facility manager.
- Scope 2 emissions, reported without a spreadsheetConvert metered consumption into disclosed emissions on a repeatable basis. Operator: the airport sustainability team.
3. What had to be modelled, and why each element earned its place
I modelled hands-on within the team, from architectural drawings and site video (levels and grid first, then structure, envelope, circulation and vertical transport), and reviewed the coordinated model floor by floor, with a site visit to confirm scale and geometry against what was actually constructed. The video was not reliable for dimensions, so the drawings governed and the video served only to resolve what the drawings left ambiguous.
Nothing was modelled for appearance. Each stall is a discrete object rather than paint on concrete, so that occupancy can be aggregated into control zones. Lighting fixtures carry type, wattage and circuit, because per-zone energy is wattage multiplied by runtime multiplied by occupancy and there is no way to compute that from geometry alone. Gates carry vehicle counts, which turn out to be the most reliable real-time occupancy signal in the building. Elevators and escalators carry equipment metadata so their runtime energy can be quantified before anyone proposes changing their schedule.
That last detail is the one worth pausing on. The sensors exist in the model because the operational question demanded them, and the operational question was asked after the building was designed and built. This is the ordinary sequence, and it is the reason construction-to-operations continuity fails so often: the party who will pay for every gap is not in the room when the information structure is decided. It is the whole reason this practice area exists.
4. From model to twin
The coordinated model was imported into a commercial digital twin platform, where elements become tagged assets with persistent identifiers, documents attach to the equipment they describe, live streams attach to assets, and thresholds convert a reading into a state.
Thresholds deserve a note. Configuring one means naming a parameter, setting the values at which it becomes a warning and then an alert, and specifying how long the condition must be sustained before the system says so. That is not a preference. It is a written decision about when a measurement creates an obligation to act, and about who is answerable when it does.
5. The interface, and the part that could not be bought
The twin platform and the load-forecasting engine were not designed to communicate. Closing that gap meant building a separate analytical interface on top of both. I built it, and that is where the project stopped being an exercise in software selection and became one in deciding what an operator should be shown, and what they should be asked to decide.
6. What the twin is not permitted to do
The most useful section of this work is the shortest. Fire alarm devices, pull stations, strobes and horns were modelled at code-required intervals, and they share infrastructure with the lighting and sensing circuits the twin is designed to control. They were modelled precisely so that the optimisation layer could never propose a change that conflicts with life-safety code.
Emergency lighting stays on regardless of occupancy. Fire detection and alarm operate independently of the twin and are never overridden by it. Minimum ventilation thresholds hold even when occupancy is near zero. And if the twin goes offline, the deck reverts to full operation on every system: the optimisation is suspended, no function is lost. The twin is an optimisation layer, not a control system, and the difference is written down.
Every one of those sentences is a governance artifact rather than a technical one. They are constraints on what an automated system is allowed to conclude, and they belong in a contract as much as in a configuration file.
7. What it would be worth
Stated as mechanisms rather than as a number, because the number depends on a building’s actual load profile: consumption avoided by dimming and idling low-occupancy zones; demand charges avoided by moving charging out of the peak window; mechanical wear avoided on lighting and ventilation that no longer runs when nobody is present. Alongside those, an effect that is easy to underrate: the energy data pipeline becomes automatic, replacing manual collection, and sustainability reporting moves from weeks of compilation to a standing view, which removes a class of human error from a disclosure that is increasingly audited.
And the sensing and metering layer, once installed, is reusable. Air-quality monitoring or predictive maintenance on the same building does not start from zero. The first twin on a site is expensive because it pays for the data layer; the second is not.
8. The published evidence base
The airport deck is one building. The reason to govern asset information with this much care is what the published record shows becomes possible once a building’s information is structured, current and connected, a record now more than a decade deep across the operational literature.
Maintenance stops being archaeology. Researchers have shown model-based visual analytics tracing equipment failures to their root causes (Motamedi, Hammad & Asen, Automation in Construction, 2014), field technicians pulling asset histories by scanning a barcode on the equipment itself (Lin, Su & Chen, 2014), and facility data systems integrated across their life cycle for maintenance decision support (Shen, Hao & Xue, Automation in Construction, 2012).
The building can guide the people inside it. Augmented reality has been used to support equipment operations and maintenance in the field (Lee & Akin, Automation in Construction, 2011) and for indoor navigation to the asset that needs attention (Koch, Neges, König & Abramovici, Automation in Construction, 2014), with route planning computed directly from the open model format (Lin, Liu, Gao, Han, Lai & Gu, Advanced Engineering Informatics, 2013).
Energy management gets a spatial brain. Model-based monitoring has been applied to thermal comfort in operating subway stations (Marzouk & Abdelaty, Energy and Buildings, 2014), to campus-scale facility energy management (Cao, Song & Wang, Procedia Engineering, 2015), and to district and city-scale building energy operation (Jung, Lee & Park, 2014).
Safety and security inherit the model. Algorithms combining building information with a building’s existing sensing infrastructure have been demonstrated for locating occupants and first responders during emergencies (Li, Becerik-Gerber & Soibelman, 2015); model-driven virtual environments have been built for fire evacuation (Wang, Li, Rezgui, Bradley & Ong, 2014) and for training hospital staff before relocation into a new facility (Merschbrock, Lassen & Tollnes, Facilities, 2016); and the model has served security directly, for analysing a building’s vulnerabilities (Porter, Tan, Tan & West, Automation in Construction, 2014) and for spatial access control (Skandhakumar, Salim, Reid, Drogemuller & Dawson, Automation in Construction, 2016).
None of it runs on goodwill. Every application above consumes structured asset data, and when researchers tested the open standards themselves (IFC and COBie) against what facility managers actually need for asset registers and service life planning, the standards and tools “exhibited some shortcomings in delivering some of the data entities, types and parameters required” (Patacas, Dawood, Vukovic & Kassem, 2015, open access). Which returns the argument to where this chapter started: the operator’s requirements must be specified while there is still a design team under contract to meet them, and verified at handover. The format alone does not save you.
9. What this does not claim
This was a team project, and it is presented as such. The project had no access to live sensor feeds or historical energy records from the building: the data behind every figure shown here is simulated for the prototype and labelled as such on the face of each view, and none of it has been validated against the deck’s actual performance. The savings described are mechanisms, not measured results. Full deployment would require phased sensor installation in a facility that never closes, alignment between information technology, facilities and sustainability functions, a cybersecurity review of connecting building systems to a cloud platform, and physical grid capacity that no amount of software optimisation can substitute for.
Digital twin framework for the West Parking Deck at Hartsfield-Jackson Atlanta International Airport, April 2026, carried out with a project team. Modelling in Autodesk Revit; twin assembled in Autodesk Tandem; the facility-manager interface built separately on top of both.
Related reading: Digital Twins & Asset Operations · Information Governance for Collaborative Delivery.
Basis
A digital twin framework for the West Parking Deck at Hartsfield-Jackson Atlanta International Airport, the world's busiest passenger airport and an FAA-regulated critical transportation asset, assembled on the Autodesk Tandem platform. The work ran from the building information model itself through the sensor and asset data architecture, the BIM-to-operations data flow and the condition-monitoring logic, up to the facility-manager interface built on top of the twin. Team project work, and the origin of the position this area takes.