Tags and keywords
In the remainder of this trail we'll be examining the following acquisition case in detail first:
Then we'll model this manifestation case (build or otherwise create), where in the terminology of Dr. Michael Grieves, one moves from a Digital Twin Prototype (DTP) as a kind of creation "template" to a Digital Twin Instance (DTI):Both are also explored further in a detailed screencast video of the Magic Model Analyst® (Cameo Simulation Toolkit®) animation available at the end of the trail.
This Block Definition Diagram (BDD) will be clearer in combination with the instance diagrams and mini StateMachines we'll see later. For now, some key points:
twinning @Entity (which is part of a sensor/actuator twinning control loop involving devices and/or humans) with the «digital» PotentialPhysicalAsset "tracker" (which is not)!Note how a PotentialPhysicalAsset may also carry some optional blocks about «process» Process, mapped by «digital» @Process (and it may carry any other information needed to aid acquisition or creation of an actual physical asset). By contrast, a «digital» @Entity may only act as a "template"
for 3D model information and materials information, but it may not carry any directly process-related information.
In the case of a Digital Twin Prototype, an AssetSpecification will typically have its information distributed (in a standardised format) across an @Entity - acting as a "template" for physical, spatial, and material aspects only - and a PotentialPhysicalAsset - to carry information about process-related and auxiliary aspects.