20: Package Diagram overview of 'asset'

This content has been marked as discussing an ADVANCED topic!
This diagram is at the limit of complexity recommended for a Package Overview

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.

Click on the image to view it full size

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:

Please DO NOT conflate the «digital» 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.

Up next
Snippets (quotes/extracts)
Visit also
Visit also (backlinks)
Related slides (includes other tutorials)
Related slides (backlinks, includes other tutorials)
External links