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