1. OMG Mailing List
  2. GEMS 1.6 Revision Task Force mailing list

Open Issues

  • Issues not resolved
  • Name: gems-rtf
  • Issues Count: 26

Issues Summary

Key Issue Reported Fixed Disposition Status
GEMS16-4 Boolean type is named inconsistently within specification. GEMS 1.5 open
GEMS16-5 Unexpected spaces are shown in Example Format table GEMS 1.5 open
GEMS16-13 Unexpected character in utime field table GEMS 1.5 open
GEMS16-14 Example for utime is missing prepended portion GEMS 1.5 open
GEMS16-19 Fix incorrect heading levels GEMS 1.5 open
GEMS16-18 Currently supported versions are missing GEMS 1.5 open
GEMS16-21 Clarify time parameter descriptions GEMS 1.5 open
GEMS16-24 Fix Response Message specification GEMS 1.5 open
GEMS16-10 Clarify device definition files GEMS 1.5 open
GEMS16-17 Missing GEMS-ASCII PSM specifications GEMS 1.5 open
GEMS16-6 Array notation in example appears wrong GEMS 1.5 open
GEMS16-23 Fix Example GEMS-ASCII Message Lengths GEMS 1.5 open
GEMS16-11 UML message classes with no Use Cases defined GEMS 1.5 open
GEMS16-20 Grammar, typo, and formatting errors GEMS 1.5 open
GEMS16-22 Clarify the Standard ASCII Header GEMS 1.5 open
GEMS16-7 Example of GEMS Device Definition File not on OMG website as mentioned in spec GEMS 1.5 open
GEMS16-15 AsyncStatusMessage is missing in the XML PSM schema GEMS 1.5 open
GEMS16-16 UnknownResponse is missing in the specification and ASCII PSM GEMS 1.5 open
GEMS16-2 Collection of items found in V1.4 specification GEMS 1.5 open
GEMS16-3 Terminology between picture and text is confusing GEMS 1.5 open
GEMS16-1 Extend PIM to allow "leaf" values to be referenced directly GEMS 1.3 open
GEMS16-50 Link for GEMS 1.5 is pointing to GEMS 1.4 document GEMS 1.5 open
GEMS16-49 GEMS XML Version Attribute Type Mismatch GEMS 1.4 open
GEMS16-8 Clarify use cases and association with implementations GEMS 1.5 open
GEMS16-12 Additional data type of time_duration GEMS 1.5 open
GEMS16-9 Describe how directives can be used to access leaf values GEMS 1.5 open

Issues Descriptions

Boolean type is named inconsistently within specification.

  • Key: GEMS16-4
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    The boolean type is inconsistently identified as 'bool' once within the GEMS 1.5 specification document. The name of this data type should be consistent throughout the specification.

    The PIM calls the boolean type "boolean".
    The XML PSM calls the boolean type "boolean".

    However, the ASCII PSM calls the boolean type "bool" on page 61 in section 8.2.1.1 table 8.1 within the Example Format column and calls the boolean type "boolean" in the example mixed_set message on page 62 in section 8.2.1.2.

  • Reported: GEMS 1.5 — Fri, 18 Feb 2022 15:35 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Unexpected spaces are shown in Example Format table

  • Key: GEMS16-5
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Table 8.1 includes spaces where they are not expected.

    "param:double=1 0.12" should be "param:double=10.12"
    "param:short=-1 2" should be "param:short=-12"

  • Reported: GEMS 1.5 — Fri, 18 Feb 2022 16:35 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Unexpected character in utime field table

  • Key: GEMS16-13
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Following text:
    Z - the character “Z” denotes GreenwichMean
    Time (GMT).

    should not contain a box character after Greenwich. Suggest changing text to:

    Z - the character “Z” denotes Greenwich Mean
    Time (GMT).

  • Reported: GEMS 1.5 — Wed, 4 May 2022 13:01 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Example for utime is missing prepended portion

  • Key: GEMS16-14
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    utime example is shown as '2009-273T09:14:50.02Z'
    However, all GEMS-ASCII fields should be formatted as: parameter_name:parameter_type=parameter_value

    Therefore, the example should look like:
    param:utime=2009-273T09:14:50.02Z

  • Reported: GEMS 1.5 — Wed, 4 May 2022 13:04 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Fix incorrect heading levels

  • Key: GEMS16-19
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Sections 6.3.3.5, 6.3.3.6 and 6.3.3.7 have the wrong heading level - should not be headings at all, but rather paragraphs under 6.3.3.4.

  • Reported: GEMS 1.5 — Wed, 11 May 2022 15:50 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Currently supported versions are missing

  • Key: GEMS16-18
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Add versions 1.3 and 1.4 to the "currently supported versions".

  • Reported: GEMS 1.5 — Wed, 11 May 2022 15:46 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Clarify time parameter descriptions

  • Key: GEMS16-21
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    The "time" parameter in Table 8.1 indicates 9 places for seconds (decimal), however any contemporary UTC time needs 10 places for seconds (see examples from GEMS web site).

    For the "utime" parameter in Table 8.1, clarify the description for:
    ss - seconds (00-59), and
    [.nnnnnnnnn] - nanoseconds (9 digit number).

  • Reported: GEMS 1.5 — Wed, 11 May 2022 16:06 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Fix Response Message specification

  • Key: GEMS16-24
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Add the missing "Field Delimiter" and "Standard Trailer" to the end of the Response Message specification in Table 8.3.
    Field Delimiter is the pipe character, and the Standard Trailer is the "END" field.

  • Reported: GEMS 1.5 — Wed, 11 May 2022 16:38 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Clarify device definition files

  • Key: GEMS16-10
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    During the March 23, 2022 GEMS RTF Meeting, the RTF members agreed to update sections 6.2.10, 6.9, 7.5, and 8.5 to clarify that the device definition file is optional, and when it is provided by the device vendor, can be retrieved through various methods, e.g. manually from the vendor via some form of electronic media, file transfer, product information, or programmatically via API request.

    Update section 6.9 to clarify that device definitions cover both read-only/GET and read-write/SET parameters. Update the second bullet in section 6.9 to explicitly call out the "Get Definitions", i.e. "List of Parameter Get Definitions or Parameter Set Definitions".

    State that the device definition file typically comes in XML format for the sole purpose of accurately describing device capabilities, and that it applies to both the ASCII and XML PSMs.

    Describe that the device definition file may contain additional device capabilities such as:

    • Async Status Message support
    • Save Configuration Message support
    • Restore Configuration Message support

    Ensure sections 6.2.10, 6.9, 7.5, and 8.5 contain helpful references among one another to aid understanding.

  • Reported: GEMS 1.5 — Wed, 23 Mar 2022 21:30 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Missing GEMS-ASCII PSM specifications

  • Key: GEMS16-17
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Add the GEMS-ASCII PSM schemas for the following:

    • PingMessage
    • PingResponse
    • MessageSequence
  • Reported: GEMS 1.5 — Wed, 11 May 2022 14:57 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Array notation in example appears wrong

  • Key: GEMS16-6
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Parameter set example shows array notation after the type field:
    setlist:set_type[2]=A:hex_value=FA/7;B:string[2]=text1,text2;,A:hex_value=2F/6;B:string[1]=text2;

    Though in section 8.2.1, array notation is defined after the parameter_name:
    parameter_name[3]:type=value1,value2,value3

    This seems inconsistent/confusing.

  • Reported: GEMS 1.5 — Fri, 18 Feb 2022 17:03 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Fix Example GEMS-ASCII Message Lengths


UML message classes with no Use Cases defined

  • Key: GEMS16-11
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    PingMessage and PingResponse appears in UML but not in Figure 6.1 nor text of Section 6.2.

    GetConfigListMessage and GetConfigListResponse appears in UML but not in Figure 6.1 nor text of Section 6.2.

    DisconnectMessage appears in UML and Figure 6.1 but not in text of Section 6.2.

    MessageSequenceResponse appears in UML but not in Figure 6.1 nor Section 6.2, nor in either PSM

    Update Figure 6.1 (GEMS Use Cases) to include missing messages, and update other sections and figures per above.

  • Reported: GEMS 1.5 — Thu, 24 Mar 2022 17:52 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Grammar, typo, and formatting errors

  • Key: GEMS16-20
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Section 6.5 typo "messages are structure as" vs "messages are structured as".

    Section 8 should be "PSM (ASCII)" not "PIM (ASCII)".

    Table 8.2, row "Transaction ID" column "Comments" - formatting error. The extra line break character after the word "message" makes the last word ("correlation") wrap outside the table cell boundary and therefore difficult to find. Fix formatting error.

  • Reported: GEMS 1.5 — Wed, 11 May 2022 15:57 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Clarify the Standard ASCII Header

  • Key: GEMS16-22
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Change the description of Table 8.2 from "Standard Request Message Fields" to "Standard header" since it is the ASCII standard header as referenced throughout section 8.

    Change the reference "<See Table 9.2>" to "<See Table 8.2>" in the first row of Table 8.3 for Standard Header to match all other references. Table 9.2 does not exist.

  • Reported: GEMS 1.5 — Wed, 11 May 2022 16:18 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Example of GEMS Device Definition File not on OMG website as mentioned in spec

  • Key: GEMS16-7
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Section 7.5.1 states that there is an example GEMS Device Definition File on the OMG website, though Examples are not available. The example file on the Space Wiki also does not appear to include an example definition file. The website or reference should be updated.

  • Reported: GEMS 1.5 — Wed, 2 Mar 2022 13:30 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

AsyncStatusMessage is missing in the XML PSM schema

  • Key: GEMS16-15
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Add schema to section 7.2.1.27 AsyncStatusMessage.

  • Reported: GEMS 1.5 — Wed, 11 May 2022 13:38 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

UnknownResponse is missing in the specification and ASCII PSM

  • Key: GEMS16-16
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    Add the missing "UnknownResponse" message to the PIM in section 6.3 and to the ASCII PSM in section 8.2.

  • Reported: GEMS 1.5 — Wed, 11 May 2022 14:47 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Collection of items found in V1.4 specification

  • Key: GEMS16-2
  • Status: open  
  • Source: Northrop Grumman Space Systems ( Stuart Austin)
  • Summary:

    1. No GEMS PSM Reference Designs are available. There is no way to independently assess a PSM implementation's conformance against the PSM or PIM.
    2. Issues with Device Definition file
    2.1 Section 7.5.1 says there is an example Device Definition file in the Examples directory on the OMG web site. This is not true.
    2.2 Section 6.2.10 "Obtain Device Information" appears to describe how a user retrieves the capabilities of the GEMS device - that is, it appears to define the Device Definition file and how to retrieve it. However there are no messages defined for the sequence in this paragraph nor any other.
    2.3 Section 6.2.10 also describes the capabilities as "descriptions of the directives (including argument name and type information) and the parameters (including name, type and range information). This therefore does not describe any of the other messages supported by the Device.
    2.4 That information is reiterated in Section 6.9, "Device Definitions" - it appears that only "parameters and directives supported by a GEMS Device" are included. Therefore should one assume that "parameters" means those attributes of a device controlled by SetConfigMessage?
    2.5 No definition of the Device Definition file in the GEMS UML
    2.6 No definition of the Device Definition file in the GEMS-ASCII PSM
    3. UML message classes with no Use Cases defined:
    3.1 PingMessage and PingResponse (appears in UML but not in Figure 6.1 nor text of Section 6.2)
    3.2 GetConfigListMessage andGetConfigListResponse (appears in UML but not in Figure 6.1 nor text of Section 6.2)
    3.3 DisconnectMessage (appears in UML and Figure 6.1 but not in text of Section 6.2)
    3.4 MessageSequenceResponse (appears in UML but not in Figure 6.1 nor Section 6.2, nor in either PSM)
    4. There are mismatches between the PIM specification and each of the XML and ASCII PSMs
    4.1 AsyncStatusMessage is not specified in the XML PSM schema.
    4.2 The following appear in XML PSM schema but not in the Spec nor ASCII PSM
    4.2.1 UnknownResponse
    4.3 No GEMS-ASCII PSM specification for
    4.3.1 DisconnectMessage
    4.3.2 PingMessage
    4.3.3 PingResponse
    4.3.4 MessageSequence, MessageSequenceResponse
    4.4 No definition of the Device Definition file in the GEMS-ASCII PSM
    4.5 No formal grammar for ParameterSet in GEMS-ASCII PSM, just "may be defined by the additional use of semi-colons".
    4.6 Specification of utime incomplete or incorrect
    5. Limitations on the GEMS specification are stated in Section 6.2.13 of that document. These specification limitations include that it:
    5.1 Does not specify exact parameters, types and ranges for any specific Device or Device type
    5.2 Proposes a Standard Devices package that would contain definitions of these standard devices, parameters and directives, but makes no attempt to define this package
    5.3 Proposes a Custom Devices package that allows Device vendors to provide the specification of their PIM in a PSM-compliant fashion, but makes no attempt to define this package
    6. version field of the GEMS message class only supports up to 1.2 though 1.4 is the current spec
    7. Sections 6.3.3.5, 6.3.3.6 and 6.3.3.7 have the wrong heading level - should not be headings at all, but rather, paragraphs under 6.3.3.4
    8. Likewise, sections 6.4.1 and 6.4.2 do not need to be headings, but rather, paragraphs under 6.4
    9. Section 6.5 typo "messages are structure as" vs "messages are structured as"
    10. Section 8 should be "PSM (ASCII)" not "PIM (ASCII)"
    11. Table 8.2 should include the "type" (per Table 8.1) of each field
    12. Table 8.2, row "Transaction ID" column "Comments" - formatting error. The extra line break character after the word "message" makes the last word ("correlation") wrap outside the table cell boundary and therefore difficult to find
    13. ASCII PSM issues:
    13.1 specifies that the message begins with the delimiter but doesn't end with the same delimiter
    13.2 time parameter shown in Table 8.1 appears to indicate 9 places for seconds, decimal, 9 places for nanoseconds; however any contemporary UTC time needs 10 places for seconds (see examples from GEMS web site)
    12.3 Table 8.3 refers to non-existent "Standard Header Table 9.2"
    12.4 Length field in message is fixed-length at 10 ASCII characters but all examples show this as 6 ASCII characters
    12.5 Description of Response message does not include a final delimiter before END marker; all examples show two delimiters between return code and END

  • Reported: GEMS 1.5 — Mon, 3 May 2021 17:46 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Terminology between picture and text is confusing

  • Key: GEMS16-3
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    In section 8.2.3, figure mentions a 'sequence number', though text that follows uses the term of 'transaction number'.

    Use of sequence number implies it is incrementing whereas transaction number does not. This is causing confusion about how the field is to be used.

  • Reported: GEMS 1.5 — Wed, 3 Nov 2021 16:05 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Extend PIM to allow "leaf" values to be referenced directly

  • Key: GEMS16-1
  • Legacy Issue Number: 19627
  • Status: open  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    The spec currently allows arrays, parameters sets, and arrays of parameter sets. These compound types can make for an API that's difficult to use. Specifically, if you want to modify a single member of a parameter set, you have to read it, deserialize it, modify part of it, re-serialize it, and write it back. This isn't wildly difficult, but I believe it's enough for a customer to complain about usability. This operation is particularly annoying in the case of arrays of parameter sets. Furthermore, the read/modify/write operation isn't atomic, and could result in race conditions that revert a simultaneous change.

    I'd like to suggest that we extend the PIM to allow "leaf" values of compound types to be referenced directly. E.g., array elements and parameter set members could be referenced under the ASCII PSM using the following parameter names:

    Array element: myArray/3
    Set member: myParamSet/memberName
    Array of sets: myArrayOfSets/5/memberName

    ...with a corresponding scheme for the XML PSM. This would require adding the forward slash as a reserved word that should not be used in parameter names, along with "|GEMS" and "|END".

  • Reported: GEMS 1.3 — Tue, 30 Sep 2014 04:00 GMT
  • Updated: Mon, 31 Oct 2022 00:09 GMT

Link for GEMS 1.5 is pointing to GEMS 1.4 document

  • Key: GEMS16-50
  • Status: open  
  • Source: L3Harris ( Jeremiah Job)
  • Summary:

    The link for the GEMS 1.5 document is pointing to the right URL for GEMS 1.5 PDF, but the document that shows up is the GEMS 1.4 PDF.

    https://www.omg.org/spec/GEMS/1.5/PDF
    Version says 1.4
    Date says June 2016

    Version should be 1.5
    Date should be January 2021

    Is it the wrong document?

  • Reported: GEMS 1.5 — Tue, 26 Jul 2022 19:35 GMT
  • Updated: Wed, 21 Sep 2022 21:56 GMT

GEMS XML Version Attribute Type Mismatch

  • Key: GEMS16-49
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    Sorry, I tried to locate an existing issue for this, but could not.

    The GEMS-XML mapping for the MessageType (7.2.1.4) has an attribute gems_version. In the pdf the type is xsd:int, in the xsd file the type is xsd:decimal.

    This error is present from at least spec version 1.2 to current.

  • Reported: GEMS 1.4 — Thu, 14 Jul 2022 15:04 GMT
  • Updated: Wed, 21 Sep 2022 21:51 GMT

Clarify use cases and association with implementations

  • Key: GEMS16-8
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    During the March 23, 2022 GEMS RTF Meeting, the RTF members agreed to:
    1. Add diagrams to sections 6.2.8 (Save Configuration Message), 6.2.9 (Restore Configuration Message), 6.2.11 (Asynchronous Status Message), and possibly 6.2.10 (get device definition file) for consistency with prior sections.
    2. Add references from the PIM and PSM sections back to the use cases.

  • Reported: GEMS 1.5 — Wed, 23 Mar 2022 17:30 GMT
  • Updated: Wed, 21 Sep 2022 21:38 GMT

Additional data type of time_duration

  • Key: GEMS16-12
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    It would be beneficial if an additional data type were available within GEMS of a time duration (time_duration). This allows for specification of a time offset. The suggested format would be:

    [-]HH:MM:SS[.fffffffff]

    Existing ground equipment solutions currently have time offsets and having this support would enable smoother and more accurate support and integration with GEMS-enabled products. Existing types do not adequately support providing an offset time duration format.

  • Reported: GEMS 1.5 — Fri, 29 Apr 2022 17:29 GMT
  • Updated: Wed, 21 Sep 2022 21:28 GMT

Describe how directives can be used to access leaf values

  • Key: GEMS16-9
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Eric Ogren)
  • Summary:

    During the March 23, 2022 GEMS RTF Meeting, the RTF members agreed to add text to the GEMS specification describing how GEMS Directives could be used to achieve direct leaf value access (GETs and SETs) without changing the current GEMS 1.4 interface. Luis Rodriguez offered to write this text and provide example directives.

    This "Directive" approach is an alternative to the preferred approach of changing the GEMS standard to generically support direct leaf value access (e.g. via standard "dot notation") - this approach is tracked in GEMS16-1.

  • Reported: GEMS 1.5 — Wed, 23 Mar 2022 19:32 GMT
  • Updated: Wed, 21 Sep 2022 16:27 GMT