The Command Request Message designates one CMD-FORMAT type as MNEMONIC, but it seems impossible to use this type to send a mnemonic-based command using the message as is, because the formatted command is to be held in CMD-DATA (binary). We have explored modifying to this message to include parameters (arguments) to fill in a looked up command, but as we have tried to go in that direction, we get further from the expected use of Command Request Message.

Therefore, this issue calls out the need to create a new message request/response to 'create' a formatted command from a mnemonic and list of command arguments. This formatted command can then be placed in the CMD-DATA of the Command Request message. (This was the solution we converged upon in Chicago, 2024).

This "Command Creation Request Message" should indicate the CMD-FORMAT desired, include a CMD-NAME field of type STRING to hold the human-readable MNEMONIC for command lookup. It is also to contain a list of 0-n Command Arguments to hold the human-supplied arguments, along with a way to specify the argument type.

The "Command Creation Response Message should include the binary field CMD-DATA to line up with the same field name/type in Command Request Message.

As part of this effort, the MNEMONIC CMD-FORMAT should be deprecated in Command Request Message, since it turned out not to be useable as is.

Late in C2MS 1.1, we aligned SDTF error levels across the specs. 1.1 initially used 'Severe' for the highest level of concern. Later, we changed this to 'Critical' as this was better alignment with XTCE. Although the document text was all changed, we had three model diagrams that referred to 'Severe' in notes: Log Message, Heartbeat Message and Device Message. The notes in these diagrams all need to be fixed to use 'Critical' instead of 'Severe'.

Note that Log Message is already being fixed as part of the proposed resolution for C2MS12-43. Therefore, this issue only addresses Heartbeat and Device Messages.

There is frequently confusion about how C2MS should be used. Normal use patterns are not described in the C2MS document, and this would be useful to add as a guide to users. This is especially true when C2MS is used in an enterprise environment, because common interpretation is critical.

The section titled: "Introduction to Specification" needs evaluation and at least some rework. This is largely written as a "how we got to here" section, but could use more C2MS-centric language. Also, this should be considered to be moved from the front matter to a numbered section, such as perhaps 5.1 (moving the existing 5.1 to 5.2), and perhaps called "System Architecture", "Guidance", "User Guide", or something like that.

If moved to a numbered section, it needs to be marked "Informative".

The idea is to communicate context for how C2MS has been created and how it is expected to be used.

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. For now, 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 release, the duplicated fields should be deprecated in the C2MS Message.

There is a STREAM-MODE in Replay Telemetry 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.

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.

MVAL and AMVAL seem pretty close in most respects, but MVAL Response Message has many fields that are not present in AMVAL Response Message. Probably just need to do some analysis regarding comparative usages and fields to determine if it is correct as-is and if not, add the missing fields to AMVAL Resp.

Priority is an optional field on a couple of messages. We need to do some analysis regarding what it means if Priority isn't specified, and consider making textual guidance in the document.

Affected messages:

• Directive Request Message
• Simple Service Request Message

We have a number of cases where there is a listing of something, like Files in Product Message. Although Num-of-files is required, nothing in the file itself is required.

Should review these and decide if any of these are dependent, and therefore required for each File.

Note that this is true in many other cases, need to find them all and come up with a plan for each.

The "Publish" MEP second paragraph talks about using either MSG or REQ messages as a means of publishing. I think this could use some revisiting.

It seems on that a REQ message "may or may not require a response. For example, one component may request another component to take some action and does not need to know immediately if the action was successful or not." f(section 6.3.2.1, pg 15). This is then enabled by specifying a BOOLEAN value for "RESPONSE" indicating whether a reponse is expected in a REQ message.

To me, it seems like not expecting a response when issuing a REQ message is a corner case. Even in the example above, how do I know that ANY component received the REQ? I would prefer to say that components that process a REQ message are expected to respond AT LEAST with a RESP Message acknowledging receipt. If the sender chooses not to look for one, fine, but it seems like an odd pattern to make a request and ignore whether anyone heard you.

This would aid in simplifying the Publish MEP to reduce it to just MSG. Actually, if we don't do this, we need to fix the sequence diagram on pg 24, anyway, because as shown it's incorrect; requiring sending a MSG before sending a REQ. It's really meant to be either-or. So, if we remove REQ as a Publish mechanism, the diagram will be adjusted to be correct. If we don't remove it, we need to split the SD into two separate diagrams.

With all this in mind, I'd suggest:

• that the Publish MEP use only MSG Messages, which is what they are intended for
• and stating that REQ messages expect a response, even if it is only an acknowledgement (this would also remove the RESPOSE:BOOLEAN field from REQ messages.
• this results in modifying the Sequence Diagram for Publish MEP (Note that this diagram is actually incorrect, anyway, because as shown, it says that to Publish, the publisher sends a MSG and then a REQ.) At a minimum, this diagram needs to be fixed, even if we don't make the semantic changes described here.

Note that if we remove "RESPONSE:BOOLEAN" concept, this affects the following:
8.4.1.3 Directive Request Contents
8.10.1.3 Command Request Message Contents
8.12.1.3 Simple Service Request Message Contents

Additionally, we'd need to look for scattered text in the spec that says REQ does not require a response.

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.

We have already added a CMD-ECHO boolean to the Command Request Message in C2MS11-87. However, there is a possible scenario where just because we asked for one, there is no way for one to be delivered.

According to C2MS11-87, the field is an attempt to "Indicate if an ECHO should be sent at any configured point(s) along the ground chain as the command is transmitted."

The question of this issue is around what to do if the back-end system is not capable of or is not configured to send an Echo. In that case, there would quietly be no echo at all in spite of setting that flag to true. Gerry has brought up that perhaps we need a message type that is "unable to echo" or use the CMD ECHO message with a value of "here's your echo, but we aren't able to collect any information".

We have a command request message and a command response message.

There can apparently be multiple responses, each as it progresses through the values of the XTCE-STATUS. These even can include if the command was accepted, is executing and if it was completed at the vehicle. But this would mean that the command service that intercepts the command request message must be able to determine from vehicle TLM each of these states.

It would probably be worth while to revisit this and document more clearly the pattern of use of this item, including the multiple responses, and the expected statuses to produce by the command component service provider.

Additionally, there may be a couple of statuses not covered by XTCE-STATUS, such as VCC checking, and TLM verification (verifying the effected change in the telemetry). The former could fall under either 'invalid' or 'failed', but these aren't really discreet enough. The latter doesn't have any status indicated in this message.

The Log Message in 1.0 is vague in the sense of what it is supposed to be used for. Is it an application-level log (similar to Log4j or is it an event alerting mechanism for ground and/or satellite events. It might be useful to split it into application logging vs ground or satellite alerting. Need to analyze its intended and current use to the extent possible and recommend a way forward that clearly demarcates event alerts from logging.

There also needs to be an Event that is to capture AWEs or state change... something to do with teh operational state of the system (Mission Data).

The Resource Message stated objective is to enable publishing "computer performance data" via a defined C2MS message. However, using C2MS messages to monitor CPU load, memory utilization, and network port status seems wholly out of scope for satellite command and control. This provides what is essentially a rudimentary mechanism for resource monitoring, which could easily be better accomplished through industry standard mechanisms completely outside of C2MS.

In C2MS11-2, we removed CPU and memory related data from the Heartbeat Message. It makes sense to completely remove the Resource Message (via deprecation) for the same reason.

The Command Response Message has in the XTCE-STATUS field the ability to convey if a message was executed and completed. However, this may be incomplete because it doesn't account for VCC checking or functional verification (the expected effect was attained after the command, as would be indicated in a changed TLM point).

One possible solution is to add a new Command Completed Message that the command subsystem would send out after all checks to indicate that all the VCC Verification, Command Accept Verification and effected TLM (Functional Verification) were completed.

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.

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.

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.

According to the Command Echo Request:

“This message is nominally sent after a Command Request is processed by the final destination (e.g., antenna or spacecraft). The Command Echo Message can also be generated without a prior Command Request Message being sent; this is known as an 'unsolicited echo' and can be generated by ground station equipment as a result of the antenna receiving noise or interference.”

The concept of an unsolicited echo seems very strange, because it raises the question of what is being echoed, if it is not the command.

The Command Echo Message Additional Information table has a CMD-ECHO-RESULT value of UNEX "Unexpected echo received" which I suspect is tied to the "unsolicited echo".

If an unsolicited echo is meant to convey that the ground equipment is receiving noise or interference from the antenna, I believe a better approach would be to define a message to capture the noise or interference as an occurrence in the ground string and to send that, rather than to overload the Command Echo Message.

Some services may depend on other services to satisfy a request. Create a MEP that discusses and shows how this could work.

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

It seems that there is a consensus that we need database data dictionary informational messages. It seems to be in work. Capturing the item here.

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

In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

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.

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.

The SM&C defines a set of mission operations services. At the bottom of this we believe there's an SM&C MAL message.

We believe that if we define a C2MS MAL message and appropriate delivery (addressing) – that any C2MS service could flow over a C2MS implementation.

The section titled: "Introduction to Specification" needs evaluation and at least some rework. This is largely written as a "how we got to here" section, but could use more C2MS-centric language. Also, this should be considered to be moved from the front matter to a numbered section, such as perhaps 5.1 (moving the existing 5.1 to 5.2).

If moved to a numbered section, it needs to be marked "Informative".

May be related to C2MS12-28.

In section 8.8.1.3 Mnemonic Value Request Message Contents, there is a kind of odd example paragraph under the explanation of PUBLISH-RATE, that states: "For example, the data provider may know that it is limited to an output rate of 1 megabyte per second. If it is currently near its maximum output rate and after calculating the additional load of the request it would exceed that rate, the data provider may reject the Mnemonic Value Request with a "Failed Completion" status in the RESPONSE-STATUS field, and an optional status of "Unable to meet demand" in the RETURN-VALUE field."

This should probably be placed elsewhere (under a different heading in the same area) and possibly reworded, as an example of not being able to meet the request, instead of an example of PUBLISH-RATE.

The issue is that PUBLISH-RATE is described, then a caveat is given, then an example of the caveat. It winds up confusing as an example of PUBLISH-RATE.

SM&C is a CCSDS spec that defines a set of ground system services, it is mainly Parameter (Mnemonic) value based (low level info is largely gone except they've added a packet construct recently). At the bottom of SM&C is the MAL message. The MAL message is technically abstract and one is to map it to your transport technology of choice – but perhaps there's no reason to literally implement a MAL message on the GMSEC bus. Determining details like "how will this really work" and so on would be part of this effort.
Once completed, we then say to SM&C folks that we could support an SM&C service. There's an additional facet related about tying into XTCE.

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

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 MVAL Response and MVAL Data messages both can contain individual MVALs. But in one, certain MVAL fields are required, while in other they are not. These need to be made consistent.

Note that this applies to AMVAL Response and AMVAL Data messages as well.

Simple Service Request uses ME1 to indicate the target of the request, but this can have one of two mutually-exclusive forms:

• Service Provider Name (a named instance of a component, such as FDServiceApp1)
• A Service Name not related to a specific component (such as Flight Dynamics)

Meanwhile, the Simple Service Response also uses ME1 in a similar, but slightly different way. In the RESP, ME1 represents one of two mutually exclusive forms:

• A Requestor Name (a named instance of a components that requested a service, or will receive data from the Service Provider, such as C2App7)
• A Service Name not specific to a component (such as Flight Dynamics)

Note that when using ME1 to designate a component, it is always the target recipient of the request/response, but when specifying a Service Name, it is always the name of the Service Provided, which is more related to the responder than the requestor. In this way, the Request Message uses that form of ME1 to designate the recipient, but the Response Message in that form designates to the provider.

This dual-hatting of ME1 is pretty confusing. One major user of C2MS has modified these messages to separate out the two uses of ME1 into ME1 and ME2, shifting ME2 and ME3 to the right.

This issue reqeusts to do that same thing, matching the modification made by that major user.

Based on review of latest specification, the problem detailed in C2MS-5 is still present. This problem makes it not possible for a client application to properly be developed to support all MEPs. If a client application is developed to support MEP2, then it will ignore all future responses after the first ACK comes in when communicating with a server that supports MEP4 or MEP5. If a client application is developed to support MEP4 and MEP5, then it will never think that a request finished when communicating with a server that supports MEP2.

As is currently specified, via table 6-9 on page 20, the Acknowledge is listed as a Final Status. Though it is only a final status in MEP2.

Possible solutions:
1. Remove MEP2. This would make Acknowledge in Table 6-9 have a Final Status of "No"
2. Add an additional status code of Acknowledge Complete (perhaps #7). In this option, Acknowledge (#1) would have Final Status of "No", though new Acknowledge Complete (#7) would have Initial Status of "Yes", Intermediate Status of "No", and Final Status of "Yes".

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.

In Mnemonic Value Data Message and Archive Mnemonic Value Data Message, the MNEMONIC.n.STATUS is Optional. Need to consider if it should be required for each MNEMONIC in the data message.

Replace simple service REQ/RESP and deprecate current simple service messages.

Numerous issues are present with the current Simple Service REQ/RESP Messages. These include:

• Destination Component is overloaded with two different meanings, depending on use.
• Using Destination Component for SERVICE-NAME essentially requires the mission to establish a naming convention to separate SERVICE-NAME from DESTINATION-COMPONENT strings in order to tell the difference between them.
• The Request can include a SERVICE-GROUP to further the SERVICE-NAME, sort of like namespacing, but this SERVICE-GROUP is not included in the Response message, which means that if needed in the Request, it is not possible to correctly correlate a Response to a Request.
• The paradigm does not include a publish MEP natively, so at some point in the past, GMSEC/C2MS declared that a Request Message could be used to publish information, completely outside the Req/Resp MEP.
• Current usage is to submit a request and then to have the response message indicate either the DESTINATION-COMPONENT of the original requestor or, alternately, the SERVICE-NAME associated with the original request. In keeping with other response messages, it should probably be just the DESTINATION-COMPONENT. It doesn't really need to have the option to use SERVICE-NAME, because the requestor is known. It also creates an odd and confusing alternate use, where in the current mode, the DESTINATION-COMPONENT is the requestor, but the SERVICE-NAME is related to the provider.

Together, this makes the Simple Service Messages hopelessly tangled. The effort here is to start from scratch, deprecate the existing messages and move forward with something more workable.

In this there are two factors that need consideration:

• The Simple Service (and its replacement) should be intended for emerging services that go online in an existing domain, but that have not yet been able to establish their own set of dedicated C2MS-derived messages. It should not be the case that services live forever on this Simple Service (or replacement) mechanism.
• The C2MS Messages themselves, perhaps in 2.0? should have a mechanism for extension without having to define new messages types. In other words, a service provider should be able to create a C2MS message that is simply expanded by what the service provider needs. If this can be accomplished, the Simple Service Paradigm is greatly aided, either by providing an easier path to offload the temporary use of Simple Service, or even by obviating the need for Simple Service.

Many fields in many messages contain value information. Some of the values are defaults and some are intended to be constant. Also, this information is in the "notes" column. There should be a way to differentiate between fixed and default values more easily than reading the notes fields. Also, this will make encoding those attributes in the .xsd PSM easier.

From Justin: In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). May need a separate field to indicate the type of data in these fields.

[NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]

The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.

The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.

For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.

The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]

[It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]

RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.

Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.

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.

The purpose NUM-OF-PROD-SUBTYPE-SUBCATEGORIES in several messages is not clear and needs to be reviewed and either removed or expanded upon. Note that this is called NUM-OF-PRODUCT-SUBTYPES in C2MS 1.0, but the explanations are simply preserved from 1.0 into 1.1 where the field was renamed, so this issue persists.

One interesting aspect of this is that these subtype subcategories are represented in the subject of the Product Message ME5 and ME6, and all other messages that have it refer to this Subject construct. This is described in the table and notes for the table for (C2MS 1.1) "Table 8-163. Properties of the Miscellaneous Elements for the Product Message"

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.

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.

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.

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.

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.

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.

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.

In the "... Subject Naming" tables, a "Subject Content" item is supposed to have brackets [] around variables and no brackets for literals. This is not always followed though. See Telemetry CCSDS Packet Message as an example.ME2-ME6 do not use brackets, but should. Several other tables are like this.

In Product Response Message, PROD-MSGS-TO-SEND field is an unsigned type, with a stated minimum "value" of 0+, but says in the description text the following:

A value of “-1” can be used to indicate “Unknown”.

Should probably find a different way to indicate unknown, such as not including this optional field in the message.

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.