To support web technology-based implementations, with common technology to the OARIS, C2INav and ALMAS standards a GraphQL PSM should be introduced for TEX.
There is a circular dependency between the EntityPayload and GroupPayload packages. In particular this causes an issue with PSM generation.
GroupPayload package contains GroupPayload class which depends on EntityRef which is in the EntityPayload package. This is as per design.
EntityPayload package contains ExtendedData which depends on ExtensionSchema which is in GroupPayload package (and it is used in the GroupMetaData class). This is not intended.
DataType EntityRef is described in section 7.3.32 which is titled EntityType (DataType). Though it goes on to describe the classifier as EntityRef.
This is confusing.
Aggregation of TEXAttribute has "Liste" with a superfluous "e"
Most composition relations in the data model part of the PIM are modelled with navigability from the part to the whole. For example the EntityPayload section and its composition of EntityMetaData.
This causes issues with automated PSM mapping and generation as it calls for additional attributes to support such mapping, which are neither expected or required.
In the v1.0 spec AggregateEntity composes EntityPayload and ComposeEntityComposes ShapedEntity.
AggregateEntity has documentation "content grouping" which suggests that a looser, by reference relationship would be appropriate.
The strong, by-value relationship that it has, enables recursion. This is probably wrong and certainly leads to PSM implementation issues.
The Identity enumeration (and also Environment and TrackPhase) have attributes that are modelled as Properties not Enumeration Literals.
E.g. for PENDING, in the XMI it is an ownedAttribute element with xmi:type="uml:Property"
For 'properly' modelled enums an ownedLiteral element with xmi:type="uml:EnumerationLiteral" is expected.
This causes problems with PSM generation and a misrepresentation on diagrams where there is additional text 'Attributes' and the enums have a superfluous + (for public) decorator.
In an aviation context altitude conventionally refers to an barometric pressure equivalent vertical distance rather than a direct measurement of vertical distance.
The DDS PSM was defined before IDL 4 was introduced and therefore could not take advantage of features that are now part of IDL 4 but were not in IDL 3.x.
IDL4.2 is now well stablished and ISO specification as well . And moreover both OpenSource and Commercial DDS vendors support it. Therefore it makes sense to update the "DDS PSM" to use these features. This will result in more natural language mappings as well as more efficient serialization.
The recommended changes are:
In 10.5 DDS PSM perform the following edits:
Replace the bullet:
Replace the bullet:
The type of attribute NSHalfDistance is AngleUnit, which is an enumeration. This is clearly a mistake, is should be a quantity type e.g. Distance.
The PSM Mapping for DDS repeats the base attributes for classes such as EntityType in each of its specializations. Particularly as EntityType has an extensive inheritance tree this leads to inefficient code in the users of the interface.
There is no TACSIT or TEX root namespace for the IDL modules. This means that there is potential to clash with applications code as well as causing confusion.
Section 12.2 (DDS PSM) states that partitions are used to identity (s/b identify) different TACSIT and client instances. An alternative, valid model is to have different separate topic instances for different TACSIT and client instances.
In particular, the DDS security model doesn't work well using partitions. It is better to have separate topic instances then each instance can have its own permissions.
STANAG 5516 is a platform to platform data exchange specific not a user display oriented standard. Therefore the SymbolId and SymbolSet tags do not apply to this class
In the Util package there are 6 enumeration classifiers marked as being derived from the OARIS standard. These were 'forked' from the OARIS 1.0 standard and at least some (e.g. TrackPhase) have changed in later OARIS revisions. These should be realigned for consistency.
Several of the Class Diagrams at the Figures in section 7, 8 & 9 don't scale well, such that the text within the classes and on the relations is not very readable.
In STANAG 5516 platform identity is a one-byte numeric code defined by environment - not a two character code.
Different users (e.g. actual operators or other client software such tactical decision aids) may require / prefer different categorization representations. However, the Entity data model forces a choice of selecting a single option on the publisher.
Consequently, the logic for how to convert between different representations may become spread around different components of a system.
A better system architecture is to have knowledge and functionality with the producer of the data. That component can best judge the equivalence of different representations in the context of their own data.
This is a PSM issue; the DataSink interface has an EntityQuery filter that can be used to specify the Categorization variant in a PSM that actively services the request (i.e. isn't publish/subscribe). For a pub/sub PSM such as DDS it would be necessary to anticipate the Categorization demands in advance (when publishing), so that all variants are published.
Therefore, the needs of this issue can be satisfied by having the DDS PSM of the DataSink interface publish Entities ...
In class diagram "EntityPayload 2 of 2" in particular relations are named (e.g. center) whilst properly it is the role than such names refer to.
The semantics of a multipoint (no implied line between consecutive points) implies that they are unordered. Therefore the relation should not have an ordered constraint applied.
To support tactical decision aid functionality (see www.omg.org/spec/TDAI) and track correlators in particular, TEX entities need to contain uncertainty information as a first-class property; e.g. covariance matrices.
The attribute use clashes with common software language syntax and is also ill-defined.
The Shaped Entity class has a table of connection description but no table for its attributes
The DDS IDL for the schema of extended data is
"ExtendedData__id_type _id;"
This is missing the name, missing description and is an inappropriate underlying type - int. It would be natural to refer to a schema through a schema prefix.
The speed, direction of movement and climb angle attributes of shaped entities are generally unknown and do not make sense if that entity is a bearing type. However, in the model they are mandatory attributes so have to be supplied.
AISCategorizationData cargoCategory is defined as "The IMO categorization of the cargo carried as identified on AIS" however IMO categorization only gives letters to hazardous cargo and does not give a value for non-hazardous cargo therefore a default needs to be decided. Also since 2008 the IMO categorization has changed from "A, B, C, D" too "X, Y, Z, OS" which no longer works as a char type.
SI is an enum literal attribute in the DistanceUnit and SpeedUnit enumeration classes. When mapped to C++ and other languages (e.g. through the IDL to DDS mapping for the TEX DDS PSM) this is a namespace clash and a compilation/build issue.
The description for the arrow class is "An entity represented as a polyline."
