Runtime instantiation of topology

[zimri-leisher]

Hello,
I've been thinking recently about the feasibility of instantiating an fprime topology at runtime. New component instances, new connections, etc could be read from a json file at the start of the application.
While it goes against the design of the fpp modeling language, I don't see why this shouldn't be possible. You can already easily instantiate/connect components at runtime in arbitrary ways, although you might want an autocoder to help you do it.

This would be extremely useful in many different scenarios. It's primarily useful for how it would speed the development workflow up.
Pros:

• Change a text file and rerun the application, no compilation needed.
• You would only need one binary for different deployments!
• For OTA updates in space, you might be able to just upload a new topology file, saving valuable bandwidth.

Cons:

• If you can't load the config file for some reason (corruption, typo, etc), your binary is useless
• Need to distribute two files instead of one to run FSW

Any thoughts on this? Has this been tried before? Do you see any more pros/cons?

[SterlingPeet]

Hi @zimri-leisher ! I actually looked at this exact scenario in my proceedings paper published at SmallSat last year. The On-Mission Software Patching section under USE-CASE VIGNETTES is the section that touches on this concept.

In a nutshell, cFS does this by using a project-provided startup script to define the Apps the are loaded at startup. The mechanisms are a bit less complicated in cFS, because the message connectivity responsibility is offloaded from the main project description to the individual Apps. In cFS, the different apps are loaded, as specified in the startup scripts, from separate libraries on the storage media. They can even be unloaded and re-loaded on-demand from the ground operator.

At the time of writing, I had inquired about this possibility and received a verbal response that doing this sort of thing is certainly possible within F Prime, but the engineering required to do so was prohibitively expensive for the core team to achieve. Reconfiguration of topology was a topic that also came up, and would be quite costly from an engineering perspective. I would assume this sentiment holds, but I invite folks from JPL to correct me if that is not true.

Specifically about the upload bandwidth point: There are already two normal albeit under-emphasized methods to reduce the upload size.

• The first one is to simply create a binary patch and upload that, applying the patch on-orbit to the existing software binary.
• The second is to build the cmake targets as separate lib files, and only update the files that have changed.

The second approach is the one we used at GT while developing software for the VISORS mission. Effectively each component is sequestered into its own lib file.

Now for the juicy stuff: While I am not of the professional opinion that the F Prime core team should take on this responsibility, I personally find it intriguing. In particular a well thought-out approach to dynamically assembling a topology could open the door to a binary component "app store". The critical metadata is already there in the FPP files. A little bit of version and compatibility info added to that would let a developer/team build one core binary library per architecture, and then go off to build deployments by just defining a topology and generating the corresponding GDS dictionary.

I think the biggest technical challenge here is that you need most of an FPP interpreter to assemble the topology per spec, and that would be an alternate implementation [in C++] to the Scala implementation. Not ideal from a maintenance perspective. You might be able to get away with a partial implementation because it does not need to feed an autocoder, but you might be close enough that its really a whole implementation.

Anyway, if you embark on this particular journey, please reach out because I would be interested in seeing it succeed and I would love to think though the requirements to get it there.

[SterlingPeet]

Having slept on it, it occurred to me that if you have the json AST, it might not be so crazy to traverse it dynamically with topology setup code. That could dynamically instantiate and assemble as topology instead of auto-coded static topology assembly.

[zimri-leisher]

Excellent write up, good to hear that someone else was thinking about this. Yes, the JSON AST would probably be sufficient, no FPP parser needed. I may experiment with this in my free time, I'll let you know.