A digitalVariant:@Building can be used to explore optimisation of the building's energy consumption vs the working environment temperature as the blinds and lights are "virtually" adjusted, before driving the «physical» Building to new aim values.

Up next

19: ANZLIC 2019 «snippet» text extracts about acquisition and creation of physical assets

Notes

[CONVENTION]{SUBJECT-TO-CHANGE} Webel: Convention: [MIGHT CHANGE]: An '@' prefix in a DigitalTwin model indicates a «digital» Block that maps a non-digital «mappable» Block.

[POLICY]{STRICT} Webel Twin Pattern: It is a DigitalEntity (a.k.a. @Entity) - not the DigitalTwin that owns it - that directly «replicates» geometrical, spatial, and material aspects (only) of a single PhysicalEntity.

[POLICY]{STRICT} Webel Twin Pattern: A DigitalTwin manages a control loop including a PhysicalEntity and a DigitalEntity (a.k.a. @Entity) that «replicates» it. It typically includes at least one Sensor and at least one Actuator.

[WARNING]{INFORMATIVE} WARNING: In natural language casual conversation one often hears people speaking of a digital twin "replicating" or "twinning" a physical entity. If you do it that way literally, you will NOT have anything to manage the control system loop!

[POLICY]{STRICT} Webel Twin Pattern: The primary aim of the digitalEntity:@Entity of a DigitalTwin is to replicate its physical:PhysicalEntity as closely as possible (not to explore variants).

[POLICY]{STRICT} Webel Twin Pattern: Communication between the ControlSystem of a DigitalTwin and its digitalEntity:@Entity is via a dedicated protocol (ReadTwin, WriteTwin) distinct from the sensor reading or actuator driving signals.

[POLICY]{STRICT} Webel Twin Pattern: A LogicalProcess may only act on a PhysicalEntity via a PhysicalProcess

Snippets (quotes/extracts)

In contrast to traditional digital models, digital twins can connect with the physical ‘twin’ they model, changing alongside the physical system via real-time sensors and actuators.