Tags and keywords
PhysicalEntityin a factory. In the terminology of Dr Michael Grieves, this case corresponds with from moving from a Digital Twin Prototype (DTP) to a Digital Twin Instance (DTI).
Dr Darren says:
I prefer the term "template" over "prototype" here, because "prototype" suggests something that is not complete or mature. With modern robotic manufacturing and Computer Numerical Control (CNC) a physical entity created from a virtual model can correspond with very high precision.
As modelled here, the entire information about the physical entity to be created is initially in an
AssetSpecification, which may contain ANY information of ANY kind, and not necessarily «digital» (it could even contain some scribbles on paper).
Typically this information will also not be in the standard internal format of the «digital» objects under management of the «twin»
DigitalTwin , and will contain a mix of 3D and other structural information, materials data, process-related information, and information on human resources and other enabling resources. It will typically have to be distributed between a «digital»
@Entity acting as a "template" for the to-be-created «physical»
PhysicalEntity and a «digital»
PotentialPhysicalAsset "tracker", noting that:
Note the initial States of the various demo objects:
- The «twin»
- The «digital»
DemoPotentialPhysicalAssetis in the
Potentialstate and does not yet contain any information about the to-be-created «physical»
ActualPhysicalAssetit will track.
- The «digital»
UnBoundand does not yet contain any "template" information about the «physical»
ActualPhysicalAssetthat it will eventually map as its «physical»
- The «physical»
DemoActualPhysicalAssetdoes NOT yet exist in the real-world, and in the terminology of the Webel Twin Pattern for SysML lifecycle it is still a
- The «sensor»
DemoActuatorare also not yet attached (because nothing physical exists yet to attach to). Their states are not yet explicitly modelled in this trail.