C2MS11 — Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message

TLM Processed Frame Message currently requires 1+ NUM-OF-MNEMONICS, which makes sense, except that "Search" is a valid status for FRAMESYNC-STATUS. If that status is Search, it doesn't seem possible for there to be MNEMONICS... yet, if there are no MNEMNOICS, because FRAMESYNC-STATUS is Search, then why would there be a TLM Processed Frame Message?

Need to do some analysis on this and decide how to handle this conundrum in the document. Should 0+ be the value of NUM-OF-MNEMONICS, or should 1=Search not be a valid FRAMESYNC-STATUS, and either way, this needs to be explained to the user of this message.

Finally, does FRAMESYNC-STATUS even belong in this "Processed Frame" message? This might have been a long-ago copy-paste error. A frame synch status of 'Verify' is used typically to say that the processing component has the frame but is looking for the next framesync marker after which it moves to 'Lock' state, and will keep everything flowing, while 'Check' means that after processing some frames in 'Lock' state, it's now trying to locate the framesync marker again (like short frame, for example). Either way, it just seems (to me) that we would only produce "Processed Frames" if the FRAMESYNC-STATUS is 'Lock'. There may be exceptional cases where a component is asked to produce MNEMONICS even under the 'Verify' or 'Check' states, but this would be rare, and error prone. So, maybe just getting rid of 'Search' would be OK-ish, but again, just need to re-evaluate this one.

Defer to a later release

Do this later