C2MS12 — Rework "Introduction to Specification" into a Section Describing Expected Use

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.

One concept to make clear is that it does not require a message bus, but that is one expected use. Also, that when using message bus architecture, that more than one bus is a probable solution for many issues. For example, raw TLM might flow on one bus, MVALs on another, Replay on another.

Rework into in 1.2

This resolution completely rewrites the existing Introduction to Specification section, removing almost all prior text and all diagrams. New text is provided to introduce the reader to the overall nature of C2MS, which is fully described in details that following in the normative document.

Guidelines used in the rewrite:

• Remove the history of how we got C2MS
• Eliminate the discussion of GMSEC, which is merely one PSM, and neither the purpose for nor the assumed implementation of C2MS.
• Move away from Pub/Sub as the assumed transport mechanism... it is supported but not required nor emphasized.
• Provide very high-level introduction to the three types of messages, but defer to the document for detail
• Introduce the concept of Message Exchange Patterns for use of the three message types, but defer to the document for detail
• Discuss the need, but not the method, for tailoring C2MS for the environment of use.
• Emphasize the flexible nature of the message set that can be used in a way determined best by the enterprise/domain where it is employed.

Rationale for the choices made in the rewrite:

• No diagrams are included, rather the introduction is reduced to a simple 3/4-ish pages to promote it as a brief high-level explanation, more likely to be read. All prior (PowerPoint-built) diagrams existed only to illustrate the use of a message bus via GMSEC API as a means of communication, which is no longer to be emphasized. The concept of components communicating with each other over a non-defined transport mechanism does not warrant a picture.
• The intro is kept in its current place in the document to be consistent with other Space Domain Task Force specification. Those that have one, have it in this location.
• NASA/GMSEC are mentioned (outside the Introduction) as providing one PSM for possible use. This already exists, but is being cleaned up. Because NASA has provided the only known PSM, it makes sense to maintain this note.