I found a defect in the way that IDL files have the keys generated for parameters that are on service interfaces. As a result I fixed the parameter generation so that all parameters that are marked as keys in the XMI are now marked as keys in the IDL. When comparing the output to 3.0 to find the affected services I also noticed that some parameters had been marked as a key in the model incorrectly i.e. The IDL was correct without them being a key. The list of issues is as follows:
Provide_Subsystem_Services.idl - receive_implemented_services missing a key for parameter the_request_id
Perform_Offline_Test.idl - receive_detailed_test_results has a key defined for offline_test_detailed_results that should not be present
Perform_Offline_Test.idl - perform_tests has a key defined for test_name that should not be present
Filter_Tracks.idl - report_track_filter missing a key for parameter filter_id
Filter_Tracks.idl - track_filter_removed missing a key for parameter filter_id
Filter_Plots.idl - report_plot_filter missing a key for parameter filter_id
Filter_Plots.idl - plot_filter_removed missing a key for parameter filter_id
Define_Test_Target_Scenario.idl - read_test_target_scenario has a key defined for test_target_scenario_id that should not be present
Allocate_Tracks_To_Stream.idl - Add_Track_To_Stream has a key defined for Stream_Id that should not be present
Allocate_Tracks_To_Stream.idl - Remove_Track_From_Stream has a key defined for Stream_Id that should not be present
Allocate_Tracks_To_Stream.idl - Add_All_Tracks_To_Stream has a key defined for Stream_Id that should not be present
Allocate_Tracks_To_Stream.idl - Remove_All_Tracks_From_Stream has a key defined for Stream_Id that should not be present

In the DDS PSM IDL the end_sensor_track_type has a key on subsystem_id. As each message is related to a particular track id then it should also be keyed on the_sensor_track_id such that subsequent instances relating to other tracks do not overwrite the current instance before it is able to be read by subscribers.

Currently the specification implies that the manage subsystem parameters service is used to be able to provide a list of encyclopaedic data alongside other subsystem parameters. It might be a nice separation of concerns if the encyclopaedic data service provided a dedicated means for subsystems to advertise data sets that they are prepared to import and export

It would be desirable for the services to support data export as well such that any encyclopaedic data that had been tailored by a user could then be exported for use on other systems or to be archived for later reloading after events such as a system reinstallation.

Some encyclopaedic data sets can be quite large and therefore giving a subsystem the ability to report progress updates to the CMS such that a user can be kept informed could be beneficial

The IDL4 language introduced the @optonal annotation that indicates that a structure member is optional. This is also supported by DDS-XTYPES. For example:

// radians per second
typedef double azimuth_rate_type;
// radians per second
typedef double elevation_rate_type;
// meters per second
typedef double range_rate_type;

struct polar_velocity_type            {
    // The rate of change in azimuth corresponding to the velocity
    azimuth_rate_type azimuth_rate;
    // The rate of change in elevation corresponding to the velocity. 
    // Optional as some sensors provide no elevation information
    @optional elevation_rate_type elevation_rate;
    // The rate of change in range corresponding to the velocity. 
    // Optional as some sensors provide no range information
    // (e.g. most passive sensors)
    @optional range_rate_type range_rate;
};

The OARIS IDL does not take advantage of this. Instead, it uses an older pre-IDL4 idiom using an extra "union" type. For example:

// radians per second
typedef double azimuth_rate_type;
// radians per second
typedef double elevation_rate_type;
// meters per second
typedef double range_rate_type;

// a simple union type, to represent an optional value
union polar_velocity_elevation_rate_type switch (boolean)       {
    // the value when present
    case TRUE : elevation_rate_type value;
};

// a simple union type, to represent an optional value
union polar_velocity_range_rate_type switch (boolean)            {
    // the value when present
    case TRUE : range_rate_type value;
};

// Velocity defined in a polar reference frame as a described by a coordinate
// specification object
struct polar_velocity_type            {
    // The rate of change in azimuth corresponding to the velocity
    azimuth_rate_type azimuth_rate;
    // The rate of change in elevation corresponding to the velocity. 
    // Optional as some sensors provide no elevation information
    polar_velocity_elevation_rate_type elevation_rate;
    // The rate of change in range corresponding to the velocity. 
    // Optional as some sensors provide no range information
    // (e.g. most passive sensors)
    polar_velocity_range_rate_type range_rate;
};

The extra union types result in more code generated to serialize and deserialize the data, increasing the size of the binary and decreasing performance.

Moreover, the use of the @optional annotation allows for a more natural and optimized language mapping. For example, the recent IDL to C++ mapping maps optional members to the standard std::optional which is more natural for a C++ programmer.

Some of the IDL files contain the construct:

#pragma keylist ...

This annotation is specific to OpenSplice. It comes from a time before there was a standardized way to indicate DDS keys. It is not standard not supported by other DDS vendors.

With the adoption of DDS-XTYPES and later IDL4 there is now a standard @key annotation supported by the recent versions of DDS from all the vendors.

Moreover, the maintainers of OpenSplice are now focused on a new codebase (Cyclone DDS) and recommending users to migrate to it (see
https://github.com/ADLINK-IST/opensplice), and Cyclone DDS also supports the @key annotation as described in https://cyclonedds.io/content/guides/supported-idl.html.

Given all this, the #pragma keylist annotation should be removed.

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