...

...

to be elaborated ...

Perform Offline test should be compliance level 3A not 3B

There are two activities "Define Test Target Scenario" & "Control Test Target Facility" for one interface

An important aspect of sensor performance estimation is to understand bias particularly for atmospheric effects.

This is a useful mode of operation ...

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

.

The class plot_summary_type was expected to be a topic type, but it isn’t mapped to an operation in the PIM – so it isn’t. We need to add a suitable operation to the Provide_Plots or Provide_Sensor_Orientation interface.

The PSM section of the document was omitted from the submission and should be re-instated

The notes field for the ONLINE state in the Technical State state machine has a typo - viathe. The notes field has other subtle differences in comparison to the corresponding enumeration attribute.

The interaction diagrams for the Control_Emissions service do not provide a mechanism for determining the initial state of the emission control setting.
Possibilities are that the CMS is expected to explicitly set this for all sensors as part of startup of each sensor (e.g. whilst they are in the READY state) or that each sensor has its own default (or persistent) state that it assumes on each startup.
Further information: The description of the ONLINE technical state, requires Control Emissions to occur once the subsystem is in this state and implies that the emission control setting is off when the subsystem enters the ONLINE state.
More information: The description of the Control_Emissions_CMS interface states: "It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem." However there is no method on the subsystem interface to provide this information.
The description of Control_Emissions_CMS interface should be updated accordingly.

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?

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

delete_sensor_track is used as an interface in the Tracking_Control service and as a method on the Provide_Sensor_Tracks interface. This is potentially confusing and in principle could cause name clashes.

The copyright holders shown at the beginning of the document should include not only the original submitters but also the members of all the subsequent FTFs/RTFs. It seems this list has not been maintained as the following companies are missing:

General Dynamics, Northrop Grumman, SimVentions, Microfocus, Real-Time Innovations,

(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!

The DDS topic types for PIM operations acquire_mastership and release_mastership are both missing from the IDL. Additionally request_id is a missing parameter from these operations, as otherwise the receive_acknowledgement operations in the sequence diagrams have an undefined source of request_id.

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).

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.

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.

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

The IDL files have the wrong interface version in them at the top of the file.

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.

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.

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

METOC RFP (c4i/08-12-02) is referenced in dtc/22-06-03 but does not yet exist on the OMG site in any form.

The following is the description of request_id in oaris 2.0 spec:

7.3.12.6 request_id_type
Type: IDLTypeDef unsigned long long
Package: Requests
The purpose of the request_id is to uniquely relate responses of the subsystem (server) to requests of the CMS (client). The request_id is set by the client. It is the responsibility of the client to specify a system-wide unique request_id (e.g. based on a combination of client id and a sequence number / time of request). Here it indicates that CMS as client should specify request_id. But in section 7.7.5.3 Provide_Subsystem_Identification, it documents that it should be the subsystem to initiate the communication to CMS, which implies subsystem will need to specify request_id required in receive_sub_identification_data_type before sending it to CMS.

The description of the interface states that
"It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."
However, there is no operation defined to request information from the subsystem.
(Note: the protocol was probably simplified in working towards the v1.0 submission without revising the overall description of this particular interface).

The description of the interface states that
"It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."
However, there is no operation defined to request information from the subsystem.
(Note: the protocol was probably simplified in working towards the v1.0 submission without revising the overall description of this particular interface).

The description of the interface states that
"It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."
However, there is no operation defined to request information from the subsystem.
(Note: the protocol was probably simplified in working towards the v1.0 submission without revising the overall description of this particular interface).

There are track_priority_type typedefs defined in both the Track_Reporting and Tracking_Control Domain Model packages.

These findings target the OARIS 2.0 Initial Submission.

Replace unque by unique :
Fig. 7.40 association from measurement_element_match_type to measurement_element_type

1..*

Unknown macro: {set is unque for each instance}

Replace activtiy by activity
in Figures 7.41, 7.44, 7.54 association from platform_type to platform_activity_type

Replace discete by discrete :
Table 7.115 2nd row 2nd column (Notes)

The semantics of the ordering of the elements of the
discete distribution

Replace transmision_mode by transmission_mode :
Table 7.145 last row first column (Attribute)
Figure 7.50 «idlStruct» transmission_sector_type last attribute

Replace perfomance_bin_type by performance_bin_type :
Figure 7.51 «idlStruct» perfomance_bin_type
7.5.8.5 perfomance_bin_type
Table 7.157 Attributes of IDLStruct perfomance_bin_type

Replace initation by initiation :
Table 7.1642nd row 2nd column (Notes)

Track initation on external request (e.g. from CMS)

Replace initiatied by initiated :
Table 7.165 continuation (page 144) 2nd row 2nd column (Notes)

initiation_mode initiation_mode_type [0..1] Initiation mode of track (automatic or externally
initiatied)

Replace configuraiton_url} by {{configuration_url :
page 159 bottom table Method change_physical_configuration Parameters

request_id_type request_id
configuration_url_type
configuraiton_url

Replace acccepted by accepted :
Figure 7.95 note at bottom right

request_ack.acccepted
= true

Replace metod by method :
Page 197 top table Method battle_override_setting Notes

This metod is used by the subsystem

Replace Altenative by Alternative :
Table 7.103 sequence diagram box label in upper left corner

alt Altenative Flows

Replace plot_concentratrion by plot_concentration :
Section 7.8.1.1 first table Method receive_plot_concentration() Parameters

request_id_type request_id
plot_concentration_report_type
plot_concentratrion

Replace subystem by subsystem :
Section 7.8.1.2 first table Method receive_periodic_clutter_assessment Notes

Interface used by CMS to receive
periodic clutter assessment reports
from the subystem.

Replace Ammendment by Amendment :
Figure 7.117 loop

[Ammendment Required]

Replace authorative by authoritative :
Page 226 bottom table every row of column Notes

The CMS [de]selects [...] match[es] as being the
authorative assessment for the sensor track

Replace masterhip by mastership :
Figure 7.143 Alternative Flow [...] loss of masterhip
Figure 7.145 Alternative Flow [...] loss of masterhip

Replace Susbystem by Subsystem :
Figure 7.153 alt Unsuccessful Request

[Susbystem unable to calculate requested nominal performance]

Replace encouters by encounters :
Figure 7.155 alt Unsuccessful Request

[Subsystem encouters an irrecoverable error condition [...]

Replace Ackowledgement by Acknowledgement :
Figure 7.157 alt Negative Acknowledgement

[Subsystem processing produces [...] after initial positive Ackowledgement]

Replace succesfull by succesfully :
Figure 7.171 sequence diagram inner box label

opt target succesfull acquired

Replace fulfil by fulfill (American English) :
7.9.3.1 page 278 2nd-to-last sentence on page

If the radar may not fulfil the illumination request, [...]

7.9.3.3 middle of page 284 standalone sentence

If the radar may not fulfil the uplink request, this is reported [...]

Globally replace splotting by spotting :

• Page 286 confirm_reposition_splash_splotting, receive_splash_splotting_area_position, receive_splash_splotting_area_track
• Page 288 receive_splash_splotting_area_position
• Page 289 confirm_reposition_splash_splotting_area, receive_splash_splotting_area_track
• Page 290 Figure 7.184 Perform Splash Spotting - Report On Splash Splotting