Comments on AMSP-04 Edition C documentation

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/NETN-FOM.md?plain=1#L91-L93

To simplify, why not just use the term "Modelling responsibility" ? Is there besides primary, also a secondary responsibility? Or do you mean initial responsibility?

Answer: Modelling responsibility of individual attributes can be shared among federates (HLA ownership) but the responsibility for the entire entity is referred to as the “primary modelling responsibility”. However, I see that this might be confusing and agree that we only use the term modelling responsibility for an entire simulated entity. A simple search in the document should find all use.

Resolution: Answer to question, no actions needed

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/NETN-FOM.md?plain=1#L103-L105

So far I have only seen federates supporting the other two patterns. So why is this one recommended?

Answer: The recommended pattern allows entities to exist in the federation as objects before they have been allocated to a specific federate. Also this pattern allows the “creator” of the object instance to keep the privilegeToDelete and manage destruction/reallocation if/when a federate resigns. This approach of central entity management is recommended for federates implementing the NETN-TMR pattern. In fact, it requires support for NETN-TMR. Suggest rewording to “However, the most advanced pattern uses …”

Proposed resolution: EDITORIAL

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-BASE/NETN-BASE.md?plain=1#L34-L36 What makes a federate a "NETN-federate" ? I.e. definition of term needed.

Answer: See 1.1 Concepts. A NETN-Federate is an application or service connected to a NETN-Federation that uses one or more NETN-FOM modules.

Proposed resolution: REJECTED

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-SMC/NETN-SMC.md?plain=1#L14-L19

Add item d on SMC_Response.

Answer: Suggest changing sentence to: The module defines three (3) basic control actions and a response, see Figure 4. Then add d) The SMC_Response interaction is used to provide feedback related to the status of a control action.

Proposed resolution: EDITORIAL

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-SMC/NETN-SMC.md?plain=1#L19-L21

I suppose the SMC_Responce is related to the status ETR Task-Status Report. When the SMC_Responce is true then there should always be a ETR-TaskStatus report with the value accepted. When the SMC_Responce is false then there should always be a ETR-TaskStatus report with the value refused.

I also noticed that the Capabilities supported are removed from the ETR FOM and placed at a higher level in the BaseEntity Supported Actions (See 4.3 bullet 2 and 6.1)

Answer: In response to the first paragraph: In the context of ETR actions, the SMC_Response is to indicate if the receiving federate accepts the task or not. The ETR-TaskStatus reports on the progress of executing the task. Clarified in the ETR chapter.

In response to the second paragraph: YES that is correct.

Proposed resolution: Answer to question, no action taken.

Follow up question: But now there are two interactions that are related to each other but are not related in the FOM and that can give inconsistencies.

For ETR tasks It should be clear that when an SMC_Reponse with true is given that always also an ETR-TaskStatus report with accepted should be given and when a SMC_Repsonse with false is given that always an ETR-TaskStatus report with refused should be given.

Answer:

Yes, we noted this overlap and I propose MSG-223 will need to update the ETR-TaskStatus interaction status enumeration to exclude Accept/Reject and only use it for task status. For now I think we can live with this and simply require the federates not to send conflicting replies. We can discuss this in MSG-223 and come to a resolution.

Related issue: https://github.com/AMSP-04/NETN-SMC/issues/2

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-ETR/NETN-ETR.md?plain=1#L113-L115

Comment: I think that the actual mode depends on the SIM, and not on what you declare in the task. Clarify text.

Answer: Agree. Suggest changing to the following. “A tasks can be executed concurrently with other tasks or sequentially. This depend both on the type of task and on the simulation model implementation of the task. However, a task parameter is included to allow indication of the expected mode of task execution.”

Proposed resolution: EDITORIAL

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-ETR/NETN-ETR.md?plain=1#L77

Requesting and Tasking. Harmonise naming.

Answer: Good catch. I prefer “Requesting” but since the entire module is about Tasking I guess that would be the best choice.

Proposed resolution: EDITORIAL

Comment (Same entry): Is the detached action without used simulation time (immediately assumes that) or is the federate that is performing the action responsible for how much simulation time is needed for the detach ? Also for all similar move tasks.

Answer: All simulations are responsible to model the time it takes to perform an action. So in this case immediately is perhaps misleading. I suggest simply changing the working to “If attached, the entity is detached before the move task starts. “

Proposed resolution: EDITORIAL

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-ETR/NETN-ETR.md?plain=1#L85

The simulation time needed for ChangeHeading, ChangeSpeed and ChangeAltitude is determined by the federate that is doing the action (depends also on the entity that is doing the action).

Answer: Correct. As mentioned above the federate determines how long it will take to complete this task. True for all tasks. However, I also spotted an editorial issue in this text. Suggest change to “Tasking of an entity to move to a specified altitude.”

Proposed resolution: EDITORIAL

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-ETR/NETN-ETR.md?plain=1#L87

Is the attach/detach action without using simulation time or is the federate that is performing the action responsible for how much simulation time is needed for the attach/detach ?

Answer: Federate is responsible

Proposed resolution: Answer to question, no action taken.

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-ETR/NETN-ETR.md?plain=1#L76

Comment 1: In NETN v3 this is a task management type task. In v3 the semantics are that a MagicMove task cancels all other tasks tasks in progress. Suggest to make this a subclass directly under SMC_EntityControl. This way of modeling corresponds with the "MagicResource" tasks in NETN-LOG.

Answer: The intention is that MagicMoves can be scheduled the same way as other tasks. The semantics that a MagicMove (when executed) cancels any current tasks being executed is still valid. If a MagicMove task is issued with an concurrent TaskMode and a time = now the effect will be exactly as in NETN v3. However, if scheduled in a non-concurrent task mode the MagicMove can form part of a sequence of scheduled tasks. The “MagicResource” task has been replaced by “SetSuppliesStatus”, “SetEquipmentStatus”, and “SetPersonnelStatus”.

Proposed resolution: Answer to question, no action taken.

Comment 2 (same entry): the location is changed. Note that for this task no simulation time is needed and can also be done when the simulation is not running.

Answer: The intention is to be able to schedule MagicMoves. Not the normal case perhaps and no simulation time = now.

Proposed resolution: Answer to question, no action taken.

[OscBer97]

https://github.com/AMSP-04/NETN-FOM/blob/40ee7b91f95c151b13990498201f5afcaa0e27ce/modules/NETN-MRM/NETN-MRM.md?plain=1#L12-L18

What is meaning of a, b, c, d, The difference between aggregation and merging is not clear.

Answer: Update a. to “Aggregation of subunits into a representation of their parent unit according to the organisational structure”

Update b. to “Disaggregation of a unit representation Ito its subunits according to the organizational structure”.

Update c. to “Division of a unit’s resources into temporary aggregate entities or physical entities.

Update d. to “Merging of temporary divided unit resources back into the original unit.

Proposed resolution: EDITORIAL