Command and Control Message Specification Avatar
  1. OMG Specification

Command and Control Message Specification — Closed Issues

  • Acronym: C2MS
  • Issues Count: 44
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
C2MS-14 Data Dictionary Messages C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-60 "Mnemonic" should be called "Parameter" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-62 Specify multiplicity for required and optional fields C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-59 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-61 Add documentation within the model C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-13 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-15 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-44 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-42 Pub/Sub subscription status unknown C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-41 Acknowledge Final Status inconsistency C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-39 XML PSM recommended C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-11 Archive Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-9 C2CX Heartbeat comments C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-3 Lack of a registry concept C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-21 In Heartbeat message: fix typo in the name of the field CONNECTION-ENDPOINT C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-19 space/18-02-03 XMI file doesn't 'validate' C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-20 space/18-02-05 (C2MS zip file for XML schemas) contains corrupt file C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-16 space/18-02-05 (C2MS zip file for XML schemas) - zip file unreadable C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-17 use of color is discouraged C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-12 Product Messages comments C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-10 Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-36 Fix C2CX Device message, field NUM-OF_DEVICES C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-24 Add Command Echo message C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-25 Change the type info for a field in the C2CX Device message C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-57 Figure 7-1, C2MS Message Exchange Patterns Diagram, misspells RESPONSE C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-40 Non-satellite-related messages are not representable C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-84 Merge figures 8-1 and 8-2 C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-83 Add (back) Simple Service request and response messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-82 Change HEADER-VERSION and CONTENT-VERSION default values to 2019 in all Message Diagrams and all Message Contents tables C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-81 Add DESTINATION-COMPONENT field to the header and to the Miscellaneous Elements of REQ, RESP, and MSG messages that are associated with a REQ C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-80 Add field MSG-VERSION to the header C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-78 Add another row in the table, for operator entered log messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-79 Add request-id to be one of the Miscellaneous Elements in subjects of MSG type messages that may be in response to a request C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-1 Expecting that GMSEC will change to use C2MS as its Subject Standard C2MS 1.0a1 C2MS 1.0 Closed; Out Of Scope closed
C2MS-2 Should GMSEC API enforce/recommend XML-formatted string constructor usage? C2MS 1.0a1 C2MS 1.0 Closed; Out Of Scope closed
C2MS-6 Have required attributes in the messages C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-8 Directive Request: strings, UNIQUE-ID and correlation IDs C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-7 Change comments regarding signed types C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-22 Make sure CCSDS info is consistent and current C2MS 1.0b1 C2MS 1.0 Closed; No Change closed
C2MS-23 Flatten the message hierarchy re: C2CX, TLM, and NDM messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-18 page numbers in early sections are messed up (i, ii, i, iii, etc.) C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-5 Acknowledge Final Status is not deterministic C2MS 1.0a1 C2MS 1.0 Closed; No Change closed
C2MS-4 Subject naming missing the concept of something not being directly tied to a satellite C2MS 1.0a1 C2MS 1.0 Closed; No Change closed
C2MS-43 Modifying a subscription is undefined C2MS 1.0b1 C2MS 1.0 Duplicate or Merged closed

Issues Descriptions

Data Dictionary Messages

  • Key: C2MS-14
  • Status: closed  
  • Source: Boeing ( David Overeem)
  • Summary:

    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.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:23 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer - out of scope for this FTF.

    SDTF Ottawa recommended deferral to next release of C2MS, ver 1.1. (Also, FYI, GMSEC project has drafted messages for retrieval of display related meta-data. They will be available with GMSEC Fall 2018 release.

  • Updated: Wed, 9 Dec 2020 21:52 GMT

"Mnemonic" should be called "Parameter"

  • Key: C2MS-60
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    This to be consistent with the XTCE Specification. Moreover Mnemonic isn't accurate as the very definition of mnemonic is a shorthand "code" for the actual parameter name.

    Recommend close/deferring this issue, but believe it's important to capture our rationale as the community will ask why the inconsistency between SDTF specifications.

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:48 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Issue received after 4 week RFC deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Specify multiplicity for required and optional fields

  • Key: C2MS-62
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    Set the association multiplicity for required fields to '1' and optional fields to '0..1'

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:37 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Received after RFC 4-week deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

For consistency, all message types should have a name that ends with "message"

  • Key: C2MS-59
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

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

    Recommendation is to deffer this issue, but wanted to capture it because the community will ask why the inconsistent naming.

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Received after 4-week RFC deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Add documentation within the model

  • Key: C2MS-61
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    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.

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:31 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1 (But good idea)

    Issue received after the RFC 4 week deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS-13
  • Status: closed  
  • Source: Boeing ( David Overeem)
  • Summary:

    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.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:21 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer - out of scope for this FTF.

    SDTF Ottawa recommended deferral to next release of C2MS, ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS-15
  • Status: closed  
  • Source: Boeing ( David Overeem)
  • Summary:

    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.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:28 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer - out of scope for this FTF.

    SDTF Ottawa recommended deferral to next release of C2MS, ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Requesting data via pub/sub requires knowing publisher's service name

  • Key: C2MS-44
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Requesting data, such as telemetry, via pub/sub requires knowing the publisher's server name. There should be a way to request data without this being already known. Solutions could include not requiring the publisher name in the subject or a registry capability.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:48 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Issue received after RFC comment deadline

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Pub/Sub subscription status unknown

  • Key: C2MS-42
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    C2MS should offer a mechanism for clients and/or servers to be able to check validity of a subscription.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:43 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Checking validity of a Request is an implementation concern - add verbiage that it is PSM responsibility

    Add to section 6.3.1 that: A mechanism to determine validity of previously issued requests should be implemented by the PSM."

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Acknowledge Final Status inconsistency

  • Key: C2MS-41
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

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

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:44 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to next revision

    This issue has ripple effects to more of the document. Needs more thought.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

XML PSM recommended

  • Key: C2MS-39
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    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.

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:07 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Add the GMSEC xsd files to C2MS as a PSM

    Larger scope than FTF 1.0. Suggest adding in C2MS RTF 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Archive Mnemonic Value Request comments

  • Key: C2MS-11
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (Archive Mnemonic Value Request) Section 7.9.1

    • Need official registry for FORMAT values
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    This issue is out of scope of FTF type of work.

    Recommend that this issue be deferred to C2MS ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

C2CX Heartbeat comments

  • Key: C2MS-9
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (C2CX Heartbeat) Section 7.5.4

    • Suggest not having CPU / Memory utilization in the messages. That would be better implemented through normal system monitoring mechanisms (e.g., SNMP). Code to retrieve such information is typically platform-specific and is not related to the business logic of the component.
    • If such information is required, suggest having a system monitoring component instead.
    • Unclear exactly how this would work in a clustered environment. Different hosts implementing the same service would provide conflicting answers.
    • Unclear why the commentary on why memory leaks are bad is in the spec
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:21 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Not necessary for now - fields are optional

    Referenced fields in HB are optional, so not necessary to use them. And others have indicated the comment re: memory leaks is useful. SDTF Ottawa recommended deferring until next update cycle, i.e., Ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Lack of a registry concept

  • Key: C2MS-3
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Discoverability of data is still a major concern due to the lack of a registry.

    • Unclear how components are supposed to find out about available resources
    • Unclear how components are supposed to find out about related subjects
    • What is the associated heartbeat subject of a client, particularly a temporary one?
    • ME1 depends on knowing the name of the other end beforehand. Where is this supposed to come from and why should a component have to care about that?
    • Recommend a registry be considered and answers to question above.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:10 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    *This issue is out of scope of FTF type of work. *

    Recommend that this issue be deferred.

    A potential workaround is that Heartbeat messages be used to discover other components/services.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

In Heartbeat message: fix typo in the name of the field CONNECTION-ENDPOINT

  • Key: C2MS-21
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Change "CONNECTION-ENDPOINT" to MW-CONNECTION-ENDPOINT in table 8-12.

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:55 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change the name of field CONNECTION-ENDPOINT to MW-CONNECTION-ENDPOINT

    Minor edit to one field name. This change appears in figure 8-12 and table 8-43.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

space/18-02-03 XMI file doesn't 'validate'

  • Key: C2MS-19
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    see line 3 extraneous namespace; line 5849 <NUL> character

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:51 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Replace the machine-readable XMI file with dtc-19-06-07.xmi to correct the invalid version that included extraneous namespaces and nul character, with the file attached to this resolution.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

space/18-02-05 (C2MS zip file for XML schemas) contains corrupt file

  • Key: C2MS-20
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    GMSEC_Defaults.xsd is mangled

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:53 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    File space-18-02-05.zip contained a zip archive within a zip archive. That has been corrected in the attached.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

space/18-02-05 (C2MS zip file for XML schemas) - zip file unreadable

  • Key: C2MS-16
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    space/18-02-05 is corrupt

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:49 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    space-18-02-05.zip contained a corrupt file.
    This was a glitch in the creation of the zip file. Fixed now. New zip attached.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

use of color is discouraged

  • Key: C2MS-17
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    For all message diagrams, color is problematic. Make black/white for printing, copying, etc.

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:50 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    lighten front 3 images and make all message diagram color lighter; also, remove table row header colors

    Spoke with Jason Smith at recent meetings (either Seattle or Ottawa) and he said this is not a show-stopper. I propose we meet in the middle and I lighten the color so that there is still some color for aesthetics but printing in black/white shows up better (and uses less ink/toner).

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Product Messages comments

  • Key: C2MS-12
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (Product Messages) Section 7.11 (Though these comments are related to guidance for custom messages

    • Consider providing guidance regarding what the minimal set of attributes should be for a custom message type.
    • Indicate that custom messages can be considered to become sponsored message types in future versions of the specification.
    • Extending the lexicon should be encouraged by the implementation, not discouraged, as the strictest of the GMSEC 4.x MIST modes does.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:26 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change section 8.1 to mention extensions

    Change: "The Message Header is a super-class for all C2MS messages in the sense that all fields in the Message Header appear in all of the C2MS messages." to "The Message Header is a super-class for all C2MS messages and any extensions in the sense that all fields in the Message Header appear in all of the C2MS messages.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Mnemonic Value Request comments

  • Key: C2MS-10
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (Mnemonic Value Request) Section 7.8.1

    • In GMSEC, re-requesting on the same name is (per an e-mail thread with GSFC) defined as replacing the previous subscription instead of being additive/subtractive. Is that notion being kept in this spec? If so, this should be explicitly defined in the specification.
    • DURATION: When there is no DURATION specified, but a component decides to have a maximum duration anyway, data will arbitrarily stop. This is problematic for subscriptions by a non-UI system component, like a script that checks telemetry values or a roll-up / derived capability that subscribes to data to produce second-level data. Mechanisms to avoid such stoppages in data, such as periodically resubscribing are wasteful and potentially inconsistent between components.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:23 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Part covered by issue 8, DURATION issue to be fixed by adding final message

    Rerequesting will be solved by resolution to issue 8, request-id. Duration will be solved by adding paragraph near duration description that final-message flag should always be set on sending final message. At the very end of section 8.8.1.3, where self-imposed duration is discussed, add this: "If a data provider does self-impose a maximum duration, the FINAL-MESSAGE field should be set appropriately in the last message sent."

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Fix C2CX Device message, field NUM-OF_DEVICES

  • Key: C2MS-36
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    The field NUM-OF_DEVICES should be NUM-OF-DEVICES - that is, the underscore should be a dash for consistency with all other messages' field names.

  • Reported: C2MS 1.0b1 — Mon, 22 Oct 2018 18:03 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Replace figure 8-11 on page 99, Device Message Diagram, with the attached figure.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add Command Echo message

  • Key: C2MS-24
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Rich Monteleone of RTLogic suggested adding a command echo message. Here is an email from him about it. I (Jay Bugenhagen) also have available Rich's sample schema and some other info re: the potential new message.
    ----------------------------------
    Per our discussions recently I’ve created a draft for a Command Echo GMSEC Message Schema (GMSEC.MSG.CMD.ECHO) for consideration by NASA/EGS.

    Notes/Rationale:
    Since Command Echo is executed out-of-band with Command Request/Response (GMSEC.REQ.CMD) I’ve elected to construct the schema for publish/subscribe messaging.
    I based the schema’s off of the 2016.00 spec delivered with the GMSEC 4.3 API
    I also attached the GMSEC.REQ.CMD schema, I’ve added an optional field that we found we needed for commanding (see CMD-ENCODING).

    Discussion topics: We need to determine whether or not we should add the comparison of metadata associated with a commands to command echo. Right now we are not comparing command metadata.
    Example metadata (SPACECRAFT-EXECUTION-TIME, LATEST-UPLINK-TIME, EARLIEST-UPLINK-TIME, RELEASE-TIME)

  • Reported: C2MS 1.0b1 — Fri, 21 Sep 2018 14:53 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    There is a need to be able to echo commands from front-end equipment. The addition of this message allows for that capability.

    Draft originally from Rich Monteleone (RTLogic). Eric Ogren supported final development of new message.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Change the type info for a field in the C2CX Device message

  • Key: C2MS-25
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    The type for the Device message field DEVICE.n.PARAM.m.VALUE should be Variable, not Binary.

  • Reported: C2MS 1.0b1 — Fri, 21 Sep 2018 14:59 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change type of DEVICE.n.PARAM.m.VALUE to Variable

    In figure 8-11, change the type of DEVICE.n.PARAM.m.VALUE from "Binary" to "Variable"

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Figure 7-1, C2MS Message Exchange Patterns Diagram, misspells RESPONSE


Non-satellite-related messages are not representable

  • Key: C2MS-40
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    The subject naming of messages expects the constructs of a mission, constellation, and satellite. It is undefined how subjects should be formed that are not associated with these. This has been dealt with in specific ISDs with MISSION=ENTERPRISE, CONSTELLATION-ID=SERVICE, SAT-ID-PHYSICAL=<service_name>.

    An example is how ground equipment should be addressed, as it might support being used by several spacecraft.

    This is based on inputs from C2MS-4.

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:13 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    For non-satellite-related services, suggest using the service name in the SAT-ID-PHYSICAL

    Append final paragraph 6.2.3.3 with:
    For services not associated with a constellation or a satellite, place the service name in the "Sat" element.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Merge figures 8-1 and 8-2

  • Key: C2MS-84
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    There's no need for these to be separate. Merge them into one.

  • Reported: C2MS 1.0b1 — Thu, 9 May 2019 19:15 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    *Merge the 2 "high-level uml class diagram" figures (8-1 and 8-2) into one. *

    All classes on one diagram for ease of reference. Figure 8-2 is deleted and Figure 8-1 is updated.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add (back) Simple Service request and response messages

  • Key: C2MS-83
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    These messages were a part of the heritage source spec (i.e., GMSEC project) for C2MS, but were not included in the final C2MS RFC submission. AF/EBIG would like these messages added back in.

  • Reported: C2MS 1.0b1 — Wed, 8 May 2019 15:22 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    As issue states, add the Simple Service messages into C2MS

    Make the new messages consistent with other changes being done as part of this FTF 1.0 work.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Change HEADER-VERSION and CONTENT-VERSION default values to 2019 in all Message Diagrams and all Message Contents tables

  • Key: C2MS-82
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    This change is to match the (expected) publication year of C2MS.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:57 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Update values for CONTENT-VERSION and HEADER-VERSION fields to 2019

    Expected publication is 2019, update Message Diagram figures and tables, as shown in attachments.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add DESTINATION-COMPONENT field to the header and to the Miscellaneous Elements of REQ, RESP, and MSG messages that are associated with a REQ

  • Key: C2MS-81
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Add an optional message field of type HEADER STRING called DESTINATION-COMPONENT to all messages, via the message header. Reasoning: many C2MS messages already specify to add this value to one of the miscellaneous subject elements. This change is to make consistent the desire that all subject elements are also elements of the message body; note that COMPONENT (name of the sender) is already a field in the message header.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:36 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add DESTINATION-COMPONENT to the message header and appropriate messages' miscellaneous elements

    Add an optional message field of type HEADER STRING called DESTINATION-COMPONENT to all messages, by adding it to the message header. Reasoning: many C2MS messages already specify to add this value to one of the miscellaneous subject elements.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add field MSG-VERSION to the header

  • Key: C2MS-80
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Add MSG-VERSION to the header (type: string, status: optional, description: “Version information for the message”). Reasoning: AF/EBIG has already added these to their messages and would like to codify it as part of the standard. This field provides more granular versioning than the HEADER-VERSION and CONTENT-VERSION fields currently available.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:27 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add MSG-VERSION field to the Message Header

    Add MSG-VERSION to the header (type: string, status: optional, description: “Version information for the message”).

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add another row in the table, for operator entered log messages

  • Key: C2MS-78
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Add a row to table 8-13 for operator entered log messages; this issue at the request of the NASA JPSS mission and also potentially for use by the NASA GMSEC Note component.
    Table is alphabetical, so add a row between FDN and ORB rows, as follows:
    OPER Operator Information Operator entered log message

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 17:55 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add row for "OPER" to table 8-13

    Add row between "FDN" and "ORB" as follows:
    OPER | Operator Information | Operator entered log message

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Add request-id to be one of the Miscellaneous Elements in subjects of MSG type messages that may be in response to a request

  • Key: C2MS-79
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Subject filtering on request-id may be useful for receivers (clients) of data. Use the new field request-id (see issue C2MS-8) to populate the new miscellaneous element in subjects.
    This change applies to MSG type of messages that are in response to a REQ type of message - currently MVAL, AMVAL, and PROD.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:13 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add a row to the Miscellaneous Element tables for MVAL, AMVAL, and PROD messages

    add request-id to be in the miscellaneous element list for subjects for MVAL, AMVAL, and PROD messages.
    Due to other concurrent changes being made, table numbers are now different. Original tables are numbers were 8-79, 8-80, 8-96, 8-97, 8-121, 8-122.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Expecting that GMSEC will change to use C2MS as its Subject Standard

  • Key: C2MS-1
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    GMSEC uses a different value for Subject Standard Specification (in table 6.4). Expecting that GMSEC will change to use C2MS as its value to be a compliant PSM.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:04 GMT
  • Disposition: Closed; Out Of Scope — C2MS 1.0
  • Disposition Summary:

    This comment is towards the GMSEC implementation, not C2MS

    The GMSEC implementation supports either C2MS or GMSEC as the SPECIFICATION, but this does not affect the C2MS document. Therefore, no change needed.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Should GMSEC API enforce/recommend XML-formatted string constructor usage?

  • Key: C2MS-2
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Being that C2MS is standardizing the XML representation of a message entering the API, should the constructor that takes an XML-formatted Message be deemed the preferred way of using GMSEC going forward?

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:09 GMT
  • Disposition: Closed; Out Of Scope — C2MS 1.0
  • Disposition Summary:

    This issue is against the GMSEC API, not C2MS

    This issue does not affect the C2MS document.

    Also, the C2MS document is not standardizing the XML representation of messages; XML files are provided by the GMSEC team as a convenience, but are not part of the standard.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Have required attributes in the messages

  • Key: C2MS-6
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Suggest favoring having required attributes in the messages rather than encouraging applications to hardcode looking for the nth element of the subject, as different existing GMSEC-based systems already have different numbers of tokens in the subject.

    • While these items may exist in the body of a message, it has been found that some existing GMSEC consuming apps are extracting from subjects
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:16 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add verbiage re: required attributes in messages; move CONSTELLATION-ID, and the 2 SAT-IDs to Required Fields

    In Figure 8-3 (Message Header), move CONSTELLATION-ID, and the 2 SAT-IDs to Required Fields.
    Edit paragraph 8.1.1 to change "Some of the elements of the C2MS subject name can be made up from fields in the C2MS Message Header." to "All of the elements of the C2MS subject name can be made up from required fields in the C2MS Message Header."

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Directive Request: strings, UNIQUE-ID and correlation IDs

  • Key: C2MS-8
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    • (Directive Request) Section 7.4.1

    • Note that directive strings are highly vendor-specific
    • There needs to be a unique ID that is set by the directive requester, not just the API. Otherwise, retrying is not deterministic. (Maybe the other side got the first directive. Maybe it didn’t. Sending the same request twice when the first was received might be dangerous.)
    • Table 8-3: UNIQUE-ID is filled in by the transport/bus layer, not the user application, so this does not remove the need for correlation IDs
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:19 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    *Add field REQUEST-ID to all REQ, RESP, and applicable MSG messages *

    Field is set by requestor and echo'd by responder in RESP and MSG messages. Same Request-ID will mean replacement, else, new request.

    Added field REQUEST-ID to all REQ messages. Field is: Required, U16, "ID to identify the request message – if different request messages have the same value, the request is a replacement; else, it is a new request."

    Added field REQUEST-ID to all RESP messages. Field is: Required, U16, "This field’s value is to be the same as the REQUEST-ID in the associated REQ message."

    Added field REQUEST-ID to the MSG messages that have associated REQ and RESP messages. Field is: Required, U16, "This field’s value is to be the same as the REQUEST-ID in the associated REQ message."

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Change comments regarding signed types

  • Key: C2MS-7
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Table 8-1: Suggest changing comments regarding signed types. As written, they read like signed magnitude, even though the range implies twos complement.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:17 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change verbiage on I16, I32 and I64 in the types table 8-1

    In Table 8-1, Field Type Definitions, make 3 changes removing the following phrase "composed of [15, 31, 63] bits for the number and 1 bit for the sign" from the I16, I32, and I64 rows.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Make sure CCSDS info is consistent and current

  • Key: C2MS-22
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Review all references and content related to CCSDS for currency, correctness, etc. For example, some fields in messages map to fields in CCSDS messages - these should be double-checked.

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:56 GMT
  • Disposition: Closed; No Change — C2MS 1.0
  • Disposition Summary:

    Reviewed CCSDS specs - no changes needed

    No inconsistencies or inaccuracies were found.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Flatten the message hierarchy re: C2CX, TLM, and NDM messages

  • Key: C2MS-23
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    There is an intermediate sub-layer that is not needed in the C2CX, TLM, and NDM messages that makes common processing more difficult. I suggest removing the sub-layer so that all messages are uniquely identifiable by their type and sub-type.

    For example, heartbeat messages are currently categorized like this:
    type - MSG
    subtype - C2CX
    c2cx-subtype - HB

    I suggest there is no need for the C2CX layer. it should be like this:
    type - MSG
    subtype - HB

    Similarly for other C2CX messages, TLM messages, and NDM messages.

  • Reported: C2MS 1.0b1 — Tue, 18 Sep 2018 19:14 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    C2CX and TLM messages were done; NDMs require more thought

    C2CX Messages:

    • re-organized section 8.5 to match other message sections
    • made all messages have a unique MESSAGE-SUBTYPE value (CFG, CNTL, DEV, HB, RSRC)
    • removed C2CX-SUBTYPE field from all messages

    TLM Messages:

    • re-organized section 8.6 to match other message sections
    • made all messages have a unique MESSAGE-SUBTYPE value (TLMFRAME, TLMPKT, TLMPROC, TLMTDM)
    • removed FORMAT field from all messages

    Updated table 6-6 to remove the row (2 cells) that shows C2CX as a Subtype value "C2CX | Component-to-Component Transfer"

    NDM Messages:
    Not flattened because the NDM-TYPE field is not fixed for the sub messages. For example, for AEM messages the value is CCSDS-AEM or AEM. Therefore, to flatten it out would require addition of 6 new messages - deemed out of scope for this revision.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

page numbers in early sections are messed up (i, ii, i, iii, etc.)

  • Key: C2MS-18
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    self-explanatory

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:50 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Page numbers in preface section (i, ii, etc.) were incorrect

    This issue was resolved as part of preparing the Beta 1 spec version. It was a word to pdf translation problem.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Acknowledge Final Status is not deterministic

  • Key: C2MS-5
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Table 6-9: Acknowledge Final Status is not deterministic (rather than Yes). It is a final status in MEP2, but not a final status in MEP 4, 5

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:15 GMT
  • Disposition: Closed; No Change — C2MS 1.0
  • Disposition Summary:

    Remove table from specification

    The table referenced is confusing and not needed.
    It's table 6-9 in the MCMS pdf (which is what this issue was created against).
    In the Beta 1 spec pdf (dtc/2018-07-01) it's on page 21 as table 0-2.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Subject naming missing the concept of something not being directly tied to a satellite

  • Key: C2MS-4
  • Status: closed  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Subject naming still missing the concept of something not being directly tied to a satellite. CC2/EGS has the MISSION==ENTERPRISE, CONSTELLATION==SERVICE concept.

    • Should more generic attribute names for these positions be considered?
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:12 GMT
  • Disposition: Closed; No Change — C2MS 1.0
  • Disposition Summary:

    *The existing fields Domain1 and Domain2 in the header portion satisfy this comment. *

    The Domain1 and Domain2 fields already present in C2MS are intended for the purpose described in this issue. Therefore, no change needed.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Modifying a subscription is undefined

  • Key: C2MS-43
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    The current specification does not detail how to handle a modification of a subscription. How this is performed should be included in the specification, such as repeating a new subscription with those items that are to remain in the subscription versus just the changes.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:45 GMT
  • Disposition: Duplicate or Merged — C2MS 1.0
  • Disposition Summary:

    This issue solved by resolution to issue #8, adding REQUEST-ID

    Duplicate - no change needed.

  • Updated: Tue, 8 Oct 2019 17:51 GMT