The multiplicity for the association between a sensor_track_type class and a sensor_plot_type class is 1..* (one to many) in the model. This doesn't allow for tracks that aren't based on plots (explicitly or implicitly). A zero to many relationship would allow for this and correspondingly offer more flexibility to implementations without unduly compromising rigour.

Change multiplicity for based_on to zero to many

Change the multiplicity for the "based_on" role for association from sensor_track_type to sensor_plot_type to be "0 .. *".
Note that this change doesn't impact the corresponding IDL for the DDS PSM. This is because the lower bound isn't modelled; in both cases it is mapped to a bounded sequence (length 256) according to the role tag in the model (Length = 256).

IDLStruct sensor_track_type does not have notes for all attributes. "* optional *" is applied to only some of the optional attributes.

Add Notes to IDLStruct sensor_track_type

Add notes where missing and remove or replace the "* optional *" markers as these are redundant due to the multiplicity being stated as [0..1]

IDLStruct cued_search_report_type is defined as an optional sensor track id. However sequence diagrams for the Perform Cued Search use case have notes that expect a possibly zero length list of track ids to be returned.

Update diagrams to refer to an optional sensor track id

It is not clear that returning a list of track ids is desirable. In particular it is not clear in general that a sensor would be aware as to when the list was complete.
Therefore the interface method should stay the same but the behavioural model should allow for multiple responses. Subsystems may only implement sending a single response; CMS components may choose to process just the first or each one (and possibly overwrite).

The TrackID parameter of method dedesignate_target has type fire_control_channel_id_type. This is inconsistent. Particularly given it is possible to designate by position rather than by track the name should be FireControlChannelID to match methods receive_target_acquired and receive_fire_control_channel_released.
Actually the name of the receive_target_acquired parameter should be changed from FireControlChannel to FireControlChannelID for consistency too.

Correct Target Designation Parameter Names

In the Process_Target_Designation use case change the parameter names for consistency.

Sequence diagram artefacts such as InteractionOccurrence and ActivityPartition have generated documentation sections as if they were classes in some subsections.
These are supposed to be suppressed by the documentation generation process

Remove sequence diagram artefact subsections

Auto-generated subsections relating to model entity artefacts from sequence diagrams should be removed

There is a leading backslash in the Engagement Support section

Remove typo from Engagement Support heading

remove backslash typo

The process target designation use case in Engagement Support contains a specific error message. This should be deleted as the general use cases method raise_error is used in the interaction diagram. Using the general method is consistent with the design intent and the approach in the other OARIS use cases. (This reflects a failure to apply a design change/improvement consistently by the original submission team).

Remove specific error method

Remove method receive_target_designation_error

The specification shows Register Interest as a prepcondition to doing anything (e.g. figure 7.2). 7.8.5.1 Provide_Sensor_Tracks contradicts this by saying that either Register Interest or Provide Subsystem Services are required. However in at least one real world system using this standard, sensor tracks are successfully received without either of these. The standard should reflect the defacto use and remove registration from cases where it is not requried.

Map Register Interest and Provide Subsystem Services to DDS Discovery

These use cases are implemented by the built-in DDS discovery mechanisms when the DDS PSM is used

Everyting in the IDL has a redundant and innacurate "Version 1.0" attached to it. Many types have documentation that is meaningless, e.g.

            // a simple union type, to represent an optional value
            union sensor_track_position_accuracy_type switch (boolean)

Maintain version number in IDL files and add DDS PSM

Update IDL file template so that the version number reflects the version number of the OARIS standard. (I.e. Version 1.1 as a result of this RTF). This will provide direct trace and is easily achieved as the IDL is generated from the UML model.

The OARIS Specification lacks specific sections for PSM. For other standards there would be a Section 8 describing the DDS PSM and then referring to the IDL files.

"The type of the recognition_type is ‘short.’ This short number is mapped to a recognition_type. " manages to be wrong (it's an unsigned short) while carrying no useful information.

Expand on and correct notes for recognition type

Reflect that the type is unsigned short. Explain that a recognition type is an abstraction for a system or implementation specific taxonomy for the kind of tactical object detected by the track.

A sensor track should carry the identity of the sensor it originates from. Forcing out of band mechanisms (e.g. partition names in the DDS PSM) to be used adds to the complexity of solutions, especially for use cases such as logging where we don't neecssarily care where it came from as long as we know. A compound key would allow all present use cases of filtering etc to be supported.
The situation is particularly confusing for bearing tracks, where the standard apparently requires us to define a bearing with no means of defining the origin.

Add subsystem id attribute to DDS PSM Topic types

Making the source (or destination) of the data explicit in the application payload for DDS makes sense, does not put an unreasonable burden on implementations, can be done with minimal change to existing implementations and is clearly beneficial for the purposes of recording and analysis.
OARIS v1.0 continued to define subsystem_id_type (unsigned short) in package Common_Types, although it is unused by the specification. Its semantics remain applicable for this change proposal.
All DDS Topic types should have a key attribute subsystem_id of subsystem_id_type added. The Subsystem sets it to zero in the receive_sub_identification_data topic and is allocated a value to use in the receive_cms_identification_data response. Note that to disambiguate the multiple subsystems case, the CMS response must be published in a subsystem specific partition.
However, the use of partitions is useful for filtering at a data reader and provides a more robust mechanism for ensuring data is from the subsystem that it labelled as belonging to. Therefore, the partition convention employed in some existing implementations should be formalised within the (new) DDS PSM section.

The name suggests something like degrees latitude per second, degrees longitude per second; probably a usable unit but not one I have ever come across. It was certainly not where I looked when looking for course and speed. I did look at polar_velocity_type, found it was wrong and used cartesian intead, which was not what my subscriber was expecting.

Admittedly it is obvious once one finally drills down to the definiton of wgs84_velocity_type, but experience shows that at least this developer did not search that far.

Add further explanation to velocity_coordinate_type

Explain the nature and purpose of the 3 velocity variants. Add explanation to wgs84_velocity_type that reports velocity from the viewpoint of the object in terms of course and speed with optional angle of climb for changes in height.

It could be speed over ground or speed along direction of travel; with a steep angle of climb the two might be significantly different.

Add notes to the course and speed attributes

Clarify that course is relative to North on the WGS84 spheroid and that speed is the total speed within the spheroid in the direction of travel accounting for angle of climb.

The intended use Cartesian only full covariance classes and accuracy classes for each of the coordinate systems has caused some confusion amongst users of the specification. The intent needs to be more clearly described and explained.

Explain that covariance should be used as an alternative to accuracy values

Some sensors are able to provide a covariance matrix to describe uncertainty in position and velocity calculation as part of their processing. For other sensors accuracy values for each (or perhaps the only) measured quantity are more appropriate.
When constructing a sensor_track_type instance subsystems should use either one strategy or the other. This should be clearly specified in the notes for the covariance matrix, position and velocity accuracy attributes,.

The search use case allows a CMS to instruct a radar subsystem to search a volume of space. This could be used to cue the radar to an existing track. However, it maybe more natural to do this by reference to another sensor track (for instance the radar then has the opportunity to subscribe to updates to the existing track directly to assist in its search).

Add a cue to track method

Add a cue to track method to the search use case that cues by reference to another OARIS sensor track instance rather than to a volume relative to the sensor.

The notes for coordinate_specification_type refer to a NEGOTIATED attribute that does not exist in the relevant enumeration classes.

Remove Reference to NEGOTIATED in Notes

Remove NEGOTIATED text and description from notes. The attribute was deleted by the submitters prior to the final submission, but the notes were not properly cleaned up.

Particularly when reporting bearings from an off-board or otherwise mobile sensor it would be more convenient, natural and precise to report the bearing origin as part of the report rather than referring implicitly to some otherwise well-known origin as the spec currently states (e.g. by reference to another track).

Add Support for Explicit Origin Reference for Bearings

Extend coordinate_origin_type to include an Explicitly Specified enumeration. Add an optional WGS84 origin attribute to polar_position_type and polar_position_accuracy_type. It is only useful to explicitly specify the origin in an absolute coordinate system, if in a relative system the ultimate question of coordinate origin is still unresolved and must rely on implicit information.

When using the DDS PSM the meaning of a topic dispose is sometimes unclear, particularly in the case of a sensor track report as this has a delete/cancel attribute inherited from the PIM.

Remove cancel track attribute from DDS PSM

The DDS PSM in general maps PIM concepts to native DDS mechanisms wherever appropriate. This principle should be applied here and the cancel attribute for IDL struct sensor_track_type omitted from the DDS PSM. However, the enum ordering / positioning should be unaffected so as to maintain compatibility with other potential PSMs.

The classes latitude_coordinate_type and longitude_coordinate_type in Coordinates_and_Positions have a Unit tag = rad (for radians) and a Range from -pi/2 .. pi/2 and -pi .. pi respectively.
The notes for the class state degrees however.

Change Class Tags to be degrees

Change the tags for classes latitude_coordinate_type and longitude_coordinate_type to be the equivalent for degrees as opposed to radians.
This is consistent with implementations and the original submitters intent.

There is an additional_information in the track_reporting use case whilst there is an (abbreviated) additional_info attribute in plot_reporting.

It also appear as additional_information in tracking_control

Change name additional_info attribute name in sensor_plot_type

Change the name of Attribute additional_info in Class sensor_plot_type to additional_information. Update class diagram for sensor plot reporting, the attributes table and the reference in the descriptive text for the class.
This will also result in a corresponding change to the IDL for the DDS PSM.

It has been found that neither of these class names suggest that they contain course and speed as components. Therefore when wishing to report in terms of course and speed a developer failed (initially) to find the correct data structure.

Add WGS84 velocity explanations

This is a duplicate of previously raised issue (same source - different route).