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

Include STANDBY as precondition to Provide_Health_State_CMS

Include STANDBY as precondition to Provide_Health_State_CMS

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?

service_health_type struct is correct in 3.0 beta

service_health_type struct is correct in 3.0 beta and the health_state attribute has been changed to type health_state_type already.

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,

Copyright holders already updated for 3.0 beta

Copyright holders already updated for 3.0 beta

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

Version has been removed from IDL files in later submissions

Version has been removed from IDL files in later submissions

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

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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

OARIS 3.0 beta has already addressed this

OARIS 3.0 beta has already addressed this by creating a common definition which is then used in specific unions elsewhere

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

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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.

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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.

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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.

Fixed in OARIS 3.0

Relationship has been changed through a plot association type and so this issue is no longer valid.

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.

Reference was removed from 3.0 beta

The missing reference was already removed from 3.0 beta submission

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.

Add functions to provide health reporting on subsystem initiative

Add functions to provide health reporting on subsystem initiative - i.e. the same as those requested by the CMS but without the 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).

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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

Make azimuth optional on the polar velocity type

Make azimuth_rate optional on the polar velocity type to allow for sensor which report bearing only tracks

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

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

...

Issue not present in 3.0 beta

The issue reported in 2.0 does not appear to be present in 3.0 beta

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.

Rename delete_sensor_track method to end_sensor_track

Rename the delete_sensor_track method in the Provide_Sensor_Tracks_CMS interface to end_sensor_track

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

Move Perform Offline Test to compliance level 3A

Move Perform Offline Test to compliance level 3A. Text and associated diagrams

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.

Acquire mastership already present in 3.0 IDL

This problem was already fixed in 3.0 beta

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

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

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

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

.

Remove suggested items from additional_information description

Remove suggested items from additional_information description that are already present as attributes on the type:
priority
identification

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

Change description of technical_state_type

Change description of technical_state_type to IDLEnum

This is a useful mode of operation ...

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

to be elaborated ...

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

...

Change types from activity to action

types used in the activity diagrams are all activity rather than action which would be preferred in current UML.

For example CORBA, ALMAS & AMSM

Normative References were already updated at 3.0 beta

Normative References were already updated at 3.0 beta with CORBA, ALMAS and AMSM not present

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.

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

The sensor orientation message reports the orientation of the sensor with two angles: azimuth and elevation. But to completely describe orientation, three angles are required. The missing angle is a rotation about the normal from the array. It can becalled a clocking angle. Using azimuth and elevation correspond to Cardan angles, which describe orientation as heading, elevation, and bank. The missing angle in this system is the bank angle. See https://en.wikipedia.org/wiki/Euler_angles

Add bank angle to sensor_orientation_type

Create a new type for bank angle and add to the sensor_orientation_type class.

Searches can potentially take a long time, there is no message/interaction to stop one once its in progress. Suggest adding a stop_cued_search as with stop_surveillance.

Add stop_cued_search operation to Perform_Cued_Search_Sub interface

Add stop_cued_search operation to Perform_Cued_Search_Sub interface. Update the table describing the operation and the sequence diagram to show usage.

The sensor orientation message reports the orientation of the sensor relative to a specified coordinate system. However, if a radar has multiple sensors there is no way to distinguish between them. I suggest adding an optional sensor_id field (type short) to distinguish between multiple sensors.

Add optional sensor_id to sensor_orientation_type

Add optional sensor_id to sensor_orientation_type of type short

Range rate type limited to 0-1e5, this should also accept negative values for closing rates. Also an issue in version 3 beta.

Modify range to allow negative

Change the range on range_rate_type to be -1 e5 .. 1 e5

range_rate_type is used to quantify the rate of change of the range. The range of allowed values is 0.0 to 1e5, but this is too restrictive. Range rate is negative when an object is getting closer to the origin, i.e. the range is decreasing so range rate is negative. The lower bound of range rate should be -1e5, the negative of the maximum value.

Fixed by duplicate issue OARIS3-23

Fixed by duplicate issue OARIS3-23

The specification and Sensor_Assessment.idl have multiple misspellings of "equipment" as "equipement". All of the misspellings are in types and structs related to sensor_plot_equipement_assessment.

Update diagram 7.158 to correct spelling

Update diagram 7.158 to correct spelling

system_track_type does not contain identity or classification

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

These tags are meaningless in the specification.

Remove ea_guid tags from the model

Remove ea_guid tags from methods in the model

The description of the NORTH_DOWN in coordinate_orientation_type says:

Valid for Polar Coordinate Kind
Azimuth has origin (0.0) at North, clockwise positive, measured in the horizontal plane
Elevation has origin (0.0) when pointing directly down, and 180.0 degrees when pointing directly up, measured in the vertical plane.

This would be fine except the elevation_coordinate_type specifically says units are radians with values from -PI/2 to +PI/2.

I suggest changing the maximum value of elevation in the description of NORTH_DOWN from 180.0 degrees to PI radians and change the maximum value of elevation_coordinate_type from +PI/2 to +PI.

Change NORTH_DOWN descriptive text and elevation_coordinate_type max limit

Change the maximum value of elevation in the description of NORTH_DOWN from 180.0 degrees to PI radians and change the maximum value of elevation_coordinate_type from +PI/2 to +PI.

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.

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

The OARIS 2.0 specification says registration includes information on:

• The service for which the actor wants to register / deregister his interest
• The information within the service for which the actor wants to register / deregister his interest
• The intended (direct or indirect) recipient(s) of the information provided by the subsystem
• Any parameters of the provision needed such as Quality of Service parameters

But according to the IDL, register_interest_type contains a sequence of interest_type, which contains only the registration type (REGISTER or DEREGISTER), the recipent, and quality of service. The message has no way to specify a service or information within a service; the first two bullet points in the requirements above.

Defer to 3.1 RTF

This issue was raised against OARIS 2.0 and transferred into the OARIS 3.0 FTF very recently and after the comment deadline. In order to not delay the OARIS 3.0 FTF it is proposed to defer this issue for resolution in OARIS 3.1 which will be chartered at the successful conclusion of this FTF.

The specification and the file Perform_Splash_Spotting.idl have multiple misspellings of spotting as "splotting". For example, confirm_reposition_splash_splotting_area, receive_splash_splotting_area_position, receive_splash_splotting_area_track.

Correct instances of splotting

Correct instances of splotting to spotting

The acquire and release mastership messages have only a "count" field. There is no way for the radar to determine which system is requesting or releasing mastership. The radar needs to know the identity of the master when reporting mastership. Suggest adding a subsystem ID to acquire and release mastership messages.

Issue is duplicated by OARIS3-19

Issue is duplicated (in part) by OARIS3-19. The resolution for OARIS 3-19 will resolve this issue.

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.

fix the typo in the notes for the ONLINE state

Fix the typo in the model. This does not affect the generated specification as the diagram and text is not present in the specification document

Can this please be checked. Looking at OARIS v1.1 changebar this documents the changes from v1.0 to v1.1. The changebar document published on v2.0 should therefore be the changes from v1.1 to v2.0. The document published shows the changes from version v2.0 to v3 beta 1

Not an OARIS 3.0 FTF Issue

Not an OARIS 3.0 FTF Issue

The sequence diagrams for Mastership Acquisition and Mastership Release show receive_acknowledgement and receive_error in response to acquire_mastership and release_mastership. However, acquire and release have no request_id to respond to. Recommend adding request_id and subsystem_id keys to acquire and release mastership.

Add subsystem and request parameters to acquire and release mastership

Add subsystem and request parameters to acquire and release mastership. Update the four sequence diagrams and table descriptions for the methods.

Section 8.2 mandates how topics and partitions should be used to include different subsystems into an OARIS based system.

However the approach mandated is not the only approach and other approaches may be used and be more suitable for a given use case. This section should be re-written to provide some guidance examples rather than mandates

Reword section 8.2

Reword section 8.2 to give guidance to a system integrator rather than mandate a particular approach.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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,

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

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.

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

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.

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

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.

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

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.

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

There are 26 #Table# markers remaining in the specification document.
These need to be replaced with their proper numbers and subsequent tables renumbered.

Resolve Table number placeholders and renumber

Each of the 26 #Table# placeholders for table numbers in the specification document should be resolved to its proper sequential number (or omitted in the cases where there is no table) and subsequent tables renumbered accordingly.
Also remove heading for non-existent tables (e.g. for typedefs which have no attributes).

The GraphQL mapping in the specification and defined in the schema files leads to an unnecessarily complicated implementation of the standard and should be simplified

Regenerate GraphQL PSM with updated mapping

The updated mappings from PIM to GraphQL as incorporated into the TDAI beta spec and C2INav v1.1 RTF should be used. This generates a single schema for each standard avoiding class duplication, has a flatter structure with respect to endpoint methods, has less duplication with respect to input types and uses a simpler mapping with less duplication for inheritance (consistent with that also now used for DDS/IDL - see OARIS2-27). The proposed schema file is attached.

Heartbeat_Signal.idl has been removed from the distribution. Searching for receive_subsystem_heartbeat_signal and receive_cms_heartbeat_signal in the IDL returns no entries. The interface can’t be found.

Exchange Heartbeat is documented as a Compliance Level 2 interface in the IFS. It is documented at section 7.7.5.2. It can only be concluded therefore that the Heartbeat_Signal.idl file has been omitted by mistake.

It is noted that the documentation omits subsystem_id as per the other interfaces. This is an error?

Document omission of Heartbeat Signal as in-built in DDS PSM

In section 8.2 describe how Heartbeat Signal is also mapped to DDS in-built API methods (as well as Register Interest, already documented).

plot_count field of concentration_plot_cell_type is defined as unsigned long long 64-bit type, which causes issues with implementation languages and machine base type representation on 64-bit machines.
Is it viable for a count of the number of plots in this clutter reporting context to exceed 2**32 (4 billion)? Would unsigned long be sufficient, hence making implementation more machine-friendly?

Change type of plot_count attribute

The plot_count attribute in struct concentration_plot_cell_type should be an unsigned long (rather than unsigned long long). This has more than sufficient range of values for any application of the clutter reporting use case.

The Plot Reporting Use Case is confusing. For OARIS 1.1, the actual Plot structure was abstracted into a sub-type write_sensor_plot_type defined in Provide_Plots.idl. In OARIS 2.0, the IDL file Provide_Plots.idl has been removed, with the interface effectively reverting back to the OARIS 1.0 version with sensor_plot_type defined in Plot_Reporting.idl. Is this intentional or was an incorrect baseline used for creating OARIS 2.0? This may also explain why subsystem_id is also missing as per sensor_track_type.

Flattened Structure Is Intentional

This change is a consequence of applying the principal of flattening PIM methods with a single parameter consistently throughout the whole model when mapping to the DDS/IDL PSM (and also GraphQL).

The topic type for Plots should have been flattened in the same way as that for Tracks in v1.1. This has now been done for v2.0.

The mapping of specialisations duplicates the location of common attributes from the generalisation class into each option of the union. This is inconvenient for the software design of applications using the types.

Use a rationalised DDS/IDL inheritance mapping.

Update the mapping of generalization / specialization inheritance so that attributes of the generalization class are encapsulated into a base class, which then appears as an attributes of each specialization rather than each of the generalization attributes individually.
Also the generated enumeration values are missing the name of the generalization class in their IDL documentation comment.

The impacted IDL files are attached as per the proposed update.

The following attributes are not correctly linked in the XMI file
In class system_track_type: system_track_number, time_of_information
In class fault_type: event
In class service_health_type: health_state, health_state_reason
In class subsystem_health_type: health_state, health_state_reason
In class downlink_request_type: own_missile_track_id
In class uplink_report_type: own_missile_track_id
In class uplink_request_type: own_missile_track_id

(They are linked to an implicitly created Java datatype by the EA tool)

Fix linkage in the master EA file

For each attribute link the type to the actual class in the model rather than free text.

Text such as
"MethodTag: ea_guid =

"
appears in some tables in the specification.
These should not be there

Remove MethodTag markers in the specification document

Remove all instance of "MethodTag: ea_guid =

" from the tables describing methods

The identifier sensor_plot_equipement_assessment_type has a typo (extra E in equipment) in all places that it is mentioned in the document.

Fix typo in sensor_plot_equipement_assessment_type

Remove the additional 'e' from the name of the type in the model and regenerate all artefacts.

The PSM generation rules lead to a duplicate class name of performance_assessment_request_type in packages for the Sensor Performance use cases (one in domain model and one in the service model). This is undesirable and may lead to confusion and/or erroneous usage of the spec.

Rename performance_assessment_request_type

The class performance_assessment_request_type in the Sensor_Performance (Domain Model) package should be renamed to performance_assessment_parameters_type. This is arguably a better name and disambiguates in the generated PSMs.
Additionally, operations sim_mode_status in Control_Simulation clashes with a Domain Model class in the PSM and operations complete in Perform_Illumination & Perform_Missile_Downlink clash in the generated PSMs. These should be renamed to be more consistent and coherent:

• sim_mode_status to report_sim_mode_status
• complete to report_illumination_completed & report_uplink_completed respectively

The Provide Sensor Orientation use case would be more useful if there was a possibility to provide an origin for the sensor. In particular, it could be used in cases where the sensor is mobile with respect to the physical platform on which it is situated; particular to communicate field of view.
Equally optional coverage in azimuth and elevation would be useful.

Add optional origin and field of view to sensor orientation

To sensor_orientation_type:

• add an optional origin of position_coordinate_type
• add an optional azimuth_coverage of azimuth_interval_type
• add an optional elevation_coverage of elevation_interval_type
• add an optional origin_coordinate_specification of coordinate_specification_type

In the DDS/IDL PSM there is a circular dependency between the Track_Reporting and Sensor_Assessment packages in Sensor_Domain. This is because the by reference association to assessment types contain an assessment_objective_id_type which is defined in the Assessment package.
References in the other direction are intentional.

Move assessment_objective_id_type to Track Reporting

Typedef assessment_objective_id_type should be moved to the Track_Reporting package to resolve the circular dependency.

There is an erroneous attribute "long _id;" in struct concentration_plot_cell_type in Clutter_Reporting.idl

This is a PSM specific issue.

Correct aggregations in the Clutter Reporting domain model

Correct composition of clutter_map_cell_type by clutter_report_type so that it is navigable only from latter to former.

Correct composition of concentration_plot_cell_type by plot_concentration_report_type so that it is navigable only from latter to former.

The diagram files exported from Enterprise Architect for this FTF are in PNG format. These don't scale well as noted in AB review comments.

Export diagrams in SVG format

All the diagrams changed by the FTF should be exported in SVG and saved in a zip file alongside the PNG file that they replaced, so that the OMG editor can use these files to create the specification file for publication.

The enumerator DELETED has been reinstated back in track_phase_type. This does question why the enumerator was renamed NOT_USED in version 1.1, in preference for the use of topic delete. Actually, having reinstated DELETED back in the IDL over using topic delete is a benefit since it makes track lifecycle easier. It is also not clear how INACTIVE assists and how long a track stays in this state before it is LOST. This is not documented but assumed to be sensor specific.

Parameter track_phase_type changed between 1.1 and 2.0. DELETED that was removed in 1.1 is now back!
OARIS 1.1
// The detection lifecycle phase of the track
enum track_phase_type

;

OARIS 2.0
// The detection lifecycle phase of the track
enum track_phase_type

;

Remove DELETED attribute and specific delete operation

The reappearance of the DELETED attribute in the DDS PSM was an error. It was an unintentional consequence of a change of approach to DDS IDL generation.
Having added also added a GraphQL PSM that also has has technology specific convention for deleting data, it makes sense to remove this from the PIM as well. At the PIM level the ability for a sensor to indicate that it has deleted a track is required and should be added. This method would be mapped to DDS API and general GraphQL mapping for the PSMs.
The INACTIVE enumerate was added to the v2.0 proposal for the case of passive sensors where the signal is expected to be intermittent.

I used RTI's DDS tool to transform the OARIS 2.0 beta 1 IDL into C++ and Java and tried to compile it. I got errors involving the enumeration types identity_type in Common_Types.idl and health_state_type in Subsystem_Control.idl. Both have an enumeration literal named UNKNOWN. The generated C++ and Java have these in the same namespace so the code does not compile.

The full error when compiling C++ is below
./Subsystem_Control.h:436:5: error: redeclaration of 'UNKNOWN'
UNKNOWN
^
In file included from ./Subsystem_Control.h:23:0,
from ./Control_Battle_Override.h:24,
from ./Control_Battle_Override.cxx:31:
./Common_Types.h:133:5: note: previous declaration 'org_omg_c4i_Domain_Model_Common_Types_identity_type UNKNOWN'

I'm using rtiddsgen version 5.3.1.14 to transform IDL into C++ and Java. I don't know if this is a problem with the specification or if I need to find a way to transform the IDL into C++ and Java that uses separate namespaces for enumeration types. But I felt someone should know about this anyway.

This was the only issue preventing compilation of the generated C++ and Java. I changed one of the literals to something else and it transformed and built with no errors.

Change health UNKNOWN enum to UNKNOWN_HEALTH

Change to disambiguate the Health enumerate as this does not impact known implementations of the standard. And the values of the Identity enumerate reflect standard usage for identification.

new Optional attributes added to sensor_track_type, to include:
• track_quality
• time_of_first_detection
• time_of_last_detection
• priority
• amplitude
• activity_id
• sensor_function_id
• observed_function_id
• equipment_id
• platform_id
Some appear to be quite low level and applicable to plots rather than tracks. It is also not clear what some of the values are. The last 5 are not documented in the IFS to assist.

Document the mapping of associations in the DDS and GraphQL PSM

All these attributes are optional and whilst not expected to be applicable to (for instance) radar tracks generally, they are applicable (and indeed required) to support the data models of some of the additional sensors scoped by OARIS v2.0 (e.g. EW).
The PSM mapping sections (within section 8) do not discuss the mapping of (by reference) associations. This should be added, which would define the semantics of these attributes in the PSM. (Each of the attributes already has documentation in the PSM in the Beta version).

The parameter subsystem_id has been removed from sensor_track_type. The parameter subsystem_id was added in OARIS 1.1 and provided a few benefits to include ensuring samples being unique since it was used in key. Please can we have it back.

The same issue can be found in sensor_plot_type, perform_cued_search_type and report_cued_search_result_type. Not all interfaces have been checked, but assume the same issue exists elsewhere.

It is assumed that removing subsystem_id is not intentional and in error, since it is documented in the DDS PSM at section 8.2, but does not appear in the PIM in the earlier sections.

Suggest also that subsystem_id_type is changed from unsigned short to unsigned long. This aligns with other UK information models.

Reinstate subsystem_id to PSMs

subsystem_id was omitted from the DDS/IDL PSM mapping in error in the v2.0 proposal (change to PSM generation approach).
This attribute should be added back in to the DDS/IDL PSM files. One keyed attribute per topic type.
Note that the subsystem_id attribute continued to be described as being a key in topic structs in section 8.2.

Request_id_type is defined as unsigned long long 64-bit type, which causes issues with implementation languages and machine base type representation on 64-bit machines.
Uses of request_id_type in several places in the standard are to identify request-response cycles that don't typically operate at high volume or high rate.
So does request_id_type need such a large range? Would unsigned long be sufficient, hence making implementation more machine-friendly?

Change request_id_type to unsigned long

Change the representation of request_id_type to long so that mapping to implementation languages is consistent. (E.g. Java doesn't have unsigned types).
OARIS doesn't have usages of request_id that would exceed a need to generate new/unique values at greater than 1Hz. This supports a system lifetime of nearly 70 years before requiring the negative range.

The subsystem_id has been removed from the perform_cued_search_type and report_cued_search_result_type data types.

For the shape model aspects, a new parameter id of type long has been added to figure_ref_point_type in Shape_Model.idl. This is not documented in the IDL or in the IFS, and the intention is hence not clear.

Remove erroneous _id parameter

A parameter named _id has been generated into the figure_ref_point_type struct. This should be removed. It arises because the aggregation to rectangle_type is navigable both ways. This should be corrected to fix the issue (navigable only from rectangle to figure ref point). This will update diagram 7.29.
There is already an issue to fix/add back subsystem ids generally in the DDS/IDL mapping. This will fix the search topic types as well.