TACSIT DATA EXCHANGE Avatar
  1. OMG Specification

TACSIT DATA EXCHANGE — All Issues

  • Acronym: TEX
  • Issues Count: 28
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
TEX11-28 GeodeticPosition should refer to height not altitude TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-53 Identity Enumeration doesn't have Enum attributes TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-48 Compositions are not intended to be reverse navigable TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-60 Add GraphQL PSM TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-25 OARIS Enumerations are out of date TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-54 Circular Dependency Between Group and Entity Payload packages TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-56 EntityRef data-type referred to as EntityType in the section heading TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-46 Type of rectangle attribute is wrong TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-5 DDS IDL PSM files use the default namespace TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-50 Aggregate Entity shouldn't compose Entity Payloads TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-58 Typo in EntityChangeEvent connection description TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-31 Update section 10.5 "DDS PSM" to take advantage of new ISO IDL4 features TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-6 Repeated base attributes in PSM Mappings for specialization inheritance TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-22 STANAG 5516 Categorization should use 5516 representation of platform identity TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-26 Multipoint class's points should not be ordered TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-33 Don't use partitions for different clients TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-21 There is no Symbol Id and Set for STANAG 5516 TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-9 Shaped Entity Class missing attribute descriptions TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-4 DDS Mapping for schema of extended data is unclear TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-8 Velocity attributes for entities don't make sense if bearing type TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-3 Arrow class has polyline description TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-11 Different users require different categorization data for the same entity TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-10 Entities need uncertainty information for correlation functionality TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-7 Ambiguity and Syntax Clash for APP6C "use" Attribute TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-17 Roles should be named rather than the relations themselves TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-32 TEX class diagrams don't scale well TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-1 cargoCategory Unclear Default TEX 1.0 $issue.fixedSpecification.name Resolved closed
TEX11-2 SI enum literal declared in two enumerations TEX 1.0 $issue.fixedSpecification.name Resolved closed

Issues Descriptions

GeodeticPosition should refer to height not altitude

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

    In an aviation context altitude conventionally refers to an barometric pressure equivalent vertical distance rather than a direct measurement of vertical distance.

  • Reported: TEX 1.0 — Wed, 5 Jul 2023 10:06 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Barometric altitude should be referred to as flight-level

    Although the OARIS standard has changed to refer to height (above mean sea-level) rather than altitude. Altitude is widely understood as height above mean sea-level .
    Barometric equivalent height for aviation should be referred to as flight level.
    Also the definition of Cartesian Position makes assumptions about the coordinate orientation and origin that are set by meta-data as well as only being approximately true in the vicinity of an appropriate origin.

  • Updated: Tue, 9 Jan 2024 19:40 GMT

Identity Enumeration doesn't have Enum attributes

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

    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.

  • Reported: TEX 1.0 — Wed, 16 Aug 2023 13:17 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Recreate Enumeration Literal Values

    Recreate the enumeration literal values for Enumerations Environment, Identity and TrackPhase.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Compositions are not intended to be reverse navigable

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

    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.

  • Reported: TEX 1.0 — Mon, 14 Aug 2023 12:36 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Introduce Directional Navigability into Compositions

    Change these compositions to be navigable only from whole to part (listed whole -> part left-to-right).
    EntityPayload -> EntityMetaData
    EntityPayload -> EntityMetaData
    AggregateEntity -> EntityPayload
    CompositeEntity -> ShapedEntity
    EntityList -> EntityRef
    Bearing -> PositionCoordinate
    (ditto all other specialisations of ShapedEntity)
    ShapedEntity -> Categorization3D
    ShapedEntity -> CategorizationData
    ShapedEntity -> ExtendedData
    ShapedEntity -> InterpolationMethodology
    GroupPayload -> EntityRef
    GroupPayload -> GroupMetaData
    GroupPayload -> EntityRelationship
    EntityRelationship -> EntityRef (both)
    GroupList -> GroupRef
    GroupMetaData -> ExtensionSchema
    GroupMetaData -> CoordinateUnits
    CoordinateUnits -> DistanceUnits (and other enumerations)
    EntityHistoryPayload -> EntityPayload
    EntityChangeEvent -> EntityPayload
    EntityChangeEvent -> EntityRef
    EntityChangeSinkEvent -> EntityRef
    GroupChangeEvent -> GroupPayload
    GroupChangeSinkEvent -> GroupPayload
    GroupChangeEvent -> GroupRef
    GroupChangeSinkEvent -> GroupRef
    EntityChangeSinkEvent -> EntityPayloadChunk

  • Updated: Tue, 9 Jan 2024 19:40 GMT

Add GraphQL PSM

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

    To support web technology-based implementations, with common technology to the OARIS, C2INav and ALMAS standards a GraphQL PSM should be introduced for TEX.

  • Reported: TEX 1.0 — Fri, 18 Aug 2023 07:42 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Create GraphQL PSM

    Add a GraphQL platform specific model as an alternative technology particular aimed at contexts using this technology and other similar web technologies.
    Base the PSM mappings on those defined for the TDAI specification, with consistent modelling of specialization / generalization hierarchies with the IDL / DDS PSM as per TEXT11-6.
    The schema is to be added to the normative machine readable files.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

OARIS Enumerations are out of date

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

    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.

  • Reported: TEX 1.0 — Wed, 5 Jul 2023 09:43 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Realign Track Phase Enumeration from OARIS

    Realign TrackPhase enumeration classifier with the equivalent track_phase_type in OARIS 2.0: remove DELETED, add INACTIVE at the end

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Circular Dependency Between Group and Entity Payload packages

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

    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.

  • Reported: TEX 1.0 — Wed, 16 Aug 2023 16:21 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Move ExtensionSchema to the Utils package.

    The ExtensionSchema class is a general utility class, so can be moved to the utils package.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

EntityRef data-type referred to as EntityType in the section heading

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

    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.

  • Reported: TEX 1.0 — Thu, 17 Aug 2023 10:02 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Change title of section to EntityRef

    The classifier is EntityRef in the model and this is how it is referred to everywhere else in the specification. The section heading appears to be an oversight or a pre-submission change made incompletely.
    Change to EntityRef

  • Updated: Tue, 9 Jan 2024 19:40 GMT

Type of rectangle attribute is wrong

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

    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.

  • Reported: TEX 1.0 — Mon, 14 Aug 2023 09:10 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Change type of NSHalfDistance to Distance

    The type of NSHalfDistance - the half distance in the North-South direction pre-rotation, should be Distance.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

DDS IDL PSM files use the default namespace

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

    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.

  • Reported: TEX 1.0 — Tue, 18 Oct 2022 07:38 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Add Root Namespace for DDS / IDL PSM

    Put existing packages within org.omg.tex namespace.
    Document this in the Data Payload DDS PSM subsection

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Aggregate Entity shouldn't compose Entity Payloads

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

    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.

  • Reported: TEX 1.0 — Mon, 14 Aug 2023 15:26 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    AggregateEntity to group entities by reference

    As the CompositeEntity class is described as being non-recursive, AggregateEntity is clearly intended to model recursive cases as well as modelling loose groupings in general.
    There should not be anything to preclude an EntityPayload belonging to more than one AggregateEntity.
    EntityPayload instances should exist in their own right and be referenced by AggregateEntities (directed association, zero-to-may at both ends)..

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Typo in EntityChangeEvent connection description

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

    Aggregation of TEXAttribute has "Liste" with a superfluous "e"

  • Reported: TEX 1.0 — Thu, 17 Aug 2023 10:33 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    *Fix Typo in EntityChangeEvent *

    Fix typo. Should be "List"

  • Updated: Tue, 9 Jan 2024 19:40 GMT

Update section 10.5 "DDS PSM" to take advantage of new ISO IDL4 features

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

    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:

    • Optional attributes are mapped to a union type with a single member present when the exists case attribute is true.
      With:
    • Optional attributes are mapped to IDL attributes of the same type annotated with the "@optional" annotation.

    Replace the bullet:

    • Specialization / Generalization PIM relationships are mapped to IDL unions. Additional data classes are introduced for generalization classes that have attributes.
      With:
    • Specialization / Generalization PIM relationships are mapped to IDL structure inheritance. All the structures that participate in a Specialization / Generalization relationship are annotated with the "@appendable" annotation.
  • Reported: TEX 1.0 — Sat, 15 Jul 2023 06:41 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Use Optional and Appendable Annotations

    The TEX specification should take advantage of the X-Types specification for the IDL/DDS PSM. This will provide additional flexibility in the future as well as more succinct and standardized definitions.
    Like the use of the key annotation with respect to topic types compatibility with older DDS implementations should be maintained. This can be done with pre-processor primitives.
    Optional attributes (and relations) in the PIM (cardinality 0..1) should be mapped to the @optional annotation in the PSM.
    Specialisations are currently mapped into a variants union. This union should be extensible, as should the enumeration that is the switch type.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Repeated base attributes in PSM Mappings for specialization inheritance

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

    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.

  • Reported: TEX 1.0 — Mon, 5 Dec 2022 10:56 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Refactor Mapping of Inheritance Relations to IDL as per OARIS

    Create a base struct and a variants union for each generalization class, with the generalization class having a base and variants attribute.
    The variants union is a union of each of specializations
    The base struct contains the attributes of the generalization class.
    This has the benefit that the base attributes can be referred to independently of the particular specialization that the object in question is, leading to simpler client code.
    This impacts class EntityPayload and its specializations in the EntityPayload IDL package and class CategorizationData and its specializations in the CategorizationData IDL package.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

STANAG 5516 Categorization should use 5516 representation of platform identity

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

    In STANAG 5516 platform identity is a one-byte numeric code defined by environment - not a two character code.

  • Reported: TEX 1.0 — Tue, 4 Jul 2023 19:52 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Change type of platform identity attribute to short

    The equivalent attribute in OARIS has type short. It would be consistent to do the same here. The documentation for attribute is already a correct distribution of how it should be.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Multipoint class's points should not be ordered

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

    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.

  • Reported: TEX 1.0 — Wed, 5 Jul 2023 09:51 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Remove ordered constraint from multipoint relation

    Remove ordered from the constrain of the PositionCoordinate role in the point relation between Multipoint and PositionCoordinate.
    Also tidy the role labels on PositionCoordinate.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Don't use partitions for different clients

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

    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.

  • Reported: TEX 1.0 — Wed, 26 Jul 2023 14:23 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Allow separate topic instances for different TACSIT instances

    This issue is also relevant to the Data Interface DDS PSM, which contains the same statement.

    In the DDS PSM, there are no client specific topic instances, therefore reference to clients here is superfluous.

    Different TACSIT instances are in effect different picture views. Each TACSIT instance should have its own set of topic instances, made unique (within the system scope) with an appropriate suffix.

  • Updated: Tue, 9 Jan 2024 19:40 GMT

There is no Symbol Id and Set for STANAG 5516

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

    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

  • Reported: TEX 1.0 — Tue, 4 Jul 2023 19:49 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Remove Symbology Tags for 5516, AIS and ADS(B)

    STANAG 5516, AIS and ADS(B) are data exchange oriented specifications; in particular they do not specify a symbology set or display representation for the data exchanged.
    Therefore the SymbolId and SymbolSet tags should be removed from classes
    AISCategorizationData, ADSBCategorizationData & STANAG5516CategorizationData

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Shaped Entity Class missing attribute descriptions

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

    The Shaped Entity class has a table of connection description but no table for its attributes

  • Reported: TEX 1.0 — Wed, 11 Jan 2023 18:12 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Insert table of Attributes for Shaped Entity

    Insert table with headings as per other classes (Attribute Notes Default) and rows for each attribute (climbAngle, directionOfMovement, isHeadingRelative, speed); content to be populated from the PIM Model as per other classes.

  • Updated: Tue, 9 Jan 2024 19:40 GMT

DDS Mapping for schema of extended data is unclear

  • Key: TEX11-4
  • Status: closed   Implementation work Blocked
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    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.

  • Reported: TEX 1.0 — Fri, 14 Oct 2022 07:38 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Schema to be reference object itself that can be included by-value

    Change the association to the ExtensionSchema class in the PIM to be a composition.
    Also make it mandatory (note that the name of the Schema could be empty if used without a formal schema).
    Also schema should be the name of the target role not of the relation.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Velocity attributes for entities don't make sense if bearing type

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

    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.

  • Reported: TEX 1.0 — Wed, 11 Jan 2023 18:10 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Shaped Entity's Velocity Attributes to be Optional

    Attributes speed, direction of movement and angle of climb should all be made optional

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Arrow class has polyline description

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

    The description for the arrow class is "An entity represented as a polyline."

  • Reported: TEX 1.0 — Wed, 20 Jul 2022 10:47 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Update description of Arrow Class

    Actually describe an arrow in its description.

  • Updated: Tue, 9 Jan 2024 19:40 GMT

Different users require different categorization data for the same entity

  • Key: TEX11-11
  • Status: closed   Implementation work Blocked
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

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

  • Reported: TEX 1.0 — Mon, 6 Feb 2023 18:08 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Categorization Data to be a struct of optional attributes

    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.
    The producer (publisher) of the entity should set all applicable categorization representations that the producer supports. Users (subscribers) process their preferred representation from the set of representations offered for the entity by the publisher.
    In the Group interface (DataSink service) querying entities should include a categorization data filter - so DataSink clients get entities with the expected kind of categorization.
    In the DDS PSM this is realised by the instantiation of a topic for each categorization kind (APP6B, 2525D, 5516 etc.); each topic instance has a different name made unique with a suffix based on the categorization kind.
    In the C# PSM the categorization kind is a parameter on instantiating a listener.
    In the HTTP PSM the categorization kind is an additional level in the request URL for an entity.

  • Updated: Tue, 9 Jan 2024 19:40 GMT

Entities need uncertainty information for correlation functionality

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

    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.

  • Reported: TEX 1.0 — Fri, 13 Jan 2023 13:20 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Add Optional Covariance to the Point Class

    Whilst OARIS provides covariance from sensor tracking, functionality to fuse information from multiple sensor would want to report remaining uncertainty in the fused information using the TEX standard.
    This should be an option when defining Point ShapedEntities.
    Add a FullCovarianceMatrix class (3D with velocity terms) to the EntityPayload package (as per OARIS 2.0) as an optional composition of the Point class.
    Define a Variance datatype in the Util package and make all attributes of the FullCovarianceMatrix class have this Variance type (note that the units of each are strictly not the same).

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Ambiguity and Syntax Clash for APP6C "use" Attribute

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

    The attribute use clashes with common software language syntax and is also ill-defined.

  • Reported: TEX 1.0 — Tue, 10 Jan 2023 15:44 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Clarify meaning of national extension character

    The current 'use' attribute corresponds to a flag indicating that the third set of 10 characters reserved for national extensions to APP6-C is to be used (i.e. characters 21 to 30 of the Symbol Identification Code (SIDC)).
    Accordingly this should be renamed to 'useNationalExtension'.
    The documentation for the attribute should also be extended to state that it relates to the national extension attributes
    The type should be Boolean

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

Roles should be named rather than the relations themselves


TEX class diagrams don't scale well


cargoCategory Unclear Default

  • Key: TEX11-1
  • Status: closed  
  • Source: BAE Systems Surface Ships Ltd ( James Apicella)
  • Summary:

    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.

  • Reported: TEX 1.0 — Tue, 5 Oct 2021 10:38 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Create and use a Cargo Category Enumeration including General Cargo

    As the valid values for this attribute are well established it is best to model this explicitly with an enumeration. Define values
    GENERAL_CARGO, CATEGORY_X, CATEGORY_Y, CATEGORY_Z, CATEGORY_OS

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments:

SI enum literal declared in two enumerations

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

    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.

  • Reported: TEX 1.0 — Wed, 16 Jun 2021 12:30 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Replace SI with actual name of the units

    Replace enum SI with Meter and MetersPerSecond in DistanceUnit and SpeedUnit respectively.

  • Updated: Tue, 9 Jan 2024 19:40 GMT
  • Attachments: