Devised within the scope of the SPHERE EU Project, the proposed
definitions aim to offer a standard framework for future development of
Building Digital Twins, providing an environment for Smart, Connected
Asset Systems (SCAS) throughout their entire life cycle.

For an in-depth discussion of these definitions, see our publications.

A Building Digital Twin describing the AECOO asset during its design and construction. It contains the informational sets necessary to describe and produce a physical version that duplicates or twins the virtual version. These informational sets include, but are not limited to:

  • Employer Requirements included inside the contracts, previous legal and geotechnical information of the land,
  • An Information Model in the form of an Object Type DB which will include 3D Geometrical Information as well as Materials and Elements Inventory,
  • Bill of Processes as a comprehensive log of past processes and actors based on Minutes and Confirmed communications.
  • Bill of Services as the current evolution on the functional characteristics of the asset, starting back from initial Employer Requirements.
  • Bill of Disposal (e.g. Material Passports, Selected Deconstruction Techniques, Circular Construction…).

DTP evolution are crucial for both via iterative improvements through Model Simulations as well as for the usage of final simulated values as baselines of DTIs after the commissioning of a real building asset.

A Building Digital Twin that is linked to throughout the life of a specific corresponding physical product, including pairing when the asset starts its operation. In the AECOO sector, this milestone corresponds to the legally binding As Built Documentation. This type of Digital Twin may contain, but again is not limited to, the following information sets:

  • A fully Information Model which will include the 3D model with General Dimensioning and Tolerances (GD&T) that describes the geometry of the physical instance an its components,
  • Bill of Materials that lists current and previous elements and components (mostly relative to architecture, structural and building services)
  • Bill of Process that lists the operations that were performed in creating this physical instance (Based on the logs and project variations generated after the Rehearing act), along with the results of any measurements and tests on the instance (e.g. Cloud Points Surveys of inner services, Structural load tests, GeoRadars…)
  • A Service Record that describes past services performed and components replaced (Major/Minor
  • Retrofitting and regular Upkeeping) Operational States captured from actual sensor data, current, past actual, and future predicted (BMS, SCADA/IoT sensors, Facility Management Servers, Simulations…).

In AECOO, similar to manufacturing, this type of Building Digital Twin is the aggregation of multiple DTIs. Instead of having an independent data structure, DTAs are a computing construct which provide direct access to all DTIs, hence allowing ad-hoc or proactively queries for benchmarking and comparisons.

This type of DT is following the same principle than in manufacturing use case, by linking similar DTIs. However, in general AECOO products presents a smaller number of assets and much more heterogeneity than manufacturing products. In addition, the legal persons involved in their production are many more than in manufacturing supply chains (e.g. OEMs and TIER1, TIER2) providing a much more distributed data ownership. These two inherent
characteristics of AECOO use cases may hinder both the representativeness of the aggregated data as well as the potential of queries scopes.

From the point of view of many related stakeholders of the AECOO sector (owners, tenants, Public Administrations, assurances…) a real state (container) has to be considered jointly as a container for the products held inside itself (contents) like appliances, furniture, and personal goods. These contents may, as well as important components of the building services and auxiliary systems (e.g. Buildings Automations), could have their own Digital Twin Instances. The connection among these multi-scale Digital Twin Instances will highly expand the boundaries of access to relevant information. On the other side, many actions are
nowadays producing DTIs from Critical Civil Infrastructures and even whole districts are proposed, thus reaching infrastructure-scale and cities-scale. Building scale is then the hinge in between cities and its contents, and the synchronization of Building Digital twins across the Digital Twin scales will allow the vertical aggregation from appliances to districts. In there, vBDTA will put the focus on the AECOO stakeholders needs of relevant information and
optimized queries.

Beyond this, by the creation of any DTE, two main purposes
are sought: Predictive (intimately linked with simulation tools
of DTPs and DTIs) and Interrogative (applying to DTIs as
well as to DTAs in-depth analysis). As it happens to be in
any DTE, these two basic drivers may include completely
different requests depending on which is the role of the
stakeholder interacting and the typology of the Digital Twin.