Method report_sim_mode_status does not contain the status of the session e.g. whether it is running, not started, frozen etc. The specification should also describe the overall state machine described by the interface.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Some passive sensors are unable to resolve a bearing around the line of symmetry through the sensor. The polar model for positions in the specifications does not allow this ambiguity to be clearly represented.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Interface Manage_Physical_Configuration_CMS contains method receive_physical_configuration_success, which is used where receive_acknowledgement from common_use_case_interface would be expected

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

For Service Health Reporting and Subsystem Health Reporting the specification describes two scenarios one on subsystem initiative and another on request.
In both cases the subsystem calls a method on the CMS interface with a request_id. In the 'on subsystem initiative' case it is unclear what value the subsystem should use for the request_id. Any value chosen could potentially be misinterpreted as a value for an actual CMS request.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

typedef sequence<org::omg::c4i::Domain_Model::Common_Types::subsystem_id_type, 256> sensor_track_based_on_id_type;

Has subsystem_id_type rather than plot_id_type as its value type.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Attribute velocity in class sensor_track_type is mandatory but will not be defined / known for bearings tracks

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

On page 95 the description of technical_state_type calls it a class while the diagrams stereotype it as an IDLEnum.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

(originally reported by Richard Smith - BAE Systems)

(Proivde_Health_State, page 194, para above table 7.185) contains the following description:

“Reason for health state
Each reported health state other than AVAILABLE is accompanied by the reason(s) for that health. In this way the CMS may for instance derive that although the technical state of the subsystem is STANDBY (and NOT AVAILABLE for that reason), there are also faults that would prevent the service to become AVAILABLE when the technical state would be switched to ONLINE.”

This appears perfectly reasonable to me, although it is then followed immediately by:
“Pre-condition: Subsystem technical state The subsystem is in technical state ONLINE or READY.”

This appears to imply, to me, that the report service health is only applicable to the ONLINE or READY technical state, even though the para above suggests it would be of use in the STANDBY state!

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The Exchange Heartbeat use case supports assurance cases relating to runtime software integrity, in particular that critical functionality continues to be available and has not failed silently.
For the DDS PSM this is currently mapped to the built-in DDS API, but the on_requested_deadline_missed requires a suitable topic definition (which could/should be provided by the Exchange Heartbeat use case).

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Within Subsystem_Control.idl the struct service_health_type (line 327) has the member health_state (line 330) declared with type health_state_reason_type. The specification states it should be health_state_type. Believe this is an error?

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

These attributes are important for enabling a sensor to processing specific to the actual category of object that it is tracking.

Raise issue in OARIS 2.1 RTF

This is an OARIS Issue, raised in the wrong task force issues list.
This has been raised as an issue in OARIS 2.1 - see https://issues.omg.org/browse/OARIS21-60