${taskforce.name} Avatar
  1. OMG Task Force

Command and Control Message Specification (C2MS) 1.1 RTF — Open Issues

  • Key: C2MS11
  • Issues Count: 111
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
C2MS11-222 Align Alarm Text/Colors with other SDTF Specs C2MS 1.0 open
C2MS11-209 mnemonic.n.sample.m.quality seems to be wrong type C2MS 1.0 open
C2MS11-221 Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model C2MS 1.0 open
C2MS11-212 Normalize Headers and Text in the new DB Query Messages C2MS 1.0 open
C2MS11-204 Re-evaluate Optional Boolean Fields C2MS 1.0 open
C2MS11-200 Revisit Tracking Fields C2MS 1.0 open
C2MS11-199 Consider Deprecating and Later Removing Resource Message C2MS 1.0 open
C2MS11-193 Rework Individual Message Header Tables C2MS 1.0 open
C2MS11-191 Remove XSDs as Normative Documents C2MS 1.0 open
C2MS11-219 Inconsistent figure and table names for Replay TLM Messages C2MS 1.0 open
C2MS11-218 Need Review/Documented Explanation of Archive Msg Ret Resp NUM-OF-PROD-SUBTYPES C2MS 1.0 open
C2MS11-217 Consolidate APID and AP ID to just APID C2MS 1.0 open
C2MS11-214 Resolve REQUEST-ID in Message Subjects C2MS 1.0 open
C2MS11-211 Expand TLM Changes into Related Messages C2MS 1.0 open
C2MS11-208 Non-sensical Description for PROD-MSGS-TO-SEND C2MS 1.0 open
C2MS11-210 AMVAL Value Response Doesn't Mirror MVAL Value Response Message C2MS 1.0 open
C2MS11-207 Inconsistent Optional/Required Fields C2MS 1.0 open
C2MS11-187 Consolidate all "Additional Information" Table and Model Figure changes into one Issue C2MS 1.0 open
C2MS11-192 Remove the Req/Resp/Pub MEP C2MS 1.0 open
C2MS11-190 Use Semantic Versioning for Version Number of Messages C2MS 1.0 open
C2MS11-189 Add a section describing expected use C2MS 1.0 open
C2MS11-173 Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages C2MS 1.0 open
C2MS11-35 Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects C2MS 1.0 open
C2MS11-45 C2MS Database Query (DBQUERY) messages C2MS 1.0 open
C2MS11-83 Consider forcing a limited subscription C2MS 1.0 open
C2MS11-182 Deprecate fields duplicated between C2MS Messages and the Message Envelope C2MS 1.0 open
C2MS11-178 Normalize the "Additional Information" Tables Showing Fields for Messages C2MS 1.0 open
C2MS11-184 Remove Superfluous Fields from Header and Envelope C2MS 1.0 open
C2MS11-163 Align TLM Messages against Subject Elements and Fields C2MS 1.0 open
C2MS11-177 At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency C2MS 1.0 open
C2MS11-176 At Next Major Revision: Order MEs and Fields Consistently C2MS 1.0 open
C2MS11-130 Create an optional Message Envelope to hold Tracking Fields C2MS 1.0 open
C2MS11-170 Replace simple service REQ/RESP C2MS 1.0 open
C2MS11-143 Header UNIQUE-ID is Type "Header String" C2MS 1.0 open
C2MS11-169 Clarify Text Associated with Simple Service Req/Resp C2MS 1.0 open
C2MS11-111 SERV message, add field SERVICE-GROUP C2MS 1.0 open
C2MS11-110 PROD message, add fields PROD_SUBTYPE C2MS 1.0 open
C2MS11-19 Larger Data Types C2MS 1.0 open
C2MS11-42 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 open
C2MS11-44 Consider a mechanism to request archived Commands and Events C2MS 1.0 open
C2MS11-16 REQUEST-ID field does not support usage as a GUID C2MS 1.0 open
C2MS11-7 XML PSM recommended C2MS 1.0b1 open
C2MS11-47 Using REQ Messages for 'Publish' C2MS 1.0 open
C2MS11-101 Text for AMVAL REQ references non-existing fields C2MS 1.0 open
C2MS11-25 Make all subjects be buildable from fields in the message C2MS 1.0 open
C2MS11-27 Time Type table clarification for the DDD portion C2MS 1.0 open
C2MS11-23 In message tables, rework the "value" column to allow for fixed values vs. default values C2MS 1.0 open
C2MS11-88 Create CMD-MNEMONIC Field in Command Request Message C2MS 1.0 open
C2MS11-139 Update Text Associated with REQUEST-ID as Replacement Issue C2MS 1.0 open
C2MS11-54 VCID and APID in Message Subject for TLMTDM Frame C2MS 1.0 open
C2MS11-114 Remove APID from TLMFRAME C2MS 1.0 open
C2MS11-115 Remove APID from TLMPROC C2MS 1.0 open
C2MS11-39 Add field APID (and VCID) to Telemetry CCSDS Packet Message C2MS 1.0 open
C2MS11-151 Reconsider Oneshot in MVAL Request/Response C2MS 1.0 open
C2MS11-137 Revisit SAMPLE-RATE C2MS 1.0 open
C2MS11-140 Replace Unsolicited Echo with a Separate Message C2MS 1.0 open
C2MS11-138 Command Echo Not Provided Message C2MS 1.0 open
C2MS11-141 Improve text related to ONESHOT in Mval Request Message C2MS 1.0 open
C2MS11-144 STREAM-MODE Issues with Replay Telemetry Message C2MS 1.0 open
C2MS11-135 NUM-OF-[ITEMS] Should be Required C2MS 1.0 open
C2MS11-131 Split ME1 in Simple Service Req/Resp C2MS 1.0 open
C2MS11-56 Clarify Correlation PUBLISH-RATE and SAMPLE-RATE on Mnemonic Value Request Message C2MS 1.0 open
C2MS11-136 MNEMONIC CRITERIA Needs alignment with C2MS11-56 C2MS 1.0 open
C2MS11-90 Real-world STREAM-MODE Issues C2MS 1.0 open
C2MS11-120 Deprecate REQ-STRING in Product Request Message C2MS 1.0 open
C2MS11-41 C2MS specification on page 168 is not clear regarding CMD-FORMAT=MNEMONIC C2MS 1.0 open
C2MS11-8 Acknowledge Final Status inconsistency C2MS 1.0b1 open
C2MS11-109 TLMTDM message, add AP-ID and VCID fields C2MS 1.0 open
C2MS11-121 Consider Making Fields in UML Public vs Private C2MS 1.0 open
C2MS11-112 Align MESSAGE-CLASS with Usage C2MS 1.0 open
C2MS11-43 Deprecate Archive Message Retrieval Messages C2MS 1.0 open
C2MS11-36 Add DESTINATION-NODE and DESTINATION-FACILITY as fields C2MS 1.0 open
C2MS11-108 TLM CCSDS FRAME, TLM Processed Frame messages need AP-ID fields C2MS 1.0 open
C2MS11-106 CFG, CNTL, DEV, HB, RSRC Messages need fields DESTINATION-NODE and DESTINATION-FACILITY C2MS 1.0 open
C2MS11-107 TLMPKT Message needs field AP-ID C2MS 1.0 open
C2MS11-14 Specify multiplicity for required and optional fields C2MS 1.0a1 open
C2MS11-15 Log message scope too broad, need Alert/Status style message introduced C2MS 1.0b2 open
C2MS11-17 Make Fields Table and UML Match the Order of Fields for greater Readabliity C2MS 1.0 open
C2MS11-30 Clarify the ".... Message Header Notes" tables re: being included in each message C2MS 1.0 open
C2MS11-11 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 open
C2MS11-4 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 open
C2MS11-49 Consider Renaming "Header String" type to "Subject Token String" C2MS 1.0 open
C2MS11-55 REQUEST-ID as "Replacement" and related STOP C2MS 1.0 open
C2MS11-18 All Messages Subclass Message Header C2MS 1.0 open
C2MS11-31 Clarify the UML diagrams regarding the values for the fields inherited from Message Header C2MS 1.0 open
C2MS11-29 In Message Header, make NODE and USER-NAME string rather than Header String C2MS 1.0 open
C2MS11-28 Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header C2MS 1.0 open
C2MS11-87 Missing Echo Request C2MS 1.0 open
C2MS11-48 Add Message-level Security Constructs C2MS 1.0 open
C2MS11-75 Move Tracking Fields to a "Message Envelope" C2MS 1.0 open
C2MS11-34 In message Archive Message Retrieval Response, fix Header field names C2MS 1.0 open
C2MS11-40 Control Message SPECIAL_INFO Field type should be String C2MS 1.0 open
C2MS11-38 In the Control Message, the field CNTL-STRING should be required C2MS 1.0 open
C2MS11-37 Remove value for CNTL-STRING from CNTL message C2MS 1.0 open
C2MS11-46 Using REQ Messages for 'Publish' C2MS 1.0 open
C2MS11-26 Document that Header String type is to be at least one ASCII character C2MS 1.0 open
C2MS11-32 Add field for USER to Message Header C2MS 1.0 open
C2MS11-33 Add security fields that GMSEC API inserts into encrypted messages as Tracking Fields in C2MS C2MS 1.0 open
C2MS11-24 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses C2MS 1.0 open
C2MS11-20 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 open
C2MS11-13 Add documentation within the model C2MS 1.0a1 open
C2MS11-22 Message-level Security Credentials C2MS 1.0 open
C2MS11-21 Larger Data Types C2MS 1.0 open
C2MS11-6 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 open
C2MS11-10 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 open
C2MS11-12 "Mnemonic" should be called "Parameter" C2MS 1.0b1 open
C2MS11-9 Pub/Sub subscription status unknown C2MS 1.0b1 open
C2MS11-2 C2CX Heartbeat comments C2MS 1.0a1 open
C2MS11-3 Archive Mnemonic Value Request comments C2MS 1.0a1 open
C2MS11-1 Lack of a registry concept C2MS 1.0a1 open
C2MS11-5 Data Dictionary Messages C2MS 1.0b1 open

Issues Descriptions

Align Alarm Text/Colors with other SDTF Specs

  • Key: C2MS11-222
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Align Alarm Text/Colors with other SDTF Specs.

    Include a listing in the document that correlates colors with codes.

  • Reported: C2MS 1.0 — Wed, 20 Mar 2024 21:01 GMT
  • Updated: Wed, 20 Mar 2024 21:01 GMT

mnemonic.n.sample.m.quality seems to be wrong type

  • Key: C2MS11-209
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Fri, 26 Jan 2024 00:18 GMT
  • Updated: Tue, 6 Feb 2024 21:12 GMT

Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model

  • Key: C2MS11-221
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Tue, 6 Feb 2024 18:41 GMT
  • Updated: Tue, 6 Feb 2024 18:41 GMT

Normalize Headers and Text in the new DB Query Messages

  • Key: C2MS11-212
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 14:21 GMT
  • Updated: Mon, 5 Feb 2024 16:45 GMT

Re-evaluate Optional Boolean Fields

  • Key: C2MS11-204
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Thu, 18 Jan 2024 21:04 GMT
  • Updated: Sat, 3 Feb 2024 00:24 GMT

Revisit Tracking Fields

  • Key: C2MS11-200
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.
  • Reported: C2MS 1.0 — Fri, 12 Jan 2024 22:17 GMT
  • Updated: Sat, 3 Feb 2024 00:24 GMT

Consider Deprecating and Later Removing Resource Message

  • Key: C2MS11-199
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

  • Reported: C2MS 1.0 — Fri, 12 Jan 2024 21:43 GMT
  • Updated: Sat, 3 Feb 2024 00:24 GMT

Rework Individual Message Header Tables

  • Key: C2MS11-193
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Each message includes a "[message name] Header table that repeats header field definitions as already listed in Table 8-3 Message Header Additional Information. Instead, this individual message table is intended to show what special values are applied to certain fields of the header. This needs to be made more clear, without duplicating information in the already-existing Header table. In other words, these tables should provide unique-to-the-message values rather than repeating header definitions.

    A specific example of why this is not practical is that the existing set of tables all show the HEADER-VERSION 2019. Because the HEADER-VERSION is being updated in 1.1, each of these 31 tables must also be updated. In order to avoid this kind of issue in the future, these tables need to be reduced to just the necessary message-specific values.

    See for example, "Table 8-108 Mnemonic Value Data Message Header". This table does not need to include the "Notes" column, since that is simply repeating word-for-word what exists elsewhere, and should not include the HEADER-VERSION row, since that is defined elsewhere, including its value.

    To make this better, change the column name of column one to "Header Field Name". Additionally, should change the table title to "Table 8-108 Mnemonic Value Data Message Header Values".

  • Reported: C2MS 1.0 — Tue, 9 Jan 2024 21:07 GMT
  • Updated: Sat, 3 Feb 2024 00:24 GMT

Remove XSDs as Normative Documents

  • Key: C2MS11-191
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some XSDs were provided by NASA when v1.0 was created. However, these are only useful in a PSM for XML and should not be considered normative for the PIM. We don't have any intention to maintain/update these, so they should be removed. If NASA wants to create and deliver these to users, that is fine, but the OMG should not be the broker for these files.

    See the listing of "Normative Documents" here: https://www.omg.org/spec/C2MS/1.0

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 20:21 GMT
  • Updated: Sat, 3 Feb 2024 00:24 GMT

Inconsistent figure and table names for Replay TLM Messages

  • Key: C2MS11-219
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Replay Telemetry Data Request Message and Replay Telemetry Data Response Message sections use inconsistent naming for section headers tables and figures compared to all other sections of the document. For example:

    "Replay Telemetry Data Request Diagram"
    "Replay Telemetry Response Message Header"

    These should be made to use the full name of the message, just like other sections in the document.

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 21:07 GMT
  • Updated: Fri, 2 Feb 2024 21:07 GMT

Need Review/Documented Explanation of Archive Msg Ret Resp NUM-OF-PROD-SUBTYPES

  • Key: C2MS11-218
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The purpose of Archive Msg Ret Resp NUM-OF-PROD-SUBTYPES is not clear and needs to be reviewed and either removed or expanded upon.

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 17:42 GMT
  • Updated: Fri, 2 Feb 2024 17:51 GMT

Consolidate APID and AP ID to just APID

  • Key: C2MS11-217
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Throughout the document, we use APID and AP ID interchangeably. For consistency, we should reduce all these references to just APID.

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 15:57 GMT
  • Updated: Fri, 2 Feb 2024 15:57 GMT

Resolve REQUEST-ID in Message Subjects

  • Key: C2MS11-214
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some Message Subjects:

    • Mnemonic Value Data Message
    • Archive Mnemonic Value Data Message
    • Command Echo Message
    • Product Message

    have Request ID as one of the Message Subject Miscellaneous Elements. However, the type of REQUEST-ID is now GUID.

    We need to figure out how to resolve this in the document text and tables. An RFC 4122 GUID does comply with Subject Token String, but we should address this.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 15:31 GMT
  • Updated: Thu, 1 Feb 2024 18:08 GMT

Expand TLM Changes into Related Messages

  • Key: C2MS11-211
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS11-163 we adjusted the base set of TLM messages to better handle CCSDS information and to include APID/SCID where appropriate.

    There are some related messages that needed to have been adjusted as well. This issue takes up where the already-approved 163 left off. Specifically, we need changes to:

    • Replay Telemetry Data Request Message
    • Command Request Message
    • Command Echo Message

    These changes align these adjacent messages to the to TLM message set and include SCID where appropriate.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 14:16 GMT
  • Updated: Thu, 1 Feb 2024 14:16 GMT

Non-sensical Description for PROD-MSGS-TO-SEND

  • Key: C2MS11-208
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

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

  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:55 GMT
  • Updated: Sat, 27 Jan 2024 00:51 GMT

AMVAL Value Response Doesn't Mirror MVAL Value Response Message

  • Key: C2MS11-210
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

  • Reported: C2MS 1.0 — Fri, 26 Jan 2024 00:20 GMT
  • Updated: Fri, 26 Jan 2024 00:20 GMT

Inconsistent Optional/Required Fields

  • Key: C2MS11-207
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The MVAL Response and MVAL Data messages both can contain individual MVALs. But in one, certain MVAL fields are required, while in other they are not. These need to be made consistent.

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

  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:51 GMT
  • Updated: Wed, 24 Jan 2024 21:51 GMT

Consolidate all "Additional Information" Table and Model Figure changes into one Issue

  • Key: C2MS11-187
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Because many separate changes have been made in the [MESSAGE-TYPE] Message Additional Information Tables and in the [MESSAGE-TYPE] Message Contents (model) Figures, this issue seeks to consolidate all such changes together for final review. Changes here should be considered, therefore, to supersede all other C2MS 1.1 changes to the specific tables and figures enclosed in this issue.

    All such tables/figures are in Chapter 8 PIM - Message Definitions.

  • Reported: C2MS 1.0 — Fri, 18 Aug 2023 23:30 GMT
  • Updated: Fri, 19 Jan 2024 16:47 GMT

Remove the Req/Resp/Pub MEP

  • Key: C2MS11-192
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 20:23 GMT
  • Updated: Thu, 18 Jan 2024 00:59 GMT

Use Semantic Versioning for Version Number of Messages

  • Key: C2MS11-190
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:53 GMT
  • Updated: Thu, 18 Jan 2024 00:59 GMT

Add a section describing expected use

  • Key: C2MS11-189
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    This is for 1.2, but have to enter it in 1.1 as that is the only current jira project. I expect it to be deferred, but think it should be done in 1.2.

    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 idea is to communicate context for how C2MS has been created and how it is expected to be used.

    This could be in the form of a section called "System Architecture", "Guidance", "User Guide", or something like that.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:36 GMT
  • Updated: Thu, 18 Jan 2024 00:59 GMT

Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages

  • Key: C2MS11-173
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Wed, 12 Jul 2023 19:02 GMT
  • Updated: Thu, 18 Jan 2024 00:59 GMT

Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects

  • Key: C2MS11-35
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects for all messages where that field is used. Also, see 2016 GMSEC ISD for discussion of destination component and add that back in to the description of Configuration Status Message. See pages 74 and 78.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:41 GMT
  • Updated: Tue, 9 Jan 2024 16:36 GMT

C2MS Database Query (DBQUERY) messages

  • Key: C2MS11-45
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

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

  • Reported: C2MS 1.0 — Wed, 26 Jan 2022 18:09 GMT
  • Updated: Mon, 7 Aug 2023 14:49 GMT

Consider forcing a limited subscription

  • Key: C2MS11-83
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the case of Mnemonic Value Request Message and Archive Mnemonic Value Request Message, the requestor can specify a STOP-TIME or DURATION, but both are optional. If neither is specified, the subscription is open-ended with no knowable end, until the requestor sends a 'STOP' message. In order to avoid infinite fulfillment of a subscription to a potentially lost requestor, we could enforce a concept that a requestor must specify either a STOP-TIME or Duration.

    In practice, this is an inadequate requirement, since a caller could specify a very long duration, like 1000 years, and circumvent the desire of this issue.

    However, this is issue simply captures the idea to promote further discussion.

  • Reported: C2MS 1.0 — Tue, 22 Mar 2022 21:15 GMT
  • Updated: Sat, 5 Aug 2023 15:24 GMT
  • Attachments:

Deprecate fields duplicated between C2MS Messages and the Message Envelope

  • Key: C2MS11-182
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Sat, 22 Jul 2023 20:27 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT

Normalize the "Additional Information" Tables Showing Fields for Messages

  • Key: C2MS11-178
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Changes need to be made to the "Additional Information" tables that contain Field listing for each message. The necessary changes are to provide complete information and to unify the names of the column headers across all messages.

    Should add a type column to the fields table "Additional Info". Currently, the only indicator of type is in the UML diagram. Because of this, it is often the case that a reader of the table, must glance at the UML diagram in addition to reading the table.

    Additionally, the tables are not uniform within the 1.0 document. Some use "Value" for a certain column header, while others use "Value/Description". To resolve this, it would be useful to use "Value" in every table and to rename the current "Notes" column to "Description" which is more accurate.

  • Reported: C2MS 1.0 — Fri, 21 Jul 2023 16:23 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT

Remove Superfluous Fields from Header and Envelope

  • Key: C2MS11-184
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.
  • Reported: C2MS 1.0 — Sun, 23 Jul 2023 15:30 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT

Align TLM Messages against Subject Elements and Fields

  • Key: C2MS11-163
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Issue C2MS11-54, already approved, has removed two subject elements that didn't belong in Telemetry TDM Frame Message. In fact, there are many more similar irregularities across all the Telemetry messages.

    The needed changes are described below, but also shown in the attachment (original and revised) that shows the fields and subject elements as they exist today and should be after corrected.

    • Add a new message type: Telemetry CCSDS CADU Message
    • Rename Telemetry CCSDS Frame Message to Telemetry CCSDS Transfer Frame Message
    • APID should be both a subject element and field in Telemetry CCSDS Packet, and in no other TLM messages.
    • VCID should be both a subject element and field in Telemetry CCSDS Packet and Telemetry CCSDS Transfer Frame, and in no other TLM messages
    • PHY-CHAN should be a field in the new Telemetry CCSDS CADU Message, with no subject element for it (Note that this message won't have APID, VCID or SCID represented.
    • Add SCID as a subject element and field in Telemetry CCSDS Packet and Telemetry CCSDS Transfer Frame messages
  • Reported: C2MS 1.0 — Fri, 14 Apr 2023 15:10 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT
  • Attachments:

At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency

  • Key: C2MS11-177
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Sun, 16 Jul 2023 21:35 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT

At Next Major Revision: Order MEs and Fields Consistently

  • Key: C2MS11-176
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Sun, 16 Jul 2023 21:29 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT

Create an optional Message Envelope to hold Tracking Fields

  • Key: C2MS11-130
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. This "Message Envelope" is the logical place for managing tracking fields and other metadata related to, but not part of a C2MS message body.

    This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning related to C2 of a satellite.

    Note that this concept was originally moved to C2MQ. However, because C2MQ is a long way away and because message envelope is a useful construct within C2MS, it was determined at the Austin (Dec, 2023) C2MS meeting to bring this back in to C2MS and take the envelope concept out of C2MQ (leaving it to cover service-based interactions outside of the messages). Therefore, this is a re-entry of the envelope mechanism.

    As part of this effort, we should do the following:

    Add fields that allow encryption of content sections of the C2MS message body as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

    The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

  • Reported: C2MS 1.0 — Tue, 7 Feb 2023 23:08 GMT
  • Updated: Sat, 5 Aug 2023 00:00 GMT
  • Attachments:

Replace simple service REQ/RESP

  • Key: C2MS11-170
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

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

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

    In this there are two factors that need consideration:

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

Header UNIQUE-ID is Type "Header String"

  • Key: C2MS11-143
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    UNIQUE-ID in the Header is of type Header String (to be Subject Token String due to C2MS11-49). According to table 8-3: "Globally unique ID – reserved for use by implementation (PSM)". Note that a "Header String" is limited to upper and lower alphanumeric plus '-' and '_'. Recommendation of C2MS is that best practice is to keep Header String to no more than 12 characters.

    So, Header String or Subject Token String isn't the right type.

    I think we need to know what GMSEC uses for a type of UNIQUE-ID. But, it possible, it would be good if it was a GUID, relating to C2MS11-16.

  • Reported: C2MS 1.0 — Sat, 18 Mar 2023 22:08 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT
  • Attachments:

Clarify Text Associated with Simple Service Req/Resp

  • Key: C2MS11-169
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    After discussion in C2MS RTF in Orlando 2023 Tech Meetings, we determined to clarify or clean up some text with Simple Service Request and Response messages as follows:

    • Say it’s not intended to be long-term but for quick on-boarding. Services meant for long-term use should create their own message set apart from Simple Service
    • Say that we intend to rework or replace Simple Service at some point in a future release.
    • Consider removing text about using it for a publish mode

    Note that the response message as it is lacks the Service-Group that was specified in the request message. This lack makes it impossible to correctly correlate a response to a request that did specify Service-Group. However, because we intend to 'rework' these messages in a future release, we won't make this change at present.

    A related issue will be created to replace simple service and deprecate current simple service, but will be deferred to later.

  • Reported: C2MS 1.0 — Tue, 11 Jul 2023 14:37 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT


PROD message, add fields PROD_SUBTYPE

  • Key: C2MS11-110
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    There are n+2 number of optional elements between ME4 and ME7. These fields map the field(s) PROD-SUBTYPE.n.NAME.
    API Workaround: API only maps the first two of these product subtypes, and the user will have set subject if they want more.
    Required C2MS Spec changes: Ditch the n+2 logic in the middle of a message subject and only display the first two PROD-SUBTYPE values in the subject (or FILL if not used). A subject that can have dynamically shifting positions of its subject elements has serious implications on compatibility.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:10 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT

Larger Data Types

  • Key: C2MS11-19
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

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

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

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

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

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

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

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

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:48 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT

C2MS: Optional Transfer Frame/Packet attributes should be described in schema

  • Key: C2MS11-42
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    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

  • Reported: C2MS 1.0 — Tue, 13 Jul 2021 12:26 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT

Consider a mechanism to request archived Commands and Events

  • Key: C2MS11-44
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Fri, 10 Dec 2021 03:22 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT

REQUEST-ID field does not support usage as a GUID

  • Key: C2MS11-16
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    From Justin: The REQUEST-ID field was defined as a U16. Recommend this field be changed to be a string to allow it to be utilized as a GUID. This allows it to work better for transport of existing interfaces that utilize a GUID to ensure message uniqueness, especially when multiple instances of the application are running concurrently.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:11 GMT
  • Updated: Sat, 22 Jul 2023 00:36 GMT
  • Attachments:

XML PSM recommended

  • Key: C2MS11-7
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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
  • Updated: Sat, 22 Jul 2023 00:36 GMT

Using REQ Messages for 'Publish'

  • Key: C2MS11-47
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

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

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

    With all this in mind, I'd suggest:

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

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

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

  • Reported: C2MS 1.0 — Thu, 17 Feb 2022 16:54 GMT
  • Updated: Wed, 21 Jun 2023 00:57 GMT
  • Attachments:

Text for AMVAL REQ references non-existing fields

  • Key: C2MS11-101
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    For the Archive Mnemonic Value Request Message, under the explanatory text, there is a paragraph stating:

    "Optionally, if known or applicable, the requestor can specify the file type and file attributes with the optional dependent fields under the Output Product Category and Output File Attributes sections."

    I'm not sure what this is referring to. There are no Product Category or Output File Attributes dependent fields in the Message. The terms "Output Product Category" and "Output File Attributes" occur in the document only in this paragraph.

    The text either needs to be clarified or removed.

  • Reported: C2MS 1.0 — Wed, 29 Jun 2022 13:05 GMT
  • Updated: Wed, 21 Jun 2023 00:57 GMT

Make all subjects be buildable from fields in the message

  • Key: C2MS11-25
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Almost all miscellaneous subject elements for messages are specified as mapping to fields in the message. But a few are not. For example, see the Miscellaneous Elements table 8-46 for the Control message. The elements DESTINATION_NODE and DESTINATION_FACILITY do not exist as fields in the message. (Note: it may be more appropriate to add some of these fields to the Message Header rather than many/most messages.) In this particular example, this may be resolved by C2MS11-28, but each message type would need to be evaluated to see what other subject elements are not mapped to fields.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:59 GMT
  • Updated: Wed, 21 Jun 2023 00:57 GMT
  • Attachments:

Time Type table clarification for the DDD portion

  • Key: C2MS11-27
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Document clarification: The DDD portion of the Time Type, as shown in table 8-2 on page 40, has a range of 1-365 (or 366). But when using a relative time (by preceding the value with a "+" or a "-"), the DDD portion can contain a zero value. Make this clear and add a couple more relative time examples.

    Consider replacing C2MS invented date format with RFC3339 or ISO8601 to include relative time.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:17 GMT
  • Updated: Wed, 21 Jun 2023 00:57 GMT

In message tables, rework the "value" column to allow for fixed values vs. default values

  • Key: C2MS11-23
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

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

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:48 GMT
  • Updated: Wed, 21 Jun 2023 00:57 GMT

Create CMD-MNEMONIC Field in Command Request Message

  • Key: C2MS11-88
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the Command Request Message, the Binary "CMD-DATA" message contains the packet/fram/CLTU, etc, for all CMD-FORMAT types. However, if the CMD-FORMAT type is MNEMONIC this doesn't make as much sense.

    Suggestion here is to create a new field in Command Request Message, "CMD-MNEMONIC" as type STRING to hold the human-readable MNEMONIC for command lookup if the CMD-FORMAT is of type MNEMONIC.

    In this way, both CMD-DATA and CMD-MNEMONIC would be Dependent fields, with usage based on the contents of CMD-FORMAT.

    RTF proposed (Burlingame, 2022) to do a second message type for MNE types, with 0-n parameters, each parameter specifying a type. Mike to create proposal text.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:54 GMT
  • Updated: Sun, 30 Apr 2023 00:24 GMT

Update Text Associated with REQUEST-ID as Replacement Issue

  • Key: C2MS11-139
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    We have previously approved C2MS11-55 that changes the concept of REQUEST-ID as Replacement. After reviewing this change with the EGS Team, it is apparent that we could tighten up some of the text in the proposed change to make it more clear what are valid second-uses of REQUEST-ID and what are invalid, along with the expected response to an invalid use.

    It should be invalid in Replay Telemetry or MVAL Request to issue a start after a start has already been done using the same REQUEST-ID. In Replay Telemetry, we probably need to think about it. If an invalid re-use of REQUEST-ID is sent in a request message, an indicator should be returned in a response for Invalid Request.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 20:03 GMT
  • Updated: Sun, 30 Apr 2023 00:24 GMT

VCID and APID in Message Subject for TLMTDM Frame

  • Key: C2MS11-54
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Subject for TLMTDM Frame Messages includes the following:
    -ME3 = VCID
    -ME4 = APID

    However these fields:
    a) don't exist in the TLMTDM Frame Message, so can't be populated to the message subject,
    b) belong only to CCSDS frames, not TDM frames.

    These Message Subject Miscellaneous Elements should be removed and replaced with "FILL" to preserve ME5 as Collection Point.

  • Reported: C2MS 1.0 — Thu, 3 Mar 2022 22:57 GMT
  • Updated: Sun, 30 Apr 2023 00:24 GMT

Remove APID from TLMFRAME

  • Key: C2MS11-114
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The APID is associated with a telemetry packet, not the frame.

  • Reported: C2MS 1.0 — Fri, 18 Nov 2022 18:16 GMT
  • Updated: Sun, 30 Apr 2023 00:24 GMT

Remove APID from TLMPROC

  • Key: C2MS11-115
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The APID is associated with packets, not the telemetry frame.

  • Reported: C2MS 1.0 — Fri, 18 Nov 2022 18:17 GMT
  • Updated: Sun, 30 Apr 2023 00:24 GMT

Add field APID (and VCID) to Telemetry CCSDS Packet Message

  • Key: C2MS11-39
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This value is used in the subject, so should be added to the message.
    (NOTE: do NOT add this field to the CCSDS Frame message; TBD for Processed Telemetry Message and TDM Frame message. Also, check the VC ID usage appropriateness in all 4 TLM messages.)

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:58 GMT
  • Updated: Sun, 30 Apr 2023 00:24 GMT
  • Attachments:

Reconsider Oneshot in MVAL Request/Response

  • Key: C2MS11-151
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

  • Reported: C2MS 1.0 — Thu, 23 Mar 2023 13:01 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

Revisit SAMPLE-RATE

  • Key: C2MS11-137
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    C2MS11-56, already approved, removed MNEMONIC.n.SAMPLE-RATE. In conveying this to the EGS Team, including MAV (NASA) and Ryan Conrad (MITRE) there was concern that we were losing fidelity with the data by only using PUBLISH-RATE to create messages but not having multiple samples at a rate of SAMPLE-RATE.

    When we were considering this one, we approached it from the perspective that SAMPLE-RATE and PUBLISH-RATE created a dual-mechanism for when to send the MVAL message. While this is still and issue, there may be a way to allow both desired results in a combined way.

    One concern of both the C2MS Team and the EGS Team is in getting too many messages published. This is a clear concern with the SAMPLE-RATE, because of the CRITERIA's indication of "when data should be provided for the mnemonic", including on "Change". In fact, it's likely that CRITERIA is the suspect field basically determining how often to "provide" the data rather than SAMPLE-RATE.

    Perhaps we could do the following:

    • state in C2MS that the messages will only be produced at the PUBLISH-RATE, but that if SAMPLE-RATE is tighter, then there will be multiple samples in the message.
    • Instead of removing SAMPLE-RATE, we remove CRITERIA, so that the SAMPLE rate simply determines how often to sample

    Whatever we do, we need to revisit SAMPLE-RATE before finalizing 1.1.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 17:39 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

Replace Unsolicited Echo with a Separate Message

  • Key: C2MS11-140
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    According to the Command Echo Request:

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

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

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

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

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 20:20 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

Command Echo Not Provided Message

  • Key: C2MS11-138
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

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

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 19:46 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

Improve text related to ONESHOT in Mval Request Message

  • Key: C2MS11-141
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

    As written, the text has to be read carefully to understand the "yes and maybe" logic. I suggest adding some supporting text to clarify this.

  • Reported: C2MS 1.0 — Thu, 16 Mar 2023 00:16 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

STREAM-MODE Issues with Replay Telemetry Message

  • Key: C2MS11-144
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is a STREAM-MODE in Replay Telemetry Message, but in this case, I believe what it is there for is to say what types of telemetry messages to replay. It's not part of the Subject, the way STREAM-MODE is for other messages. I'm not sure it makes sense in this message type and should be re-evaluated. At a minimum, beefing up the description of it would be helpful.

  • Reported: C2MS 1.0 — Sun, 19 Mar 2023 21:16 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

NUM-OF-[ITEMS] Should be Required

  • Key: C2MS11-135
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    As part of C2MS11-14, which was already approved, there was a subtle inconsistency through its text and image changes. This issue is to capture the change for final submission of the documentation for C2MS 1.1.

    In that issue, in the Configuration Status Message there is a field, NUM-OF-ASSOCS. It is marked optional in the diagram, but required in the text table.

    In the Heartbeat Message, NUM-OF-SUBSCRIPTIONS is shown as optional, both in the diagram and in the text table.

    In the Mnemonic Value Request Message, NUM-OF-MNEMONICS is shown as required, both in the diagram and in the text table.

    In all cases throughout C2MS where there is a NUM-OF-[ITEMS] field, it should be required in the corresponding diagram and text table.

    This is to align it with the obvious. The NUM-OF field indicates how many items are present in a set, such as MNEMONICS. If there are none, this field should simply be set to 0. However, if it were optional, that would mean that the field would either be present or set to 0. The former is preferred for clarity.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 12:05 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT
  • Attachments:

Split ME1 in Simple Service Req/Resp

  • Key: C2MS11-131
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

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

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

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

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

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

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

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

  • Reported: C2MS 1.0 — Thu, 16 Feb 2023 15:53 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

Clarify Correlation PUBLISH-RATE and SAMPLE-RATE on Mnemonic Value Request Message

  • Key: C2MS11-56
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In Mnemonic Value Request Message, there is a PUBLISH-RATE and there is a SAMPLE-RATE that can be specified for each MVAL. The correlation between these is somewhat open to interpretation. For example, the text of the SAMPLE-CRITERIA, associated with SAMPLE-RATE, says it drives "when data should be provided" which overlaps with the PUBLISH-RATE. If taking SAMPLE-RATE to be independent of PUBLISH-RATE, it means something else entirely.

    The supporting text of the Mnemonic Value Request Message needs to make clear how these interact.

    Note that we previously determined to remove SAMPLE-RATE due to perceived overlap, but have since decided to leave it in place and make clear its usage.

  • Reported: C2MS 1.0 — Fri, 4 Mar 2022 00:40 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT
  • Attachments:

MNEMONIC CRITERIA Needs alignment with C2MS11-56

  • Key: C2MS11-136
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is an already-accepted issue, C2MS11-56, that removed MNEMONIC.n.SAMPLE-RATE, but that issue did not address the related field, MNEMONIC.n.CRITERIA.

    In that other issue, the MNEMONIC.n.SAMPLE-RATE was removed because it overlapped with the PUBLISH-RATE of the base message.

    Since SAMPLE-RATE has been removed, one of the following additional steps needs to be taken:

    Option A - remove the value "3 = Sample Rate" from MNEMONIC.n.CRITERIA

    Option B - Remove MNEMONIC.n.CRITERIA completely for the same reasons SAMPLE-RATE was removed

    Option B - Move MNEMONIC.n.CRITERIA to a field in the base message now to be called "PUBLISH-CRITEREA" with the following possible values:
    1 = Change (value, flags, status) [publish when any MVAL experiences a change]
    2 = Every Sample [publish when any new sample arrives for any MVAL]
    3 = Publish Rate [publish at the rate specified in PUBLISH-RATE, already in the base message]

    The bottom line is that just as in C2MS11-56, it doesn't make sense to have different publish/sample rates for the main message and each MVAL, so any of the above options are preferred over what it is in 1.0. (Mike: Personally, I like Option C).

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 15:21 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

Real-world STREAM-MODE Issues

  • Key: C2MS11-90
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    A number of C2MS Messages include the concept of marking the mode of the data as “real-time (RT), replay (RPY), simulation (SIM), or test (TEST)” through a required field, STREAM-MODE.

    The specific messages are:

    • Telemetry CCSDS Packet Message
    • Telemetry CCSDS Frame Message
    • Telemetry TDM Frame Message
    • Telemetry Processed Frame Message
    • Replay Telemetry Data Request Message
    • Attitude Parameter Message
    • Attitude Ephemeris Message
    • Orbit Parameter Message
    • Orbit Mean-Elements Message
    • Orbit Ephemeris Message
    • Tracking Data Message

    Where used, STREAM-MODE is a required field. A typical explanation in the C2MS Spec is that, “The STREAM-MODE field is used to classify the kind or source of the” message.
    Although this may be useful in a closed experimental/engineering system, the concepts are not appropriate for an operational SATOPS system, where replay, test, sim data should never be mixed with real-world operational data. In a system with many components, the use of the STREAM-MODE field assumes that every component will properly handle the distinction for every message. As an example, a FireThrusters CMD message is received and the component fails to note that this particular message is a RPY STREAM-MODE and thinks to itself… ‘huh, I thought we fired thrusters, yesterday… but, OK, here it goes…”. In another example, a SelfDestruct CMD message is received and the component fails to note that the message is marked as TEST or SIM…

    Instead of marking messages themselves, this type of distinction should be performed environmentally; one system is the operational system, other, separate systems are for simulation or test, another separate system performs forensics (replay). Keeping these purposed environments isolated from each other ensures that data never intermixes where not appropriate.
    The resolution to this concern could be any of the following:

    1. Remove the STREAM-MODE field — breaks backward compatibility, and affects any system already using this field. However, it represents a clean break from a field that should never be used in practice, anyway.
    2. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and mark the field as deprecated (deprecated = should no longer be used and will be removed in a future major release) — maintains backward compatibility, but signals to users to cease using the field.
    3. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and provide a best-practices statement; something to the effect of, “Although maintained for backward compatibility, the use of this field is strongly discouraged for operational systems, where test, sim, or replay data should never mix with real-world operational data” — this weakest approach leaves the use of the field in the hands of the user, but would be a bit embarrassing from the standpoint of a specification to preserve a capability that is strongly discouraged.

    See attachment for non-exhaustive use in C2MS Spec.

  • Reported: C2MS 1.0 — Fri, 10 Jun 2022 13:45 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT
  • Attachments:

Deprecate REQ-STRING in Product Request Message

  • Key: C2MS11-120
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Similar to C2MS11-43, this issue is to consider deprecating REQ-STRING in the Product Request Message. The desciption of the field is a bit different than in the Archive Request Message, so just needs some investigation to make sure that this message is still usable without the field.

  • Reported: C2MS 1.0 — Fri, 16 Dec 2022 23:53 GMT
  • Updated: Sat, 8 Apr 2023 00:34 GMT

C2MS specification on page 168 is not clear regarding CMD-FORMAT=MNEMONIC

  • Key: C2MS11-41
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    It is not clear in the C2MS specification how to use/support the CMD-FORMAT=MNEMONIC on page 168. Explanation of the encoding should be provided to understand how to represent a command mnemonic and its arguments.

  • Reported: C2MS 1.0 — Tue, 6 Jul 2021 13:01 GMT
  • Updated: Sat, 18 Mar 2023 00:20 GMT
  • Attachments:

Acknowledge Final Status inconsistency

  • Key: C2MS11-8
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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
  • Updated: Sat, 18 Mar 2023 00:20 GMT

TLMTDM message, add AP-ID and VCID fields

  • Key: C2MS11-109
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value. Add field VCID (String, Optional) to the message. ME4 should refer to this field for its value.

    Are required for CCSDS packets only, and optional otherwise.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:06 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

Consider Making Fields in UML Public vs Private

  • Key: C2MS11-121
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    All fields in the UML Model classes are shown as Private. This would make sense if these blocks were really supposed to be classes, but in their usage in C2MS, these are handled as structures with all fields accessible.

    Since we are already going to change every UML diagram in C2MS 1.1, we should consider if it would be good to change these all to Public.

    See the attachment for a comparison between fields. Private fields are marked with '-', while private fields (like DATA shown as an example) are marked with '+'.

  • Reported: C2MS 1.0 — Fri, 16 Dec 2022 23:58 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT
  • Attachments:

Align MESSAGE-CLASS with Usage

  • Key: C2MS11-112
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    C2MS 1.0 defines MESSAGE-CLASS as an optional field (in the C2MS Header, "Generic field for missions to classify their message set to aid message disposition.").

    A principal user of C2MS reclassifies MESSAGE-CLASS as a required field with a finite set of defined enum-like values.

    In order to help align this user with C2MS, the C2MS MESSAGE-CLASS field should become required. Alternatively, C2MS should define a way for a consumer of the C2MS definitions to require what is to C2MS an optional field with defined values.

  • Reported: C2MS 1.0 — Thu, 20 Oct 2022 20:00 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

Deprecate Archive Message Retrieval Messages

  • Key: C2MS11-43
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Archive Message Retrieval Request Message and related Archive Message Retrieval Response Message should be considered for deprecation.

    These are useful messages in an engineering environment when all messages and their corresponding storage method allows unfettered access to all consumers regardless of authentication/authorization, but in a real-world operational environment, this construct is much too uncontrolled.

    For example, the Archive Message Request allows, and suggests, sending a SQL statement or script expression in the REQ-STRING field, which the service provider would execute on behalf of the requestor, creating an exploitable cyber attack opportunity for malicious software.

    Even if the REQ-STRING were removed and the request only allowed for PROD-TYPE/PROD-SUBTYPE (the other way to request the archive), this would allow for all messages that ever flowed in the environment to be forwarded to a single requestor. In an unsecured system, that might make sense, but it is not appropriate in any system that closely controls who is allowed to send/receive any given message.

  • Reported: C2MS 1.0 — Fri, 10 Dec 2021 03:20 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT
  • Attachments:

Add DESTINATION-NODE and DESTINATION-FACILITY as fields

  • Key: C2MS11-36
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    One goal for consistency (and ease of implementation and use of said implementation) is to have all subject elements also be fields in the message. Adding DESTINATION-COMPONENT late in the adoption process of C2MS was a step in this direction, but DESTINATION-NODE and DESTINATION-FACILITY are needed also. See page 82 for example for CFG messages.

    (Note: this applies to all 5 C2CX messages - CFG, CNTL, DEV, HB, and RES)

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:45 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

TLM CCSDS FRAME, TLM Processed Frame messages need AP-ID fields

  • Key: C2MS11-108
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:02 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

CFG, CNTL, DEV, HB, RSRC Messages need fields DESTINATION-NODE and DESTINATION-FACILITY

  • Key: C2MS11-106
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Subject not able to be fully created from Message fields in all cases.

    Add fields DESTINATION-NODE (String, Optional) and DESTINATION-FACILITY (String, Optional) to the messages. ME3 and ME4 should refer to those two fields for their values, respectively.

  • Reported: C2MS 1.0 — Wed, 21 Sep 2022 23:53 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

TLMPKT Message needs field AP-ID

  • Key: C2MS11-107
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field AP-ID (String, Required) to the message. ME4 should refer to this field for its value. If field AP-ID is added as OPTIONAL, then ME4 should also be changed to OPTIONAL.

  • Reported: C2MS 1.0 — Wed, 21 Sep 2022 23:58 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

Specify multiplicity for required and optional fields


Log message scope too broad, need Alert/Status style message introduced

  • Key: C2MS11-15
  • Status: open  
  • Source: The MITRE Corporation ( Ryan Conrad)
  • Summary:

    The LOG message is nice to cover a certain scope of messages needing to be utilize by developers using the specification, however the ProductMessage again and again finds itself utilized instead of the LOG message because of the structure the LOG message has versus the ProductMessage for making things like status or event messages.

    Because of this, I had looked at the ALMAS specification from Navy and the CAP (Common Alerting Protocol) from OMG to come up with an Alert Notification and Alert Ack message that would be greatly helpful in making a solid Header for alert and status messages that could be different in scope than typical LOG messages.

    I have these messages defined in GMSEC/COMPATC2, and would need to attach it for you to see the details. Thank you

  • Reported: C2MS 1.0b2 — Mon, 30 Sep 2019 18:57 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

Make Fields Table and UML Match the Order of Fields for greater Readabliity

  • Key: C2MS11-17
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    It would greatly aid readability of the specification if the tables listing the message contents by field separated the required fields from the optional fields. By doing this, the UML and descriptive tables would be in alignment.

    This is true throughout, but for one pretty clear example, see section 8.6.1.3. The UML (figure 8-13) (page 101) and the table (table 8-69) are hard to read together when looking at both.

    In this case, there are two blocks in the UML diagram that contain fields: one block is "Required Fields" and the other "Optional Fields". The table, simply shows fields. When reading down the fields in the table, the listed fields come from the two different UML blocks in the following order:

    1-Required
    2-Optional
    3-Required
    4-Optional
    5-Optional
    6-Required
    7-Required
    8-Optional
    9-Optional
    10-Required

    It would be much more clear to have all the fields in the table be listed in the same order as the UML diagram, with Required first, followed by Optional, along with a column specifying required or optional. Alternatively, there could be two tables: one for required fields in the same order as the "Required Fields" block of UML, and a second table with all the optional fields in the same order as the "Optional Fields" block of UML.

    As mentioned above, this is one example, but this disconnect between the UML and the Fields table is true throughout the document.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:33 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT
  • Attachments:

Clarify the ".... Message Header Notes" tables re: being included in each message

  • Key: C2MS11-30
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The ".... Message Header Notes" tables can be confusing. For example, table 8-8. It should be made clear that the fields listed in those tables are from the Message Header definition, but the values apply only for that specific message. A small wording change would go a long way to helping, especially for newer users.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:39 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

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

  • Key: C2MS11-11
  • Status: open  
  • 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

    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

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Updated: Thu, 19 Jan 2023 00:57 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS11-4
  • Status: open  
  • Source: Boeing ( Mr. 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
  • Updated: Thu, 19 Jan 2023 00:57 GMT

Consider Renaming "Header String" type to "Subject Token String"

  • Key: C2MS11-49
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    I believe the distinction between "Header String" and "String" types is to enforce compliance with Subject Element format (UPPERCASE Alphanumeric, "-" and "_" as only valid values). The description of "Header string" in Table 8-1, Field Type Definitions, indicates that this type is used for "subject name elements".

    It's a bit confusing to call this a "Header String", because not all Strings in the Header are Header Strings, and some fields are Header String type even though they are not in the Header (Some examples: USER, SUBCLASS, REFERENCE-ID, and OCCURRENCE-TYPE in Log, CNTL-KEYWORD in Control Message).

    In all cases, the fields that are Header String type are intended to be used as subject elements.

    One side note, that would need to be fixed, either way is that the actual type listed in Table 8-1, Field Type Definitions, lists the type in two places as "Header string" (lowercase s on string), where everywhere else in the document and in UML model figures, it is listed as "Header String".

  • Reported: C2MS 1.0 — Fri, 25 Feb 2022 13:37 GMT
  • Updated: Sun, 13 Nov 2022 00:00 GMT
  • Attachments:

REQUEST-ID as "Replacement" and related STOP

  • Key: C2MS11-55
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Numerous field tables in C2MS allow reusing the same REQUEST-ID for a request to provide a "replacement". For example, MVAL REQ Message says in the Fields table (Table 8-99) under REQUEST-ID:

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

    In all cases, this is the only explanatory text of what is meant by "replacement". This is pretty ambiguous about expected result. So, for example,

    • If I send an initial request to start receiving MVAL A and B, and then send another request of the same REQUEST-ID for MVAL C, is the result that I'm now subscribed to A, B and C, or just to C?
    • If I send a request to start receiving MVAL X and Y with a PUBLISH-RATE of 1 and then send another request for a duration of 120 minutes, and then send another request wit the same REQUEST-ID for MVAL Y with a PUBLISH-RATE of 5, am I subscribed to X at 1 and Y at 5, or just Y at 5?

    There's no description of semantics regarding what is being replaced.

    A related issue is STOP request, specifying non-symmetrical MVALs, and what to do in that situation.

    • If I send a request to start receiving MVAL 11 and 12, and then send a STOP, but only specify MVAL 11, do I still get 12?

    In C2MS 1.0, in every instance of sending a REQUEST-ID as part of a request, the Notes for the field states the identical, "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." However this copy-paste doesn't always make sense.

    Re-use of a REQUEST-ID only makes sense if the request leaves some process continuing to fulfill data streaming. Only two request messages have a start/stop concept. Therefore, this resolution assumes no other messages have a use case for 'replacement' and removes the confusing extra text.

    Additionally, the concept of 'replacement' is not needed in the two cases where start/stop actions are present... just stop the old one and start a new one. Using 'replacement' can lead to confusion.

  • Reported: C2MS 1.0 — Fri, 4 Mar 2022 00:28 GMT
  • Updated: Sun, 13 Nov 2022 00:00 GMT

All Messages Subclass Message Header

  • Key: C2MS11-18
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The way the UML is shown for each message, each C2MS message inherits the Message Header type. This isn't really semantically correct.

    Consider the diagram from section 8.6.3.3 (although this is true throughout all message specifications), which is included as Attachment 1. Organized this way, this UML means that Telemetry TDM Frame Message IS A Message Header, rather than that it contains a Message Header.

    THere are two options for making this a little more clear:

    Option A is that Instead, they should be subclasses of something called "C2MS Message" that itself contains a Message Header, as shown in Attachment 2, in which Telemetry TDM Frame Message IS A C2MS Message, and all C2MS Messages contain a Message Header.

    Option B is to use composition where each message contains a message header. This is as shown in Attachment 3.

    It's not a major point, but would increase readability and have better optics.

    After discussion, Option B seems like the right choice.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:53 GMT
  • Updated: Sun, 13 Nov 2022 00:00 GMT
  • Attachments:

Clarify the UML diagrams regarding the values for the fields inherited from Message Header

  • Key: C2MS11-31
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This issue is related to C2MS11-30, which is about the table immediately prior to every message UML diagram. The UML diagrams, for example figure 8-3, seem to indicate that "MESSAGE-TYPE" and "MESSAGE-SUBTYPE" are fields in the individual message when they are actually in the Message Header.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:43 GMT
  • Updated: Sun, 13 Nov 2022 00:00 GMT
  • Attachments:

In Message Header, make NODE and USER-NAME string rather than Header String

  • Key: C2MS11-29
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The NODE and USER-NAME fields are tracking fields supplied by the implementation (API). They should just be whatever strings are returned by the local o/s rather than forcing them to be of type Header String (upper alphanumeric, "-", "_").

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:23 GMT
  • Updated: Sun, 13 Nov 2022 00:00 GMT
  • Attachments:

Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header

  • Key: C2MS11-28
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    In the Message Header (pages 41-45), add the fields DESTINATION_NODE and DESTINATION_FACILITY as Optional with type of Header String. This enhances the routing/subscribing options currently available for the DESTINATION_COMPONENT field.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:20 GMT
  • Updated: Sun, 13 Nov 2022 00:00 GMT

Missing Echo Request

  • Key: C2MS11-87
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is no “need Echo” in the EGS REQ CMD Message. At present, all we can say is that based on MUS configuration, EGS CMDECHO may be generated.

    I propose using a new Boolean CMD-ECHO field in Command Request Message to indicate if an ECHO should be sent at any configured point along the ground chain as the command is transmitted.

    This would be an Optional field, defaulting to FALSE.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:48 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT
  • Attachments:

Add Message-level Security Constructs

  • Key: C2MS11-48
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Add fields that allow encryption of content sections of C2MS messages as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

    The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

    Note that currently, GMSEC provides a level of encryption/signing, but my thought is that it would be preferred to allow the mission to manage this outside the transport layer. Providing encryption/signing FIELDS in the message definition allows for this decouplling.

    I've got some specific ideas about how to do this, which I can share, but just want to capture the need here.

  • Reported: C2MS 1.0 — Tue, 22 Feb 2022 16:50 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Move Tracking Fields to a "Message Envelope"

  • Key: C2MS11-75
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. Recommended here, is to define a C2MB Sister spec that encompasses the 'how' of sending C2MS messages. This is the logical place for managing tracking fields in a "Message Envelope".

    This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning in C2MS itself.

  • Reported: C2MS 1.0 — Sun, 20 Mar 2022 01:04 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

In message Archive Message Retrieval Response, fix Header field names

  • Key: C2MS11-34
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Typo in the diagram only for Archive Message Retrieval Response calls the Header fields it uses MSG-TYPE and MSG-SUBTYPE. They should be MESSAGE-TYPE and MESSAGE-SUBTYPE, respectively. See page 64, figure 8-5.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:38 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT
  • Attachments:

Control Message SPECIAL_INFO Field type should be String

  • Key: C2MS11-40
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the Control Message, the field SPECIAL_INFO is Binary type in the UML diagram (Figure 8-9), but is described as "For application use. Any additional information can be provided here." (Table 8-48).

    Because C2MS has no definition or understanding of the binary format, it is probably better if the type be changed to "String", so that opaque data is not transmitted around the system where only the producer and consumer can understand what it is. Log messages, for example, would not be able to record, in any meaningful way, what was sent in the control message.

  • Reported: C2MS 1.0 — Tue, 6 Oct 2020 17:46 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

In the Control Message, the field CNTL-STRING should be required

  • Key: C2MS11-38
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Change the CNTL-STRING field in the Control Message from optional to required. That field is the reason for the message. This also will be consistent with Directive Message, where DIRECTIVE-STRING is required. See Figure 8-9.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:52 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT
  • Attachments:

Remove value for CNTL-STRING from CNTL message

  • Key: C2MS11-37
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The field CNTL-KEYWORD in the Control Message is supposed to contain the keyword extracted from the field CNTL-STRING. It should not be fixed. So, remove the value from the diagram. Figure 8-9. This is a Model change.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:49 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT
  • Attachments:

Using REQ Messages for 'Publish'


Document that Header String type is to be at least one ASCII character

  • Key: C2MS11-26
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This is just a documentation clarification. Header Strings are the type used for building message subjects. It's invalid for a message subject element to be null. So, Header Strings need to be at least one character.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:09 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Add field for USER to Message Header

  • Key: C2MS11-32
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    In Log, Directive Request, and Simple Service Request, there is a USER field for use by communicating applications. This field should be moved to the Message Header, so that any message can utilize this field.

    Note: in the Log Message this field is used in the subject, so is defined as a Header String. In the Directive and Simple Service messages, it is not used in the subject so is defined as a string.

    Note 2: There is another field in the Message Header called USER-NAME; this is a tracking Field, so is reserved for use by the implementation and is the account/user name that started the application.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 18:01 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Add security fields that GMSEC API inserts into encrypted messages as Tracking Fields in C2MS

  • Key: C2MS11-33
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The intent of tracking fields is to reserve them for use by the implementation. So, to be complete, these fields should be added to the specification. If any of these fields were to be inadvertently added to the messages by an application, the implementation (GMSEC API) could potentially overwrite their values.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:33 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Add a Message Exchange Pattern (MEP) for a component to forward requests/responses

  • Key: C2MS11-24
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

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

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:52 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Harmonize Replay TLM and Archive Mnemonic Message Sets

  • Key: C2MS11-20
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    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.

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 16:28 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Add documentation within the model

  • Key: C2MS11-13
  • Status: open  
  • 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
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Message-level Security Credentials

  • Key: C2MS11-22
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Justin Boss:
    A username or alternate security credential should be able to be provided with all C2MS requests (and possibly should be required)?

    Systems should not automatically trust remote clients and therefore a credential should be required with all messages. This would allow components to authorize and audit requests on a per-user/connection level.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 03:38 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Larger Data Types

  • Key: C2MS11-21
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). (From Justin Boss)

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:44 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS11-6
  • Status: open  
  • Source: Boeing ( Mr. 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
  • Updated: Fri, 7 Oct 2022 01:00 GMT

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

  • Key: C2MS11-10
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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. This could potentially be solved by a registry concept, as in C2MS11-1, but this particular issue proposes adding a service-matching capability wherein the requester is asking for a subscription to some data and the request results in linking the subscription to a service that provides that data.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:48 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

"Mnemonic" should be called "Parameter"

  • Key: C2MS11-12
  • Status: open  
  • 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
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Pub/Sub subscription status unknown

  • Key: C2MS11-9
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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
  • Updated: Fri, 7 Oct 2022 01:00 GMT

C2CX Heartbeat comments

  • Key: C2MS11-2
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (C2CX Heartbeat) Section 8.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
  • Updated: Fri, 7 Oct 2022 01:00 GMT
  • Attachments:

Archive Mnemonic Value Request comments

  • Key: C2MS11-3
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (Archive Mnemonic Value Request) Section 8.9.1

    • Need official registry for FORMAT values

    The AMVR message has a field called FORMAT that is of type String, but there is no enumeration of possible formats. This could be handled by requestor and supplier agree on a format.

    FORMAT is used to define the file format of the return data.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Lack of a registry concept

  • Key: C2MS11-1
  • Status: open  
  • Source: NASA ( Mr. John 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
  • Updated: Fri, 7 Oct 2022 01:00 GMT

Data Dictionary Messages

  • Key: C2MS11-5
  • Status: open  
  • Source: Boeing ( Mr. 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
  • Updated: Fri, 7 Oct 2022 01:00 GMT