C2MS11 — Real-world STREAM-MODE Issues

A number of C2MS Messages include the concept of marking the mode of the data as “real-time (RT), replay (RPY), simulation (SIM), or test (TEST)” through a required field, STREAM-MODE.

The specific messages are:

• Telemetry CCSDS Packet Message
• Telemetry CCSDS Frame Message
• Telemetry TDM Frame Message
• Telemetry Processed Frame Message
• Replay Telemetry Data Request Message
• Attitude Parameter Message
• Attitude Ephemeris Message
• Orbit Parameter Message
• Orbit Mean-Elements Message
• Orbit Ephemeris Message
• Tracking Data Message

Where used, STREAM-MODE is a required field. A typical explanation in the C2MS Spec is that, “The STREAM-MODE field is used to classify the kind or source of the” message.
Although this may be useful in a closed experimental/engineering system, the concepts are not appropriate for an operational SATOPS system, where replay, test, sim data should never be mixed with real-world operational data. In a system with many components, the use of the STREAM-MODE field assumes that every component will properly handle the distinction for every message. As an example, a FireThrusters CMD message is received and the component fails to note that this particular message is a RPY STREAM-MODE and thinks to itself… ‘huh, I thought we fired thrusters, yesterday… but, OK, here it goes…”. In another example, a SelfDestruct CMD message is received and the component fails to note that the message is marked as TEST or SIM…

Instead of marking messages themselves, this type of distinction should be performed environmentally; one system is the operational system, other, separate systems are for simulation or test, another separate system performs forensics (replay). Keeping these purposed environments isolated from each other ensures that data never intermixes where not appropriate.
The resolution to this concern could be any of the following:

1. Remove the STREAM-MODE field — breaks backward compatibility, and affects any system already using this field. However, it represents a clean break from a field that should never be used in practice, anyway.
2. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and mark the field as deprecated (deprecated = should no longer be used and will be removed in a future major release) — maintains backward compatibility, but signals to users to cease using the field.
3. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and provide a best-practices statement; something to the effect of, “Although maintained for backward compatibility, the use of this field is strongly discouraged for operational systems, where test, sim, or replay data should never mix with real-world operational data” — this weakest approach leaves the use of the field in the hands of the user, but would be a bit embarrassing from the standpoint of a specification to preserve a capability that is strongly discouraged.

See attachment for non-exhaustive use in C2MS Spec.

*Update Text to Indicate that this Should not be Used at Enterprise-level *

Create a section to describe this capability as appropriate for small-scale or experimental SATOPS, but inappropriate for formal enterprise-level operations.

Put a note in each field of the effected messages to indicate this as well.