TACSIT DATA EXCHANGE Avatar
  1. OMG Specification

TACSIT DATA EXCHANGE — Open Issues

  • Acronym: TEX
  • Issues Count: 33
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

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

Issues Descriptions

Add GraphQL PSM

  • Key: TEX11-60
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

Circular Dependency Between Group and Entity Payload packages

  • Key: TEX11-54
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

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

  • Key: TEX11-56
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT

Typo in EntityChangeEvent connection description

  • Key: TEX11-58
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

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

  • Reported: TEX 1.0 — Thu, 17 Aug 2023 10:33 GMT
  • Updated: Fri, 25 Aug 2023 00:15 GMT

Compositions are not intended to be reverse navigable


Aggregate Entity shouldn't compose Entity Payloads

  • Key: TEX11-50
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

Identity Enumeration doesn't have Enum attributes

  • Key: TEX11-53
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

GeodeticPosition should refer to height not altitude

  • Key: TEX11-28
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT

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

  • Key: TEX11-31
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

Type of rectangle attribute is wrong

  • Key: TEX11-46
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

Repeated base attributes in PSM Mappings for specialization inheritance

  • Key: TEX11-6
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

DDS IDL PSM files use the default namespace

  • Key: TEX11-5
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Fri, 25 Aug 2023 00:15 GMT
  • Attachments:

Don't use partitions for different clients

  • Key: TEX11-33
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 15 Aug 2023 00:22 GMT

There is no Symbol Id and Set for STANAG 5516

  • Key: TEX11-21
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 15 Aug 2023 00:22 GMT
  • Attachments:

OARIS Enumerations are out of date

  • Key: TEX11-25
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 15 Aug 2023 00:22 GMT
  • Attachments:

TEX class diagrams don't scale well


STANAG 5516 Categorization should use 5516 representation of platform identity

  • Key: TEX11-22
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 15 Aug 2023 00:22 GMT
  • Attachments:

Different users require different categorization data for the same entity

  • Key: TEX11-11
  • Status: open   Implementation work Blocked
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 15 Aug 2023 00:22 GMT

Roles should be named rather than the relations themselves


Multipoint class's points should not be ordered

  • Key: TEX11-26
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

Entities need uncertainty information for correlation functionality

  • Key: TEX11-10
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

Ambiguity and Syntax Clash for APP6C "use" Attribute

  • Key: TEX11-7
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

Shaped Entity Class missing attribute descriptions

  • Key: TEX11-9
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT

DDS Mapping for schema of extended data is unclear

  • Key: TEX11-4
  • Status: open   Implementation work Blocked
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

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

  • Key: TEX11-8
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

cargoCategory Unclear Default

  • Key: TEX11-1
  • Status: open  
  • 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

SI enum literal declared in two enumerations

  • Key: TEX11-2
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT
  • Attachments:

Arrow class has polyline description

  • Key: TEX11-3
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Tue, 25 Jul 2023 00:11 GMT

Normative or not?

  • Key: TEX-5
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Section 6.2 contains two subsections that are specified as non-normative and six subsections which are not specified at all. Is one to assume that the six that are not specified are, in fact, normative? If so, they are certainly odd in that they do not include the kinds of things that might normally be considered normative, e.g., Dependencies. If not, then the reason for specifying the two as non-normative is mysterious. Similarly, section 6.4 as a whole is specified as non-normative. What are we to conclude, then, about 6.1 and 6.3? A related issue applies to the diagrams. Section 6.2.2 is not labeled "non-normative", however, figure 6.5, which is contained in 6.2.2 is so labeled. I am not sure how to understand this. Conversely, in Section 6.2.7, which is specified as non-normative, none of the diagrams are labeled "non-normative", in stark contrast to Section 6.2.1, where all diagrams are labeled to agree with the section.
    Overall, this is minor, but the inconsistency/incompleteness of the labeling only increases the chances that a user will misunderstand the specification.

  • Reported: TEX 1.0b1 — Thu, 3 Jan 2019 13:01 GMT
  • Updated: Tue, 14 May 2019 00:09 GMT

Comment of 7.3.4Arc (Class)

  • Key: TEX-4
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    "An entity represented as a segment of the outline of an ellipse. It is defined by the ellipse it is part of and the start and end angle of the arc on that ellipse. The arc is defined in a clockwise direction from the startangle to the endangle."
    Are startangle and endangle meant to reference the attributes in the table that follows or are they meant to be known terms? They either need a space or a capital letter depending on meaning.

  • Reported: TEX 1.0b1 — Thu, 3 Jan 2019 13:01 GMT
  • Updated: Tue, 14 May 2019 00:09 GMT

Explanation on proprietary-ness

  • Key: TEX-3
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Prior to 6.2.2
    “A last (optional) channel allows both back-ends to exchange information preventing them to serve inconsistent data; this channel is, as of today, considered as proprietary but might be subject to a future standard or could use elements of TEX.”
    There is no explanation why this is proprietary or how it could be standardized? Not sure why this statement was made.

  • Reported: TEX 1.0b1 — Thu, 3 Jan 2019 13:01 GMT
  • Updated: Tue, 14 May 2019 00:09 GMT

[AB comment] Form and mispelling (trivia)

  • Key: TEX-2
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    1. There are no tables in the TOC, however section 10.6.2 Mapping has a large mapping table. This should be labeled and included in the TOC.
    2. 6.2.5 Optional Capabilities
    “Some capabilities have been considered as optional, meaning that conforming implementations are allowed not to implement them.”
    Optional does not mean that they are NOT allowed to implement them. It means that they are not obliged to do so.
    3. Several of the table rows in 7.3 cross pages. These should be modified so that they do not do so.
    4. 7.4.8 STANAG2525CCategorizationData (Class)
    The data needed for displaying the 2525C symbol set (TBD).
    What does TBD mean in this context?
    5. 7.4.9 STANAG2525DCategorizationData (Class)
    This section has several blank lines and extra carriage returns. This should be cleaned up.
    6. Is the standard APP6 or APP-6? Both are used throughout the document.
    7. The table in Section 10.6.2 needs some sub-headings.
    8. Misspelling prior to figure 6.4:
    The “TACIST” back-end or TACSIT server that serves display data to the TACSIT component. This occurs a few times in the document.
    9. 7.4.2 AISCategorizationData (Class)
    “The IMO categorisation of the cargo carried as identified on AIS”. Some British spelling has crept in.
    10. Section 10.6.1 seems to include an extra blank line between "…as NVG-formatted data." And "This PSM:"
    11. There appears to be an extra blank line between the header for 12.3 and 12.3.1.

  • Reported: TEX 1.0b1 — Thu, 3 Jan 2019 13:00 GMT
  • Updated: Tue, 14 May 2019 00:09 GMT

[AB comment] UML misuse

  • Key: TEX-1
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    1. Why the hand drawings for section 6? It should certainly possible to do this in a drawing tool or PPT.
    2. Figure 6.5
    I am not familiar with the notation of connection interfaces to interfaces to interfaces. I think that this needs some explanation.
    3. Diagram inconsistency:
    I am a little puzzled about the diagrams contained in the specification on two fronts: 1. The diagrams in sections 6.x and section 7 are stylistically different. I trust that this is intentional as one reflects "Additional Information" and the other is the actual model, but this is only an assumption. This is not a problem, but it seems odd and unnecessary. 2. The quality of the diagrams differs significantly. The diagrams in 7 are clear at significant magnification whereas the diagrams in 6.x are not. In the publication process, this should be rectified.
    4. Also, there is a use of color in the diagrams with no explanation as to what each color means.
    5. Figure 6.6
    What are the dashed boxes meant to represent? Not namespaces as stated in the text, but as they 6 packages are contained within the TACSIT package, what is the relationship with TCI and TEX?
    6. Figure 6.11 – The 'TEX and TCI' Use pattern
    What are the green and blue boxes under the TACSIT and other box? I am not familiar with this notation.
    7. 7 Data Payload Platform-Independent Model
    The word “gather” is used a few times in this section and other places. I think that “contain” would be better.

  • Reported: TEX 1.0b1 — Thu, 3 Jan 2019 12:59 GMT
  • Updated: Tue, 14 May 2019 00:09 GMT
  • Attachments: