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.

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

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

Fix typo in parameter name

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

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.

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

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.

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

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

Add count to manage mastership method

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

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

Add count to receive heartbeat method

Add parameter count : unsigned long to methods receive_subsystem_heartbeat_signal and receive_cms_heartbeat_signal

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

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.

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

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.

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.

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

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

Rename manage frequency usage method as a response

Rename method transmission_frequency_state transmission_frequency_state_response to remove the ambiguity.

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.

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

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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)

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

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.

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.

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.

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.

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.

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)

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.

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

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.

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.

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.

Fix by using Common Use Case Interface

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

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.

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.

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

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

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

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

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.

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

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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

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

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

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.

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)

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

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.

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.

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.

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.

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

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.