21: Example instances for 'asset'

Gallery
Tutorial
TRAIL: A SysML Pattern for Digital Twinning
Section
Topic level
ADVANCED
UML keywords
instance
InstanceSpecification
"link" InstanceSpecification
Keywords
Slide kind
hybrid diagram
SysML Package Diagram
UML Object diagram
This content has been marked as discussing an ADVANCED topic!
Click on the image to view it full size
These instance (object) diagrams show typical configurations for the acquisition and creation cases respectively once the «twin» DigitalTwin and «physical» ActualPhysicalAsset are attached to a «sensor» Sensor and «actuator» Actuator.
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.
The upper diagram corresponds to this case:
ANZLIC-2019: 'Traditionally, industry has created digital twins by retrospectively mapping, scanning, surveying, digitising or developing a digital copy of a real world object.'

The «digital» PotentialPhysicalAsset has a process related mapper «digital» *howAcquire for a «process» howAcquire. Selected information from data sets for :EntityMappingData, :EntityScanningData, :EntitySurveyingData, :EntityDigitisingData, and :EntityCopyData gleaned from a pre-existing «physical» actual:ActualPhysicalAsset has been translated and written into the «digital» *actual:@Entity in a standard internal format.

The lower diagram corresponds to this case:
ANZLIC-2019: 'Today this process can occur in reverse, with the digital model developed first followed by the physical asset.'
The «digital» PotentialPhysicalAsset has a process related mapper «digital» *howBuild for a «process» howBuild. Selected information from an :AssetSpecification has been translated and written into the «digital» @Entity (acting as a Digital Twin Prototype) and the «digital» PotentialPhysicalAsset in a standard internal format, and has been used to create a new «physical» ActualPhysicalAsset .

In both cases, in terms of states, the «physical» ActualPhysicalAsset now Exists, the «digital» PotentialPhysicalAsset is now Integrated, and the DigitalTwin is now Attached. We'll see this simulated in a screencast video Magic Model Analyst® (Cameo Simulation Toolkit®) later in the trail. These states are indicated here in the instance diagrams using additional "state flags":

UML/SysML: A Boolean "state flag" attribute corresponding to a State can be useful for indicating states in some diagram types (but must be synchronised with Transitions to States carefully).

And in both cases:

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).
Up next
22: Mini StateMachines for @Entity, PotentialPhysicalAsset, ActualPhysicalAsset
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: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman).
[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).
[ASSERTION]{STRONG} Webel Twin Pattern: Not every twinnable PhysicalEntity is worth treating as an asset.
[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]{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]{STRONG} Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital».
[CONVENTION]{SUBJECT-TO-CHANGE} Webel Twin Pattern: Convention: [MIGHT CHANGE]: A '*' prefix in a Property name of a «digital» @Block in a DigitalTwin model indicates a mapped block property, which must be typed by a non-digital «mappable» Block, and must have the «@» keyword applied.
[TIP]{INFORMATIVE} UML/SysML: During modelling it can really help to create little instance (object) diagrams as you go! This can also help communicate with non-SysML stakeholders.
[MODELLING, TIP]{SUGGESTED} UML/SysML: A Boolean "state flag" attribute corresponding to a State can be useful for indicating states in some diagram types (but must be synchronised with Transitions to States carefully).
Snippets (quotes/extracts)
 Traditionally, industry has created digital twins by retrospectively mapping, scanning, surveying, digitising or developing a digital copy of a real world object.
 Today this process can occur in reverse, with the digital model developed first followed by the physical asset.
Visit also
Visit also (backlinks)
Related slides (includes other tutorials)
Related slides (backlinks, includes other tutorials)