CDM Non-Standard Additional Parameters

Orekit development
1

Hi,

Is anyone opposed to me removing key value pairs from CdmParser that aren’t mentioned in any published CCSDS CDM standard? I’d like to make it match the blue book a little closer.

While I was working on the CCSDS parsers, I noticed that the CDM parser can parse many additional parameters that are not in any published CCSDS CDM standard that I can find. The CDM parser supports all of the OCM physical parameters, plus many more that don’t seem to be mentioned in any standard.

In the code at [1] I saw a reference to pink book CCSDS 508.0-P-1.0.2. Perhaps that means that CCSDS was considering adding these parameters, but ultimately decided not to? I couldn’t find a copy of that pink book.

The latest CCSDS blue book lists only 8 additional parameters on page 3-9 of [2].

The original MR at [1] is to address issue #940. It involved Giuseppe Cavallaro, @MaximeJ, and @Serrof. Maybe you know why it was originally added or if it’s OK to remove?

Regards,
Evan

[1] Fix Issue #940: Erroneous check when parsing CDMs (!280) · Merge requests · Orekit / Orekit · GitLab

[2] CCSDS.org - Blue Books: Recommended Standards

2

Hi @evan.ward !

What parameters do you want to remove for CDM?

Maybe the pinkbook used was this one: https://ccsds.org/wp-content/uploads/gravity_forms/9-6f599803174a64f5da08b9814720b5c4/2025/02/508x0p11.pdf

Thank you

Bryan

3

Hi @evan.ward,

I remember parsing elements that were in the draft release of CDM (pink book) was a request since some providers released CDM that were following the new unofficial standard.
And we decided it would be good that Orekit could parse them or at least do not throw an exception.
I have found the related discussion, I think it is this one: Suspected bug in CDM parsing.
As to whether or not we should remove these additional parameters and stick to the blue book I don’t know. I almost never use parse CDMs. But I guess if we had to add them in the past we should probably keep them ?

Regards,
Maxime

4

Ah, that makes sense. I’m glad I asked then. Yes let’s keep them if some CDM providers are using them. And I didn’t realize that these parameters were included in new pink books for the CDM format.

Regards,
Evan

1 Like
5

In my experience many providers add many attributes to CCSDS Messages (CDM, TDM, O*M) and then claim to be CCSDS “inspired” or even CCSDS compliant which causes problems using the OREKIT libraries and even worse, using standards based (XML) parsers.

Putting aside questions on how the CCSDS standard should evolve more dynamically, I would suggest that being able to ensure OREKIT can ensure compliant I/O is crucial, rather than promulgating non-standard standards; but then I would suggest that being flexible is highly desirable to be able to use the libraries in practice (without pre/post processing).

For flexibility overall I would recommend

  1. Holding non-compliant values in a key-value maps for each section, and including the ability to report on and enforce compliance of files in and out.
  2. Supporting multiple CCSDS versions concurrently
  3. Ensuring comments are easily managed as they are often used as an extensibility vehicle whilst remaining syntactically, if not semantically compliant
  4. Considering handling ill-placed comments on read

I realise this opinion extends beyond the scope of your question and that it is already marked as solved, and that OREKIT can already so some of this, but I hope some views from the coal-face are constructive.

1 Like