17: Staging BDD for working environment temperature vs building energy consumption control loop

Gallery
Tutorial
TRAIL: A SysML Pattern for Digital Twinning
Section
Topic level
INTERMEDIATE
SysML keywords
Block
Keywords
Slide kind
SysML Block Definition Diagram (BDD)
A BDD for the Webel Twin Pattern for SysML as applied to this case:
ANZLIC-2019: 'Sensors [DISPUTED] in office buildings for example, can adjust lights, blinds and temperature to balance optimal working environment with energy consumption, with the digital twin managing and adjusting in near real-time.'
Click on the image to view it full size

It's not specified here how the temperature of the «physical» Building and «mappable» WorkingEnvironment are related, but the Building has a sensor named temperatureSensorWG of type «sensor» TemperatureSensor for directly measuring the temperature of the working environment.

The «physical» Building has a value energyConsumption and a sensor of type «sensor» EnergyConsumptionSensor.

A «actuator» BlindActuator can adjust a «physical» Blind and a «actuator» LightActuator can adjust a «physical» Light.

Note that WorkingEnvironment is «mappable» but not «physical», although it may aggregate «physical» elements. Therefore, in the Webel Twin Pattern for SysML, it can't directly participate in the control loop of a «twin» DigitalTwin; it can't act as a unique «physical» PhysicalEntity replicated by a unique «digital» @Entity.

The «digital» @Building has values energyConsumption and temperatureWE (for the working environment).

Up next
18: IBD for working environment temperature vs building energy consumption control loop
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: 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.
[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: 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: 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.
Snippets (quotes/extracts)
 In contrast to traditional digital models, digital twins can connect with the physical ‘twin’ they model, changing alongside the physical system via real-time sensors and actuators.
 Sensors [DISPUTED] in office buildings for example, can adjust lights, blinds and temperature to balance optimal working environment with energy consumption, with the digital twin managing and adjusting in near real-time.
Visit also
Visit also (backlinks)
Related slides (includes other tutorials)
Related slides (backlinks, includes other tutorials)