02: Overview of Package 'twin' and notations

Gallery

Tutorial

TRAIL: The Webel SysMLv1 Pattern for Digital Twinning

Section

Tags and keywords

Topic level

INTERMEDIATE

SysML keywords

SysML Package Diagram

Keywords

Slide kind

SysML Package Diagram

We're diving straight in to interpret this:

ANZLIC2019: 'Digital twins are dynamic, data driven, multi-dimensional digital replicas of a physical entity. They encompass potential or actual physical assets, processes, people, places, systems, devices and the natural environment.'

Click on the image to view it full size

Some custom Stereotypes and icons

«twin»
«mappable»
«physical»
«process»
«sensor»
«actuator»
«digital»

Some special notations

CAVEAT: Some of these notational conventions may be subject to change!

The Webel Twin Pattern for SysML has some special notational conventions to support it:

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

A «digital»

entity element prefixed with an ‘@’ is a twinning entity or mapping entity. It maps (“twins”) a corresponding non-digital entity:

@Entity maps a real-world «physical» PhysicalEntity.
@Person maps a real-world «physical» Person (+ data).
@Place maps a real-world «mappable» Place (+ data).
@System maps a real-world «mappable» System.

Additionally:

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.

Example: The block «twin» DigitalTwin has *person:@Person[0..*] and *system:@System[0..*] properties.
Compare: The same block «twin» DigitalTwin has a digitalEntity:@Entity[1] property (uses the verbose form for clarity for this special case)..

Dr Darren says:

I'm not 100% happy with that '*' prefix notation. The tool won't let one use '@' as a prefix in Property names, so this is a workaround. It is meant to be reminiscent of a "pointer".

The target of a «digital» DigitalEntity (a.k.a. @Entity) is always at least «mappable». Not every «mappable» element is «physical» (has mass). For example, a «process» Process is not «physical» but can still be mapped by a «digital» @Process entity.

By definition here a Place is «mappable» but not «physical» - because it is used here to reference place in a purely geometrical, geographical way. You can't "pick up a Place and feel how heavy it is". It may, however, refer to the spatial location of something «physical» that does have mass.

Last but not least, the following is a strict policy throughout the Webel Twin Pattern for SysML:

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.

Up next

03: Focus BDD for the DigitalTwin block

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: A DigitalTwin must model processes and the entities they act on separately.

[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: 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.

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

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

Snippets (quotes/extracts)