Non-self-describing CCSDS attributes for either transfer frames or space packets should be provided as dependent attributes of the frame messages. This would enable full integration between a sender and receiver. Right now, whether these optional fields are provided is unknown, causing the proper rendering of the frame to not be possible without outside negotiation (beyond the specification).

Examples:

Frame Header Error Control of the AOS transfer frame (AOS Space Data Link Protocol (ccsds.org)), where nothing prior to it in the definition specifies whether it is there or not:

4.1.2.6 Frame Header Error Control
4.1.2.6.1 If implemented, Bits 48-63 of the Transfer Frame Primary Header shall contain the Frame Header Error Control. NOTE – The 10-bit Master Channel Identifier, the 6-bit Virtual Channel Identifier, and the 8-bit Signaling Field may all be protected by an optional error detecting and correcting code, whose check symbols are contained within this 16-bit field.
4.1.2.6.2 The presence or absence of the optional Frame Header Error Control shall be established by management.
4.1.2.6.3 If present, the Frame Header Error Control shall exist in every Transfer Frame transmitted within the same Physical Channel.

Space Packets and the secondary header (Space Packet Protocol (ccsds.org)): A space packet might have a secondary header with a variable length time code, a variable length ancillary data field, or both. A space packet might have a secondary header, a user data field, or both. The length is not specified for any of them. When present, the format of the time code can be one of several options, but which one is not specified:

4.1.3.3.3 Secondary Header Flag 4.1.3.3.3.1 Bit 4 of the Packet Primary Header shall contain the Secondary Header Flag. 4.1.3.3.3.2 The Secondary Header Flag shall indicate the presence or absence of the Packet Secondary Header within this Space Packet. It shall be ‘1’ if a Packet Secondary Header is present; it shall be ‘0’ if a Packet Secondary Header is not present. 4.1.3.3.3.3 The Secondary Header Flag shall be static with respect to the APID and managed data path throughout a Mission Phase. 4.1.3.3.3.4 The Secondary Header Flag shall be set to ‘0’ for Idle Packets

4.1.4.2.1.5 If present, the Packet Secondary Header shall consist of either: a) a Time Code Field (variable length) only; b) an Ancillary Data Field (variable length) only; or c) a Time Code Field followed by an Ancillary Data Field. 4.1.4.2.1.6 The chosen option shall remain static for a specific managed data path throughout all Mission Phases. NOTE – The format of the Packet Secondary Header is shown in figure 4-3. ANCILLARY DATA FIELD (optional) variable PACKET SECONDARY HEADER TIME CODE FIELD (optional) variable Figure 4-3: Packet Secondary Header

4.1.4.2.2 Time Code Field 4.1.4.2.2.1 If present, the Time Code Field shall consist of an integral number of octets. 4.1.4.2.2.2 The Time Code Field shall consist of one of the CCSDS segmented binary or unsegmented binary time codes specified in reference [3].CCSDS RECOMMENDED STANDARD FOR SPACE PACKET PROTOCOL CCSDS 133.0-B-2 Page 4-8 June 2020 NOTE – The time codes defined in reference [3] consist of an optional P-Field (Preamble Field), which identifies the time code and its characteristics and a mandatory T[1]Field (Time Field). Examples of time codes are CCSDS Unsegmented Time Code and CCSDS Day Segmented Time Code. Examples of characteristics are ambiguity period, epoch, length, and resolution. 4.1.4.2.2.3 The time code selected shall be fixed for a given managed data path throughout all Mission Phases. 4.1.4.2.2.4 If the characteristics of the chosen time code are fixed, the corresponding P[1]field (as described in reference [3]) need not be present. If the characteristics are allowed to change, the P-field shall be present so as to identify the changes. 4.1.4.2.2.5 The presence or absence of the P-field in the Time Code Field shall be fixed for a given managed data path throughout all Mission Phases. If present, it shall immediately precede the T-field that is defined in reference [3]

4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

For a complete implementation of C2MS on the systems I use, we need some kind of Procedure Script Execution set of messages. These would include being able to launch procedures, monitor them, show progress, etc. This could be a topic of some significant discussion and is entirely new scope. The closest analogue I have so far found is the Activity Tracking stuff in the CCSDS Mission Operations Common Services.

if I do not write it down, I will forget.

Some message fields of type Boolean are listed as optional. This has a pretty ambiguous meaning for a boolean, which if present, is always True or False.

For one non-exhaustive example, some messages include a FINAL-MESSAGE boolean field that is optional. What does it mean when not present? It could be inferred that it is equivalent to False, but it could also be inferred that this is ignored when there is only one message, which would be the same as True.

We need to go through all these usages individually and decide if these should be required, rather than optional.

There is a second possible approach. It may be OK to change something form optional to required, even in a 1.x baseline, if it is the case that the optionality was not workable and in practice it must already always be specified. However, in cases where we cannot clearly state the above, it would at a minimum be beneficial to C2MS users to give guidance, which would look like: "Although [field-x] remains optional for backward-compatibility, in practice it should always be present, with true meaning xx and false meaning yy."

The following Boolean fields are optional:



[Various Messages]

[Various Messages].FINAL-RESPONSE. This field is always optional by necessity as it was introduced in 1.2, so making it required would have been backward-breaking. A description of this situation is already provided in section 6.4.3.3 C2MS RESP Message Type, and the default value (if not present) is already designated for each message that includes it. Because of this, no changes is needed for this field.



Archive Message Retrieval Request

Archive Message Retrieval Request.DELIVER-VIA-REFERENCE - already states the default (if not specified). No change needed.

Archive Message Retrieval Request.DELIVER-VIA-INCLUDE - already states the default (if not specified). No change needed.



Telemetry CCSDS Frame Message

Telemetry CCSDS Frame Message.RS-PRESENT - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this message has already been deprecated, so perhaps no change is needed.



Telemetry CCSDS CADU Frame Message

Telemetry CCSDS CADU Frame Message.INVERTED-DATA - Does not specify a default. Seems pretty reasonable to state a default of FALSE.

Telemetry CCSDS CADU Frame Message.FEC-UNCORRECTABLE - Does not specify a default. Seems reasonable to default to False, , but discussion needed.



Telemetry CCSDS Transfer Frame Message

Telemetry CCSDS Transfer Frame Message.FECF-ERROR - Does not specify a default. Seems pretty reasonable to state a default of FALSE.

Telemetry CCSDS Transfer Frame Message.HECF-ERROR-UNCORRECTABLE - Does not specify a default. Seems pretty reasonable to state a default of FALSE.



Mnemonic Value Response Message

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.LIMIT-ENABLE-DISABLE - Does not specify a default. Hard to say if defaul should be FALSE (Disabled) or TRUE (Enabled). Discussion needed.

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.RED-HIGH - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.RED-LOW- Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.YELLOW-HIGH - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.YELLOW-LOW - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.STATIC - Does not specify a default. Seems pretty reasonable to state a default of FALSE (Active), but discussion needed.

Mnemonic Value Response Message.MNEMONIC.n.SAMPLE.m.QUALITY - Does not specify a default. Seems pretty reasonable to state a default of FALSE (Good quality), but discussion needed.



Mnemonic Value Data Message

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.LIMIT-ENABLE-DISABLE - Does not specify a default. Hard to say if defaul should be FALSE (Disabled) or TRUE (Enabled). Discussion needed.

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.RED-HIGH - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.RED-LOW- Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.YELLOW-HIGH - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.YELLOW-LOW - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.STATIC - Does not specify a default. Seems pretty reasonable to state a default of FALSE (Active), but discussion needed.

Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.QUALITY - Does not specify a default. Seems pretty reasonable to state a default of FALSE (Good quality), but discussion needed.



Archive Mnemonic Value Data Message

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.LIMIT-ENABLE-DISABLE - Does not specify a default. Hard to say if defaul should be FALSE (Disabled) or TRUE (Enabled). Discussion needed.

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.RED-HIGH - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.RED-LOW- Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.YELLOW-HIGH - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.YELLOW-LOW - Does not specify a default. Seems pretty reasonable to state a default of FALSE. However, this field has already been deprecated, so perhaps no change is needed.

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.STATIC - Does not specify a default. Seems pretty reasonable to state a default of FALSE (Active), but discussion needed.

Archive Mnemonic Value Data Message.MNEMONIC.n.SAMPLE.m.QUALITY - Does not specify a default. Seems pretty reasonable to state a default of FALSE (Good quality), but discussion needed.



Command Request Message

Command Request Message.BYPASS - Does not specify a default. Seems pretty reasonable to state a default of FALSE.

Command Request Message.CMD-ECHO - Does not specify a default. Seems pretty reasonable to state a default of FALSE.



Command Echo Message

Command Echo Message.ECHOED-CMD-BYPASS - Does not specify a default. Seems pretty reasonable to state a default of FALSE, but discussion needed.



Product Request Message

Product Request Message.DELIVER-VIA-REFERENCE - Already states the default (if not specified). No change needed.

Product Request Message.DELIVER-VIA-INCLUDE - Already states the default (if not specified). No change needed.



Product Message

Product Message.DELIVER-VIA-REFERENCE - Does not specify a default. Already states the default (if not specified). Seems pretty reasonable to state a default of FALSE, but discussion needed. However, according a careful reading of the field description, at least one of VIA-REF and VIA-INCLUDE must be TRUE. Both is allowed here. The text of the field description should be updated to state this more directly.

Product Message.DELIVER-VIA-INCLUDE - Does not specify a default. Already states the default (if not specified). Seems pretty reasonable to state a default of FALSE, but discussion needed. However, according a careful reading of the field description, at least one of VIA-REF and VIA-INCLUDE must be TRUE. Both is allowed here. The text of the field description should be updated to state this more directly.

With the advent of the C2MS Message Envelope, some tracking or meta-data fields exist in both the new Message Envelope and in the already-existing C2MS Message. In 1.x, it is the case that we want to leave fields in the C2MS message and encourage migration toward Message Envelope usage. In a follow-on major release, assuming we make the Message Envelope required, the duplicated fields should be removed in the C2MS Message.

There are many 'classes' in the model (because that's what is in the message) for Mnemonic, frequently with different values. Same probably true of Sample and others. It would be great if these structs in the messages and classes in the model were better reused so that we don't have two different items both called "Mnemonic".

This issue sort of harkens back to when we had things like "Required Fields" in each message in the model, with no relationship to each other.

In C2MS2.0, we need to revisit the Req/Resp/Pub MEP, as is the same with MVAL Req, followed by an MVAL Resp, followed by an indefinite number and duration of MVAL Data Messages.

This should really be either a standard Pub-Sub construct or should just be a simple req/response.

This is one for C2MS 2.0. Capturing it here, because this is the only avenue to enter issues at present.

Instead of a F32 for version number, which then uses a year, like 2024.0, we should change this to a formatted string that uses Semantic Versioning, with a string that looks like the following:

MAJOR.MINOR.PATCH

Examples: "2.0.0", "2.1.1"

Note that this means changing the base type and the meaning of the current version numbers.

Note, too, that this shouldn't simply be type STRING, but should be something like VERSION-STR with the format defined by C2MS.

Also, consider getting rid of the separate header version and message content version. This is just something to bring up to the group.

Many fields in the C2MS Header (which have of necessity also been put in the C2MS Envelope) should be evaluated for change or removal in the next major release. Change to be made in both C2MS Message and C2MS Envelope. Examples:

• ROLE should be renamed COMPONENT-ROLE to avoid confusion with user role (authorization).
• USER-NAME should be removed. This seems to be only debug info and does not have anything to do with authentication/authorization. The new fields SENDER-IDENTITY and SENDER-ACCESS in the envelope provide that.
• FACILITY/NODE/PROCESS-ID/CONNECTION-ID are candidates for removal. These seem only valuable for debugging. Debug info doesn't belong in a standard, IMO.
• CONNECTION-ID should be removed. This is definitely only valuable for debugging.
• MW-INFO - no idea why this is there. Probably need a use case or example of what this is used for, but it doesn't seem to belong.

Some fields and message elements that should be required are listed as optional. For example, in the Telemetry CCSDS Packet Message, ME SCID was added in 1.1, so had to me marked optional, but it should be required. APID already existed in that message as a Message Element, but not as a field, so whereas the ME is required, the field had to be made optional (for backward compatibility).

Additionally, in section 6.2.2 Format of C2MS Subject Names, there is a description that says, "If an element is required but not applicable for that mission or to that type of message, the publisher inserts “FILL” (no quotes) for that element." However, this should be cleaned up. If a field is required it should be required, if not, then it should not be required. Need a run through the messages to see how this can be improved.

Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.

This is described in Mnemonic Value Request Message as:
"The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously."

and

Mnemonic Value Response Message:
"For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."

However, in a significant way, these statements conflict with the next line:
"For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."

In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).

The effect of this is that the MVAL Req/Resp works in a primary subscription-based manner or in a different manner when specifying ONESHOT.

With this in place the MVAL Req/Resp sometimes follow the Request/Response Message Exchange Patter, and other times follow the Request/Response/Publish MEP. In fact, figure 8-19 Mnemonic Value Message Sequence Diagram illustrates the Request/Response/Publish MEP. It is not valid for the Request/Response MEP. No example of the Request/Response MEP is shown for this message.

Furthermore, some fields are handled specially depending on which MEP is used. For example, it is stated in the spec that when using ONESHOT, the following fields are ignored in the Request:
• PUBLISH-RATE
• DURATION
• MNEMONIC.n.CRITERIA
• MNEMONIC.n.SAMPLE-RATE

Meanwhile, in the Reponse, RESPONSE-STATUS field values 3 and 4, likely only apply to ONESHOT, while 1 likely only applies to non-ONESHOT. requests.

This odd dual-purposing of these messages was all likely done at some point out of convenience of overloading existing messages rather than creating new messages that would have been a more coherent design.

It has the effect, for a 'Start' of the consumer needing to read both the MVAL Return message for data and then a series of MVAL data message, rather than simply reading MVAL data messages.

In order to remove this overload, I suggest one of the following:

1 - deprecating ONESHOT and related fields in those messages and creating a new Message Type for retrieving current values. These could be called Mnemonic Current Value Request Message and Mnemonic Current Value Response Message.

2 - removing the value fields from the Response Message above, then simply convert the ONESHOT to a form of Request/Response/Publish MEP in which only one publish happens, and then the subscription ends. Subscription termination is already part of the spec, because of DURATION. The way this would work is the requestor sends a request message marked for ONESHOT, the service sends a response message, the service sends a single Mnemonic Value Data Message, the subscription is terminated. In this way, Mvals are only communicated in one type of message: Mval Data Message, easing the burden for handling two message types.

In a certain sense, I like the first option better, because it addresses the need to get current values using dedicated messages. However, the second approach is a much smaller change and represents a solution that is FAR more straight-forward than the way it is implemented today.

Some Message Elements and Fields are in different order from message to message. The fields are just a listing so not as important, but the MEs are order-dependent. One example of how this is an issue is that the Telemetry CCSDS Packet Message added a new ME, but this had to go to the end (ME6) because of backward compatibility. This creates a strange ordering with VCID, APID, Collection Point, SCID. This is just one example, but the need is to evaluate all the MEs and fields and see if any need to be moved to make messages more uniform in structure.

Additionally, there are cases where some MEs have been removed between 1.0 and 1.x, leaving "not used"/"FILL" in the corresponding positions of MEs and these need cleaning up.

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.

For most of the message types in C2MS, this convention is followed. The exceptions are:

-Archive Message Retrieval Request
-Archive Message Retrieval Response

These were likely left this way because they already have "Message" in the name, though with a different meaning. Archive Message Retrieval Request Message does sound redundant. Perhaps renaming to any of the following would help:

• Archived Messages Request Message
• Archive Retrieval Request Message
• Archive Request Message
• Archive Message Request Message

Not using "Archive Message" in the title is a bit confusing because there is Archive data that is not simply archived messages, see "Archive Mnemonic Value Request Message"

Note that when originally entered, this issue listed all the following... but in 1.1, the only messages not ending in "Message" are the Archive request/responses.

-Archive Message Retrieval Request
-Archive Message Retrieval Response
-Telemetry Message for CCSDS Packet
-Telemetry Message for CCSDS Frame
-Telemetry Message for TDM Frame

I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

The messages for mnemonic access do not appear to include a request/response for "setting" the value of a parameter (mnemonic) from an application participating using C2MS. This capability is used for ground and other types of non-telemetered parameters (mnemonics).

if I do not write it down, I will forget.

The various Navigation Data Messages are nearly identical. They should be consolidated into a hierarchy that defines a Navigation Data Message base class and then let the others derive from it for better model structure. The Tracking Data Message has a few extra fields. Otherwise, everything is identical across all messages except for some type values.

I thought about doing this when I was updating the model in 1.1, but would have also had to update the chapter text and didn't have time for all that in 1.1.

From C2MS13-33, which was a DUP of this one: "Similar to C2MS12-118, it would be nice to create a model hierarchy for the TDM messages. They are almost all nearly identical, so inheritance would be nice. Of course, this can't break the CONTENT in the tables, but can greatly improve the diagrams."

See C2MS12-177, which defined new common types (Request, Response, and Notification) and had all messages subclass these, for an example of how this should be done.

The text for MVAL and related messages doesn't explain or give examples of how to specify for example an array or record – for example a BATV[1] or something more complicated like: SBUS.STATUS.PFRAME[27].STACK_DEPTH.

Any text addressing this should also discuss the XTCE repeat concept which the author of this issue believes today is handled by NUM-OF-SAMPLES.

TLM and MVALs can be retrieved from the archive, but it would be useful to define a way to retrieve archived Commands and Events as well, since these represent, along with TLM, the SatOPs messages.

The AMVAL Response and AMVAL Data messages mostly line up with MVAL Response and MVAL Data messages, but not quite. There are some inconsistencies among these messages. One aspect of these is that there should only ever be one MVAL Response Message, but may be multiple AMVAL Response Messages. The documentation does state this, and I'm only relaying it how not to confuse this issue. That difference is expected and normal. The reason for this particular difference is that the AMVAL REQ/RESP has a finite end (see descr of STOP-TIME in AMVAL REQ: "Requested stop time of the mnemonic values to be retrieved from the telemetry archive. Defaults to the end of the telemetry archive") while MVAL can be no-end. This is also manifested in the concept of START and STOP request types in MVAL REQ, which don't exist in AMVAL REQ.

However, there are some inconsistencies that do need analysis and probably correction in one form or another:

• The AMVAL Response contains no samples, which are present for all of MVAL Response, MVAL Data and AMVAL Data. So, if requesting the data back in the AMVAL Response, not all the data is returned. It could also be seen that you might request the data to come back in AMVAL Data if you need this deeper detail, which would be fine, but maybe some explanation in text would be warranted if we keep that construct.
• Also, AMVAL Response, contains a Product Subtype Category not found in any of the others. This needs analysis and convergence to align these messages better. Note, too that Product info is contained in AMVAL Request, as well. This seems out-of-place, almost like it was copied from the product message. Interestingly, the PRODCUT-TYPE is always AAA (Archive and Assessment) and the PROD-SUBTYPE is always DATA. Is that really necessary to say? I mean, it is a request for archived MVALs, it doesn't seem to add anything to say that that's a DATA product from AAA. Instead, this seems like it aligns more with the Product Request Message that has these fields that are to be searched generically. Note that this has a corollary in Archive Message Retrieval Request/Response, which also contain Product Info, so need to look into that at the same time. These are the only other messages than Product Messages that reference PROD-NAME.

Add the DBQUERY messages that were defined by NASA to the formal specification.

These messages are listed as being part of the OMG specification here:
https://software.nasa.gov/software/GSC-18536-1

"A Graphics User Interface (GUI) based desktop viewer for XML Telemetry and Command Exchange (XTCE) files which allows some editing of the various XTCE properties of that open file, and then allows saving the updated information back to file. It includes a Goddard Mission Services Evolution Center (GMSEC) GMSEC Search XTCE (GSX) connector to support some GMSEC/ (Command and Control Message Specification) C2MS Database Query (DBQUERY) messages to search for some XTCE information which is then sent over GMSEC bus to the initiator of the search request."

NOTE: C2MS12-2 is being closed as a DUP of this message, so the intent of that issue needs to be addressed in the resolution of this one.

In the already-approved C2MS11-45, we added DB Query Messages. However, this issue did not include a text description for each message, which is common for all other C2MS Messages.

Specifically, the new sections 8.14.1 and 8.14.2 need a description in order to be consistent with other C2MS Messages.

Additionally, some of the subsection headers, table and figure titles don't conform to usage in the remainder of the document.

In C2MS11-45, approved in Ballot #10, the C2MS11 RTF added two new DB Query messages to C2MS 1.1. However, late in the 1.1 cycle, it was determined that these new messages are inadequate at the present time and need significant rework. The decision was made by the author of the DB Query messages to remove these from 1.1 and resubmit updated versions in a later release (1.2).

Therefore this issue is intended to undo the effect of C2MS11-45, so that those changes are not included in 1.1.

Note related issue (that was added to capture some of, but not all, of the updates needed) C2MS11-212.

An attached word doc includes markup text that was intended to augment the previously-approved C2MS11-45. This is simply included to aid recreation of a resolution issue in the future 1.2.

Two other attachments contain the originally-approved text for the spec. These should all be combined and reworked.

In C2MS 1.0, there is no indicator whether a tracking field (special fields in the Message Header and Heartbeat Messages) is required, optional or dependent. As such, in C2MS 1.1, we are marking these all optional, except for Heartbeat.SUBSCRIPTION.n.SUBJECT.PATTERN, which is being marked as dependent (required if NUM-OF-SUBSCRIPTIONS is > 0).

These should all be evaluated for R/O/D. One special case is HEARTBEAT.NUM-OF-SUBSCRIPTIONS. Normally, this should be required, because of C2MS11-135. However, in discussion for C2MS11-187, we went back to optional for this field. The rationale for this is that because it is a tracking field and therefore reserved for use by the PSM, rather than the generator of the message, it is difficult to understand what it means for a tracking field to be required. This reflects a shortcoming of the current C2MS documentation where it's not very clear what it means for a field to be a tracking field.

Finally, there are some tracking fields that should be considered for removal, such as CONNECTION-ID, MW-INFO, and USER from the Message Header. These fields seem useful for debugging, but not operations.

With the context stated above, the following need to be addressed in a future revision of C2MS:

• Revisit which tracking fields should remain and deprecate the others.
  • • As part of this, note that outside the Message Header, the only C2MS message that defines tracking fields is the Heartbeat Message. Do these belong? It just seems strange.
• Determine R/O/D (required/optional/dependent) for each tracking field. Note that in an OMG meeting in Jan, 2024, broad-brushing it, it appeared that UNIQUE-ID and PUBLISH-TIME in the Message Header and NUM-OF-SUBSCRIPTIONS in the Heartbeat could be required, and the others optional in the Message Header.
• Document the expected use for these tracking fields, including:
  • • What the expected population of tracking fields is by both the Message Sender and the underlying PSM. (example, many of these are set as part of the GMSEC API and are supposed to be left alone before invoking the API in the one PSM that we currently have, but this is inner-workings knowledge and not clearly specified in C2MS).
    • What the expected use of these tracking fields, if any, is by a Message Recipient. For example, are these stripped off by the PSM before delivery? That would be symmetrical if the PSM populates the fields, but no mention of this exists in the current documentation. Some fields may be handled differently from others... for example UNIQUE-ID makes sense, but is the PSM really going to deliver CONNECTION-ID to the Message Recipient?
    • What does it mean if a tracking field is required? If only the PSM sets them, this would mean that a message would have to be created without a required field and then handed to the PSM, which is required to populate it.... this all needs clarity in the documentation.

This is probably one for 2.0...

Message subtypes include the following that need to be address, possibly reworked/renamed:

• TLMPKT that should be renamed TLMCCSDSPKT
• TLMFRAME (already deprecated).
• TLMCCSDSCADUFRAME (new in 1.1 and OK)
• TLMCCSDSTRANSFERFRAME (new in 1.1 and OK)
• TLMTDM that probably should be renamed TLMTDMFRAME

Additionally, there is an enumerated value CCSDSPKT in Replay Telemetry Data Request Message and CCSDSPACKET in Command Request Message and Command Echo Message. These two should be make the same name.

In the messages where it exists, mnemonic.n.sample.m.quality is of type Boolean, with False meaning Good Quality and True meaning Questionable Quality. This just seems wrong. Probably should be a U16 with 1 = good and 0 = questionable.

The following notes were made when originally deferring it:
"This proposal changes the data type to signed 16 bit. And redefines GOOD as any non-negative value. BAD then become any negative value. Although this breaks the original slightly (0 is GOOD, 1 is BAD) ... it also allows for an expansion by implementations on kinds of good quality and kinds of bad quality without requiring the basic implementation to do anything more than report GOOD >= 0, or BAD < 0 by default. CAUTION: this is NOT backwards compatible. alternate approach would be BAD >= 1, and GOOD <= 0 – although this means some "goods" may be negative. this is not what is being proposed and is only a note."

Due to lack of the ability to have multiple independent implementations of GMSEC due to its message-building API functions in source code, it would be appreciated if there were an XML PSM available. This would allow for an independent implementation apart from the single known implementation at this time. At this time, there is no known PSM that enables implementation of C2MS at this time that does not depend on FOSS or government-licensed IP.

This is based on inputs from C2MS-2.