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?

The title of the spec as well as the introduction of it (section 1.1...) make the reader think that this spec is about all known and future spacecrafts while it's about Earth Satellites as proved by, e.g., the use of UTC time.
The introduciton needs clearly to state this and the name of the spec should be changed - earth Satellite Operations Language Metamodel (eSOLM)? -.

Rename Spacecraft Operations Language Metamodel to Satellite Operations
Language Metamodel. Occurrences corrected on Title page, document footer,
and Glossary (p 4).
On page 1 introduction replace first paragraph:
This specification defines a meta-model, Spacecraft Operations Language Meta-model (SOLM), for
representing spacecraft operations procedures. These procedures contain sequences of instructions to
conduct spacecraft operations, typically consisting of spacecraft commands and spacecraft telemetry
comparisons. These procedures may also include the configuration of ground equipment, configuration of
spacecraft test equipment, execution of ground testing, and execution of on-orbit testing. Historically, these
procedures have been captured in flowcharts, text manuals, and a number of different scripting languages
used for ground station automation. A standard meta-model to represent spacecraft operations procedures
will facilitate the transfer of procedures between the spacecraft vendor and the spacecraft operator, as well
as allow for maintenance and transfer of the procedures across different ground systems employed over the
lifetime of the spacecraft.
With:
This specification defines a meta-model, Satellite Operations Language Meta-model (SOLM), for
representing spacecraft operations procedures. These procedures contain sequences of instructions to
conduct spacecraft operations, typically consisting of spacecraft commands and spacecraft telemetry
comparisons. These procedures may also include the configuration of ground equipment, configuration of
spacecraft test equipment, execution of ground testing, and execution of on-orbit testing. Historically, these
procedures have been captured in flowcharts, text manuals, and a number of different scripting languages
used for ground station automation. A standard meta-model to represent spacecraft operations procedures
will facilitate the transfer of procedures between the spacecraft vendor and the spacecraft operator, as well
as allow for maintenance and transfer of the procedures across different ground systems employed over the
lifetime of the spacecraft.
This specification is primarily aimed at providing procedure portability for earth-orbiting satellites. While
deep-space spacecraft use similar operational procedures, they also use extensive on-board procedures and
there are significant considerations in the representation of time that are not incorporated in this metamodel.

The SpacePython mapping is too vague to insure compatible implementations, and the example python script in the document will not cut-and-paste as a valid script. Please provide all example scripts as machine-consumable files and expand the SpacePython example to cover all of the SOLM features or add additional examples to cover the features

Added two additional SpacePython script examples to cover the Python extensions required by
SOLM. Created an installable Python package that contains the script examples and enough
skeleton implementation to run the scripts on any Python-compatible platform. Also created a
package with the equivalent CCL scripts in machine-consumable form. Regress the Python
version compatibility requirement to 2.6 to allow working with current enterprise Linux releases.

Model should be exported in latest available XMI (2.4.1 is current)

The original XMI file in the specification was exported in XMI 1.4 from the model in Enterprise
Architect. This file is replaced with a current export after all other modeling changes have been
applied.

Procedure.duration is typed by an unknown tyoe - RelativeTime. Reset this type to TimeInterval

This resolution applies to the non-normative model as captured in Enterprise Architect and results
in changes to the normative XMI model when it is exported. The “revised text” below shows the
impact on the XMI model.

The classifier - Time - for WaitOnExpression.timeout and WaitOnTime.time were not set correctly (usually if the classifier is typed into the field)..

This resolution applies to the non-normative model as captured in Enterprise Architect and results
in changes to the normative XMI model when it is exported. The “revised text” below shows the
impact on the XMI model. Figures 5 and 6 are generated from the non-normative model and
required updating for consistent use of the TimeInterval and SpecificTime classifiers. A document
search also found that section 6 contained two references to an older non-existent classifier
name (RelativeTime) instead of the TimeInterval classifier in the normative metamodel.

SpecificTime.dayOfYear() returns a void - change to Integer per the other methods

This resolution applies to the non-normative model as captured in Enterprise Architect and results
in changes to the normative XMI model when it is exported. The “revised text” below illustrates
the impact on the XMI model. There is also a change in Figure 11 for the method signature.

The model makes use of a 'UML' Code product type - if you set the Language for each class to '<none>' you not only get the same PrimitiveTypes, but the XMI exporter will produce the correct hrefs in the XMI to those DataTypes defined in UML

This resolution applies to the language selection in the non-normative model as
captured in Enterprise Architect and results in changes to the normative XMI
model when it is exported. The “revised text” below illustrates the impact on the
XMI model, but does not identify every line changed, since the XMI is machine
generated.