The class plot_summary_type was expected to be a topic type, but it isn’t mapped to an operation in the PIM – so it isn’t. We need to add a suitable operation to the Provide_Plots or Provide_Sensor_Orientation interface.

The PSM section of the document was omitted from the submission and should be re-instated

The syntax for an optional string (parameter_range: string [0..1]) can cause confusion to parsers of the XMI as to whether the syntax is for being optional or fixed length.
Optional strings would be better defined as an optional TypeDef.

This affects parameter_range and typical_value in the descriptor_type struct within Subsystem_Domain -> Subsystem_Control

The relationship between plot_association_type and sensor_track_type should be a composition such that the sensor track contains a collection of plot_association_type objects rather than a collection of references which can not be resolved as the plot_association_type does not have an id and is not published separately on another topic.

The plot_association_type contains both a plot_subsystem attribute and a plot_id attribute which contains a subsystem_id attribute.

These both refer to the same piece of information and therefore one is redundant and should be removed.

The exported XMI from the EA model has been generated with the option selected to alphabetically sort the attributes in the model. This does not affect the word specification but does impact the XMI and IDL.

The sequence diagrams for Mastership Acquisition and Mastership Release show receive_acknowledgement and receive_error in response to acquire_mastership and release_mastership. However, acquire and release have no request_id to respond to. Recommend adding request_id and subsystem_id keys to acquire and release mastership.

Section 8.2 mandates how topics and partitions should be used to include different subsystems into an OARIS based system.

However the approach mandated is not the only approach and other approaches may be used and be more suitable for a given use case. This section should be re-written to provide some guidance examples rather than mandates

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.

Sparx Enterprise Architect A (build v 16.1..1626) reports that the OARIS v3 beta (also v2 beta) XMI document is in XMI Version 1.1 - which is no longer supported by recent versions of EA.

Suggest specifying XMI 2.1 schema in source tooling and reissuing for compatibility.

The acquire and release mastership messages have only a "count" field. There is no way for the radar to determine which system is requesting or releasing mastership. The radar needs to know the identity of the master when reporting mastership. Suggest adding a subsystem ID to acquire and release mastership messages.

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.

Can this please be checked. Looking at OARIS v1.1 changebar this documents the changes from v1.0 to v1.1. The changebar document published on v2.0 should therefore be the changes from v1.1 to v2.0. The document published shows the changes from version v2.0 to v3 beta 1

The C2INav Model refers to a package defined by OARIS 1.1.
OARIS 2.0 is about to be published and there are 2.1 RTF & 3.0 FTF in progress.

The description of the NORTH_DOWN in coordinate_orientation_type says:

Valid for Polar Coordinate Kind
Azimuth has origin (0.0) at North, clockwise positive, measured in the horizontal plane
Elevation has origin (0.0) when pointing directly down, and 180.0 degrees when pointing directly up, measured in the vertical plane.

This would be fine except the elevation_coordinate_type specifically says units are radians with values from -PI/2 to +PI/2.

I suggest changing the maximum value of elevation in the description of NORTH_DOWN from 180.0 degrees to PI radians and change the maximum value of elevation_coordinate_type from +PI/2 to +PI.

The OARIS 2.0 specification says registration includes information on:

• The service for which the actor wants to register / deregister his interest
• The information within the service for which the actor wants to register / deregister his interest
• The intended (direct or indirect) recipient(s) of the information provided by the subsystem
• Any parameters of the provision needed such as Quality of Service parameters

But according to the IDL, register_interest_type contains a sequence of interest_type, which contains only the registration type (REGISTER or DEREGISTER), the recipent, and quality of service. The message has no way to specify a service or information within a service; the first two bullet points in the requirements above.

The specification and the file Perform_Splash_Spotting.idl have multiple misspellings of spotting as "splotting". For example, confirm_reposition_splash_splotting_area, receive_splash_splotting_area_position, receive_splash_splotting_area_track.

Searches can potentially take a long time, there is no message/interaction to stop one once its in progress. Suggest adding a stop_cued_search as with stop_surveillance.

The sensor orientation message reports the orientation of the sensor relative to a specified coordinate system. However, if a radar has multiple sensors there is no way to distinguish between them. I suggest adding an optional sensor_id field (type short) to distinguish between multiple sensors.

Range rate type limited to 0-1e5, this should also accept negative values for closing rates. Also an issue in version 3 beta.

range_rate_type is used to quantify the rate of change of the range. The range of allowed values is 0.0 to 1e5, but this is too restrictive. Range rate is negative when an object is getting closer to the origin, i.e. the range is decreasing so range rate is negative. The lower bound of range rate should be -1e5, the negative of the maximum value.

The specification and Sensor_Assessment.idl have multiple misspellings of "equipment" as "equipement". All of the misspellings are in types and structs related to sensor_plot_equipement_assessment.

system_track_type does not contain identity or classification

The sensor orientation message reports the orientation of the sensor with two angles: azimuth and elevation. But to completely describe orientation, three angles are required. The missing angle is a rotation about the normal from the array. It can becalled a clocking angle. Using azimuth and elevation correspond to Cardan angles, which describe orientation as heading, elevation, and bank. The missing angle in this system is the bank angle. See https://en.wikipedia.org/wiki/Euler_angles

These tags are meaningless in the specification.

I am trying to download the OARIS v1.1 XMI file but I am getting a http error 404 - Page not found message when clicking on the link provided (https://www.omg.org/spec/OARIS/20190301/OARIS%20PSM%20XMI.xml) under the OARIS v1.1 page (https://www.omg.org/spec/OARIS/1.1)

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.

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.

An important aspect of sensor performance estimation is to understand bias particularly for atmospheric effects.

.

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

This is a useful mode of operation ...

Perform Offline test should be compliance level 3A not 3B

The DDS topic types for PIM operations acquire_mastership and release_mastership are both missing from the IDL. Additionally request_id is a missing parameter from these operations, as otherwise the receive_acknowledgement operations in the sequence diagrams have an undefined source of request_id.

There are two activities "Define Test Target Scenario" & "Control Test Target Facility" for one interface

to be elaborated ...

...

For example CORBA, ALMAS & AMSM

...

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

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

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.

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

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

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

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.

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.

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.

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.

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

(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!

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?

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,

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

there are several instances where the IDL generated from the XMI has String (capitalised) rather than in lower case which causes an error in some DDS IDL compilers. These should be generated as lower case in the following files:
Manage_Network_Participation.idl
Plot_Reporting.idl
Track_Reporting.idl
Label_Tracks.idl

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

The IDL4 language introduced the @optonal annotation that indicates that a structure member is optional. This is also supported by DDS-XTYPES. For example:

// radians per second
typedef double azimuth_rate_type;
// radians per second
typedef double elevation_rate_type;
// meters per second
typedef double range_rate_type;

struct polar_velocity_type            {
    // The rate of change in azimuth corresponding to the velocity
    azimuth_rate_type azimuth_rate;
    // The rate of change in elevation corresponding to the velocity. 
    // Optional as some sensors provide no elevation information
    @optional elevation_rate_type elevation_rate;
    // The rate of change in range corresponding to the velocity. 
    // Optional as some sensors provide no range information
    // (e.g. most passive sensors)
    @optional range_rate_type range_rate;
};

The OARIS IDL does not take advantage of this. Instead, it uses an older pre-IDL4 idiom using an extra "union" type. For example:

// radians per second
typedef double azimuth_rate_type;
// radians per second
typedef double elevation_rate_type;
// meters per second
typedef double range_rate_type;

// a simple union type, to represent an optional value
union polar_velocity_elevation_rate_type switch (boolean)       {
    // the value when present
    case TRUE : elevation_rate_type value;
};

// a simple union type, to represent an optional value
union polar_velocity_range_rate_type switch (boolean)            {
    // the value when present
    case TRUE : range_rate_type value;
};

// Velocity defined in a polar reference frame as a described by a coordinate
// specification object
struct polar_velocity_type            {
    // The rate of change in azimuth corresponding to the velocity
    azimuth_rate_type azimuth_rate;
    // The rate of change in elevation corresponding to the velocity. 
    // Optional as some sensors provide no elevation information
    polar_velocity_elevation_rate_type elevation_rate;
    // The rate of change in range corresponding to the velocity. 
    // Optional as some sensors provide no range information
    // (e.g. most passive sensors)
    polar_velocity_range_rate_type range_rate;
};

The extra union types result in more code generated to serialize and deserialize the data, increasing the size of the binary and decreasing performance.

Moreover, the use of the @optional annotation allows for a more natural and optimized language mapping. For example, the recent IDL to C++ mapping maps optional members to the standard std::optional which is more natural for a C++ programmer.

Some of the IDL files contain the construct:

#pragma keylist ...

This annotation is specific to OpenSplice. It comes from a time before there was a standardized way to indicate DDS keys. It is not standard not supported by other DDS vendors.

With the adoption of DDS-XTYPES and later IDL4 there is now a standard @key annotation supported by the recent versions of DDS from all the vendors.

Moreover, the maintainers of OpenSplice are now focused on a new codebase (Cyclone DDS) and recommending users to migrate to it (see
https://github.com/ADLINK-IST/opensplice), and Cyclone DDS also supports the @key annotation as described in https://cyclonedds.io/content/guides/supported-idl.html.

Given all this, the #pragma keylist annotation should be removed.