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: 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! [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"). [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]{STRONG} Webel Twin Pattern: A DigitalEntity (a.k.a. «digital» @Entity) used as a digital variant must not be bound to a «physical» 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. [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 PhysicalEntity (even if only via another leveraged DigitalTwin)! [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] 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. 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 UML and SysML and the MagicDraw/Cameo tools Visit also (backlinks) Flags 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! Webel Twin Pattern: A DigitalEntity (a.k.a. «digital» @Entity) used as a digital variant must not be bound to a «physical» PhysicalEntity. 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 PhysicalEntity (even if only via another leveraged DigitalTwin)! 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. 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. 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). Webel Twin Pattern: A DigitalTwin must model processes and the entities they act on separately. Webel Twin Pattern: A LogicalProcess may only act on a PhysicalEntity via a PhysicalProcess 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. 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! 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"). Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity. 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. 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. 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. 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. 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. Webel Twin Pattern: Not every twinnable PhysicalEntity is worth treating as an asset. 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). Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital». 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). Webel Twin Pattern: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman). Book traversal links for The Webel Digital Twin Pattern for SysML policy notes Previous Up Next