08: IBD of basic twin control loop

Gallery

Tutorial

TRAIL: A SysML Pattern for Digital Twinning

Section

Tags and keywords

Topic level

INTERMEDIATE

SysML keywords

SysML Internal Block Diagram

Keywords

Slide kind

SysML Internal Block Diagram (IBD)

ANZLIC-2019: '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.'

The following control loop pattern - shown as a portion of the Internal Block Diagram (IBD) for block DigitalTwin - applies uniformly across the entire Webel Twin Pattern for SysML:

Click on the image to view it full size

It does not matter whether one has some composite device that can behave both as a «sensor» and «actuator»

and at the same time, the signals can always be represented respectively split. Note that:

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.

Up next

09: IBD of DigitalTwin

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

[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: 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: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman).

Snippets (quotes/extracts)

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.

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.

A sensor is a transducer that receives and responds to a signal or stimulus from a physical system. It produces a signal, which represents information about the system

An actuator is a device that is responsible for moving or controlling a mechanism or system. It is controlled by a signal from a control system or manual control.