C2MS12 — Clarity and Usage Issues with Replay Telemetry Data Request (and Response) Message

There are some clarity issues with Replay Telemetry Data Request (and Response) Message:

• There is a STREAM-MODE the fields of the Replay Telemetry Data Request Message, but in this case, I believe what it is there for is to say what types of telemetry messages to replay. It's not part of the Subject, the way STREAM-MODE is for other messages. I'm not sure it makes sense in this message type and should be re-evaluated. At a minimum, beefing up the description of it would be helpful.

• There is no mention that the replayed TLM messages should be marked with STREAM-MODE of RPY (Replay), but I assume that would be true, because otherwise, there would be no way to have RPY messages. This should be discussed in the context of this message.

• There is a lot of messiness that can come from replaying the telemetry messages back in an operational environment. I could pick messages to replay from two years ago. What processes are listening for those messages? Do MVAL messages also get produced from the replayed TLM? Note that these cannot be marked RPY. Are Event Messages produced from the limit checks? Note that these cannot be marked RPY. Blech. Probably need a discussion of all this and a warning, again, not to have RPY messages flow in an operational environment.

• There is discussion in "8.8 Replay Telemetry Data Messages" regarding using the Replay Request Message to get "real-time" or even "a future flow of data". In other words, there has been consideration at some point about using these messages as a way to request TLM messages wholly apart from subscribing to the normal published TLM messages. The only apparent benefits of this are the ability to constrain the DATA-RATE, to affect the PLAYBACK-RATIO, or to allow pausing or stepping through the TLM stream of the current (or future) real-time data. Any other elements of the data stream, could simply be filtered out as part of normal pub-sub of the standard messages. This makes for a bit of a Frankenstein meaning to the Replay messages. Not sure what do do about this. I think it actually simply makes more sense to say, if you want to do this kind of stuff, get the messages replayed from the archive, rather than to use this as a mechanism to affect real-time data. In any case, this could use some attention and explanation. Bottom line, I feel like this is one of those cases where the power of infinite flexibility has been employed so say, "Sure this is a message about replay, but you can get it to do basically whatever you want related to telemetry streams."

• Section "8.8 Replay Telemetry Data Messages" refers to "Replay Telemetry Data Messages". However, this is a category rather than a specific message type, so some rewording is probably worthwhile to avoid confusion. The term "Replay Telemetry Data Messages" refers to replayed messages related to telemetry, which are specifically and exclusively: Telemetry CCSDS Packet Message, Telemetry CCSDS Frame Message, Telemetry CCSDS CADU Frame Message, Telemetry CCSDS Transfer Frame Message, Telemetry TDM Frame Message, and Telemetry Processed Frame Message.