Tags and keywords
DigitalTwin, still keeping this in mind:
The sensor/actuator control loop part is addressed by this, and will be a major focus of this trail, with both some abstract cases (to show the basic pattern) and some very accessible examples (to show the pattern applied):
Note that sensor and actuator as defined here are quite general:
This is supported by a strict policy:
There's also a group of elements dedicated to asset acquisition and creation (which includes any kind of manifestation such as building something or manufacturing it in a factory), which we'll also explore later in the trail, including using simulations in Magic Model Analyst® (Cameo Simulation Toolkit®) ):
Currently, a «robot»
Robot is just handled as a special case of a «physical»
Device, but this might change.
There is a «mappable»
Organisation block, but this case does not seem to be mentioned in the ANZLIC 2019 source document, so it's not included explicitly in the twinning model here yet. Of course, having a «digital»
@Organisation entity that twins a «mappable» real world
Organisation would be very useful.
We must not forget Magritte:
That is the job of a «digital»
EntityRepresentation, of which an «digital:visual»
EntityView is a special case. Note that these are both cases of «digital» (as opposed to an oil painting by Magritte).
Please pay also special attention to these:
If you want to play games, do it with a variant! Once the unique
@Entity is bound to a
PhysicalEntity, and has entered into a synchronisation cycle, it MUST only carry data inputs from sensors (or reliable humans).