Open Architecture Radar Interface Standard Avatar
  1. OMG Specification

Open Architecture Radar Interface Standard — Closed Issues

  • Acronym: OARIS
  • Issues Count: 21
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
OARIS2-24 Document generation placeholders remaining in the specification OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-33 Update GraphQL PSM Mapping OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-7 Heartbeat_Signal.idl has been removed OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-11 Is type definition for plot_count field appropriate? OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-6 sensor_plot_type structure changed OARIS 2.0b1 OARIS 2.0 Closed; No Change closed
OARIS2-27 Rationalise DDS/IDL inheritance mapping OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-30 Attribute types incorrectly linked in the XMI file OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-23 Method Tags erroneous generated into specification document 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-56 Duplicate class name performance assessment request in generated PSMs OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-53 Sensor Orientation should contain be able to specify origin OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-52 Circular Dependency between Track Reporting and Assessment packages OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-28 DDS/IDL mapping for concentration_plot_cell_type has _id attribute OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-60 Diagrams produced in the FTF don't scale well OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-4 track_phase_type DELETED enumerate OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-2 UNKNOWN enumeration literal appears twice OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-5 new Optional attributes added to sensor_track_type OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-3 subsystem_id removed from v2.0 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
OARIS2-8 Perform Cued Search issues OARIS 2.0b1 OARIS 2.0 Resolved closed
OARIS2-1 Ambiguous PIM/PSM definition wrt subsystem_id and track_phase_type, and DDS implementation OARIS 1.1 OARIS 2.0 Duplicate or Merged closed

Issues Descriptions

Document generation placeholders remaining in the specification

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

    Resolve Table number placeholders and renumber

    Each of the 26 #Table# placeholders for table numbers in the specification document should be resolved to its proper sequential number (or omitted in the cases where there is no table) and subsequent tables renumbered accordingly.
    Also remove heading for non-existent tables (e.g. for typedefs which have no attributes).

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

Update GraphQL PSM Mapping

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

    Regenerate GraphQL PSM with updated mapping

    The updated mappings from PIM to GraphQL as incorporated into the TDAI beta spec and C2INav v1.1 RTF should be used. This generates a single schema for each standard avoiding class duplication, has a flatter structure with respect to endpoint methods, has less duplication with respect to input types and uses a simpler mapping with less duplication for inheritance (consistent with that also now used for DDS/IDL - see OARIS2-27). The proposed schema file is attached.

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

Heartbeat_Signal.idl has been removed

  • Key: OARIS2-7
  • Status: closed  
  • 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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Document omission of Heartbeat Signal as in-built in DDS PSM

    In section 8.2 describe how Heartbeat Signal is also mapped to DDS in-built API methods (as well as Register Interest, already documented).

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

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:

sensor_plot_type structure changed

  • Key: OARIS2-6
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — OARIS 2.0
  • Disposition Summary:

    Flattened Structure Is Intentional

    This change is a consequence of applying the principal of flattening PIM methods with a single parameter consistently throughout the whole model when mapping to the DDS/IDL PSM (and also GraphQL).

    The topic type for Plots should have been flattened in the same way as that for Tracks in v1.1. This has now been done for v2.0.

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

Rationalise DDS/IDL inheritance mapping

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

    Use a rationalised DDS/IDL inheritance mapping.

    Update the mapping of generalization / specialization inheritance so that attributes of the generalization class are encapsulated into a base class, which then appears as an attributes of each specialization rather than each of the generalization attributes individually.
    Also the generated enumeration values are missing the name of the generalization class in their IDL documentation comment.

    The impacted IDL files are attached as per the proposed update.

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

Attribute types incorrectly linked in the XMI file

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

    Fix linkage in the master EA file

    For each attribute link the type to the actual class in the model rather than free text.

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

Method Tags erroneous generated into specification document

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

    Remove MethodTag markers in the specification document

    Remove all instance of "MethodTag: ea_guid =

    {<GUID>}

    " from the tables describing methods

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

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

Duplicate class name performance assessment request in generated PSMs

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

    The PSM generation rules lead to a duplicate class name of performance_assessment_request_type in packages for the Sensor Performance use cases (one in domain model and one in the service model). This is undesirable and may lead to confusion and/or erroneous usage of the spec.

  • Reported: OARIS 2.0b1 — Wed, 25 May 2022 08:01 GMT
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Rename performance_assessment_request_type

    The class performance_assessment_request_type in the Sensor_Performance (Domain Model) package should be renamed to performance_assessment_parameters_type. This is arguably a better name and disambiguates in the generated PSMs.
    Additionally, operations sim_mode_status in Control_Simulation clashes with a Domain Model class in the PSM and operations complete in Perform_Illumination & Perform_Missile_Downlink clash in the generated PSMs. These should be renamed to be more consistent and coherent:

    • sim_mode_status to report_sim_mode_status
    • complete to report_illumination_completed & report_uplink_completed respectively
  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Sensor Orientation should contain be able to specify origin

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

    Add optional origin and field of view to sensor orientation

    To sensor_orientation_type:

    • add an optional origin of position_coordinate_type
    • add an optional azimuth_coverage of azimuth_interval_type
    • add an optional elevation_coverage of elevation_interval_type
    • add an optional origin_coordinate_specification of coordinate_specification_type
  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Circular Dependency between Track Reporting and Assessment packages

  • Key: OARIS2-52
  • Status: closed   Implementation work Blocked
  • Source: BAE SYSTEMS ( Mr. 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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Move assessment_objective_id_type to Track Reporting

    Typedef assessment_objective_id_type should be moved to the Track_Reporting package to resolve the circular dependency.

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

DDS/IDL mapping for concentration_plot_cell_type has _id attribute

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

    Correct aggregations in the Clutter Reporting domain model

    Correct composition of clutter_map_cell_type by clutter_report_type so that it is navigable only from latter to former.

    Correct composition of concentration_plot_cell_type by plot_concentration_report_type so that it is navigable only from latter to former.

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

Diagrams produced in the FTF don't scale well

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

    The diagram files exported from Enterprise Architect for this FTF are in PNG format. These don't scale well as noted in AB review comments.

  • Reported: OARIS 2.0b1 — Fri, 17 Jun 2022 07:11 GMT
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Export diagrams in SVG format

    All the diagrams changed by the FTF should be exported in SVG and saved in a zip file alongside the PNG file that they replaced, so that the OMG editor can use these files to create the specification file for publication.

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

track_phase_type DELETED enumerate

  • Key: OARIS2-4
  • Status: closed  
  • 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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Remove DELETED attribute and specific delete operation

    The reappearance of the DELETED attribute in the DDS PSM was an error. It was an unintentional consequence of a change of approach to DDS IDL generation.
    Having added also added a GraphQL PSM that also has has technology specific convention for deleting data, it makes sense to remove this from the PIM as well. At the PIM level the ability for a sensor to indicate that it has deleted a track is required and should be added. This method would be mapped to DDS API and general GraphQL mapping for the PSMs.
    The INACTIVE enumerate was added to the v2.0 proposal for the case of passive sensors where the signal is expected to be intermittent.

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

UNKNOWN enumeration literal appears twice

  • Key: OARIS2-2
  • Status: closed   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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Change health UNKNOWN enum to UNKNOWN_HEALTH

    Change to disambiguate the Health enumerate as this does not impact known implementations of the standard. And the values of the Identity enumerate reflect standard usage for identification.

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

new Optional attributes added to sensor_track_type

  • Key: OARIS2-5
  • Status: closed  
  • 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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Document the mapping of associations in the DDS and GraphQL PSM

    All these attributes are optional and whilst not expected to be applicable to (for instance) radar tracks generally, they are applicable (and indeed required) to support the data models of some of the additional sensors scoped by OARIS v2.0 (e.g. EW).
    The PSM mapping sections (within section 8) do not discuss the mapping of (by reference) associations. This should be added, which would define the semantics of these attributes in the PSM. (Each of the attributes already has documentation in the PSM in the Beta version).

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

subsystem_id removed from v2.0

  • Key: OARIS2-3
  • Status: closed  
  • 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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Reinstate subsystem_id to PSMs

    subsystem_id was omitted from the DDS/IDL PSM mapping in error in the v2.0 proposal (change to PSM generation approach).
    This attribute should be added back in to the DDS/IDL PSM files. One keyed attribute per topic type.
    Note that the subsystem_id attribute continued to be described as being a key in topic structs in section 8.2.

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

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:

Perform Cued Search issues

  • Key: OARIS2-8
  • Status: closed  
  • 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
  • Disposition: Resolved — OARIS 2.0
  • Disposition Summary:

    Remove erroneous _id parameter

    A parameter named _id has been generated into the figure_ref_point_type struct. This should be removed. It arises because the aggregation to rectangle_type is navigable both ways. This should be corrected to fix the issue (navigable only from rectangle to figure ref point). This will update diagram 7.29.
    There is already an issue to fix/add back subsystem ids generally in the DDS/IDL mapping. This will fix the search topic types as well.

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

Ambiguous PIM/PSM definition wrt subsystem_id and track_phase_type, and DDS implementation

  • Key: OARIS2-1
  • Status: closed  
  • Source: QinetiQ ( Jon Astle)
  • Summary:

    Issues with spec:
    OARIS/1.1/PDF, formal/20-08-03

    Ambiguous PIM/PSM definition:
    Figure 7-41: Track Reporting - Sensor Track (Logical diagram)
    Does not include in the sensor_track_type class:
    org::omg::c4i::Domain_Model::Common_Types::subsystem_id_type subsystem_id;

    Table 7-110: Attributes of IDLStruct sensor_track_type
    Does not include :
    org::omg::c4i::Domain_Model::Common_Types::subsystem_id_type subsystem_id;

    track_phase track_phase_type Track phase (e.g. TRACKED, DELETED, LOST)
    DELETED has been removed, but the enumerate renamed NOT_USED

    Table 7-111: Attributes of IDLEnum track_phase_type
    «idlEnum» DELETED Track has been deleted.
    Should be:
    «idlEnum» NOT_USED Note: Delete enumeration not used for DDS; dispose topic instance instead.

  • Reported: OARIS 1.1 — Sat, 24 Oct 2020 20:23 GMT
  • Disposition: Duplicate or Merged — OARIS 2.0
  • Disposition Summary:

    Duplicate of two separate issues

    The issues raised duplicate the contents of two issue raised separately subsequently

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