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).

Webel Twin Pattern: An AssetSpecification may contain ANY information or data of ANY kind in ANY format about how to acquire, manifest, build, or create a physical asset. This information may be distributed across an @Entity and a PotentialPhysicalAsset.

Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital».

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:

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!

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.

The simulation of this case in Magic Model Analyst^® (Cameo Simulation Toolkit^®) is recorded in this screencast video, but if this is your first time through this trail it is recommended that you NOT watch it yet until the very end of this trail.

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

32: Activity CreatePhysicalEntityFromDigitalEntity

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]{STRICT} Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity.

[ASSERTION]{STRONG} Webel Twin Pattern: An AssetSpecification may contain ANY information or data of ANY kind in ANY format about how to acquire, manifest, build, or create a physical asset. This information may be distributed across an @Entity and a PotentialPhysicalAsset.

[POLICY]{STRONG} Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital».

Snippets (quotes/extracts)

Today this process can occur in reverse, with the digital model developed first followed by the physical asset.