Dynamic Behaviour of the SMS
If you need an overview about the topic, please visit the WIKI HOME PAGE.
The ALP has been outlined during a brainstorming in spring 2019 (ALP Brainstorming).
A suggestion for a transport protocol to be used is given at Transport via RTP
We found the fact that models can contain Network Sensors for the calculation of simulation relevant values (states and events for MIDAS - Multiuser Interactivity Driven Animation and Simulation) and for the purpose of exchanging those states and events among scene instances.
We found that fact at the WIKI pages Operational Paradigm and Improved Operational Paradigm (MMF).
Now, when a model is contained in more than one scene instance, the model - and its contained Network Sensors - might act according to following modes of operation:
- LOADED: the model has been loaded from the 3D Web (already http traffic, no exchange of states/events yet)
- Detached (Initialized): the model has been initialized or detached (no exchange of states/events)
- Attached (inactive): may receive states/events from the network. Does not react to the local user. Does not send
- Active: reacts to user input. Displays its state to the user. May send and/or receive network traffic
Charlie's car is controlled by the simulation software in Charlie's scene instance and the state (position, velocity, direction, ......) is distributed via the Collaboration Server to all scene instances and to the ITR. The collaboration server just acts as a broker for the state and as a persistent storage for the case that Charlie's scene instance may get into struggle and disconnects from the simulation.
Alice's scene instance may display the state of Charlie's car, but the car is inactive there and cannot be influenced by Alice (probably Alice is too far away from the car).
Bob's scene instance contains an active model of Charlie's car. Bob can influence the car (e.g. open or close the doors).
The car has no counterpart in the IoT, it is a pure virtual car. The State 1 in the ITR is just a dummy model, which might be used for calculation of collisions. There is no RLE 1 (real life entity of Charlie's car).
The train is controlled by Alice and Bob.
The model of the train is active at both - Alice's and Bob's scene instances - AND the controlling software in the train's model has authorized Alice AND Bob to be allowed to control the train.
For some reason, Charlie is not interested in the train - maybe his car is directed away from the railway station - hence the train model is detached in Charlie's scene instance. That means, it is neither following the global state nor is it creating network traffic.
For some reason, the train is a REAL train. There's an RLE 2 (real life entity "train"), which is directly controlled by the ITR. Regarding State 2 the ITR acts as a server that reacts to Alice's and Bob's input.
Bob's drone is easy to control. The state (position, velocity, direction, ......) is calculated at the Collabortion Server with simple server side calculations. The hardware follows the shared state in a stiff way.
Alice and Charlie are not interested in Bob's drone - model 3 is detached in their scene instances.