04: Composite DigitalTwin | Webel IT Australia

Gallery

Tutorial

TRAIL: A SysML Pattern for Digital Twinning

Section

Tags and keywords

Topic level

INTERMEDIATE

SysML keywords

SysML Block Definition Diagram

Block

Keywords

Slide kind

SysML Block Definition Diagram (BDD)

Click on the image to view it full size

A «twin» DigitalTwin can be a composite that owns child DigitalTwins. The «digital» @Entity of the parent is then effectively also a composite of the «digital» @Entity of each of the child twins (and thus the «physical» PhysicalEntity of the parent is likewise mapped - virtually encapsulated - as a composite of the «physical» PhysicalEntity from each of the child twins). This enables recursive twinning of complex structures.

A «twin» DigitalTwin can also reference (leverage) other DigitalTwins to create arbitrarily complex "logical" systems (of systems) of twins. However, note again that in the Webel Twin Pattern for SysML things always ultimately percolate down to involve a «physical» PhysicalEntity somewhere:

Webel Twin Pattern: A DigitalTwin (even a "process twin" or "finance twin"), always, without exception, BY DEFINITION HERE either directly or indirectly involves at least one existing or anticipated PhysicalEntity (even if only via another DigitalTwin)!

In this trail, only the case of a single «twin» DigitalTwin managing a single «digital» @Entity and «physical» PhysicalEntity is explored in detail.

Up next

05: Twin instances

Notes

[CONVENTION]{SUBJECT-TO-CHANGE} Webel: Convention: [MIGHT CHANGE]: An '@' prefix in a DigitalTwin model indicates a «digital» Block that maps a non-digital «mappable» Block.

[POLICY]{STRICT} Webel Twin Pattern: It is a DigitalEntity (a.k.a. @Entity) - not the DigitalTwin that owns it - that directly «replicates» geometrical, spatial, and material aspects (only) of a single PhysicalEntity.

[POLICY]{STRICT} Webel Twin Pattern: The primary aim of the digitalEntity:@Entity of a DigitalTwin is to replicate its physical:PhysicalEntity as closely as possible (not to explore variants).

[POLICY]{STRICT} Webel Twin Pattern: A DigitalTwin may use one or more variantEntity:@Entity[0..*] to explore the impact of changes (optimisation studies, trade off studies) and then use them to drive the PhysicalEntity into a desired state (via its ControlSystem).

[CONSTRAINT, POLICY]{STRICT} Webel Twin Pattern: DigitalTwin: The multiplicity of 'digitalEntity:@Entity' and 'physicalEntity:PhysicalEntity' MUST be [1] when the DigitalTwin is in the state Attached, the @Entity is in the state Bound, and the PhysicalEntity is in the state Exists.

[ASSERTION, POLICY]{STRICT} Webel Twin Pattern: A DigitalTwin (even a "process twin" or "finance twin"), always, without exception, BY DEFINITION HERE either directly or indirectly involves at least one existing or anticipated PhysicalEntity (even if only via another DigitalTwin)!

Snippets (quotes/extracts)

Visit also

Visit also (backlinks)