24: Case: Acquisition: Twin a pre-existing physical asset

For easier illustration (and more traceable screencasting) various concrete demo types are created externally at the top-level (as opposed to injecting a family of types using the Abstract Factory pattern or similar).

Note the initial States of the various demo objects:

The «physical» DemoActualPhysicalAsset pre-exists in the real-world but in the terminology of the Webel Twin Pattern for SysML lifecycle it is still a Phantom.
The «digital» DemoPotentialPhysicalAsset is merely a "shell" in the Potential state (it does not yet know which «physical» ActualPhysicalAsset it will track).
The «twin» DemoDigitalTwin is Unattached.
The «digital» @DemoEntity is UnBound (and does not yet digitally map the «physical» ActualPhysicalAsset as its «physical» PhysicalEntity).
The «sensor» DemoSensor and «actuator» DemoActuator are also not yet attached (their states are not yet explicitly modelled in this trail, however you can imagine they still need to be connected up as part of the control loop to be managed by the «twin» DemoDigitalTwin).

If this is your first time working through these slide pages it is suggested that you please not watch the full length accompanying screencast video yet until the very end of this trail.

For experts

If you are particularly sharp, you might have noticed a «twin» DigitalTwin has to start off without a «digital» @Entity or «twin» DigitalTwin assigned (at least for a while), which concern was slightly glossed over in the multiplicity indicators in some of the earlier diagrams, as explained in detail here:

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.

Watch full video

Screencast: The Webel Digital Twin Pattern for SysML: Part 1: Simulating acquisition or creation of physical assets using Activities and StateMachines in Cameo Simulation Toolkit.

Up next

25: Effect Activities used by the acquisition case

Notes

[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 «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] Webel Twin Pattern: Once a PotentialPhysicalAsset has been integrated with a real, existing (has mass) ActualPhysicalAsset under twinning control, its job is done forever (although it may be kept as an historical tracking record).

[POLICY]{STRICT} Webel Twin Pattern: A DigitalTwin and PhysicalEntity must both be 'attached' to Sensors and/or Actuators under management of the DigitalTwin before the twinning control loop is fully entered.

[POLICY]{STRICT} Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity.

[CONSTRAINT, POLICY]{STRICT} 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.