(Note: This is a consolidated and cleaned-up issue for CCSDS SM&C and MAL, which exist in several other C2MS issues.
This information has been collected from those sources and refined for clarity moving forward. Previous issues listed below.)

The CCSDS (Spacecraft Monitor & Control) SM&C defines a set of mission operations services. At the bottom of these
services is an abstract MAL message layer.

It is possible that an abstract MAL message could be mapped to a C2MS version, along with an appropriate addressing
scheme so that SM&C services could flow over a C2MS system, coexisting with C2MS message-based services. The following
is a copy of the current MAL message. It has a header consisting of several fields; after these data fields, this will
be (preliminarily) further discussed following the header section.

Within the header, there are TO and FROM fields. The CCSDS MAL Blue Book states that these fields are “open” in the MAL
abstract definition, although some form of reasonable quality-of-delivery service should also be provided for MAL message
delivery. There is also a service model—this is described in a separate Blue Book—which suggests that each service has an
associated URI.

Finally, there are several MAL mappings defined in various Blue Books—TCP, HTTP, and Space Packets, to name three. These
show how the MAL URI TO/FROM fields are mapped to specific protocol headers such as source/destination IP addresses, HTTP
URLs, and APIDs, to align with the above references. Given that the C2MS message can define services using C2MS subjects,
these can be used directly for the MAL TO/FROM fields or mapped from corresponding URI/URL values.

The REFERENCES section at the end of this description points to several CCSDS reports and multiple implementations in
different programming languages, using a variety of transport mechanisms.

Abstract MAL Header

URI MAL Header

(possible and vague mapping of MAL as C2MS minus fixing up types and the List)

C2MS MAL Header

For C2MS most of the fields can be mapped to C2MS types with exception List<NameType> which should follow the C2MS pattern:
Field Type Description
Supplement.n.Name Scalar Value Optional supplementary fields

An "InteractionType" is:

Interaction Types

(PRELIMINARY)

MAL MESSAGE BODY
After these header items the MAL body appears to consist of a TYPE/VALUE pair that is aligned with a specific message specification from the service.
In other words there is not a name associated with each field.

This means there are 2 options to further map a MAL message to C2MS:
1) bundle up any concrete MAL message's data body into a C2MS blob type and send it on, with the idea that the MAL service receiving it through C2MS
layer will then know what to do with it, because it has its own service definitions.
2) Let the mapper handle this because it's sophisticated and it will map each MAL field to a C2MS field using the appropriate service definition,
(somehow) giving each field in that service (a type/value pair) a name as well.

Alternative approaches?
One alternative approach to all the above would be to take any concrete MAL message, and in total make it a blob-style part of C2MS message in the
data body – and broadcast this message on the C2MS bus – and any particular node implementing SM&C services would receive that message - and
then decode it enough to determine if it's recipient or not.

This is a simpler approach overall but every node that receives such "broadcast" MAL messages will have to look at every
one of them to determine if any particular one is for them or not.

Other approaches considering essentially involved tunnelling a URL based MAL message through C2MS and then inserting/stuffing it into the http "stack" and so on and
this seem messy and possibly a security horror.

REFERENCES
– there's a large number of related ccsds publication found here under the "Mission Operations..." title
---- https://ccsds.org/publications/moims/
– https://en.wikipedia.org/wiki/Message_Abstraction_Layer
– https://github.com/CNES/ccsdsmo-maljava
– https://github.com/CNES/ccsdsmo-malc (note: uses zeromq but not clear if c2ms subject/topics would be mappable to it)
– https://github.com/nasa/CCSDS-MAL-Http-Binding-Xml-Encoding
– https://github.com/CNES/ccsdsmo-malgo
– https://github.com/tanagraspace/ccsdsmo-malc-sepp-apps (fork may have updates)

PREVIOUS or EXISTING ISSUES (Deferred)
The following issues (& related proposals) have previously been submitted on this topic. They have in general been deferred (to 1.3 now). However the intent of this issue is to subsume them all into this one issue which will carry forward.

They are as follows:
– C2MS12-79
– C2MS12-97
– C2MS12-74
– C2MS12-112

Create a PowerPoint Set of Slides with Further Guidance for C2MS which will be placed in the C2MS Spec site and referenced from the Non-normative References section.

Attached is a powerpoint that contains the main topics to cover.

Below is the set of modifications we had planned for 1.2, but then backed off:
= = =
(At the end of the Intro to Specification)
In addition to this detailed specification, the Space Domain Task Force of the OMG has created supporting documents that may aid in the use of C2MS, which are listed in the "Non-Normative References" (see Section 3.2.1 OMG Space Domain Task Force Guidance Documents).

(NOTE to Reviewers/Editor: OMG SDTF is to create two PowerPoints to be used to give additional guidance of a more free-form nature such as why and how to go about using these specs, best practices, etc that don't belong directly in the specs but that would be useful to people trying to figure these out. The documents haven't been created yet, but will be by the time this goes to BETA.)

3.2 Non-Normative References
3.2.1 OMG Space Domain Task Force Guidance Documents

The following documents provide guidance for the usage of C2MS set forth by the OMG Space Domain Task Force.

• OMG C2MS Overview and Guidance (see https://www.omg.org/spec/C2MS/1.2/OMG_C2MS_Overview_and_Guidance.pptx [final link to be provided during document finalization])
• System Integrator and Use of Standards (see https://www.omg.org/space/ [final link to be provided during document finalization])

3.2.12 NASA GMSEC Documents

Note that NASA has developed a Platform Specific Model (PSM) referred to as GMSEC. The GMSEC API software, selected components, and documentation are distributed by NASA. Others are free to develop alternative PSMs.

The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.

• GMSEC Architecture Document, Release 3.0.0, February 2018
• GMSEC API 5.2 User’s Guide, November 2023

See 6.2.2 Format of C2MS Subject Names in the 1.1 document. “An asterisk (*) can take the place of exactly one whole element but not a substring of an element.”

We want to allow asterisk to be used in a part of an element string, like:

".FO*-B*R-*AZ." matching to "FOO-BAR-BAZ"

There doesn't seem to be any reason that this couldn't work... we simply don't currently allow it. because it is not currently allowed and we would be now allowing it, it is backward compatible.

Also allow blank or empty subject elements and document the the use of FILL as only satisfying otherwise required elements. Make clear that you can't use blank for elements that are required. matching an empty would look like "foo..baz"... which would not match "foo.bar.baz".

In the OMG Leeds Meeting, we talked about idenifying a special character, instead of the special word FILL. Possible suggestions were = % ^ which would look like any of the following:

FOO.=.BAZ
FOO.%.BAZ
FOO.^.BAZ

But as we discussed using a special character in a subject name could cause problems and if so, the implementing component might have to substitute it with some text... I don't know... something like FILL.

So, for now, we are setting this aside, living with FILL and we can revisit at a time in the future.

We could add a message called Service Lookup Request Message that asks "who is out there that can service this request?" Then the requestor will receive 0-many responses.

The idea here is to help with the issue that all request messages today want a DESTINATION-COMPONENT, but we have no facility for the requestor to find one native to C2MS.

Request would have all the standard subject elements, up to ME1, which instead of the DESTINATION-COMPONENT would be REQ-SUB-TYPE, so if I'm asking who serves MVALs for a given satellite, I'd have a topic of "Domain1.Domain2.Mission.Const.Sat.REQ.SVC-LOOKUP.MVAL" which means, who handles the specific satellite for the MVAL subtype (obviously, this would only be needed for request service providers, so the REQ is not needed as part of the query.

The responses would (all) contain the name of the servicing component, that could then be used in an MVAL REQ for DESTINATION-COMPONENT.

After the resolution to C2MS12-192, this may not be needed. However, capturing it for future consideration.

From an implementation standpoint, C2MS (and C2MS-EXT) Messages should be registerable at some kind of "C2MSMessageDescriptionManagerService" which serves them up, possibly pushing them out? To all active nodes on a gmsec bus ...

Perhaps a Register Service message that includes what 'services' and message types are provided, a Service Registered message published to all, a Lookup Service Request message that asks 'who can do what I need?' and a Service Lookup Response message.

C2MS doesn't need to define how that registry is maintained or made resilient or how services stay in the list (heartbeat?) at all. That is up to the implmentor, if any.

Similar to C2MS12-118, it would be nice to create a model hierarchy for the TDM messages. The 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.

Many t&c systems support some form of namespaces in their database definitions. For example a "parameter" might be associated with a certain namespace ("/myagency/mymission/mysystem/mysubsystem/batv1") or a command as well. XTCE supports a kind of namespace through the spacesystem tree. GSFC's ITOS supports namespaces in the database. (the other one, ASIST does not). And so forth.

This might be a buy-back type of message. Need to see what there is and if we could use it. This may already be accomplished via Tracking Data Message. Need to identify the need and see if these satisfy it already.

In C2MS 1.0, XSDs were provided by NASA Goddard and published as 'normative' along with the spec. However, these were somewhat incomplete and not maintained by OMG, so these were removed as part of C2MS in 1.1.

The issue is that we do need to supply some PSMs to encourage C2MS usage in the space community. To address GMSEC, it makes sense to supply an XML PSM, but it also seems good to have a REST/JSON PSM to make it more modern and usable in modern architectures. Also consider PSM for Protobuf.

The intent should be to stop using NASA Goddard as the point of contact for all things C2MS. In fact, OMG should supply these PSMs to Goddard as input, rather than Goddard supplying XSDs to OMG as happened in 1.0.

Additionally, a REST/JSON and/or Protobuf PSM should focus on non-pub-sub usage... something that can exist and operate in a services-based architecture. In this case, it could be that the message subjects are ignored as these are used entirely for pub-sub subscriptions/delivery. If that turns out to be the case, we might make clear in the PIM that subjects are optional.

Related to the above, we COULD make subjects part of a PSM rather than PIM???

PSMs can be done as new chapters within the spec, perhaps in a C2MS 1.3 release.

In our model diagrams, we tend to use "default" values in UML to signify constants, which isn't correct UML. To resolve this, evaluate each item with a default value to decide if it is supposed to be constant and if so, check the "Is Read Only" flag in the attribute for that class. If it is also static, check the "Is Static" flag, too. The former adds "

" to the display of the attribute, the latter underlines it. Note, though, that with C2MS12-118, CONTENT-VERSION and SPECIFICATION, two obvious cases, have been added to the Constraints section of classes, which enforces a specific value, so these are already OK.

Also consider marking all final classes with "Final Specification" to indicate that they can't be subclassed.

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.

SM&C (Spacecraft Monitor & Control) is a CCSDS working area 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. The MAL is explained further here – https://en.wikipedia.org/wiki/Message_Abstraction_Layer ... Note that in essence the idea which may need refinement is to make a mapping of the MAL into a concrete C2MS message. Implementation an addressing scheme in the pub/sub environ is another aspect. at least some implementations by esa use tcp/ip and it may be that some hard address approach would work well enough for pub/sub (broadcast not being needed)

This issue covers the reevaluation of the GUID type to consider specifying not only the format (RFC 4122), but also the algorithm for generating the guid.

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 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.

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 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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.