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.

Issues with spec:
OARIS/1.1/PDF, formal/20-08-03

Ambiguous PIM/PSM definition:
Figure 7-41: Track Reporting - Sensor Track (Logical diagram)
Does not include in the sensor_track_type class:
org::omg::c4i::Domain_Model::Common_Types::subsystem_id_type subsystem_id;

Table 7-110: Attributes of IDLStruct sensor_track_type
Does not include :
org::omg::c4i::Domain_Model::Common_Types::subsystem_id_type subsystem_id;

track_phase track_phase_type Track phase (e.g. TRACKED, DELETED, LOST)
DELETED has been removed, but the enumerate renamed NOT_USED

Table 7-111: Attributes of IDLEnum track_phase_type
«idlEnum» DELETED Track has been deleted.
Should be:
«idlEnum» NOT_USED Note: Delete enumeration not used for DDS; dispose topic instance instead.

Duplicate of two separate issues

The issues raised duplicate the contents of two issue raised separately subsequently