Tags and keywords
@Entity always starts with
isBound = false and in the state
UnBound; it only becomes
Bound once it has a «physical»
PhysicalEntity (such as an
Exists ( has mass) assigned, noting that:
ActualPhysicalAsset always starts by default with
isExists = false and in the state
Phantom (even if one is acquiring rather than creating one).
In the acquisition case, the state of an identified (candidate)
ActualPhysicalAsset is immediately shifted to
Exists (it is asserted that it is known to have mass) and then a «digital»
@Entity binds to it after it has been populated with any initial mapping data (such as digital survey data, scanning data etc.).
The block «digital»
PotentialPhysicalAsset tracks the integration of an acquired (pre-existing) or planned (to be built or otherwise created) «physical»
ActualPhysicalAsset. It always starts off with
isIntegrated = false and in the
In the acquisition case, it moves from state
In the creation case, it moves from state
Integrated has a scripted OpaqueBehavior
isIntegrated=true as 'entry' Behavior.
By the time it reaches the
Integrated state, its target
actual exists ( has mass) and then its active job as an acquisition or creation tracker is done forever.
@Entity only enters the twinning synchronisation and control cycle under the management of a parent «twin»
DigitalTwin once that twin and its «physical»
PhysicalEntity (such as an
ActualPhysicalAsset) have both 'attached' to any «sensor»
Sensor or «actuator»
Actuator items. The «twin»
DigitalTwin has then become an active Digital Twin Instance (DTI).
You might be asking why some of these states (such as
Integrated)) are not carried by the «physical»
ActualPhysicalAsset block. Well, one could do it that way, but the approach here is that the «physical»
ActualPhysicalAsset is a relatively passive target without explicit knowledge of the twinning, and the «digital»
PotentialPhysicalAsset is its active "tracker". So all the
ActualPhysicalAsset knows how to do is move from state
Phantom to state
Exists, which means it is then known to have mass.
The twinning entity «digital»
@Entity can only become
Bound once its mapped «physical»
PhysicalEntity - in this case a «physical»
ActualPhysicalAsset - is known to exist (has mass) and so can enter into a sensor/actuator control loop managed by the parent «twin»
Digital Twin once it is
Attached (and has become a functioning Digital Twin Instance).
A word on the modelling strategy for expert Magic Model Analyst® (Cameo Simulation Toolkit®) users:
The system uses mostly synchronous Operation triggers on Transitions with 'effect' Behaviors given by Activities; many of these could be done instead with concise OpaqueBehavior scripting, however using verbose Activity Diagrams does make it easier to annotate.
And in many cases one could use asynchronous Signal triggers, however that makes it a bit harder to coordinate the simulation and also harder to make a screencast video.
Note how some of the Operations return the target object (so-called method chaining). One advantage of this approach is that it helps reduce the number of Forks in the driving Activity Diagrams. To see how this is done visit this mini-tutorial (but afterwards please):Magic Model Analyst® (Cameo Simulation Toolkit®) knows how to match the 'effect' Activity parameters against the Operation parameters, including the synchronous return parameters.