search

AMSP-04 / NETN-ORG

NATO Education and Training Network (NETN) Organisation (ORG) Module
Other
1 stars 1 forks source link

FederateApplication unit allocations #42

Closed bergtwvd closed 4 years ago

bergtwvd commented 4 years ago

The class FederateApplication provides the unit allocations. With the addition of EquipmentItem, this may also be equipment items besides units.

While at this class, we should reconsider if this is the best way to provide the allocation information. The allocation information can also be an attribute in the Unit class.

At the moment a federate subscribes on units (and gets the data), but can only decide on what unit is actually allocated to the federate when the FederateApplication instance is updated. Is seems more logical to have that information in the Unit itself.

Currently it is also possible to make mistakes. E.g. the unit is listed in the FederateApplication, but never created.

lofstrandbjorn commented 4 years ago

I have no problem with optimizing the way we indicate the initial allocation of responsibility of Units and EquipmentItems. Implement proposal in feature branch and request review of pull-req.

bergtwvd commented 4 years ago

First, before we can proceed, what are the use cases for publishing ORBAT data?

lofstrandbjorn commented 4 years ago

First, before we can proceed, what are the use cases for publishing ORBAT data?

  • UC-1: One ORBAT-application takes care of everything: reading the MSDL FOM, publishing all the data, and potentially updating/removing some of the data;
  • UC-2: Several ORBAT-applications will publish ORBAT data for the same simulation execution, but for different Federate Applications. Each ORBAT-application has its own MSDL file and the data can be published any time during the execution. For example, if we need capability X sometime during the simulation, it can be started and configured by the ORBAT data that is also provided at that time. The ORBAT-application may even be part of capability X.
  • UC-3: Several ORBAT-applications will publish ORBAT data for the same simulation execution, for different Federate Applications or an existing Federate Application. Unit data can be added by different ORBAT-applications by just publishing the data.

Some thoughts:

The number of ORBAT-applications is a federation design/agreement. Each publish the content of provided MSDL file(s). Multiple MSDL files at any point during execution can be loaded. Or even not provided as MSDL but some other format or runtime editing. Scenario prep. and design should ensure that MSDL files are disjunct but ORBAT-applications should also subscribe to NETN-ORG objects and not register duplicates. This could be handled if the NETN-ORG requires objects to be registered with UUID as object name and ORBAT federates can e.g. use reserveObjectInstanceName. Owership transfer of NETN-ORG objects should be allowed and objects should become unowned in the federation if the registering ORBAT federate resign without deleting.

lofstrandbjorn commented 4 years ago

Investigate drop of FederateApplication object class replaced by "FederateAllocation" attribute of Unit and EquipmentItem classes. Make sure the semantics are clear to cover UC.

lofstrandbjorn commented 4 years ago

I propose to put the description of different cases for initialization in NETN-FOM descriptions on the use of modules. "Initialization" subsection.

bergtwvd commented 4 years ago

After reviewing more closely the proposal is now:

The assumption is:

If a unit is moved in the organisation:

If a equipment item is moved in the organisation:

Advantages of this change are:

Another option is to include the federate name in the Unit class. But then this has to be done for every unit, and this can lead to inconsistencies

lofstrandbjorn commented 4 years ago

The assumption is:

  • if a unit is allocated to a federate, the unit plus all its children is allocated to the same federate.

Not sure if this is true. The NETN-MRM allows initial allocation of an aggregate unit to a federate and during disaggregation, the child units can be allocated to a different federate. E.g. One federate operating on a battalion level and another on company level. However, if a unit is allocated to a specific federate, non of its descendants should have an initial allocation of modelling responsibility. In NETN federations we do full aggregation & disaggregation but we allow division of a unit's equipment items into temporary (Divided) AggregateEntities or individual Physical platforms.

lofstrandbjorn commented 4 years ago
  • FederateApplication class: the Units attribute will only contain root units, i.e. units that are not a child of another unit.

A ORBAT may have an initial allocation of modelling responsibility of a Unit that is not a "Root" unit. E.g. An orbat may contain a brigade organization as "Root" unit but the initial allocation of modelling responsibility is at the company level where each company is allocated to a different federate.

bergtwvd commented 4 years ago

If this is what we want, then the units listed at the federate application must be as we had before, i.e. all the ORBAT units allocated to the federate regardless if they are root or not. The other changes can remain as proposed I think.

At the same time, not every simulator will support this mix of allocation....

bergtwvd commented 4 years ago

I think we have not reached a conclusion yet.

After more discussion, the proposal to simplify the structure and handling:

LennartOlsson commented 4 years ago

I do not think that "the SuperiorUnit attribute is replaced by ChildUnits attribute" will simplify the handling.

In MSDL is the CommandingSuperior unit defined directly at a Unit.

hendersonhc commented 4 years ago

I know that the reference in the MSDL is from unit to superior but that is a complete file with the total Orbat inside. When we receive the units as defined in the FOM we cannot create the units completely until all objects are received. When a aggregate is received we don't know which children are beneath (we are not sure that all children beneath the aggregate are already published). Now I have make a work around by waiting with the creation of the units until all units in the FederateApplication unit list are received. That is one of the reasons why I need the federate application unit list. It is the only trigger for me that everything is received and that all children are complete known. I think a better and easier way is to create a unit when the unit itself and all the children beneath are received. With the current structure that is not possible.

So the change will not simplify the handling at the federate that is generated the FOM objects from the MSDL but there all the information is available in the file. It will simplify the handling for the federate that receives the FOM objects since more information (also the uuids of the expected children and equipments) are already known when the unit is received.

lofstrandbjorn commented 4 years ago

Even if you have the children list you will not know if the unit is allocated to your federate or not until you receive the FederateApplication info. If the initial allocation is an attribute, it is a little bit better; but you still have to wait for the update of that attribute to know how the Unit is allocated. The assumption that all children are allocated to the same federate as a "root" unit is not true. There may be many Units in the ORBAT with no allocation at all and with children that are allocated to different systems. The perspective that, if a unit is allocated then all its children must be allocated to the same federate is a simplification. IMHO I think we should stick with the SuperiorUnit (possibly adding children even if it creates some redundancy and can cause inconsistencies). But we should raise this issue again for AMSP-04 Ed C when we are moving towards HLA 4 and we surely will need to revisit both NETN-ORG, NETN-MRM and NETN-Physical again. For NETN v4 I also expect some work on Simulation Exeuction Maagement and Control to synchronize initialization and start of scenario.

bergtwvd commented 4 years ago

Ok, let's postpone this issue to Edition C. @hendersonhc : comments?

lofstrandbjorn commented 4 years ago

I am working on the documentation and I noticed one more thing on the Deployment info. In the FederateApplication object class we should either rename the attribute Unit to something that would include EquipmentItems or we should add an attribute Equipment. The latter corresponds better to the MSDL type and is my suggestion. It also makes it more explicit that allocated units should become Aggregate Entities and allocated Equipment should become Physical Entities.

bergtwvd commented 4 years ago

Yes, agree to have two atteibutes: Units and EquipmentItems.