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, including the following:

• XML PSM (replace the GMSEC-supplied XSDs from 1.0 and the informal 1.2)
• REST/JSON PSM - to make it more modern and usable in modern architectures.
• Also consider PSM for Protobuf. In this case, make the attempt and see how easy it is.
• Others? IDL? We did talk about IDL as a way to satisfy the OMG... IMO, it's unnecessary.

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.

Related to the above, we COULD make subjects part of a PSM rather than PIM??? However, this probably isn't feesible in a 1.x baseline. We do discuss that these are optional, but it is also possible to use them for straight filtering, rather than just pub-sum.

Any PSM should consider including example messages based on the schemas provided by the PSMs.

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

Note this text from C2MS13-3, which was originally created in 2018: "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."

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.

Also create a 'brocure' one-two page glossy pdf with an overview. The powerpoint would be more detailed guidance.

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"

And for multiple characters within a string:

".FO*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 that 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 and the services that handle them should be registerable at some kind of "C2MSMessageRegistryService."

The idea would be to list all the C2MS and C2MS-EXT messages that are used within that system and for cases of request messages, list all DESTINATION-COMPONENT of the service-providers of that request.

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.

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.

(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

One other that is being brought into this one is C2MS12-27, which is being closed as a dup of this one... text from that issue:

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)

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)

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 "{readOnly}" 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.

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.

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