OARIS — Inconsistent mechanisms for determining subsystem state across use cases

Across several of the subsystem control, sensor control and sensor tracking use cases the mechanism for determing subsystem state are inconsistent and some cases do not allow for this without modifying the subsystem's state. CMS functionality will in many cases need to determing current state of the subsystem (without modification) - e.g. to present a control window to an operator.

(extract from Nick Davies email - Thales)
Looking at some of the sensor management and CMS use-cases, there seems to be 3 patterns used to obtain the state of the subsystems amongst the interfaces. Those patterns are essentially:

• Modify/Response
  The CMS issues a modification request to the subsystem. The subsystem will then call the CMS back with the new state (or old if unsuccessful); the state published will only include the attributes that pertain to the original modify request. The callback is mapped to the original request through a request ID attribute that is present in both request and response.
• Request/Response
  The CMS issues a report request to the subsystem. The subsystem will then call the CMS back with the current state; the state published will only include the attributes that pertain to the original report request. The callback is mapped to the original request through a request ID attribute that is present in both request and response.
• Notification
  The subsystem notifies CMS of the current state in an unsolicited fashion, either periodically or on state change

For each of the use-cases in detail:

• ‘Manage Subsystem Parameters’ use-case uses both request/response and modify/response – there is no callback interface for retrieving data.
• ‘Manage Frequency Usage’ use-case uses modify/response and Notification pattern. There is a ‘report_frequencies_state()’ method for notifying frequency state either periodically or on change, and also a ‘transmission_frequency_state’ method that reports the changed frequencies in response to a specific request. For transmission mode, however, there is only the modify/response mechanism – there is no way of discovering the transmission mode without setting a value.
• ‘Control Battle Override’ use-case uses the modify/response mechanism – there is no way of discovering the battle override state without setting a value
• ‘Control Emissions’ use-case uses the modify/response mechanism – there is no way of discovering the emissions state without setting a value first
• ‘Manage Technical State’ use-case uses all three patterns – there is a modify/response interface, a request/response interface and a pure notify interface
• ‘Manage Operational Mode’ use-case uses the modify/response mechanism and the request/response mechanism. However, the interface specifies that the response interface can also be used for ‘spontaneous’ mode change, where a request_id of 0 will be specified.
• ‘Manage Tracking Zones’ use-case uses the modify/response mechanism
• ‘Manage Transmission Sectors’ use-case uses the modify/response mechanism

As you can see, only ‘Manage Frequency Usage’ (part) and ‘Manage Technical State’ provide an interface that allow the subsystems to report their state unsolicited by the CMS. ‘Manage Operational Mode’ provides a definition of where it can provide state information unsolicited, but the standard only states that it will be used when the subsystem needs to change its own state; it does not say that it will also be used when it receives a request to change state from the CMS.

For the other use-cases, there are the following options:

• For the use-cases where the state is atomic, assume that the last value on the topic is the current value, not matter what request caused it to be populated. This can only be used for ‘Control Battle Override’ , ‘Control Emissions’, ‘Manage Frequency Usage’ (other part), ‘Manage Operational Mode’ – the others can allow only part of the state to be reported back, depending on what request initiated the published value. This still relies on the subsystem publishing its initial value on start-up.
• We can assume that all the interfaces use the approach specified in the ‘Manage Operational Mode’ use-case where the full state is reported on a request_id of 0. But then why not just define the interface without the request_id, always reporting all values?
• Where a request/response interface is specified, the CMS can poll periodically for the state. This only helps us with ‘Manage Subsystem Parameters’ out of those not covered in the options so far.

That leaves ‘Manage tracking Zones’ and ‘Manage Transmission Sectors’ where none of our options give us a mechanism for discovering the underlying state without changing it.

Emphasise CMS responsibility to initiate determination of initial state

Add paragraph below to the relevant use case descriptions (as identified in the issue).

"It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."