Open Architecture Radar Interface Standard Avatar
  1. OMG Specification

Open Architecture Radar Interface Standard — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
OARIS21-4 Description of Manage_Transmission_Sectors protocol is inconsistent OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-6 Description of Manage_Tracking_Zones protocol is inconsistent OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-5 Description of Control_Battle_Override protocol is inconsistent OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-1 Two track_priority_type typedef classes defined OARIS 2.0b1 $issue.fixedSpecification.name Deferred closed
OARIS21-10 The state of a simulation session is not apparent on the interface OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-11 Representation of Ambiguity in Passive Bearings OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-9 Manage Physical Configuration doesn't use common request response protocol OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-8 Missing Reference OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-16 request_id for report_service_health on subsystem intiative OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-18 PSM mapping for sensor_track_based_on_id_type has unexpected type OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-14 Mandatory velocity for sensor tracks doesn't work for bearings OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-13 IDL files are labelled as v1.1 not v2.0 OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-23 Update copyright holders OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-22 technical_state_type incorrectly described as class when it is an enumeration OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-24 delete_sensor_track used as an interface and a method OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-21 Inconsistent state condition for Health Service OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-20 Heartbeat required as the basis for on_requested_deadline_missed for DDS PSM OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-2 Initial Emission Control State Undefined in Control_Emissions protocol OARIS 2.0 $issue.fixedSpecification.name Deferred closed
OARIS21-27 service_health_type struct within Subsystem_Control IDL not in keeping with specification documentation. OARIS 2.0b2 $issue.fixedSpecification.name Deferred closed
OARIS21-7 contradiction on who (subsystem or CMS) should initiate the identification process and set the request id. OARIS 2.0b1 $issue.fixedSpecification.name Deferred closed
OARIS21-3 Typo in ONLINE state description in the model OARIS 2.0 $issue.fixedSpecification.name Deferred closed
TDAI-11 system_track_type does not contain identity or classification OARIS 2.0b2 TDAI 1.0 Closed; Out Of Scope closed
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
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
OARIS-76 Length of subsystem parameter string types OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-79 Typo in parameter for report_transmission_mode_state operation OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-82 Wrong description in Sensor Orientation resolution OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-75 Inconsistent mechanisms for determining subsystem state across use cases OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-66 Manage Mastership has an empty topic type OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-65 Heartbeat Signal has an empty topic type OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-64 System Track should have a key OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-67 receive error method from common use case interface not used OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-41 C++ for general_polar_volume_type does not compile OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-68 Name clash between operation and type for transmission_frequency_state OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-63 Track Extractors may need to know where Radar is pointing OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-61 Technical State state transition diagrams omitted from specification OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-59 Manage Frequency Usage classes don't all follow class naming convention OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-57 Response to a frequency range request to be supported by the PIM OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-55 How is the set of frequencies supported by a sensor determined by the CMS OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-53 Semantics of sector_added unclear for use case manage_transmission_sectors OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-51 Unable to create transmission mode sectors OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-45 Request_ack_type/error_reason_type/denial_reason_type needs more identifying information OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-48 No Unknown / No Statement value for environment OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-47 No identity_type field on the sensor_track_type class OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-43 Emphasise uniqueness requirement on parameter names OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-24 Error in service_indication_type IDL OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-26 Class descriptor contains range attribute (reserved word in Ada) OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-25 identification_response_type contains an 'accept' enumeration (reserved in Ada) OARIS 1.0b1 OARIS 1.0 Duplicate or Merged closed
OARIS-3 IDL does not explicitly define topics OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-2 Heartbeat Use Case Name OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-1 Control Interface Connection use case was redundant OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-14 IDL for sensor_track_set_type is wrong OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-19 No Upper Bound for Plots a Sensor Track is based on OARIS 1.0b1 OARIS 1.0 Closed; No Change closed
OARIS-21 Sensor Track Set is modelled as a set of ids (int values) in PSM OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-20 No Upper Bound for Sensor Tracks within a Sensor Track Set OARIS 1.0b1 OARIS 1.0 Closed; No Change closed
OARIS-23 Class Service Indication Type has unintended id field in DDS/IDL PSM OARIS 1.0b1 OARIS 1.0 Duplicate or Merged closed
OARIS-22 Related Parameter self relation for Class descriptor is ambiguous in DDS PSM OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-9 Receive Response for Subsystem Identification OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-8 Receive Error for Manage Subsystem Parameters OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-7 Origin for WGS84 and ECEF OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-6 Inaccuracte documentation of enumerate in coordinate_orientation_type OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-5 Subsystem Id Attributes are unnecessary OARIS 1.0b1 OARIS 1.0 Resolved closed
OARIS-4 Sensor Track Id not a member of topic type OARIS 1.0b1 OARIS 1.0 Duplicate or Merged closed
OARIS-10 Heartbeat Signal Basic Flow Operations OARIS 1.0b1 OARIS 1.0 Resolved closed

Issues Descriptions

Description of Manage_Transmission_Sectors protocol is inconsistent

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

    The description of the interface states that
    "It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."
    However, there is no operation defined to request information from the subsystem.
    (Note: the protocol was probably simplified in working towards the v1.0 submission without revising the overall description of this particular interface).

  • Reported: OARIS 2.0 — Wed, 28 Sep 2022 10:59 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Description of Manage_Tracking_Zones protocol is inconsistent

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

    The description of the interface states that
    "It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."
    However, there is no operation defined to request information from the subsystem.
    (Note: the protocol was probably simplified in working towards the v1.0 submission without revising the overall description of this particular interface).

  • Reported: OARIS 2.0 — Wed, 28 Sep 2022 14:52 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Description of Control_Battle_Override protocol is inconsistent

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

    The description of the interface states that
    "It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."
    However, there is no operation defined to request information from the subsystem.
    (Note: the protocol was probably simplified in working towards the v1.0 submission without revising the overall description of this particular interface).

  • Reported: OARIS 2.0 — Wed, 28 Sep 2022 11:58 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Two track_priority_type typedef classes defined

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

    There are track_priority_type typedefs defined in both the Track_Reporting and Tracking_Control Domain Model packages.

  • Reported: OARIS 2.0b1 — Mon, 25 Jul 2022 16:51 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

The state of a simulation session is not apparent on the interface

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

    Method report_sim_mode_status does not contain the status of the session e.g. whether it is running, not started, frozen etc. The specification should also describe the overall state machine described by the interface.

  • Reported: OARIS 2.0b2 — Fri, 16 Dec 2022 14:10 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Representation of Ambiguity in Passive Bearings

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

    Some passive sensors are unable to resolve a bearing around the line of symmetry through the sensor. The polar model for positions in the specifications does not allow this ambiguity to be clearly represented.

  • Reported: OARIS 2.0b2 — Fri, 16 Dec 2022 16:04 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Manage Physical Configuration doesn't use common request response protocol

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

    Interface Manage_Physical_Configuration_CMS contains method receive_physical_configuration_success, which is used where receive_acknowledgement from common_use_case_interface would be expected

  • Reported: OARIS 2.0b2 — Fri, 16 Dec 2022 08:44 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Missing Reference

  • Key: OARIS21-8
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Paul Marsh)
  • Summary:

    METOC RFP (c4i/08-12-02) is referenced in dtc/22-06-03 but does not yet exist on the OMG site in any form.

  • Reported: OARIS 2.0 — Mon, 10 Oct 2022 15:11 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

request_id for report_service_health on subsystem intiative

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

    For Service Health Reporting and Subsystem Health Reporting the specification describes two scenarios one on subsystem initiative and another on request.
    In both cases the subsystem calls a method on the CMS interface with a request_id. In the 'on subsystem initiative' case it is unclear what value the subsystem should use for the request_id. Any value chosen could potentially be misinterpreted as a value for an actual CMS request.

  • Reported: OARIS 2.0b2 — Wed, 8 Feb 2023 15:31 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

PSM mapping for sensor_track_based_on_id_type has unexpected type

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

    typedef sequence<org::omg::c4i::Domain_Model::Common_Types::subsystem_id_type, 256> sensor_track_based_on_id_type;

    Has subsystem_id_type rather than plot_id_type as its value type.

  • Reported: OARIS 2.0b2 — Thu, 23 Feb 2023 11:27 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Mandatory velocity for sensor tracks doesn't work for bearings

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

    Attribute velocity in class sensor_track_type is mandatory but will not be defined / known for bearings tracks

  • Reported: OARIS 2.0b2 — Wed, 11 Jan 2023 18:04 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

IDL files are labelled as v1.1 not v2.0

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

    The IDL files have the wrong interface version in them at the top of the file.

  • Reported: OARIS 2.0 — Mon, 9 Jan 2023 11:56 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Update copyright holders

  • Key: OARIS21-23
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The copyright holders shown at the beginning of the document should include not only the original submitters but also the members of all the subsequent FTFs/RTFs. It seems this list has not been maintained as the following companies are missing:

    General Dynamics, Northrop Grumman, SimVentions, Microfocus, Real-Time Innovations,

  • Reported: OARIS 2.0 — Fri, 19 May 2023 05:17 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

technical_state_type incorrectly described as class when it is an enumeration

  • Key: OARIS21-22
  • Status: closed  
  • Source: Naval Combat Systems Integration Support Service ( Matthew Burleigh)
  • Summary:

    On page 95 the description of technical_state_type calls it a class while the diagrams stereotype it as an IDLEnum.

  • Reported: OARIS 2.0b2 — Wed, 3 May 2023 13:25 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

delete_sensor_track used as an interface and a method

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

    delete_sensor_track is used as an interface in the Tracking_Control service and as a method on the Provide_Sensor_Tracks interface. This is potentially confusing and in principle could cause name clashes.

  • Reported: OARIS 2.0 — Tue, 20 Jun 2023 12:29 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Inconsistent state condition for Health Service

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

    (originally reported by Richard Smith - BAE Systems)

    (Proivde_Health_State, page 194, para above table 7.185) contains the following description:

    “Reason for health state
    Each reported health state other than AVAILABLE is accompanied by the reason(s) for that health. In this way the CMS may for instance derive that although the technical state of the subsystem is STANDBY (and NOT AVAILABLE for that reason), there are also faults that would prevent the service to become AVAILABLE when the technical state would be switched to ONLINE.”

    This appears perfectly reasonable to me, although it is then followed immediately by:
    “Pre-condition: Subsystem technical state The subsystem is in technical state ONLINE or READY.”

    This appears to imply, to me, that the report service health is only applicable to the ONLINE or READY technical state, even though the para above suggests it would be of use in the STANDBY state!

  • Reported: OARIS 2.0b2 — Fri, 24 Feb 2023 10:41 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Heartbeat required as the basis for on_requested_deadline_missed for DDS PSM

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

    The Exchange Heartbeat use case supports assurance cases relating to runtime software integrity, in particular that critical functionality continues to be available and has not failed silently.
    For the DDS PSM this is currently mapped to the built-in DDS API, but the on_requested_deadline_missed requires a suitable topic definition (which could/should be provided by the Exchange Heartbeat use case).

  • Reported: OARIS 2.0b2 — Thu, 23 Feb 2023 14:42 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Initial Emission Control State Undefined in Control_Emissions protocol

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

    The interaction diagrams for the Control_Emissions service do not provide a mechanism for determining the initial state of the emission control setting.
    Possibilities are that the CMS is expected to explicitly set this for all sensors as part of startup of each sensor (e.g. whilst they are in the READY state) or that each sensor has its own default (or persistent) state that it assumes on each startup.
    Further information: The description of the ONLINE technical state, requires Control Emissions to occur once the subsystem is in this state and implies that the emission control setting is off when the subsystem enters the ONLINE state.
    More information: The description of the Control_Emissions_CMS interface states: "It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem." However there is no method on the subsystem interface to provide this information.
    The description of Control_Emissions_CMS interface should be updated accordingly.

  • Reported: OARIS 2.0 — Wed, 28 Sep 2022 09:19 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

service_health_type struct within Subsystem_Control IDL not in keeping with specification documentation.

  • Key: OARIS21-27
  • Status: closed  
  • Source: MCS-IA ( Jez Merchant-Locke)
  • Summary:

    Within Subsystem_Control.idl the struct service_health_type (line 327) has the member health_state (line 330) declared with type health_state_reason_type. The specification states it should be health_state_type. Believe this is an error?

  • Reported: OARIS 2.0b2 — Wed, 21 Jun 2023 08:20 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

contradiction on who (subsystem or CMS) should initiate the identification process and set the request id.

  • Key: OARIS21-7
  • Status: closed  
  • Source: BAE Systems ( Jia Liu)
  • Summary:

    The following is the description of request_id in oaris 2.0 spec:

    7.3.12.6 request_id_type
    Type: IDLTypeDef unsigned long long
    Package: Requests
    The purpose of the request_id is to uniquely relate responses of the subsystem (server) to requests of the CMS (client). The request_id is set by the client. It is the responsibility of the client to specify a system-wide unique request_id (e.g. based on a combination of client id and a sequence number / time of request). Here it indicates that CMS as client should specify request_id. But in section 7.7.5.3 Provide_Subsystem_Identification, it documents that it should be the subsystem to initiate the communication to CMS, which implies subsystem will need to specify request_id required in receive_sub_identification_data_type before sending it to CMS.

  • Reported: OARIS 2.0b1 — Tue, 13 Sep 2022 16:29 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

Typo in ONLINE state description in the model

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

    The notes field for the ONLINE state in the Technical State state machine has a typo - viathe. The notes field has other subtle differences in comparison to the corresponding enumeration attribute.

  • Reported: OARIS 2.0 — Wed, 28 Sep 2022 10:49 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 9 Jul 2024 14:40 GMT

system_track_type does not contain identity or classification

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

    These attributes are important for enabling a sensor to processing specific to the actual category of object that it is tracking.

  • Reported: OARIS 2.0b2 — Sat, 23 Sep 2023 12:45 GMT
  • Disposition: Closed; Out Of Scope — TDAI 1.0
  • Disposition Summary:

    Raise issue in OARIS 2.1 RTF

    This is an OARIS Issue, raised in the wrong task force issues list.
    This has been raised as an issue in OARIS 2.1 - see https://issues.omg.org/browse/OARIS21-60

  • Updated: Mon, 25 Mar 2024 14:23 GMT

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

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

Length of subsystem parameter string types

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

    The length of the subsystem parameter string types is contrained to a maximum of 32 characters. This is not long enough to accomodate a hierarchical naming scheme with (potentially long and) meaningful names at each level.
    This issue only impacts the IDL for the DDS PSM. The specification at PIM level does not specify a maximum length.

  • Reported: OARIS 1.0b1 — Mon, 29 Jun 2015 10:29 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Increase length of parameter_name attributes

    Increase the length of the parameter_name attribute from 32 to 128 in the following classes in package Subsystem_Control
    name_value_pair_type
    parameter_name_type
    name_error_pair_type
    descriptor

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Typo in parameter for report_transmission_mode_state operation

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

    There is a typo (missing 'n') in a parameter for the report_transmission_mode_state operation in the use case Manage Frequency Usage
    trasmissionModeSetting should be transmissionModeSetting

  • Reported: OARIS 1.0b1 — Wed, 8 Jul 2015 07:42 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Fix typo in parameter name

    Change name of parameter to transmissionModeSetting from trasmissionModeSetting (add the missing 'n')

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Wrong description in Sensor Orientation resolution

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

    The description of the table for new interface for Sensor Orientation (in proposal 69) has the sensor plot detail in it, instead of the detail for the new interface.

    i.e.
    Method | Notes | Parameters
    write_sensor_plot() | This method receives a individual plot update from the sensor. It is expected to be called periodically from the sensor. | sensor_plot_type plots The set of plots

    should be
    Method | Notes | Parameters
    write_sensor_orientation() | Informs the CMS of the orientation of the sensor. | sensor_orientation_type orientation The orientation of the sensor.

  • Reported: OARIS 1.0b1 — Wed, 8 Jul 2015 13:09 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Correct text for sensor orientation

    Correct text describing the operations of the interface from that described by proposal 69 (a copy of previous section) to that as intended from the proposal description

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Inconsistent mechanisms for determining subsystem state across use cases

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

    Across several of the subsystem control, sensor control and sensor tracking use cases the mechanism for determing subsystem state are inconsistent and some cases do not allow for this without modifying the subsystem's state. CMS functionality will in many cases need to determing current state of the subsystem (without modification) - e.g. to present a control window to an operator.

    (extract from Nick Davies email - Thales)
    Looking at some of the sensor management and CMS use-cases, there seems to be 3 patterns used to obtain the state of the subsystems amongst the interfaces. Those patterns are essentially:

    • Modify/Response
      The CMS issues a modification request to the subsystem. The subsystem will then call the CMS back with the new state (or old if unsuccessful); the state published will only include the attributes that pertain to the original modify request. The callback is mapped to the original request through a request ID attribute that is present in both request and response.
    • Request/Response
      The CMS issues a report request to the subsystem. The subsystem will then call the CMS back with the current state; the state published will only include the attributes that pertain to the original report request. The callback is mapped to the original request through a request ID attribute that is present in both request and response.
    • Notification
      The subsystem notifies CMS of the current state in an unsolicited fashion, either periodically or on state change

    For each of the use-cases in detail:

    • ‘Manage Subsystem Parameters’ use-case uses both request/response and modify/response – there is no callback interface for retrieving data.
    • ‘Manage Frequency Usage’ use-case uses modify/response and Notification pattern. There is a ‘report_frequencies_state()’ method for notifying frequency state either periodically or on change, and also a ‘transmission_frequency_state’ method that reports the changed frequencies in response to a specific request. For transmission mode, however, there is only the modify/response mechanism – there is no way of discovering the transmission mode without setting a value.
    • ‘Control Battle Override’ use-case uses the modify/response mechanism – there is no way of discovering the battle override state without setting a value
    • ‘Control Emissions’ use-case uses the modify/response mechanism – there is no way of discovering the emissions state without setting a value first
    • ‘Manage Technical State’ use-case uses all three patterns – there is a modify/response interface, a request/response interface and a pure notify interface
    • ‘Manage Operational Mode’ use-case uses the modify/response mechanism and the request/response mechanism. However, the interface specifies that the response interface can also be used for ‘spontaneous’ mode change, where a request_id of 0 will be specified.
    • ‘Manage Tracking Zones’ use-case uses the modify/response mechanism
    • ‘Manage Transmission Sectors’ use-case uses the modify/response mechanism

    As you can see, only ‘Manage Frequency Usage’ (part) and ‘Manage Technical State’ provide an interface that allow the subsystems to report their state unsolicited by the CMS. ‘Manage Operational Mode’ provides a definition of where it can provide state information unsolicited, but the standard only states that it will be used when the subsystem needs to change its own state; it does not say that it will also be used when it receives a request to change state from the CMS.

    For the other use-cases, there are the following options:

    • For the use-cases where the state is atomic, assume that the last value on the topic is the current value, not matter what request caused it to be populated. This can only be used for ‘Control Battle Override’ , ‘Control Emissions’, ‘Manage Frequency Usage’ (other part), ‘Manage Operational Mode’ – the others can allow only part of the state to be reported back, depending on what request initiated the published value. This still relies on the subsystem publishing its initial value on start-up.
    • We can assume that all the interfaces use the approach specified in the ‘Manage Operational Mode’ use-case where the full state is reported on a request_id of 0. But then why not just define the interface without the request_id, always reporting all values?
    • Where a request/response interface is specified, the CMS can poll periodically for the state. This only helps us with ‘Manage Subsystem Parameters’ out of those not covered in the options so far.

    That leaves ‘Manage tracking Zones’ and ‘Manage Transmission Sectors’ where none of our options give us a mechanism for discovering the underlying state without changing it.

  • Reported: OARIS 1.0b1 — Wed, 27 May 2015 14:36 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Emphasise CMS responsibility to initiate determination of initial state

    Add paragraph below to the relevant use case descriptions (as identified in the issue).

    "It is the CMS's responsibility to initiate the determination of initial state by making a request for information to the subsystem."

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Manage Mastership has an empty topic type

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

    Following the revision to the DDS PSM mappings Manage Mastership now has empty topic types - this is illegal IDL. See OARIS-5 & OARIS-17.

  • Reported: OARIS 1.0b1 — Thu, 30 Apr 2015 15:42 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add count to manage mastership method

    Add parameter count : unsigned long to methods acquire_mastership and release_mastership.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Heartbeat Signal has an empty topic type

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

    The revised DDS mappings lead to empty topic types in the Heartbeat Signal use case - this is illegal IDL. See OARIS-5 & OARIS-17

  • Reported: OARIS 1.0b1 — Thu, 30 Apr 2015 15:36 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add count to receive heartbeat method

    Add parameter count : unsigned long to methods receive_subsystem_heartbeat_signal and receive_cms_heartbeat_signal

  • Updated: Tue, 22 Dec 2015 15:07 GMT

System Track should have a key

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

    The system track class is now being used as a topic type and thus requires a key to differentiate individual instances. (See OARIS-3 & OARIS-13).

  • Reported: OARIS 1.0b1 — Thu, 30 Apr 2015 15:29 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add key stereotype to attribute system_track_number

    The attribuite system_track_number for class system_track_type is to have a stereotype of "key". Consequently this attribute will be a key for the topic in the DDS PSM due to the PIM to PSM transformation mapping.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

receive error method from common use case interface not used

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

    The receive_error method from the common_use_case interface is not used by some of the use case service interfaces, but rather these interfaces redefine such a method themselves. The service interface use cases are:
    Provide_Health_State
    Perform_Missile_Downlink
    Perform_Illumination
    Perform_Missile_Uplink
    Register_Interest

  • Reported: OARIS 1.0b1 — Tue, 5 May 2015 11:21 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Update services to use common use case method

    Service Interfaces for use cases Provide_Health_State, Perform_Missile_Downlink, Perform_Illumination, Perform_Missile_Uplink and Register_Interest are to be updated to remove methods that are duplicates of the common use case interface.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

C++ for general_polar_volume_type does not compile

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

    The stand alone C++ mapping for general_polar_volume_type does not compile (at least for v6.4 of OpenSplice). This is because the fields within the union have the same name as as their type (also declared in that namespace). Therefore access functions hide the struct declaration below the point at which they are declared.

  • Reported: OARIS 1.0b1 — Tue, 10 Mar 2015 15:42 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Suffix all Shape_Model class names with _type to make unique

    Suffix each class name in package Shape_Model with '_type'. This is in accordance with the REG's modelling guidelines and is consistent with the rest of the specification. (Note that general_polar_volume_type already has _type suffix - no change required in that respect).

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Name clash between operation and type for transmission_frequency_state

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

    There is an operation in the CMS interface for use case Manage Frequency Usage named transmission_frequency_state and a type within the Sensor Control domain model named transmission_frequency_state_type.
    In the DDS PSM, with the generated mappings, this leads to two types named transmission_frequency_state_type. This is at best confusing and can lead to code compilation difficulties (they are generated into different, but related, namespaces).

  • Reported: OARIS 1.0b1 — Wed, 13 May 2015 12:16 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Rename manage frequency usage method as a response

    Rename method transmission_frequency_state transmission_frequency_state_response to remove the ambiguity.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Track Extractors may need to know where Radar is pointing

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

    Track Extractor functions may need to know where the (rotating) sensor which is feeding the measurements is pointing at any moment in time. E.g. to know when plots on a particular bearing would be expected to be received. There is not an interface in the OARIS specification to do this, but it is functionally coupled to the provision of plots so the plot_reporting summary use case is a natural home for it.

  • Reported: OARIS 1.0b1 — Tue, 31 Mar 2015 15:13 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Create Provide Sensor Orientation use case

    A new use case within the Plot Reporting summary use case is created (alongside Provide Plots) to provide the sensor orientation to functions such as track extraction. The use case is placed at compliance level 2.
    Following the modeling framework for OARIS, the use case interface (for the CMS) has a single method to provide the orientation of the sensor. The sensor orientation describes its angle (azimuth and optional elevation), the coordinate orientation (using enumerate from Common Types) and its time of validity.
    The coordinate orientation allows for absolute or relative interpretation of angles and defines the zero point for elevation.
    (XMI for the updated model is attached together with a document containing views of updated and new diagrams).

  • Updated: Tue, 22 Dec 2015 15:07 GMT
  • Attachments:

Technical State state transition diagrams omitted from specification

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

    The UML model for OARIS (from which the specification is generated) contains two state transition diagrams to show the mandatory and superset of transitions between technical states. However, the specification does not include these diagrams (because of the generation template used). The specification consequently lacks some of the intended semantic detail for the class technical_state_type leading to a lack of understanding from users.

  • Reported: OARIS 1.0b1 — Mon, 30 Mar 2015 13:40 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add state transition diagrams to technical state type

    The document generation should be amended to include state transition diagrams that are members of a class.
    The missing state transition diagram will thus be included in the specification.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Manage Frequency Usage classes don't all follow class naming convention

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

    The naming convention for OARIS is to suffix all classes with "_type". This was laid down in the REG's modelling guidelines. The following classes don't follow this guideline: -
    frequencies_set_request
    freqency_range_set
    all_frequencies_state
    reported_frequency_state
    selected_frequency_list
    transmission_frequency_state

  • Reported: OARIS 1.0b1 — Mon, 30 Mar 2015 08:38 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Rename Sensor Control Classes to have "_type" suffix

    All classes in the Sensor Control domain model should follow the convention and have the _type suffix. Consistency will aid understanding and usability (particularly at the programming level).
    This impacts: -
    frequencies_set_request (to be deleted by proposal 58)
    freqency_range_set (to be deleted by proposal 58)
    all_frequencies_state
    reported_frequency_state
    selected_frequency_list
    transmission_frequency_state
    and also from other use cases: -
    test_target_scenario_state
    control_emission_state
    test_target_scenario_common_parameter_target
    test_target_scenario_independent_target
    test_target_plus_scenario
    test_target
    test_target_scenario_id
    test_target_scenario

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Response to a frequency range request to be supported by the PIM

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

    In the Manage Frequency Usage use case, if the CMS requests a range of frequencies rather than a discrete set (see class frequency_set_request) then the response from the sensor subsystem does not properly model the subsystem adopting the requested state. Class selected_frequency_list contains a list of discrete frequencies. In particular a list with two frequencies in it is indistiguishable from the expected response to a request to use just those two discrete frequencies - as opposed to the range inbetween them.

  • Reported: OARIS 1.0b1 — Mon, 30 Mar 2015 07:37 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Frequency band to designate a discrete or range of frequencies

    The specification already contains an abstraction of the actual frequencies to use through the frequency band typedef. This class allows a discrete value to be mapped to particular frequencies supported by the sensor. The interface would be simplified without loss of flexibility or rigour by developing the semantics of the frequency_band_type such that it may refer to a discrete frequency or a frequency range.
    The frequency_range_set class is then redundant (as a band may refer to a range) - a range of bands does not in general make sense as it would pre-suppose some logical organisation of the discrete frequency band type that it need not have. Consequently, the frequency_set_request union class is also redundant as there would only be the single way of representing frequency state on the interface as opposed to the current two styles; removing the union is a useful simplification.
    The set_frequencies() method should both take a selected_frequency_list parameter mirroring the transmission_frequency_state() method.
    Metadata pertaining to a frequency band (e.g. whether refers to a discrete frequency or a range) can be communicated using the Manage Subsystem Parameterts use case.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

How is the set of frequencies supported by a sensor determined by the CMS

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

    It is not clear from the design of the Manage Frequency Usage use case how the set of frequencies supported by the sensor is determined by the CMS.

  • Reported: OARIS 1.0b1 — Fri, 27 Mar 2015 18:51 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Describe usage of report_frequencies_state to determine supported set

    Update use case descriptive text and figure 7.104 to describe CMS potential usage of report_frequencies_state to determine the supported set (whether available, enabled or otherwise) before further modification is made.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Semantics of sector_added unclear for use case manage_transmission_sectors

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

    The attribute sector_added :Boolean in class transmission_sector_type has no descriptive text. The semantics of this attribute are not readily deduced, nor can a coherent proposal for what they should be for all instances of the class be formed. For instance, it should be noted that the class is used both for the CMS to request a setting and for the Sensor to report its current state. Equally, there are not attributes to indicate that a sector has been or should be removed.

  • Reported: OARIS 1.0b1 — Thu, 26 Mar 2015 19:06 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Remove attribute sector_added

    Attribute sector_added from class transmission_sector_type should be removed as it is both ill-defined and also unnecessary. Both the CMS and a Sensor are able to deduce which sectors have been added, updated or removed (if necessary for their processing) as each sector has its own unique sector_id. Also, having an attribute sector_added etc. makes it possible for the data to be inconsistent - not a good feature.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Unable to create transmission mode sectors

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

    The description of the Manage Transmission Sectors use case states that sectors with a particular transmission mode can be defined. However, this is not supported in the PIM model - for instance no suitable attribute on transmission_sector_type. Also there is a typo on the bullet heading for Transmission Mode Sectors within the description for this use case.

  • Reported: OARIS 1.0b1 — Thu, 26 Mar 2015 18:41 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add transmission mode to transmission sector type

    By adding transmission mode to transmission sector type the transmission mode of a sector can be defined. The value of AUTOMATIC is suitable as a default value for the case where the CMS does not need to constrain the sensor.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Request_ack_type/error_reason_type/denial_reason_type needs more identifying information

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

    These are generic fields used to describe responses following requests. They are published asynchronously to the original request – the request and response are associated with each other using a common request ID found in each.
    The response information is a free-text String. Though this can represent useful information to convey directly to an operator, it does not allow a specific field to be identified at fault (the original request may be composed of a number of fields). Also, there may be several fields at fault.
    I would suggest the following –
    o Allow multiple denial/error reason fields to be associated with the response rather than just one
    o Add an identifier to the field, which can be a generic string. The identity will be appropriate to the original response e.g. the parameter name at fault with appropriate namespacing, or a null value if the error message refers to the whole request in general (e.g. loss of communication). The format of the error identifier should be defined in the description of the request service/topic.
    (From Nick Davies - Thales UK)

  • Reported: OARIS 1.0b1 — Fri, 13 Mar 2015 08:11 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Allow multiple error reasons with parameter identifier

    A rejecting request_ack should be able to refer to the particular fields that are at fault and to be able to identify multiple discrete errors (for requests with sets of parameters in particular - e.g. Manage Subsystem Parameters and Manage Transmission Sectors).
    A new struct class denial_type with attributes for the existing reason and zero-to-many parameter reference (new typedef of string) should be added to the model. request_ack_type then composes zero-to-many of these.
    <<idlStruct>> denial_type
    + reason : denial_reason_type
    + related_parameter : parameter_reference_type [0..*]

    <<idlTypedef>> parameter_reference_type
    (generalizes string)
    Tag: Length = 64

    compostion of denial_type by request_ack_type
    denial_type role: name = element, multiplicity 0..*

  • Updated: Tue, 22 Dec 2015 15:07 GMT

No Unknown / No Statement value for environment

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

    The sensor_track_type class does not allow a track to not have a defined environment value. Whilst the environment may be known or assumed for most cases of a naval radar track, for other types of sensor this is not necessarily the case.

  • Reported: OARIS 1.0b1 — Fri, 13 Mar 2015 22:23 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Environment should be optional in sensor_track_type

    Make attribute environment optional in sensor_track_type - environment_type then continues to enumerate actual environments and so it is possible to use this type in a non-optional (mandatory) context to define an object as being in a definite environment.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

No identity_type field on the sensor_track_type class

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

    It is inconsistent to define an identity_type field for use with system_track_type class but to then not have the option to use it with the sensor_track_type class.

  • Reported: OARIS 1.0b1 — Fri, 13 Mar 2015 22:20 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add an identity attribute to sensor_track_type

    Add an optional sensor_track_pre_identification attribute with type identity_type to sensor_track_type. This is the sensor's view of the tracked object's identity for cases where a sensor has such a capability.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Emphasise uniqueness requirement on parameter names

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

    The operation of the Manage Subsystem Parameters use case requires that the names of the parameters are unique within the scope of a particular subsystem. This is not well described in the beta specification.

  • Reported: OARIS 1.0b1 — Thu, 12 Mar 2015 13:06 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add uniqueness notes to description of parameter_name values

    The Manage Subsystem Parameter names use case requires parameter names to be unique within the scope of a subsystem.
    This should be documented for each applicable attribute in the spec (domain model classes) and in the description of the use case (service model interface)

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Error in service_indication_type IDL

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

    The IDL for this struct has an '_id' member. This is due to generation of the IDL from the PIM, with the PIM having set the navigability for the aggregation within service_indication_list_type in the wrong direction.

  • Reported: OARIS 1.0b1 — Mon, 2 Mar 2015 10:45 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Correct navigability of service indication set composition

    Set navigability to be from service_indication_set_type to service_indication_type (and not in reverse direction).

    (This will prevent _id attribute being generated in updated set of IDL for DDS PSM).

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Class descriptor contains range attribute (reserved word in Ada)

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

    Class descriptor, supporting use case Manage Subsystem Parameters, contains an attribute called range. This is a reserved word in Ada and leads to compilation errors in code generated from the OARIS model.

  • Reported: OARIS 1.0b1 — Mon, 2 Mar 2015 11:24 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Change name of attribute to parameter_range

    Change name of attribute range in class descriptor in package Domain_Model.Subsystem_Domain.Subsystem_Control to parameter_range.

    Changing the name to parameter_range is both more descriptive and consistent with other attribute names for the type (parameter_name, parameter_type & parameter_unit). It also avoids clashes with names from other language specifications.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

identification_response_type contains an 'accept' enumeration (reserved in Ada)

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

    identification_response_type from the domain model, supporting the Provide Subsystem Idenitification use case, contains an 'accept' enumeration. This is a reserved word in Ada and hence automatically generated code does not compile.

  • Reported: OARIS 1.0b1 — Mon, 2 Mar 2015 11:16 GMT
  • Disposition: Duplicate or Merged — OARIS 1.0
  • Disposition Summary:

    Fix by using Common Use Case Interface

    Remove problem classes and use Common Use Case Interface methods instead. (As per REG's Modelling Guidelines).

  • Updated: Tue, 22 Dec 2015 15:07 GMT

IDL does not explicitly define topics

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

    There are no #pragma keylist statements in the OARIS IDL. Whilst this statement does not appear to be part of the formal DDS specification, the specification recognises that there does need to be a way of doing this. By way of example the ALMAS PSM does contain keylist statements.
    However, X-Types introduces @Key as a syntax for indicating keys - better to do this.

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 10:49 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Define key fields to define object uniqueness semantics

    Attributes and roles with a <<Key>> stereotype should be defined in the Domain Model so as to define object unqiueness where such concepts exist for the defined classes.
    Classes with such semantics are sensor_track_type and possibly sensor_plot_type. Objects of sensor_plot_type are never updated, therefore all occurrence can be treated as separate instances (objects). Therefore a key is necessary for implementation and is not to be applied to sensor_plot_type (this is convenient as the sensor_plot_id_type is defined as optional).
    For topic types in general the IDL clearly identifies the Topic types and their mapping to PIM operations in the preceding comments. Therefore no further action is required for the identification and definition of OARIS topic types in general.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Heartbeat Use Case Name

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

    Heartbeat Signal in PIM but Exchange Heartbeat in Conformance and in the name of a sequence diagram

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 10:43 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Change Conformance section to align with PIM

    Change Exchange Heartbeat to Heartbeat Signal in Conformance section and update diagram name as identified by the issue. Do this by updating the EA model

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Control Interface Connection use case was redundant

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

    This use case is referenced in the activity diagrams and the compliance levels but is (no longer) present in the PIM services

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 10:40 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Remove all references to the Control Interface Connection use case

    Delete references to the use case on pages identified by Issue 1 by updating the EA model.
    Where used as a condtion for the entry state of an activity diagram, it should be replaced with the Provide Subsystem Services use case (consistent with the Compliance Level 3B diagram for instance).

  • Updated: Tue, 22 Dec 2015 15:07 GMT

IDL for sensor_track_set_type is wrong

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

    The PSM maping for sensor_track_set_type is a list of ids, whereas the operation of the interface requires that it is a list of sensor track values.

  • Reported: OARIS 1.0b1 — Thu, 29 Jan 2015 08:32 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Change relation from aggregation to composition

    A composition is a by-value relation and so the PSM mapping generates a by-value sequence for a composition

  • Updated: Tue, 22 Dec 2015 15:07 GMT

No Upper Bound for Plots a Sensor Track is based on

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

    There was modelling rule (from the REG's proposal for OARIS) that relationship multiplicities targeting sequences in the IDL PSM all had upper bounds defined. This was achieved by using a Length Tag. There is no such Tag for the 'based on' association role relating sensor_track_type to sensor_plot_type. As a consequence, implementations cannot bound the number of plots that a track may be based on.

  • Reported: OARIS 1.0b1 — Wed, 18 Feb 2015 13:24 GMT
  • Disposition: Closed; No Change — OARIS 1.0
  • Disposition Summary:

    Implementation decision to constrain number of plots a track can be based on

    It shall be an implementation decision to constrain the number of plots a track can be based on. Including such a constraint in the standard may reduce the standard's applicability and doesn't overly reduce interoperability.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Sensor Track Set is modelled as a set of ids (int values) in PSM

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

    The semantics of Sensor Track Set in the Service Model are that it should contain each Sensor Track by value. However, the DDS / IDL PSM models the class as a sequence of int - i.e. by reference to sensor track instances. Reporting by set is an alternative to reporting individual instances so it is not possible to refer to separately published instances by reference to their id/key value. (Nor does it make any sense to do so).
    This is because the relatiohship in the model is aggregation rather than compoistion and the transformation used maps this to a 'by reference' mechanism rather than a 'by value'.

  • Reported: OARIS 1.0b1 — Wed, 18 Feb 2015 13:31 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Change sensor track set relation to composition

    Change the sensor track set types aggregation of class sensor track type to be a composition (by value).

    This changes the generated IDL for the DDS PSM to generate a by value sequence, which is the intended semantic

  • Updated: Tue, 22 Dec 2015 15:07 GMT

No Upper Bound for Sensor Tracks within a Sensor Track Set

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

    There was modelling rule (from the REG's proposal for OARIS) that relationship multiplicities targeting sequences in the IDL PSM all had upper bounds defined. This was achieved by using a Length Tag. There is no such Tag for the 'element' association role relating sensor_track_set type to sensor_track_type. As a consequence, implementations cannot bound the number of tracks that may be contained in a track set.

  • Reported: OARIS 1.0b1 — Wed, 18 Feb 2015 13:26 GMT
  • Disposition: Closed; No Change — OARIS 1.0
  • Disposition Summary:

    Implementation decision to constrain size of track sets

    It shall be an implementation decision to constrain the size of track sets. Including such a constraint in the standard may reduce the standard's applicability and doesn't overly reduce interoperability.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Class Service Indication Type has unintended id field in DDS/IDL PSM

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

    In package Subsystem Control, the class Service Indication Type has an unintended '_id' attribute generated. This is because the composition on the list type is navigable in the reverse direction - leading to the generation of an unintended reference to the list, when the PIM is transformed. The composition between service list type and service name type has a similar problem in the PIM, but being an enumeration the transformation does not generate an extra attribute.

  • Reported: OARIS 1.0b1 — Wed, 18 Feb 2015 15:26 GMT
  • Disposition: Duplicate or Merged — OARIS 1.0
  • Disposition Summary:

    Reverse navigability of service indication set type composition

    The navigability of the composition of service indication type by class service indication set type should be from service indication set type to service indication type.

    Fixing this will prevent the generation or erroneous _id field in the DDS IDL PSM

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Related Parameter self relation for Class descriptor is ambiguous in DDS PSM

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

    Class descriptor in package Subsystem Control has an association with itself with a 0..* related parameter role. This is mapped to int[] in the IDL for the DDS PSM (and array of integers). The meaning of these integers is not documented in the PSM.

  • Reported: OARIS 1.0b1 — Wed, 18 Feb 2015 13:43 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Related Parameter to mean index of parameter in descriptor sequence

    The related_parameter relation is well defined by UML in the PIM. The related_parameter_id attribute in the DDS PSM IDL should have a comment that this refers to the index of the related_parameter struct within the same descriptor_sequence.element sequence.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Receive Response for Subsystem Identification

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

    Interfaces Provide_Subsystem_Identification_CMS and Provide_Subsystem_Identification_Sub both contain a receive_cms/sub_response method instead of using the common_use_case_interface.

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 13:15 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Use common use case interface receive acknowledgement in Provide Subsystem Identification

    Remove the use case specific classes and methods and use the common use case interface instead (as per the REG's modelling guidelines). This also means that language name clashes are avoided as well.
    The sequence diagrams for the use case's service interface are updated.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Receive Error for Manage Subsystem Parameters

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

    Interface Manage_Subsystem_Parameters_CMS contains method receive_error. The method in the common_use_case_interface should be used

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 13:13 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Use common use case interface receive error in Manage Subsystem Parameters

    The operation receive_error should be removed from interface Manage_Subsystem_Parameters_CMS. In the use cases sequence diagrams the receive error messages should be mapped to the operation from the common_use_case_interface (This has the same signature, so won't be apperent on diagrams only through property dialogs in the model).

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Origin for WGS84 and ECEF

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

    An 'EARTH_REFERENCED' value is required for the WGS84 and ECEF coordinate systems.

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 13:03 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Add EARTH_REFERENCED enumeration literal to coordinate_origin_type

    Add EARTH_REFERENCED enumeration literal to enumeration coordinate_origin_type. This value signifies that the origin for the coordinate system is well-defined with respect to the Earth by the coordinate system. E.g. centre of the Earth for Earth-Centred-Earth-Fixed or the WGS84 spheroid for WGS84.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Inaccuracte documentation of enumerate in coordinate_orientation_type

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

    NORTH_EAST_DOWN enumerate in coordinate_orientation_type is described as EAST_NORTH_DOWN . Also does not state applicability to Cartesian Coordinate System and EAST_NORTH_DOWN does not either (and should)

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 12:55 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Update documentation of coordinate_orientation_type enumerates

    Describe NORTH_EAST_DOWN as x = north, y = east, z = down
    State that NORTH_EAST_DOWN and EAST_NORTH_DOWN apply to Cartesian coordinate systems

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Subsystem Id Attributes are unnecessary

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

    Subsystem Ids are introduced in the DDS IDL PSM (by the tool PIM to PSM transformation). They are added to each topic type (generated from each interface method).
    DDS Partitions are a more flexible mechanism for logically partitioning multiple publishers and subscribers for the same topic.
    Note that this is an issue raised on the DDS IDL PSM, it does not affect the PIM. The PIM considers it to be a PSM concern as to how multiple actors for the subsystem role in particular are distiguished.

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 12:47 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Remove subsystem id insertion from PSM generation

    The DDS PSM generation inserts a subsystem_id attribute into each topic type. This functionality should be removed, resulting in IDL without subsystem_id attributes, simplifying the translation of the PIM to DDS. Note that this does not impact the PIM.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Sensor Track Id not a member of topic type

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

    Key fields need to be attributes of topic types (at least for some DDS implementations). Sensor Track Id is a member of Sensor_Track_Id_Type, which is not the top-level topic type.

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 12:43 GMT
  • Disposition: Duplicate or Merged — OARIS 1.0
  • Disposition Summary:

    Issue fixed by proposal for Issue 3

    Fixed by proposal 13.
    Using the //@Key notation from X-Types means that lower level types can have keys.

  • Updated: Tue, 22 Dec 2015 15:07 GMT

Heartbeat Signal Basic Flow Operations

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

    The message connectors in the Heartbeat Signal Basic Flow sequence diagram are modelled as Signals rather than Calls and are not mapped to the interface operations as is the standard for the other use cases

  • Reported: OARIS 1.0b1 — Wed, 28 Jan 2015 13:17 GMT
  • Disposition: Resolved — OARIS 1.0
  • Disposition Summary:

    Fix Heartbeat Signal Sequence Diagrams

    Update the sequence diagrams for use case Heartbeat Signal to use calls not signals and map the messages to interface operations.

  • Updated: Tue, 22 Dec 2015 15:07 GMT