07: BDD of twin control loop Blocks

Note that bit about variants again! The ControlSystem can play with any number of variants separately and use them to help drive the PhysicalEntity into a desired state (as then measured later by sensors or other reliable data sources):

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).

Webel Twin Pattern: A DigitalTwin may use one or more variantEntity:@Entity[0..*] to explore the impact of changes (optimisation studies, trade off studies) and then use them to drive the PhysicalEntity into a desired state (via its ControlSystem).

Please note again also that the terms 'sensor' and 'actuator' are used in the most general way:

Webel Twin Pattern: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman).

Up next

08: IBD of basic twin control loop

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: A DigitalTwin may use one or more variantEntity:@Entity[0..*] to explore the impact of changes (optimisation studies, trade off studies) and then use them to drive the PhysicalEntity into a desired state (via its ControlSystem).

[POLICY]{STRICT} Webel Twin Pattern: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman).

Snippets (quotes/extracts)

Digital twins are dynamic, data driven, multi-dimensional digital replicas of a physical entity.

They encompass potential or actual physical assets, processes, people, places, systems, devices and the natural environment.

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.

A sensor is a transducer that receives and responds to a signal or stimulus from a physical system. It produces a signal, which represents information about the system

An actuator is a device that is responsible for moving or controlling a mechanism or system. It is controlled by a signal from a control system or manual control.