Convert Fprime GDS to using YAMCS

[gcgandhi]

Convert Fprime GDS to using YAMCS (https://yamcs.org). YAMCS has been used on NASA projects already and by other aerospace companies.

[celskeggs]

I really appreciate F Prime GDS because it is simple and hackable. I haven't looked at YAMCS much, but it seems to be a Java application... "Java" does not scream "simple and hackable" to me. Does anyone have experience modding YAMCS who could chime in with their experiences?

To give a specific example, my team was able to slap together a F Prime GDS plugin to support a totally new interface (SEGGER RTT) in less than 200 lines of Python code: https://github.com/fprime-community/fprime-vorago/blob/main/Va416x0/Drv/SeggerByteStream/gds_plugin.py. I'd like to make sure we maintain the current level of modifiability, even if we move to an alternative.

[thomas-bc]

For your specific use case (new adapter interface), it is in the category of things that are configured in the YAMCS config files (see Data Links config) and you can provide your own class. So your plugin would look very similar, as far as I can tell.
My understanding is a lot of what we would typically care about can be configured that way.

[timcanham]

NASA IV&V allegedly did a pilot where they got the F Prime reference app running with YAMCS. Maybe somebody has a reference?

[zlynch2]

NASA IV&V allegedly did a pilot where they got the F Prime reference app running with YAMCS. Maybe somebody has a reference?

Yes I was the developer on that, there is a basic example using a python layer in between fprime and yamcs. By hooking into the fprime data network and modifying data around. Its basic but works and can be developed basically making a translation table between yamcs cmd/tlm definitions with NOS3 (https://github.com/nasa/nos3)

the example was proved out with fprime version 3.6.3 and nos3 version 1.7.2 or 3. (nasa/nos3#428)
Basically utilizing our sample component in our NOS3 Digital Twin Simulator to command from yamcs and translate a request HK command to fprime on the network.

Let me know if you have any more questions

[thomas-bc]

I very much support having support for YAMCS "out-of-the-box". That does not need to mean the F Prime GDS goes away

My understanding is YAMCS is also highly configurable. https://docs.yamcs.org/yamcs-server-manual/yamcs-plugin-format/

I have done a little bit of research to see what we would need to support running F´ <-> YAMCS (direct connection, no middleware). We would need three things at first:

• autocode an XTCE dictionary describing our data formats. This is akin to our dictionary.json
• install a sample yamcs.yml config. We can provide a default config that would make YAMCS connect to our default TCP/UDP setup, which would essentially be again very similar to how we use fprime-gds
• install a few Java plugins to e.g. publish events as YAMCS events, maybe others

I have experimented a little bit and was able to get a direct FPrime<->YAMCS connection and was able to send commands, receive telem channels and events (very much of a prototype, I handcoded an XTCE for a few items). For files, they support CFDP out of the box (https://docs.yamcs.org/yamcs-server-manual/services/instance/cfdp/)

[zlynch2]

Very interested in this, we created the "middleware" as seen by a comment above. But NOS3 could serve as a good resource to utlize if interested in testing/developing fprime with yamcs fully. (https://github.com/nasa/nos3)

Seeing as Yamcs and Fprime exist in one spot. Using a basic set of commands already defined with xtce definitions. you could see what needs to be processed on the fprime side. The comment above highlights the middleware work we did to connect yamcs and fprime.

[bevinduckett]

@celskeggs & I met with @LeStarch & @thomas-bc to discuss functionality that should be added to the fprime_test_api to better support integration testing. In that discussion, a significant gap identified in the current fprime GDS is that it has no data base back-end, all the events/telemetry/command records are in program memory.

1. This limits event & telemetry visibility to only what's happened since fprime_test_api was started for a given test file. (An issue in testbed environments where SW was started before a test was started and test code needs to verify the SW initialization complete event was received before doing any additional checks.)
2. For GDS sessions which produce a large amount of channel & event records, memory can be exhausted which could lead to it being dropped (good chance that that's the cause of the bugs in fprime_test_api (from fprime-gds repo) intermittently fails to find events reported by fprime-gds logs #4706 & fprime_test_api: Continuing after a breakpoint from pdb.set_trace() results in event search failures #4707)

[celskeggs]

To clarify the implications of this: If YAMCS provides an efficient, versatile Python API to query its database for events and telemetry, adopting it could be a significant benefit for future FIT testing using F Prime.

[swanchr]

YAMCS has a solid Python API - I was able to easily build command and telemetry scripts.

My experience with the Fprime GDS and python scripting was not great. (perhaps my own fault... but YAMCS just worked)