31: Case: Create a new physical asset using a «digital» @Entity initially as a digital "template"

The term creation is used here in the broadest sense, and includes, for example, manufacturing a «physical» PhysicalEntity in 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:

Therefore, any process-related information (such as descriptions of the manufacturing process) is captured in a «digital» PotentialPhysicalAsset "tracker".

Note the initial States of the various demo objects:

• The «twin» DemoDigitalTwin is Unattached.
• The «digital» DemoPotentialPhysicalAsset is in the Potential state and does not yet contain any information about the to-be-created «physical» ActualPhysicalAsset it will track.
• The «digital» @DemoEntity is UnBound and does not yet contain any "template" information about the «physical» ActualPhysicalAsset that it will eventually map as its «physical» PhysicalEntity.
• The «physical» DemoActualPhysicalAsset does NOT yet exist in the real-world, and in the terminology of the Webel Twin Pattern for SysML lifecycle it is still a Phantom.
• The «sensor» DemoSensor and «actuator» DemoActuator are also not yet attached (because nothing physical exists yet to attach to). Their states are not yet explicitly modelled in this trail.

---