Some information and data one might initially extract from a pre-existing «physical» PhysicalEntity (such as our target «physical» ActualPhysicalAsset ) are indicated by:

ANZLIC-2019: 'Traditionally, industry has created digital twins by retrospectively mapping, scanning, surveying, digitising or developing a digital copy of a real world object.'

Click on the image to view it full size

The Activities MapPhysicalEntity, ScanPhysicalEntity, SurveyPhysicalEntity, DigitisePhysicalEntity, and DevelopCopyPhysicalEntity, and are all just mainly "passthrough" «stub» placeholders.

They have corresponding data and information:

EntityMappingData
EntityScanningData
EntitySurveyingData
EntityDigitisingData
EntityCopyData.

You might be able to think of some others as well.

Note that there is no requirement that these output "data" or information sets be «digital»

! Some of them could include even sketches or notes written by humans on paper!

Note also that these data and information sets will mostly NOT already be in the standard internal format the «digital» @Entity (or «digital» PotentialPhysicalAsset ) employ. For example, the scanning data might be in a format only used by the particular scanning technology.

It is the job of PopulateDigitalEntity, which we'll have a quick look at next, to extract and write the data into the «digital» @Entity in the standard internal format (such as via a web services API).

The CallOperationAction for bind then assigns the «physical» PhysicalEntity to be mapped by the «digital» @Entity , which enters state Bound.

ASIDE: The name CreateDigitalEntityFromPhysicalEntity is not ideal because it in fact takes a "shell" «digital»

@Entity as input, which is then also fed to PopulateDigitalEntity.

Up next

28: Activity «stub» PopulateDigitalEntity

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] Webel Twin Pattern: Once a PotentialPhysicalAsset has been integrated with a real, existing (has mass) ActualPhysicalAsset under twinning control, its job is done forever (although it may be kept as an historical tracking record).

[POLICY]{STRICT} Webel Twin Pattern: A DigitalTwin and PhysicalEntity must both be 'attached' to Sensors and/or Actuators under management of the DigitalTwin before the twinning control loop is fully entered.

[POLICY]{STRICT} Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity.

Snippets (quotes/extracts)