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

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

Using the value ESTIMATED for both accuracy_derivation_type and navigation_derivation_kind_type causes problems in some programming languages; it is also better practice to be more descriptive.

Using the value ESTIMATED in accuracy_derivation_type and navigation_derivation_kind_type causes problems when mapped to some programming languages; it is also better practice to be more descriptive.

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 IDL shipped with this specification uses @Key but that should be @key, IDL is case sensitive and DDSXTypes/IDL42 define @key, all lower case

Change IDL to use @key

IDL 4.2 & DDS X-Types defines the annotation as @key (lower case).
See section 8.3.2.1 of IDL specification v4.2
Update the relevant PSM files accordingly

Some but by now means all of the Issue Resolution from FTF-1 are applicable to the GraphQL PSM. These should be determined and applied as appropriate.

Generate new GraphQL PSM Schema from the PIM

The 1-1 FTF did not apply PIM changes to the GraphQL PSM. Furthermore the proposed schema mapping was in practice less than optimal for specialization-generalization relationships, leading to a complicated mapping in many GraphQL software language clients.
This proposal uses an improved mapping where there is a base type for common attributes and union for the specialized attributes.

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

Regenerate GraphQL PSM with updated mapping

The updated mappings from PIM to GraphQL as incorporated into the TDAI beta spec should be used.

Unlike other parts of the data model there isn't the capability to model the accuracy of (water) depth information.

Add Depth Accuracy Class

Add a depth accuracy class, which is a specialisation of navigation accuracy
It should have an optional attribute for each of the depth report class' optional attributes.

The inclusion of surge/sway/heave & the associated rates under Attitude::offset_report_type seemed slightly odd at first glance. I would have expected these to be more logically included as variations in Position, not attitude. (Albeit typically measured using a different frame of reference). But I can also see a counter-argument that says as surge/sway/heave are normally assessed in terms of current platform attitude, it’s a more logical place. I guess it comes down to whether you’re interested in position on a macro scale or a micro scale ? On the macro scale you probably don’t care so much about headings at all … on the micro scale you absolutely do. I don’t’ know whether the specs or their requirements make any indication about their intended use and associated limitations ?

Explain rationale for attitude and position packages

Explain that services relating to the micro-scale are in attitude and that services relating to macro-scale are in the position

The structs intended to be topic types in the DDS/IDL mapping are missing their key declarations. Consequently the intended DDS API for the mapping from the PIM is not generated.

Add key definition to the intended topic types

Add @Key stereotype if using DDS X-Types (according to pre-processor variable) and a keylist pragma otherwise for each topic type with respect to its keys.
Topic types are
attitude_rotation_type,
attitude_rotation_rate_type,
position_offset_type,
velocity_offset_type,
depth_report_type,
own_position_type,
own_velocity_type,
own_acceleration_type,
navigation_covariance_type,
request_default_navigation_data_type,
request_custom_navigation_data_type,
request_covariance_type

Reporting::navigation_request depends on Attitude::measurement_kind;
Attitude::offset_report depends on Reporting::navigation_report

This means that the DDS API does not cleanly generate from the IDL

Move navigation_request_type to a new package Requests

Break the circular dependency by moving the type involved to a new sibling package
Create a new package 'Requests' in Navigation_Domain that contains navigation_report_type.

In Attitude.idl struct offset_report_type is declared out of order. This means that the DDS API does not cleanly generate.

Superceded as offset_report_type attribute now inlined

To allow for keyed attributes needing to be top-level the attributes of abstract type offset_report_type are proposed to be inlined into the classes that inherit from it in the DDS/IDL PSM mapping.
Therefore no particular change is required in response to this observation as the struct is not present in the new mapping proposed.

The IDL has missing import statements such that the DDS API cannot be cleanly generated.
import "Navigation_Domain.idl" is missing from "Attitude.idl"
import "Attitude.idl" is missing from "Ext.idl"
import "Navigation_Domain.idl" and "Reporting.idl" are missing from "Position.idl"

Add Missing Include Statements

Add include statements as per observation

So that application can bound the size of their data structures dynamically sized types should have a maximum size.
A maximum string length of 32 should be added to attribute specific_system in class navigation_report_type.

Add Length Tag to Specific_System attribute

Add Length Tag, value = 32, to Specific_System attribute in struct navigation_report_type

The Beta generation scheme included a version comment for each class. This is inappropriate as there isn't a sense in which classes can be independently versioned.

Remove Version Numbers from IDL Type Definitions

Remove version number from the head of the comments for each type definition

Although this is legal IDL, it is confusing and also couples import dependency in a non-functional way and so non-ideal. The generation scheme should be changed so that the file names are unique and each module has its own file.

Use full module path in IDL filenames

Use full path in module filenames and hence include statements as well.

To allow applications to bound the size of their data structures dynamically sized data structures should have a bounding size.
The composite_contributors attribute of class navigation_report_type should have a Length tag, size = 6

Add length tag to composite contributors

Add length tag value = 6 to composite contributors attribute

To be clear on the meaning notes/comments should be added to each of the literals of navigation_report_kind_type in the IDL/DDS PSM (implementation is PSM specific).

Add notes to the literals

Due to need to also reference the keys for specialised topics the relevant enumeration in the PSM mapping is now navigation_report_key_kind_type. The class navigation_report_kind_type is now a struct with an attribute of this enumeration.

A note of the form
"The literal for referencing the

specialisation of navigation_report_type." to each attribute

There are no explanatory notes to qualify the meaning of the relation from navigation_covariance_type to navigation_report_type.

Add notes to report relation of navigation_covariance_type

Add descriptive notes

Unlike other reports from the Navigation subsystem a Depth Report does not inherit from navigation_report_type even though it should be qualified by the attributes of navigation_report_type.

*depth_report_type to Inherit from navigation_report_type *

Add an inheritance of navigation_report_type from depth_report_type

To enable static calculation of memory requirements in applications using the standard sequences should be bounded.

Add length tag to bound report_id sequence

Add a length tag, value = 6 to the association from navigation covariance type to navigation_report_type with role report.
This means that sequence navigation_report_kind_sequence_type has a bound of 6 elements

Some but by now means all of the Issue Resolution from FTF-1 are applicable to the GraphQL PSM. These should be determined and applied as appropriate.

Determine GraphQL PSM changes in FTF-2

GraphQL PSM changes should be determined and applied in FTF-2, when there will be the opportunity to validate them with respect to a more mature implementation.

Rotations should be measured relative to the centre of rotation - otherwise actual rotational motion has to be described by additional translational motion, leading to a more complicated description of motion than is necessary.

Describe Rotation Relative to the Center of Rotation

The descriptions of pitch, roll, yaw and their respective rates is with reference to the platforms reference point. In the case of these attributes it should be with reference to the center of rotation, which is not necessarily the same.

The 'inherit' relation 'implementation defined' for navigation_report_kind_type is miss-spelled (missing first 'e').

Correct typo in navigation_report_kind_type

Change inheritance to "implementation defined" for class navigation_report_kind_type.

The accuracy compositions for attitude, offset, position and their rate classes is missing Notes/Documentation.
This should be added so that the meaning is clear and the information provided by the specification and associated PSM files is consistent and uniform.

Add accuracy descriptions into PSM files

In the specification document compositions are shown in the diagrams rather than tables. Notes associated with compositions are shown in the generated PSM files such as IDL.

In the supporting modelling tool (auxiliary file) the rotation parameter of the write_rotational_attitude operation does not have its classifier entered correctly. This means that it appears as a built-in type in the XMI and IDL generated from the XMI is incorrect.

Fix parameter assignment in XMI model

Assign class from pick-list rather than the typed-in text

To allow application to statically size (bound) their data structures variably sized datatypes should have a tag to bound the size.
Accordingly navigation_covariance_type should have a Length tag.
The maximum value = 253
(sum(3n+1; n=7) = 22 * 23 / 2) (as there are seven topics each with three values - plus time that can contribute to the covariance; this is very much a worst-case upper bound)

Add Length Tag to covariance value attribute

Add Length tag value = 253 as per issue description

State that sequences are bounded in the IDL PSM

Section 8.1 states that IDL files defined by OARIS, but referred to by this spec are in the OARIS distribution, but it does not specify which files. It would be helpful to do so.

State the IDL dependencies from OARIS explicitly

Refer to Time Base, Common Type and Coordinates and Positions

Overloaded operation names are not legal with the PSM mapping as this leads to duplicate type declarations.

Rename operations to be unique

rename request_navigation_data with 2 params to request_default_navigation_data
rename request_navigation_data with 3 params to request_custom_navigation_data

To enable applications to static determine their memory requirements sequences in the standard should be bounded with a maximum length

Add bound for navigation_report_sequence_type

Add tag Length: value = 6 to class navigation_report_sequence_type

The type of the reference from navigation covariance type to navigation_report_type is long, but the key for the topics is composite - and there is more than one topic. The mapping from a long to an individual topic instance is ill-defined.

Map associations to the relevant key types rather than long

In the current IDL/DDS PSM mapping referencing associations are mapped to a long value which is used to index the topic instances (such references must be to a topic type).
Many C2INav topics have composite keys - typically an enumerate and a Boolean. The mapping to long is ill-defined.
Each associated instance should be mapped to a key value, or set of values where there are multiple keys.
Where the association is to a generalisation a union of the possible key types of the specialisations should be used.
One-to-many associations should map to a sequence of such values.

Attributes of offset_report_type and navigation_report_type are declared with the key stereotype. However in the DDS PSM these attributes of these abstract type are encapsulated into struct members for each level inheritance so that the key attributes are no longer top level in the concrete topic types.

Inline attributes from abstract base types into topic type specialisations

Inline the attributes from navigation_report_type and offset_report_type into the types that are derived from them
attitude_rotation_type,
attitude_rotation_rate_type,
position_offset_type,
velocity_offset_type
(both base types)
depth_report_type,
own_position_type,
own_velocity_type,
own_acceleration_type
(navigation_report_type_only)