[Ccsds-omg-liaison] Light Feedback on the GovSat RFC Document 2012-08-01

[Overeem, David T]

Hi all.  I have been looking this over and I have a number of thoughts/comments/questions.  Some of it may look like I am thinking aloud.

The "rule numbering" came from my writing them on the document table sequentially as I went.


(1) Would it be wise to address this directly at XTCE V1.2?  For the purpose of the programs I am using XTCE for, V1.2 is necessary.  It has fixes that the GovSat model may also benefit from without having to do another delta on the RFC.  I realize this creates a moving dependency and is probably worth discussing in committee.

(2) Rule 1: I am surprised that GovSat can get away with only one SpaceSystem.  I found the SpaceSystem to be the seemingly obvious method to divide the parameter namespace.  I assume that government programs also have tables of structured data, possibly star tracker tables, fpga tables, configuration tables, etc etc that would also benefit from having a telemetry "commutate" and "decommutate" definition in the database?  The vendors ought to love getting table definitions this way.  Makes them just a "giant telemetry packet" from the perspective of the ground.  We have encoded our tables in XTCE as well as TM and TC.

(3) Since Xpath 2 specifies the GovSat rules, an XSLT file would be great to provide.  By applying it to an XTCE document, a quick compliance check could be done.

(4) Rule 4: Is this really helpful?  If we had number 3...

(5) Rule 8: Has it been considered to support the Unit/@description attribute?  We found this handy to specify the type of measurement being described.  For a trivial example, <Unit description="current">amperes</Unit>.

(6) Rule 24: Since calibrators are applied against encoding types, does it matter if the engineering type is enumerated?  I doubt this causes any of the vendors heartburn - although I do wonder about how useful it is.

(7) Rule 27: Wow, 10 terms - never seen anyone go out that far that I can remember.  Is 8 a more common implementation for the vendors?  Of course, there might be an extra note for those folks who go both ways.  If I want to "commutate" that parameter type (eg. "encode" an engineering value), perhaps for a table upload, having anything past 3rd? order gets ugly.

(8) Rule 29: Appears to be an error on this rule.  It talks to BinaryDataEncoding of EnumeratedParameterType, but the Xpath rule refers to StringDataEncoding.

(9) Rule 38: Is this rule a duplicate of 33?

(10) Rule 42: Recommend adding a statement to the user, "just use EnumeratedParameterType instead"

(11) Rule 47: Wow, is there nobody using 1750A anymore?

(12) Rules 51&52: Perhaps the statement about the @scale and @offset should say that the default value (which is no change) is the only supported configuration?  Instead of saying they are ignored.  The case of @units seems wise to include since there is not a UnitSet for this type.

(13) Rule 53: I found the BooleanParameterType to be useful and I cannot imagine the vendors complaining about it.  It decays to an EnumeratedParameterType in the event that a particular vendor does not explicitly have this type...

(14) Rule 56: Users may be disappointed without Float encoding for a relative time.  For example, a unit of seconds could very well have a fraction and be a float instead of a fixed decimal value?

(15) Rule 58 - same comment as (12) above.

(16) Rule 59: I think you need ParameterRef for CCSDS verification of counter increments?  Might want to look at this again.

(17) Rule 60: Is this restriction necessary?  By convention, we are using things like "_TMType" and "_TCType" that match 1:1 with parameters, but there are some cases where there are hundreds of parameters with the same type.  It can save significant space/memory to share the same parameter type across many parameters.  This should not block any ground system implementation.  On one program, we are doing the ECSS PUS and the "Structure ID" is a classic example of this.  Without sharing, we need to duplicate the same EnumeratedParameterType (with the same hundred enum values) hundreds of times.

(18) Rule 71: Are you sure about StreamSet not supported?  This seems to be the means to specify which containers are members of an incoming base container type.  For instance, a CCSDS TM Frame described in XTCE is a stream containing umpteen TM Packet containers.  Seems like this is needed for the TT&C vendor applications.

(19) Rule 72: I am also surprised at the omission of AlgorithmSet.  How does GovSat permit the description of derived parameter formulae/algorithms without that?  We have tons of these on the projects I am working.

(20) Rule 79: I think this is a duplicate.  See comment (6) above.

(21) Rule 80: I think this is also a duplicate.  Similar apparent typo to comment (8)

(22) Rule 90: Similar typo as (8)

(23) Rule 93: Does it make more sense to create the CCSDSCommandPacket as a Container inside of CommandContainerSet instead of as a MetaCommand abstract?  It does not have any arguments in this example that would drive it to the MetaCommand side.  This of course brings up a topic on best practive usage of CommandContainerSet and MetaCommand/CommandContainer elements that I would like to pursue further.  It is not totally clear to me.

(24) Rule 95&96&97: Another typo on the Xpath side.

(25) Rule 99: Same comment as (13)

(26) Rule 100&102&104&105&106&107: Don't you need at least some of these?  Does GovSat not verify command execution states?  I am very surprised, but later in the document (section 6.2.3.5) it describes how to use these - so perhaps just a few too many are shown as not used here?

Towards the end of the commanding discussion, there is mention of the mismatch with @parameterRef and @argumentRef.  Our people have also encountered a problem with this.  Would like to discuss further, perhaps at the meeting in September.

In Section 6.3 - the Template, it would look really nice if we included the text from the CCSDS standard itself in the long description for the parameters.  This is user pleasant :-)

Well, sorry for all the "long windedness"
Dave