03: Focus BDD for the DigitalTwin block

The sensor/actuator control loop part is addressed by this, and will be a major focus of this trail, with both some abstract cases (to show the basic pattern) and some very accessible examples (to show the pattern applied):

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.

Note that sensor and actuator as defined here are quite general:

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

And importantly:

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.

Because:

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!

This is supported by a strict policy:

Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) encapsulates strictly geometrical, spatial, and material aspects of a «physical» PhysicalEntity only. BY DEFINITION of this pattern it DOES NOT encapsulate processes!

There's also a group of elements dedicated to asset acquisition and creation (which includes any kind of manifestation such as building something or manufacturing it in a factory), which we'll also explore later in the trail, including using simulations in Magic Model Analyst^® (Cameo Simulation Toolkit^®) ):

Webel Twin Pattern: A PotentialPhysicalAsset is «digital», not «physical». It is used to acquire (an existing) or create (build, manifest, make) an «physical» ActualPhysicalAsset, which is a special case of «physical» PhysicalEntity.

Currently, a «robot» Robot is just handled as a special case of a «physical» Device, but this might change.

There is a «mappable» Organisation block, but this case does not seem to be mentioned in the ANZLIC 2019 source document, so it's not included explicitly in the twinning model here yet. Of course, having a «digital» @Organisation entity that twins a «mappable» real world Organisation would be very useful.

We must not forget Magritte:

Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) is NOT a representation! It is a digital encapsulation (it can only be perceived at the level of "bits and bytes"). It HAS many representations (such as views)!

That is the job of a «digital» EntityRepresentation, of which an «digital:visual» EntityView is a special case. Note that these are both cases of «digital» (as opposed to an oil painting by Magritte).

Please pay also special attention to these:

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

If you want to play games, do it with a variant! Once the unique @Entity is bound to a PhysicalEntity, and has entered into a synchronisation cycle, it MUST only carry data inputs from sensors (or reliable humans).

Webel Twin Pattern: DigitalTwin: The multiplicity of 'digitalEntity:@Entity' and 'physicalEntity:PhysicalEntity' MUST be [1] when the DigitalTwin is in the state Attached, the @Entity is in the state Bound, and the PhysicalEntity is in the state Exists.

Up next

04: Composite DigitalTwin

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: A DigitalTwin must model processes and the entities they act on separately.

[POLICY]{STRICT} Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) encapsulates strictly geometrical, spatial, and material aspects of a «physical» PhysicalEntity only. BY DEFINITION of this pattern it DOES NOT encapsulate processes!

[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 PotentialPhysicalAsset is «digital», not «physical». It is used to acquire (an existing) or create (build, manifest, make) an «physical» ActualPhysicalAsset, which is a special case of «physical» 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: A «digital» DigitalEntity (a.k.a. @Entity) is NOT a representation! It is a digital encapsulation (it can only be perceived at the level of "bits and bytes"). It HAS many representations (such as views)!