Re-usable CCSDSpy packet definition

[tloubrieu-jpl]

Hi @ddasilva ,

I am starting a new thread to combine discussions started on discussion #120 and ticket #50

If we had a re-useable CCSDS packet definition as code, based on CCSDSpy packet definitions, we could share across mission softare to:

• parse the CCSDS packets (as currently done in https://github.com/nasa/pyDownlinkParser)
• generate documentation to be shared in the flight mission projects, across teams
• generate test files at the earliest stage of the mission projects (see ticket Add the ability to create simulated packets #50).

The would allows the missions to manage the CCSDS packets definitions as code, at the interface of the Instruments, Flight and the Ground Data Systems and teams. We would manage the packet definition centrally, e.g. on gitHub, in configuration, e.g. with PR, for better tracking and validation of the changes.

That would avoid the hassle of managing changes in different documents and disconnected pieces of software which currently represents a significant amount of work and risks in the mission systems integration.

So far, as an example, we are having a representation of the CCSDS packets definition used by Europa Clipper Science Data System available there:
https://github.com/nasa/pyDownlinkParser/tree/main/src/ccsds/packets/europa_clipper

We use these definitions to parse the downlinks for 3 instruments of the Europa-Clipper mission as part of the Science Data System. See discussion #120 to share the packet definitions as re-useable plugins.

If we can consolidate the representation of packet definitions across missions, that would ease the re-usability of the software around this packet definitions, as we already can do for parsing in application https://github.com/nasa/pyDownlinkParser.

We could use these CCSDS packet definitions to generate human readable documentations (pdf, html) to replace the manually edited documents maintained by the different instrument teams.

We could also generate test datasets automatically, as proposed in the work done by @ehsteve in ticket #50.

Thanks,

Thomas

[ddasilva]

I support this proposal, but want to know what @ehsteve thinks. We've gotten some criticism that defining packets in code is bad for the language interoperability, which we could potentially solve with a to_csv() method on packet definitions.

[tloubrieu-jpl]

Hi @ddasilva, I recently learn about the ipython rich display protocol, see https://ipython.readthedocs.io/en/stable/config/integrating.html#rich-display, that might help us here.

[ddasilva]

@jmbhughes would you participate in this system for PUNCH?

[jmbhughes]

I'd be interested. I'm not sure if it would make it into PUNCH since we're approaching launch, but I have some other work it could apply to.

[tloubrieu-jpl]

Hi @jmbhughes,

I am working on and off on that. But thanks for your interest.

Could you tell me what other work you were thinking of ? I am trying to put together interested people to see how this activity could be funded.

Thanks,

Thomas