1. OMG Mailing List
  2. OARIS 1.1 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: oaris-rtf
  • Issues Count: 21

Issues Summary

Key Issue Reported Fixed Disposition Status
OARIS11-7 Use of covariance versus accuracy attributes OARIS 1.0 open
OARIS11-6 Cue to another OARIS track OARIS 1.0 open
OARIS11-5 Non existent NEGOTIATED attribute of coordinate specification types OARIS 1.0 open
OARIS11-4 Option for an explicit bearing only track origin OARIS 1.0 open
OARIS11-3 Topic lifecycle semantics for the DDS PSM OARIS 1.0 open
OARIS11-1 Inconsistency in name additional information attribute OARIS 1.0 open
OARIS11-10 Sensor track does not identify the sensor OARIS 1.0 open
OARIS11-9 Documentation embedded in IDL files OARIS 1.0 open
OARIS11-8 Poor documentation of recognition_type OARIS 1.0 open
OARIS11-14 Confusion between polar velocity type and wgs84 velocity type OARIS 1.0 open
OARIS11-2 inconsistency: units of Latitude/Longitude in notes verses tags OARIS 1.0 open
OARIS11-13 wgs84_velocity_type::speed is ambiguous OARIS 1.0 open
OARIS11-12 Name "wgs84_velocity_type" is misleading OARIS 1.0 open
OARIS11-11 Register Interest appers to be redundant OARIS 1.0 open
OARIS11-26 Missing notes from attributes of sensor_track_type OARIS 1.0 open
OARIS11-25 Inconsistent content in cued_search_report_type OARIS 1.0 open
OARIS11-24 Error in dedesignate_target parameter OARIS 1.0 open
OARIS11-23 Erroneous documentation text from sequence diagrams OARIS 1.0 open
OARIS11-22 Typo in Engagement Support OARIS 1.0 open
OARIS11-21 Specific Error Method in Process Target Designation OARIS 1.0 open
OARIS11-42 Multiplicity for based on for sensor track's plots OARIS 1.0 open

Issues Descriptions

Use of covariance versus accuracy attributes

  • Key: OARIS11-7
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:55 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Cue to another OARIS track

  • Key: OARIS11-6
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

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

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:48 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Non existent NEGOTIATED attribute of coordinate specification types

  • Key: OARIS11-5
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

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

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:41 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Option for an explicit bearing only track origin

  • Key: OARIS11-4
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

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

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:36 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Topic lifecycle semantics for the DDS PSM

  • Key: OARIS11-3
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:28 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Inconsistency in name additional information attribute

  • Key: OARIS11-1
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:05 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Sensor track does not identify the sensor

  • Key: OARIS11-10
  • Status: open  
  • Source: BAE SYSTEMS ( Peter Hammond)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Wed, 6 Dec 2017 10:27 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Documentation embedded in IDL files

  • Key: OARIS11-9
  • Status: open  
  • Source: BAE SYSTEMS ( Peter Hammond)
  • Summary:

    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)
    
  • Reported: OARIS 1.0 — Wed, 6 Dec 2017 10:20 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Poor documentation of recognition_type

  • Key: OARIS11-8
  • Status: open  
  • Source: BAE SYSTEMS ( Peter Hammond)
  • Summary:

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

  • Reported: OARIS 1.0 — Wed, 6 Dec 2017 10:15 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Confusion between polar velocity type and wgs84 velocity type

  • Key: OARIS11-14
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Fri, 7 Sep 2018 19:25 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

inconsistency: units of Latitude/Longitude in notes verses tags

  • Key: OARIS11-2
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Tue, 17 Oct 2017 13:21 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

wgs84_velocity_type::speed is ambiguous

  • Key: OARIS11-13
  • Status: open  
  • Source: BAE SYSTEMS ( Peter Hammond)
  • Summary:

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

  • Reported: OARIS 1.0 — Mon, 11 Dec 2017 10:42 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Name "wgs84_velocity_type" is misleading

  • Key: OARIS11-12
  • Status: open  
  • Source: BAE SYSTEMS ( Peter Hammond)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Mon, 11 Dec 2017 10:36 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Register Interest appers to be redundant

  • Key: OARIS11-11
  • Status: open  
  • Source: BAE SYSTEMS ( Peter Hammond)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Wed, 6 Dec 2017 10:42 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Missing notes from attributes of sensor_track_type

  • Key: OARIS11-26
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

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

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 10:39 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Inconsistent content in cued_search_report_type

  • Key: OARIS11-25
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 10:32 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Error in dedesignate_target parameter

  • Key: OARIS11-24
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 08:33 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Erroneous documentation text from sequence diagrams

  • Key: OARIS11-23
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 08:21 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Typo in Engagement Support

  • Key: OARIS11-22
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    There is a leading backslash in the Engagement Support section

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 08:16 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Specific Error Method in Process Target Designation

  • Key: OARIS11-21
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

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

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 08:13 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT

Multiplicity for based on for sensor track's plots

  • Key: OARIS11-42
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    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.

  • Reported: OARIS 1.0 — Wed, 9 Jan 2019 15:11 GMT
  • Updated: Mon, 1 Apr 2019 18:07 GMT