Open Architecture Radar Interface Standard Avatar
  1. OMG Specification

Open Architecture Radar Interface Standard — Open Issues

  • Acronym: OARIS
  • Issues Count: 18
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Sensor Orientation should contain be able to specify origin

  • Key: OARIS2-53
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    The Provide Sensor Orientation use case would be more useful if there was a possibility to provide an origin for the sensor. In particular, it could be used in cases where the sensor is mobile with respect to the physical platform on which it is situated; particular to communicate field of view.
    Equally optional coverage in azimuth and elevation would be useful.

  • Reported: OARIS 2.0b1 — Fri, 20 May 2022 14:29 GMT
  • Updated: Fri, 20 May 2022 16:25 GMT

Circular Dependency between Track Reporting and Assessment packages

  • Key: OARIS2-52
  • Status: open   Implementation work Blocked
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    In the DDS/IDL PSM there is a circular dependency between the Track_Reporting and Sensor_Assessment packages in Sensor_Domain. This is because the by reference association to assessment types contain an assessment_objective_id_type which is defined in the Assessment package.
    References in the other direction are intentional.

  • Reported: OARIS 2.0b1 — Fri, 20 May 2022 14:19 GMT
  • Updated: Fri, 20 May 2022 16:25 GMT

Update GraphQL PSM Mapping

  • Key: OARIS2-33
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    The GraphQL mapping in the specification and defined in the schema files leads to an unnecessarily complicated implementation of the standard and should be simplified

  • Reported: OARIS 2.0b1 — Tue, 3 May 2022 12:59 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

Rationalise DDS/IDL inheritance mapping

  • Key: OARIS2-27
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    The mapping of specialisations duplicates the location of common attributes from the generalisation class into each option of the union. This is inconvenient for the software design of applications using the types.

  • Reported: OARIS 2.0b1 — Sat, 30 Apr 2022 13:36 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

Attribute types incorrectly linked in the XMI file

  • Key: OARIS2-30
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    The following attributes are not correctly linked in the XMI file
    In class system_track_type: system_track_number, time_of_information
    In class fault_type: event
    In class service_health_type: health_state, health_state_reason
    In class subsystem_health_type: health_state, health_state_reason
    In class downlink_request_type: own_missile_track_id
    In class uplink_report_type: own_missile_track_id
    In class uplink_request_type: own_missile_track_id

    (They are linked to an implicitly created Java datatype by the EA tool)

  • Reported: OARIS 2.0b1 — Tue, 3 May 2022 11:05 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

DDS/IDL mapping for concentration_plot_cell_type has _id attribute

  • Key: OARIS2-28
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    There is an erroneous attribute "long _id;" in struct concentration_plot_cell_type in Clutter_Reporting.idl

    This is a PSM specific issue.

  • Reported: OARIS 2.0b1 — Sat, 30 Apr 2022 13:39 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

Is type definition for plot_count field appropriate?

  • Key: OARIS2-11
  • Status: open  
  • 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
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

Method Tags erroneous generated into specification document

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

    Text such as
    "MethodTag: ea_guid =

    {674682AC-3306-4567-8E2C-7A9C428EAA34}

    "
    appears in some tables in the specification.
    These should not be there

  • Reported: OARIS 2.0b1 — Wed, 20 Apr 2022 15:38 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT

Document generation placeholders remaining in the specification

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

    There are 26 #Table# markers remaining in the specification document.
    These need to be replaced with their proper numbers and subsequent tables renumbered.

  • Reported: OARIS 2.0b1 — Thu, 28 Apr 2022 18:18 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT

Is type definition for request_id_type appropriate?

  • Key: OARIS2-10
  • Status: open  
  • 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
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

Perform Cued Search issues

  • Key: OARIS2-8
  • Status: open  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    The subsystem_id has been removed from the perform_cued_search_type and report_cued_search_result_type data types.

    For the shape model aspects, a new parameter id of type long has been added to figure_ref_point_type in Shape_Model.idl. This is not documented in the IDL or in the IFS, and the intention is hence not clear.

  • Reported: OARIS 2.0b1 — Sun, 13 Mar 2022 17:10 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

Heartbeat_Signal.idl has been removed

  • Key: OARIS2-7
  • Status: open  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    Heartbeat_Signal.idl has been removed from the distribution. Searching for receive_subsystem_heartbeat_signal and receive_cms_heartbeat_signal in the IDL returns no entries. The interface can’t be found.

    Exchange Heartbeat is documented as a Compliance Level 2 interface in the IFS. It is documented at section 7.7.5.2. It can only be concluded therefore that the Heartbeat_Signal.idl file has been omitted by mistake.

    It is noted that the documentation omits subsystem_id as per the other interfaces. This is an error?

  • Reported: OARIS 2.0b1 — Sun, 13 Mar 2022 17:02 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT

sensor_plot_type structure changed

  • Key: OARIS2-6
  • Status: open  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    The Plot Reporting Use Case is confusing. For OARIS 1.1, the actual Plot structure was abstracted into a sub-type write_sensor_plot_type defined in Provide_Plots.idl. In OARIS 2.0, the IDL file Provide_Plots.idl has been removed, with the interface effectively reverting back to the OARIS 1.0 version with sensor_plot_type defined in Plot_Reporting.idl. Is this intentional or was an incorrect baseline used for creating OARIS 2.0? This may also explain why subsystem_id is also missing as per sensor_track_type.

  • Reported: OARIS 2.0b1 — Sun, 13 Mar 2022 16:59 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT

Typo sensor_plot_equipement_assessment_type

  • Key: OARIS2-9
  • Status: open  
  • 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
  • Updated: Fri, 20 May 2022 00:08 GMT

track_phase_type DELETED enumerate

  • Key: OARIS2-4
  • Status: open  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    The enumerator DELETED has been reinstated back in track_phase_type. This does question why the enumerator was renamed NOT_USED in version 1.1, in preference for the use of topic delete. Actually, having reinstated DELETED back in the IDL over using topic delete is a benefit since it makes track lifecycle easier. It is also not clear how INACTIVE assists and how long a track stays in this state before it is LOST. This is not documented but assumed to be sensor specific.

    Parameter track_phase_type changed between 1.1 and 2.0. DELETED that was removed in 1.1 is now back!
    OARIS 1.1
    // The detection lifecycle phase of the track
    enum track_phase_type

    { // DEAD_RECKONED DEAD_RECKONED, // Delete enumeration not used for DDS; dispose topic instance instead. NOT_USED, // LOST LOST, // TRACKED TRACKED }

    ;

    OARIS 2.0
    // The detection lifecycle phase of the track
    enum track_phase_type

    { // Track provided based on extrapolated position (dead-reckoned) DEAD_RECKONED, // Track has been deleted. DELETED, // Track has been lost LOST, // Regular update of new and existing track TRACKED, // No new measurements were available to contribute to this track at the last // opportunity to do so. It is expected that should such measurements be made at the // next opportunity, these will successfully update the track. INACTIVE }

    ;

  • Reported: OARIS 2.0b1 — Sun, 13 Mar 2022 16:52 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT

new Optional attributes added to sensor_track_type

  • Key: OARIS2-5
  • Status: open  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    new Optional attributes added to sensor_track_type, to include:
    • track_quality
    • time_of_first_detection
    • time_of_last_detection
    • priority
    • amplitude
    • activity_id
    • sensor_function_id
    • observed_function_id
    • equipment_id
    • platform_id
    Some appear to be quite low level and applicable to plots rather than tracks. It is also not clear what some of the values are. The last 5 are not documented in the IFS to assist.

  • Reported: OARIS 2.0b1 — Sun, 13 Mar 2022 16:54 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT

subsystem_id removed from v2.0

  • Key: OARIS2-3
  • Status: open  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    The parameter subsystem_id has been removed from sensor_track_type. The parameter subsystem_id was added in OARIS 1.1 and provided a few benefits to include ensuring samples being unique since it was used in key. Please can we have it back.

    The same issue can be found in sensor_plot_type, perform_cued_search_type and report_cued_search_result_type. Not all interfaces have been checked, but assume the same issue exists elsewhere.

    It is assumed that removing subsystem_id is not intentional and in error, since it is documented in the DDS PSM at section 8.2, but does not appear in the PIM in the earlier sections.

    Suggest also that subsystem_id_type is changed from unsigned short to unsigned long. This aligns with other UK information models.

  • Reported: OARIS 2.0b1 — Sun, 13 Mar 2022 16:44 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments:

UNKNOWN enumeration literal appears twice

  • Key: OARIS2-2
  • Status: open   Implementation work Blocked
  • Source: Raytheon Technologies ( David Bainbridge)
  • Summary:

    I used RTI's DDS tool to transform the OARIS 2.0 beta 1 IDL into C++ and Java and tried to compile it. I got errors involving the enumeration types identity_type in Common_Types.idl and health_state_type in Subsystem_Control.idl. Both have an enumeration literal named UNKNOWN. The generated C++ and Java have these in the same namespace so the code does not compile.

    The full error when compiling C++ is below
    ./Subsystem_Control.h:436:5: error: redeclaration of 'UNKNOWN'
    UNKNOWN
    ^
    In file included from ./Subsystem_Control.h:23:0,
    from ./Control_Battle_Override.h:24,
    from ./Control_Battle_Override.cxx:31:
    ./Common_Types.h:133:5: note: previous declaration 'org_omg_c4i_Domain_Model_Common_Types_identity_type UNKNOWN'

    I'm using rtiddsgen version 5.3.1.14 to transform IDL into C++ and Java. I don't know if this is a problem with the specification or if I need to find a way to transform the IDL into C++ and Java that uses separate namespaces for enumeration types. But I felt someone should know about this anyway.

    This was the only issue preventing compilation of the generated C++ and Java. I changed one of the literals to something else and it transformed and built with no errors.

  • Reported: OARIS 2.0b1 — Tue, 23 Mar 2021 14:27 GMT
  • Updated: Fri, 20 May 2022 00:08 GMT
  • Attachments: