Semantics for updating the ORG data in the simulation not clear

[bergtwvd]

Suggest to firm up semantics:

For a unit to be created by a simulator, the following must hold:

• The Unit object instance is created (with required values)
• The Units attribute of the FederateApplication object instance lists the UUID of the unit

Similar for deletions. Simulator removes unit iff:

• Unit object instance is deleted, and
• UUID is removed from the Units attribute of the FederateApplication

[lofstrandbjorn]

See issue #42

[lofstrandbjorn]

Will be closed by #42 if the allocation info is an attribute of Unit & EquipmentItem instead of using FederateApplication object.

[lofstrandbjorn]

I will revisit this comment since we are keeping FederateApplication.

[lofstrandbjorn]

I propose to add the following text to the documentation:

The NETN-ORG objects represent data used for (re-)initialization of ground truth objects such as NETN-Physical Platforms and NETN-MRM Aggregate entities. The initial value of the NETN-ORG object attributes can be used by federates to perform initial registration and update of ground-truth objects. Note that each federate will interpret these values and perform their internal initialization which might include approximations, adjustments etc. to all the unit or equipment to be modelled. E.g. an equipment item representing a ground vehicle can be located in water or inside buildings/trees and therefore the initial value of the corresponding ground-truth platform can be adjusted by the federate. The initial allocation of modelling responsibilities is represented in the federation by FederateApplication objects which associates specific federates applications with Unit and EquipmentItem objects.

Subsequent updates of a NETN-ORG Unit or EquipmentItem object with an associated ground-truth representation should be considered a re-initialization of the ground-truth object. A federate with current modelling responsibility of a ground-truth object will perform re-initialization based on the updated Unit or EquipmentItem attribute values. Federation agreements should specify any limitation to which NETN-ORG object attributes that are allowed to be updated during the execution of the scenario. In addition, any update of the NETN-ORG Force relations attribute should be reflected and used by federates that depend on this information.

Snapshots of the simulation ground-truth can be made at any point during execution but preferable during simulation pause state. The snapshot is an update of all NETN-ORG objects and attributes to reflect the current simulated ground-truth state. E.g. locations are updated.

[LennartOlsson]

In the second part, an update of a NETN-ORG Unit or Equipment attribute shall not necessarily result in a re-initialization of the ground-truth object. E.g. the corresponding aggregate unit has changed position when the Symbol attribute is changed at the Unit, this shall result in showing the new symbol for the aggregate in a viewer but not moving the aggregate back to its initial position.

[bergtwvd]

Yes, re-initialization w.r.t. the NETN-ORG Unit or Equipment attributes that have been updated.

Wording: ORG object vs Physical / Aggregate entity ?

Also add: When a NETN-ORG Unit or Equipment object is deleted, the associated ground-truth entity should be deleted by the federate that has current modelling responsibility of the entity, along with any related child entities where applicable.

And: NETN-ORG Unit objects typically result in NETN-MRM Aggregate entities and NETN-ORG Equipment objects in NETN-Physical entities.

[lofstrandbjorn]

Also add: When a NETN-ORG Unit or Equipment object is deleted, the associated ground-truth entity should be deleted by the federate that has current modelling responsibility of the entity, along with any related child entities where applicable.

I do not think this is the preferred behaviour. Deleting a Unit or EquipmentItem object will not result in anything changing in the ground-truth. A ORBAT-application resigning or simply deleting objects will not affect the rest of the simulation. If a Unit/Eq.Item is re-registered (the same uuid) and updated this will have the same effect as updating an existing Unit/Eq.Item object (re-initialization). The same is true for Forces and FederateApplication.

An updated FederateApplication allocation (new object just updated units attribute) should be interpreted by the associated federate as an attempt to create the entities. If the entity already exists in the federate it will not re-register (any attribute updates will be based on updates of the Unit/Eq.Item attributes). If the entity does not exist in the federation it will be created and updated. If the entity exists but attributes are allocated to some other federate, the object will not be created and attributes will be updated based on updates of the Unit/Eq.Item object. If a Unit is no longer in any FederateApplication units list but a corresponding entity exist in the federation, nothing will happen.

The initial allocation of modelling responsibilities should be interpreted as which federate creates the object.

All Physical and Aggregate entities should be registered in the federation with their UUID as an object instance name. A federate could attempt to reserve names based on FederateApplication units attribute and then register objects for those that could be reserved. Any failure to reserve a name or register an object with a specific name could potentially be reported back to an ORBAT application but this requires an additional HLA interaction in NETN-ORG (something for EdC?)

[bergtwvd]

Following this scheme, there is no way to re-initialize a simulation with a new ORBAT, You have to re-start all the federates. There must be a better way. And a mechanism to do this is by deleting the FederateApplication ....

[lofstrandbjorn]

I think re-initializing a federation should be controlled by some other mechanism (NETN-SIMAN?) that will specify the various states of simulation execution and how to control it. I do not think that simply removing the FederateApplication object instance should be that trigger.

[bergtwvd]

Lacking a mechanism right now, VRF deletes entities when the ORBAT gets deleted. For CWIX we could not afford restarting the service for every new ORBAT. Especially for decision support type of applications the back-end service(s) will constantly be fed with new scenarios. Restarting them is a no-go. So, if SIMAN is going to handle this, then this needs to be top of the list.

[lofstrandbjorn]

There is nothing in NETN-ORG that prevents an agreement with the interpretation that removal of FederateApplication leads to resetting the federate but at the same time, it is not a required behaviour.

[bergtwvd]

Yes, agreements are always the escape pod.... Anyway, a few of the different mechanisms that could be agreed upon need to be captured. But eventually (maybe with SIMAN) there should be one recommended way.