To become a digital twin, and not just a digital entity, a related physical entity (also called “target entity”) must exist., or at least be planned. In exceptional cases, the twin part (the related entity), might also be a digital entity. For one physical entity, a set of digital twins, with different purposes, may also be created. 

The Digilab/BE project is focused on digital twins for the built environment (BE).  

On the physical twin  

In the built environment, the physical twin is something build-up, or at least planned to be built-up. The physical twin might be 

• A single part of the built environment (a door, a window, an elevator, a fence) 

• An aggregation of parts (a room, a building, a ventilation system, a bridge) 

• A high-level aggregation (a complete road, a neighborhood, a university campus, a city)  

On the digital twin 

Creating a digital twin must be based on a purpose, a wish or a need to achieve something. The Wikipedia definition lists some relevant activities (simulation, integration, testing, monitoring and maintenance) as example of activities it might be more convenient to do using a digital twin possibly in combination with the physical twin. Example of situations when a digital twin might be useful: 

• Simulations to support the design (no physical entity exists yet)

• Expensive physical simulation. Example: aircraft pilot training 

• Dangerous simulations. Example: fire rescue actions for big buildings, training emergency actions for drivers/vehicles or pilots/aircrafts 

• More convenient saving travel cost by “digital inspection” and not visiting the physical entity itself 

• Access to limited resources. Example: digital museums 

Digital twins might be focused on the physical properties of the related twin. The digital twin might also be a digital twin supporting processes e.g. design and construction of tools and buildings, use of equipment. When processes are in focus, actors and project phases become important. 

What is required of the digital entity to become a digital twin? 

The most important requirement is that there exist (or at least in planned) a target entity (“Physical twin). Example of what is not a digital twin might be a bank account. This is just a digital entity. Several sources set up additional requirements to become a digital twin. One common requirement to become a digital twin, is have a two-way, automated connection between the digital twin and the target entity:  

• The digital twin must be able automatically to sense the state of the physical twin, and must also be able to automatically force the behavior of the physical twin. Example: Indoor climate control and regulation. 

• When this is not the case, the following terms  are used: 

• digital shadow. Example: ship navigation based on digital (GNSS) sensor for positioning and manual steering input to modify the moving direction of the ship. 

• digital copy. Example: a digital map of a terrain based on aerial photos taken at a given date 

In the Digilab/BE project we do not distinguish between these three (twin, shadow, copy). Whenever there is a use case (purpose) for a digital representation of something (planned) build-up, we use the term digital twin. 

Requirements to the two twins 

As stated above, digital twins should have a purpose. To fulfil the purpose, a set of requirements must be fulfilled. These requirements should be specified in a digital language, making it possible to validate if the digital twins fulfill the requirements.  

One kind of requirements is connected to accuracy issues, both on the digital and the physical twin. Other kinds of requirements are related to e.g., sustainability issues, durability issues and performance issues. (examples needed?). 

When processes are involved in a digital twin, process-related requirements are also relevant. 

Demo cases

We have created demo cases where we show how these four aspects can be united to achieve one purpose: 

• Setting up a user certification systems for lab users. 

• (more to come)