[Css-csts] Monitored Data Dictionary

[Wolfgang.Hell at esa.int]

Dear colleagues,

Please find attached a revised spreadsheet that lists the candidate core of
parameters that shall be accessible by means of the Monitored Data Service.
The revisions of the spreadsheet reflect the questions / comments that I
received since the 2010 spring meeting. The main changes are in the area of
ranging which has been tuned to be better aligned with the CCSDS PN Ranging
Standard and in the area of open loop recording which is completely new.

As far as this spreadsheet is concerned, we will have to determine if this
can be regarded as the WG consensus in terms of parameters that shall be
available in a standard representation. You will notice that there is a
relatively high number of parameters that are 'static' in the sense that they
reflect the configuration and as such should simply confirm that the provider
did what he was asked to do. Shall we really 'invest' into the monitoring of
such parameters.

You will also find attached the outcome of the first crack I took at coming
up with a formally specified data dictionary. As discussed in one of the
telecons we had, I have taken PVL (CCSDS 641.0-B-2) to do so. Please note
that the attached document is incomplete in the sense that for those types
that are specified in PVL I did not bother to copy the definitions into the
dictionary. For types such as WhiteSpace, Integer, FloatingPoint,
Exponential, QuotedString1 etc. please refer to chapter 4 of  CCSDS
641.0-B-2. If we want to make future versions self-contained, that can be
easily done by importing the missing type specifications. As regards
engineering units, I have included that information so far in comments only,
but this could be expressed also in PVL.

The PVL approach is feasible, but I'm not convinced that this is really the
best way to go. My concerns are the following:

- PVL results in a fairly verbose representation, perhaps not as bad as XML,
but certainly not appealing for high sampling rate monitoring applications.
If we were to add the engineering units, it gets even worse.
- PVL specifies how parameters are to be presented to human users - but do we
really need to standardize that? Can't this be left to the local
implementations as long as we agree on the parameter names?
- The typing / constraining supported by PVL is quite weak (e.g. the only way
to constrain the range of parameters is by means of comments) and the
definition of enumerated values is clumsy.
- PVL is specified using ASN.1 syntax. As a consequence, at least some ASN.1
knowledge is needed to understand PVL. That being so, why not use ASN.1 from
the beginning which results in a far less verbose transfer syntax and offers
much stronger typing and constraining?
- We should have means to check that the specification is formally correct.
For ASN.1 this is not a problem, as parsers/compilers exist. What about PVL?
Also, does software exist that helps implementing applications that generate
/ digest PVL?

I look forward to seeing you at BSI next week.

Best regards,

Wolfgang

(See attached file: CCSDS Candidate Monitored Data.xls)(See attached file:
Monitored Data Dictionary 01.doc)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS Candidate Monitored Data.xls
Type: application/msexcel
Size: 50688 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20101021/2237b228/CCSDSCandidateMonitoredData-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Monitored Data Dictionary 01.doc
Type: application/msword
Size: 430080 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20101021/2237b228/MonitoredDataDictionary01-0001.doc