Since WebSockets is a message-based protocol, it could fit with GEMS and provide another transport for persistent connections.
Discuss the need and viability of this.
With HTTP as the transport for JSON/REST, there is little to no need to support the AsyncStatus message because HTTP is a request/response protocol with a stateless nature where each request/response pair is independent, i.e. the server does not retain session data between requests by default. That said, the following approach to support the AsyncStatus message in a future version of the JSON/REST PSM (post GEMS v1.7) has been vetted through the SDTF via the following notes captured during SDTF meetings:
Request from GEMS user - HTTP POST AsyncStatus-Directive containing:
1) a webhook/callback-URL of the GEMS user,
2) a list of parameters to provide status for, and
3) periodicity of response messages.
Response from GEMS device - HTTP POST AsyncStatus-Message containing the latest values of the requested parameter(s).
The GEMS PIM currently supports a "Save Configuration" message, however does not support a reciprocal "Delete Configuration".
Requesting the addition of a "Delete Configuration" message to the PIM and supporting content in each of the PSMs, i.e. the upcoming GEMS JSON/REST PSM.
Add the following section to the new GEMS JSON/REST PSM as follows:
9.2.17 Delete Configuration
The normative definition for the delete configuration message is defined below. Everything is normative other than the example values. The TARGET is the configuration service for the given GEMS device which must provide the deleteConfiguration directive that implements the following API to comply with this standard.
Delete Configuration in a GEMS device (i.e. deletes the specified configuration file):
HTTP Verb: POST
URI: https://<host>:<port>/gems/<configService>/_directives/deleteConfiguration
Content-Type: application/json
{
"name":
}
JSON Response for Load Configuration:
{
"result":
}
Add a new row to Table 9.2 of the JSON/REST PSM for GEMS Message "Delete Configuration" with HTTP Method/Verb "POST" and a link to the above "Delete Configuration" section 9.2.17.
Add corresponding sections for the XML and ASCII PSMs.
Currently the GEMS PIM supports nanoseconds in its "time" and "utime" standard types. All of the GEMS PSMs map to this nanoseconds requirement.
More satellite ground systems are requiring picosecond resolution, so adding GEMS support for picoseconds is requested.
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.
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.
The ASCII PSM specifies that the "Message Length" field in the Standard Header is a fixed length of 10 characters, but all Example GEMS-ASCII Message Lengths are only 6 characters. So correct the Message Length of all Example GEMS-ASCII Messages in:
1) https://www.omgwiki.org/space/lib/exe/fetch.php?media=gems-1.2-examples.zip
2) https://www.omgwiki.org/space/doku.php?id=gems#gems_example_messages
Add the GEMS-ASCII PSM schemas for the following:
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.
In the GEMS version 1.4 specification ASCII PSM, Table 8.6 for the "Disconnect Message Request" is missing the "Comments" column which contains certain interface details, e.g. Message Type Field = DISC.
Refer to the two attachments for the missing column in V1.4 and V1.3 which contains the column.
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. Mr. 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.
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".
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.
This is the main addition for GEMS 1.7 RTF.
The 2024 Q4 San Francisco RTF made progress creating the new JSON/REST PSM via the draft GEMS_1.7_RTF_REST_PSM_v6.doc, specifically the JSON encoding formats.
The 2025 Q1 Reston RTF made more progress updating the draft GEMS_1.7_RTF_REST_PSM_v7.doc.
Continue updating the draft spec in Denver (2025 Q2) and in Leeds (2025 Q3).
Once done, update this ticket with a proposal containing the details.
This will be a new major section '9' in the GEMS spec, starting at page 48.
The time format in the specification is a variant of ISO 8601 (not RFC 3339). Recommend showing time format string as a reference to ISO 8601 and using "D" and fractional in alignment with ISO 8601 rather than alternate definition within the specification.
See https://en.wikipedia.org/wiki/ISO_8601#:~:text=It%20is%20represented%20as%20%22YYYY,as%20%221981%2D095%22.
