Icon class icon_class far fa-sticky-note icon_class_computed far fa-sticky-note Note kind CONVENTION Policy level SUBJECT-TO-CHANGE Keywords Webel Best Practice Webel Twin Pattern Relates to 02: Overview of Package 'twin' and notations 03: Focus BDD for the DigitalTwin block 05: Twin instances 06: Focus BDD for EntityRepresentation 07: BDD of twin control loop Blocks 08: IBD of basic twin control loop 09: IBD of DigitalTwin 11: Example: Twinning a construction Pipe 12: Overview of 'pipe' package 13: PipeDigitalTwin instances 14: IBD for PipeDigitalTwin flow control 16: Overview of 'building' package 17: Staging BDD for working environment temperature vs building energy consumption control loop 18: IBD for working environment temperature vs building energy consumption control loop 04: Composite DigitalTwin Related notes Related notes (backlinks) [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. [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: 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 «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)! [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: 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: 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: 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 must model processes and the entities they act on separately. Related snippets (extracts) Visit also Visit also (backlinks) Flags Book traversal links for Webel: Convention: [MIGHT CHANGE]: An '@' prefix in a DigitalTwin model indicates a «digital» Block that maps a non-digital «mappable» Block. Previous Up Next
