The Webel Digital Twin Pattern for SysML policy notes

Icon class

icon_class_computed

fas fa-book

Policy notes supporting the Webel Twin Pattern for SysML. For examples of their use, please visit:

TRAIL: A SysML Pattern for Digital Twinning

The following list is NOT ordered:

[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).
[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] 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 «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!
[ASSERTION]{STRONG} Webel Twin Pattern: Not every twinnable PhysicalEntity is worth treating as an asset.
[POLICY]{STRICT} Webel Twin Pattern: A DigitalTwin must model processes and the entities they act on separately.
[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: 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: 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: A DigitalTwin manages a control loop including a PhysicalEntity and a DigitalEntity (a.k.a. @Entity) that «replicates» it. It typically includes at least one Sensor and at least one Actuator.
[POLICY]{STRICT} Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity.
[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]{STRONG} Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital».
[WARNING]{INFORMATIVE} WARNING: In natural language casual conversation one often hears people speaking of a digital twin "replicating" or "twinning" a physical entity. If you do it that way literally, you will NOT have anything to manage the control system loop!
[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.
[POLICY]{STRICT} Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) is NOT a representation! It is a digital encapsulation (it can only be perceived at the level of "bits and bytes"). It HAS many representations (such as views)!
[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).
[POLICY]{STRICT} Webel Twin Pattern: Communication between the ControlSystem of a DigitalTwin and its digitalEntity:@Entity is via a dedicated protocol (ReadTwin, WriteTwin) distinct from the sensor reading or actuator driving signals.
[POLICY]{STRICT} Webel Twin Pattern: A LogicalProcess may only act on a PhysicalEntity via a PhysicalProcess
[ASSERTION]{STRICT} Webel Twin Pattern: A DigitalEntity (a.k.a. «digital» @Entity) used as a digital variant must not be directly bound to a «physical» PhysicalEntity (may not directly actuate/sense/affect)
[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.
[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)!

Notes

Relevant snippets (from other sources)

Visit also

Screencast: The Webel Digital Twin Pattern for SysML: Part 1: Simulating acquisition or creation of physical assets using Activities and StateMachines in Cameo Simulation Toolkit.

Webel's Best Practice policy notes for MBSE with SysML1.x (and UML) and the MagicDraw/Cameo tools

Visit also (backlinks)

Policy Notes for the Webel Parsing Analysis recipe for SysML

TRAIL: A SysML Pattern for Digital Twinning

Flags