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

All Issues

  • All Issues
  • Name: oaris-rtf
  • Issues Count: 24

Issues Summary

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

Issues Descriptions

Is type definition for plot_count field appropriate?

  • Key: OARIS2-11
  • Status: closed  
  • Source: BAE Systems ( Ian Grover)
  • Summary:

    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?

  • Reported: OARIS 2.0b1 — Tue, 1 Mar 2022 16:22 GMT
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Typo sensor_plot_equipement_assessment_type

  • Key: OARIS2-9
  • Status: closed  
  • Source: BAE Systems ( Ian Grover)
  • Summary:

    The identifier sensor_plot_equipement_assessment_type has a typo (extra E in equipment) in all places that it is mentioned in the document.

  • Reported: OARIS 2.0b1 — Mon, 7 Mar 2022 19:38 GMT
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Is type definition for request_id_type appropriate?

  • Key: OARIS2-10
  • Status: closed  
  • Source: BAE Systems ( Ian Grover)
  • Summary:

    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?

  • Reported: OARIS 2.0b1 — Tue, 1 Mar 2022 16:19 GMT
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    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.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Multiplicity for based on for sensor track's plots

  • Key: OARIS11-42
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

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

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Missing notes from attributes of sensor_track_type

  • Key: OARIS11-26
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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]

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Inconsistent content in cued_search_report_type

  • Key: OARIS11-25
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

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

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Error in dedesignate_target parameter

  • Key: OARIS11-24
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    Correct Target Designation Parameter Names

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

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Erroneous documentation text from sequence diagrams

  • Key: OARIS11-23
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    Remove sequence diagram artefact subsections

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

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Typo in Engagement Support

  • Key: OARIS11-22
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    There is a leading backslash in the Engagement Support section

  • Reported: OARIS 1.0 — Thu, 4 Oct 2018 08:16 GMT
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    Remove typo from Engagement Support heading

    remove backslash typo

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Specific Error Method in Process Target Designation

  • Key: OARIS11-21
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    Remove specific error method

    Remove method receive_target_designation_error

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Register Interest appers to be redundant

  • Key: OARIS11-11
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Documentation embedded in IDL files

  • Key: OARIS11-9
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Poor documentation of recognition_type

  • Key: OARIS11-8
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Sensor track does not identify the sensor

  • Key: OARIS11-10
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Name "wgs84_velocity_type" is misleading

  • Key: OARIS11-12
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

wgs84_velocity_type::speed is ambiguous

  • Key: OARIS11-13
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Use of covariance versus accuracy attributes

  • Key: OARIS11-7
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

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

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Cue to another OARIS track

  • Key: OARIS11-6
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Non existent NEGOTIATED attribute of coordinate specification types

  • Key: OARIS11-5
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Option for an explicit bearing only track origin

  • Key: OARIS11-4
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Topic lifecycle semantics for the DDS PSM

  • Key: OARIS11-3
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

inconsistency: units of Latitude/Longitude in notes verses tags

  • Key: OARIS11-2
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Inconsistency in name additional information attribute

  • Key: OARIS11-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 1.1
  • Disposition Summary:

    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.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Confusion between polar velocity type and wgs84 velocity type

  • Key: OARIS11-14
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Duplicate or Merged — OARIS 1.1
  • Disposition Summary:

    Add WGS84 velocity explanations

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

  • Updated: Mon, 30 Mar 2020 19:49 GMT