Harmonization Needed

I’d like to recommend a review of the Replay Telemetry Data Request Message compared to the Archive Mnemonic Value Request Message. These two messages should be nearly identical in form, but appear to have grown up in neighborhoods on opposite sides of the tracks.

Some base behaviors are different between the two. Many fields exist in one request message but not the other. In one case, the same field exists in both request messages, but has a different meaning. The response paradigm is different between the two message sets.

This issue is to harmonize the two message sets.

Throughout this discussion, I’ll use the following abbreviations:

• “RTDRM” - Replay Telemetry Data Request Message
• “AMVRM” - Archive Mnemonic Value Request Message

Sections below describe elements of the two that are dissimilar:

Message Naming

For TLM, the Message is called Replay Telemetry Data Request Message (RTDRM). For the MVAL it is Archive Mnemonic Value Request Message (AMVRM). Since both have the concept (implemented differently) of replay, but the AMVRM has a way to receive the data as an output file, I think that “Archive” is more meaningful. In fact the descriptive text under the RTDRM, refers to the “Telemetry Archive component”. So, I’d suggest renaming the RTDRM to Archive Telemetry Data Request Message to match better with Archive Mnemonic Value Request Message.

Real-time and Future “Replay”

Replay Telemetry Data Message set includes a long description of how to use the “replay” service provider as a way to get real-time, or even future TLM messages (Section 8.7). There is no analog in Archive Mnemonic Value Messages.

I recommend we don’t include that discussion in the Archive Mnemonic Value Messages. It seems odd to have “replay” messages for something that isn’t replay. I believe the same intent can be achieved by simply requesting a “replay” whose end-date-time is in the future, and indicate that the archive service will continue to send out TLM, as long as it is put in the archive during that window. That is logically similar, without trying to fake out the system, because the data would still originate from the archive.

The STREAM-MODE of the RTDRM (sec 8.7.1.3) can be RT or RPY, to accommodate the intent of separating real-time from replay. I don’t’ think this is needed. If we assume that we only replay data that is in the archive, whether it is arriving into the archive now or in the future, this is logically the same and wouldn’t require special handling in the message definition.

Section 8.7.1 indicates that the two fields PLAYBACK-RATIO and DATA-RATE (described in sec 8.7.1.3) only apply if the STREAM-MODE is RT. However, having to specify STREAM-MODE as RT or RPY doesn’t seen necessary. These values could easily be applied to RPY: this would mean that the playback rate would be some ratio of the timing of the original TLM (play back at the same rate it was originally received, or some ratio related to it) or play it back at a certain data rate, from the archive. The distinction makes it awkward and I don’t think it’s necessary. The AMVRM uses PLAYBACK-RATIO and DATA-RATE with exactly these meanings, without any indicator of STREAM-MODE.

I’m confused about what is meant by the fields of the RTDRM in Section 8.7.1.3 for files. There is a NUM-OF-FILES and a FILE.n.NAME-PATTERN, with very limited description of how this is to be used. The only clue is in Section 8.7.1, where there is indication that this only applies to a “real-time data stream”. I’m not sure how the requester is to know the names of files in the archive and why this would only apply to RT. Probably should be removed, unless we have a specific use-case for it.

STREAM-MODE

STREAM-MODE (described in sec 8.7.1.3) exists in RTDRM, but not in AMVRM at all. This would be useful in AMVRM, because STREAM-MODE can indicate SIM or TEST. RT and RPY are not needed, as described above.

Request All Data Construct

In addition to retrieving MVAL Data Messages as a stream, the AMVRM also has the concept of requesting the entire data set in a single message. In fact, this can either be in the payload of the single message or the data can be placed in a file at a specified URI. The RTDRM does not have this concept at all, and all retrieved TLM must be in a set of streamed messages. I like this capability of the AMVRM and recommend that it be added to the RTDRM.

One oddity in this concept is that in the AMVRM (sec 8.9.1.3), if the RESPONSE-VIA-MSG is set to RESP.AMVAL, then it can be delivered in the single message or at a URI. However, the selection is controlled by two Boolean fields: DELIVER-VIA-REFERENCE (URI) and DELIVER-VIA-INCLUDE (message payload). It’s odd that these are separate Booleans, because there is no description of what would happen if they are both set to ‘0’ or if they are both set to ‘1’. I can surmise that setting both to ‘0’ would be an error and setting both to ‘1’ would mean to deliver the data set in both the single data message and also at the URI, but it’s hard to imagine the usefulness of doing so. I’d recommend we drop DELIVER-VIA-INCLUDE and just use the DELIVER-VIA-REFERENCE to mean that the data is to be EITHER in a URI OR in the data message.

ACTION Field

The RTDRM has an ACTION field to control flow (start, stop, etc). There is no analogue in AMVRM, but there probably should be.

PDB-VERSION Field

The AMVRM has a PDB-VERSION field. This field does not exist in RTDRM. To me this seems way down in the weeds, and was probably an add-on for a special one-off case somewhere along the line. Is it necessary? If not it should be removed. If so, it should be added to RTDRM as well.

ORBIT Field

RTDRM can specify a particular orbit. This field does not exist in AMVRM.

Filename Fields

RTDRM, as discussed earlier, has fields for the source files for TLM. This concept doesn’t exist for AMVRM. Unless we can come up with a specific use case for this (along with a better description of the fields in the RTDRM), I’d be in favor or dropping it from RTDRM. Otherwise, it should probably be added to AMVRM for consistency.

FORMAT Field

Both RTDRM and AMVRM have a FORMAT field. They are used for different purposes. I’d recommend calling the one in RTDRM TLM_FORMAT and the one in AMVRM something like FILE_FORMAT since that corresponds to their use.

VCID and APID Fields

RTDRM has VCID and APID fields. The AMVRM does not. Yet, the MVALs originated from the same TLM stream, so these seem applicable to AMVRM. Needs discussion. Note that both request messages have COLLECTION-POINT with identical meaning, so the origination of TLM and MVALs are tied in that way.

Mnemonic Value Data Message vs Archive Mnemonic Value Data Message vs TLM Messages

In the RTDRM, asking to retrieve TLM messages results in identical TLM messages to when these messages came in, real-time. The only exception is in the STREAM-MODE of that message type, which is set to RT for original messages, or RPY for messages coming out of the archive. This is a useful construct.

However, for AMVRM, the original real-time messages have one format, defined in section 8.8.3.3 and a different format for messages retrieved from the archive, described in section 8.9.3.3.

It seems logical to use either one pattern or the other. I prefer the pattern used by TLM, where the original message format reappears, but with a designator that it is a RPY message.

defer to a later 2.0 release

This is a good reason to have a C2MS Roadmap discussion. For now, defer to a later release (2.0?)