The Comet Control Language is a vendor-specific language that is not maintained by the SOLM RTF or any active member of the Space Domain Task Force. As such, it is unable to be maintained by the SOLM RTF maintainers. In addition, we do not see value in maintaining it due to lack of awareness of it being implemented/used in conjunction with SOLM.

Within SpacePython times.py TimeInterval _str_() function, the following lines are faulty:

hours = seconds / 3600
minutes = (seconds % 3600) / 60

Both of these variables should be integers (not floating point values)

These instead should be:
hours = int(seconds / 3600)
minutes = int((seconds % 3600) / 60)

Section 6.7 represents compliance between the SOLM spec and the original RFP requirements. This likely should have been part of section 0 and removed during FTF. As such, this section should now be removed.

The comments in SetMomentumWheelSpeed.py state that the <module>._doc_ text corresponds to the Procedure.description attribute in the metamodel. This text should correspond the HeaderComment in the metamodel instead, and the Procedure.description should correspond to <module>.invoke._doc_

Change text within SetMomentumWheelSpeed.py

Change the text comment within SetMomentumWheelSpeed.py.

The SpacePython files should point to the copyright information within the SOLM specification itself rather than a single vendor.

Change copyright in files

Change the copyright to be based on the Object Management Group's SOLM specification

Within space/parameters.py, the ulong (an unsigned type) is mapped to an int (a signed type). Should be mapped to unsigned (an unsigned format).

Change ulong mapping to be "unsigned"

Within the typeNames assignment of space/parameters.py, change int to unsigned in:
'uint': unsigned, 'long': int, 'ulong': int,\

SpacePython is not compatible with Python version 3. Multiple script errors are encountered. Python version 2 is no longer supported, so software should be updated to work with later version.

Update reference of Python 2.6 and deliver Python3 version of SpacePython files

Within spec document, update references of Python 2.6 to Python 3.

Apply changes to Python files to incorporate changes to make it work under Python3. These changes were performed using Git and a patch file is provided of the changes.

... While doing this we think we’ve identified an omission in the mapping table.

If you look at the SOLM you’ll see this model for the Parameter. Note the highlighted aggregate object. If we go to the table for the mapping we see:

Parameter.value()
Parameter.raw()

Of course raw() doesn’t exist in the model, but there’s a description (note uncal doesn’t exist). But the but is there’s no mapping item to get the timestamp. However in the reference implementation in a section that should be normative there’s the report method that returns the time and the value (effectively a tuple that represents the InstantValue – see the 6.4.6 description).

In my book this should be a bug report to add a Parameter.report() that returns the InstantValue data as a tuple of value, timestamp. So can we report this as a bug?

Defer to future minor revision version

Defer to future revision.

The terms XTCE and GEMS should not be part of the SOLM meta models or functions that are projected from it (like SpacePython).

The specification should talk about Parameters that are being queried (possibly as Spacecraft or Ground Parameters), though the transport/method should be decoupled since there are multiple interfaces that could be used (direct integration with an end product, via GEMS, via SNMP, via a message bus/C2MS, or perhaps via a database).

Defer to future minor revision version

Defer implementation until future revision

operatorQuery allows for any number of inputs of any type to be provided. An implementation is very difficult to provide a friendly experience.

Would be valuable if guidance is provided for common usage patterns, including:

• Yes/No prompt
• Confirmation prompt (Message Box)
• Pick from a list (enum/dropdown/picklist)
• Input string, number, arrays
• Considerations for rich dialogs
• Password/credential prompts

SpacePython defines its own time object. It should instead utilize native time/date functionality. This would make procedures be easier to author and better integrate with existing and third-party libraries.

The data model should harmonize spacecraft and ground assets and therefore the language model should simplify/make this consistent as much as possible.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that provide parameter and type information are lacking or insufficient in the language.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that allow retrieval of metadata from a previous directive/command that was issued do not exist in the language.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that create ground system events do not currently exist in the language.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that enabling the establishment and release of command locks are missing from the language.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that allow determining the current status/flags of a parameter (including the severity) are not available in the language at this time.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that perform telemetry and limit checks are missing from the language at this time.

The user interface (operatorQuery) function is embedded in the middle of the SpacePython implementation and is not able to be separately implemented.

The method of prompting for a value may vary (such as for a web user interface versus a desktop application) and this variance is independence of the implementing provider for the SOLM language module.

SpacePython 1.1 requires that the reference implementation is modified/tailored by an implementing project/customer. As such, it does not have a loosely coupled implementation where the interface and implementation are separate.

The terms XTCE and GEMS should not be part of the SOLM meta models or functions that are projected from it (like SpacePython).

The specification should talk about Parameters that are being queried (possibly as Spacecraft or Ground Parameters), though the transport/method should be decoupled since there are multiple interfaces that could be used (direct integration with an end product, via GEMS, via SNMP, via a message bus/C2MS, or perhaps via a database).

... While doing this we think we’ve identified an omission in the mapping table.

If you look at the SOLM you’ll see this model for the Parameter. Note the highlighted aggregate object. If we go to the table for the mapping we see:

Parameter.value()
Parameter.raw()

Of course raw() doesn’t exist in the model, but there’s a description (note uncal doesn’t exist). But the but is there’s no mapping item to get the timestamp. However in the reference implementation in a section that should be normative there’s the report method that returns the time and the value (effectively a tuple that represents the InstantValue – see the 6.4.6 description).

In my book this should be a bug report to add a Parameter.report() that returns the InstantValue data as a tuple of value, timestamp. So can we report this as a bug?