-
Key: C2MS12-53
-
Status: open
-
Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
-
Summary:
Find a way to make messages extensible so that missions that tailor C2MS messages do not need to create new forms of C2MS-like messages, but can simply use the C2MS message and add content to it specific to their mission. What we have seen in C2MS 1.0 is numerous cases where SatOps programs have modified C2MS messages to add information they need, and in so doing, have created a specification of C2MS-like messages that are not themselves C2MS messages. An example would be to have a COMMAND REQUEST MESSAGE that adds a field called SOUND-TO-MAKE-WHEN-SENT, and because of this, they change the message to use a SPECIFICATION of MY-MISSION-SPEC and version numbers with their own versioning. Usually, the Message Type and Subtype are affected as well. Sometimes, they have added to the C2MS Message Header itself, making it diverge further.
One possible approach, simply as an example, is to allow name-value pairs to be added to the message. This would likely need some kind of namespace-like designator to indicate it is for Mission ABC, and would also need a way to have a type specified (maybe it's a Name-Type-Value triplet.
Example of Name-Value pair to add to Command Request Message: NAME[0]="MISSION-FOO.SOUND-TO-MAKE-WHEN-CMD-SENT" VALUE[0]="BLEEP-BLOOP".
Example of Name-Value-Type triplet to add to Command Request Message: NAME[0]="MISSION-FOO.SOUND-TO-MAKE-WHEN-CMD-SENT" VALUE[0]=[some binary like a wav] TYPE=BINARY.
-
Reported: C2MS 1.1b1 — Sat, 29 Jun 2024 20:26 GMT
-
Updated: Thu, 26 Sep 2024 22:00 GMT
C2MS12 — Make C2MS Messages Extensible
- Key: C2MS12-53
- OMG Task Force: Command and Control Message Specification (C2MS) 1.2 RTF