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

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

  • Key: C2MS11
  • Issues Count: 39
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
C2MS11-19 Larger Data Types C2MS 1.0 open
C2MS11-21 Larger Data Types C2MS 1.0 open
C2MS11-7 XML PSM recommended C2MS 1.0b1 open
C2MS11-39 Add field APID (and VCID) to Telemetry CCSDS Packet Message 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-36 Add DESTINATION-NODE and DESTINATION-FACILITY as fields 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-34 In message Archive Message Retrieval Response, fix Header field names 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-32 Add field for USER to 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-30 Clarify the ".... Message Header Notes" tables re: being included in each message 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-27 Time Type table clarification for the DDD portion C2MS 1.0 open
C2MS11-26 Document that Header String type is to be at least one ASCII character C2MS 1.0 open
C2MS11-25 Make all subjects be buildable from fields in the message C2MS 1.0 open
C2MS11-24 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses 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-22 Message-level Security Credentials C2MS 1.0 open
C2MS11-1 Lack of a registry concept C2MS 1.0a1 open
C2MS11-20 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 open
C2MS11-18 All Messages Subclass Message Header C2MS 1.0 open
C2MS11-17 Make Fields Table and UML Match the Order of Fields for greater Readabliity C2MS 1.0 open
C2MS11-16 REQUEST-ID field does not support usage as a GUID C2MS 1.0 open
C2MS11-15 Log message scope too broad, need Alert/Status style message introduced C2MS 1.0b2 open
C2MS11-13 Add documentation within the model C2MS 1.0a1 open
C2MS11-14 Specify multiplicity for required and optional fields C2MS 1.0a1 open
C2MS11-12 "Mnemonic" should be called "Parameter" C2MS 1.0b1 open
C2MS11-11 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 open
C2MS11-9 Pub/Sub subscription status unknown C2MS 1.0b1 open
C2MS11-8 Acknowledge Final Status inconsistency C2MS 1.0b1 open
C2MS11-10 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 open
C2MS11-6 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 open
C2MS11-5 Data Dictionary Messages C2MS 1.0b1 open
C2MS11-4 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 open
C2MS11-3 Archive Mnemonic Value Request comments C2MS 1.0a1 open
C2MS11-2 C2CX Heartbeat comments C2MS 1.0a1 open

Issues Descriptions

Larger Data Types

  • Key: C2MS11-19
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( 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:48 GMT
  • Updated: Wed, 24 Jun 2020 19:31 GMT

Larger Data Types

  • Key: C2MS11-21
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( 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: Wed, 24 Jun 2020 19:31 GMT

XML PSM recommended

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

    Due to lack of the ability to have multiple independent implementations of GMSEC due to its message-building API functions in source code, it would be appreciated if there were an XML PSM available. This would allow for an independent implementation apart from the single known implementation at this time. At this time, there is no known PSM that enables implementation of C2MS at this time that does not depend on FOSS or government-licensed IP.

    This is based on inputs from C2MS-2.

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:07 GMT
  • Updated: Wed, 24 Jun 2020 19:28 GMT

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

  • Key: C2MS11-39
  • Status: open  
  • Source: NASA ( Jay 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: Wed, 24 Jun 2020 18:58 GMT

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

  • Key: C2MS11-38
  • Status: open  
  • Source: NASA ( Jay 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: Wed, 24 Jun 2020 18:52 GMT

Remove value for CNTL-STRING from CNTL message

  • Key: C2MS11-37
  • Status: open  
  • Source: NASA ( Jay 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.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:49 GMT
  • Updated: Wed, 24 Jun 2020 18:49 GMT

Add DESTINATION-NODE and DESTINATION-FACILITY as fields

  • Key: C2MS11-36
  • Status: open  
  • Source: NASA ( Jay 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: Wed, 24 Jun 2020 18:47 GMT

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

  • Key: C2MS11-35
  • Status: open  
  • Source: NASA ( Jay 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: Wed, 24 Jun 2020 18:42 GMT

In message Archive Message Retrieval Response, fix Header field names

  • Key: C2MS11-34
  • Status: open  
  • Source: NASA ( Jay 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: Wed, 24 Jun 2020 18:38 GMT

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

  • Key: C2MS11-33
  • Status: open  
  • Source: NASA ( Jay 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: Wed, 24 Jun 2020 18:33 GMT

Add field for USER to Message Header

  • Key: C2MS11-32
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 18:15 GMT

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

  • Key: C2MS11-31
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 17:43 GMT

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

  • Key: C2MS11-30
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 17:39 GMT

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

  • Key: C2MS11-29
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 17:23 GMT

Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header

  • Key: C2MS11-28
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 17:20 GMT

Time Type table clarification for the DDD portion

  • Key: C2MS11-27
  • Status: open  
  • Source: NASA ( Jay 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.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:17 GMT
  • Updated: Tue, 23 Jun 2020 17:17 GMT

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

  • Key: C2MS11-26
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 17:09 GMT

Make all subjects be buildable from fields in the message

  • Key: C2MS11-25
  • Status: open  
  • Source: NASA ( Jay 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.)

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:59 GMT
  • Updated: Tue, 23 Jun 2020 16:59 GMT

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

  • Key: C2MS11-24
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 16:52 GMT

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

  • Key: C2MS11-23
  • Status: open  
  • Source: NASA ( Jay 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: Tue, 23 Jun 2020 16:48 GMT

Message-level Security Credentials

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

    Justing 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: Tue, 23 Jun 2020 14:13 GMT

Lack of a registry concept

  • Key: C2MS11-1
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

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

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

Harmonize Replay TLM and Archive Mnemonic Message Sets

  • Key: C2MS11-20
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( 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: Sat, 21 Mar 2020 21:48 GMT

All Messages Subclass Message Header

  • Key: C2MS11-18
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( 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. Instead, they should be subclasses of something called "C2MS Message" that itself contains a Message Header.

    Consider the diagram from section 8.6.3.3 (although this is true throught all message sepcifications), 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.

    The proper relationship would be as shown in Attachment 2, in which Telemetry TDM Frame Message IS A C2MS Message, and all C2MS Messages contain a Message Header.

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

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:53 GMT
  • Updated: Fri, 28 Feb 2020 19:53 GMT
  • Attachments:

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

  • Key: C2MS11-17
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( 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) 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: Fri, 28 Feb 2020 19:33 GMT

REQUEST-ID field does not support usage as a GUID

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

    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: Fri, 28 Feb 2020 19:11 GMT

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: Fri, 3 Jan 2020 20:50 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, 3 Jan 2020 20:50 GMT

Specify multiplicity for required and optional fields

  • Key: C2MS11-14
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:37 GMT
  • Updated: Fri, 3 Jan 2020 20:50 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, 3 Jan 2020 20:50 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
    -Telemetry Message for CCSDS Packet
    -Telemetry Message for CCSDS Frame
    -Telemetry Message for TDM Frame

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

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Pub/Sub subscription status unknown

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

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

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:43 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Acknowledge Final Status inconsistency

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

    Based on review of latest specification, the problem detailed in C2MS-5 is still present. This problem makes it not possible for a client application to properly be developed to support all MEPs. If a client application is developed to support MEP2, then it will ignore all future responses after the first ACK comes in when communicating with a server that supports MEP4 or MEP5. If a client application is developed to support MEP4 and MEP5, then it will never think that a request finished when communicating with a server that supports MEP2.

    As is currently specified, via table 6-9 on page 20, the Acknowledge is listed as a Final Status. Though it is only a final status in MEP2.

    Possible solutions:
    1. Remove MEP2. This would make Acknowledge in Table 6-9 have a Final Status of "No"
    2. Add an additional status code of Acknowledge Complete (perhaps #7). In this option, Acknowledge (#1) would have Final Status of "No", though new Acknowledge Complete (#7) would have Initial Status of "Yes", Intermediate Status of "No", and Final Status of "Yes".

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:44 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

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

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

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

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:48 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS11-6
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    For a complete implementation of C2MS on the systems I use, we need some kind of Procedure Script Execution set of messages. These would include being able to launch procedures, monitor them, show progress, etc. This could be a topic of some significant discussion and is entirely new scope. The closest analogue I have so far found is the Activity Tracking stuff in the CCSDS Mission Operations Common Services.

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:28 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Data Dictionary Messages

  • Key: C2MS11-5
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    It seems that there is a consensus that we need database data dictionary informational messages. It seems to be in work. Capturing the item here.

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:23 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS11-4
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    The messages for mnemonic access do not appear to include a request/response for "setting" the value of a parameter (mnemonic) from an application participating using C2MS. This capability is used for ground and other types of non-telemetered parameters (mnemonics).

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:21 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Archive Mnemonic Value Request comments

  • Key: C2MS11-3
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (Archive Mnemonic Value Request) Section 7.9.1

    • Need official registry for FORMAT values
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

C2CX Heartbeat comments

  • Key: C2MS11-2
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (C2CX Heartbeat) Section 7.5.4

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