What is the best practice for sharing mission-specific runtime parameters between multiple apps?

[irowebbn]

I work on a cFS distribution where we have the need for multiple apps to use the same mission-specific parameters. We intended to use a table to hold these values. As I understand it, if multiple apps were to register the same table, there would be multiple copies of the table in the Table Registry, each prepended with an app name, and subsequent updates to any of these tables would cause the copies to get out of sync. The solution to that problem is to use the CFE_TBL_Share API, but this seems to mean that a single app needs to be the "owner" or "originator" of the table.

In the case of our distribution, the data in the table isn't coupled to any one of the applications more than the others, so it seems weird to have to designate one as the owner of the table. One solution might be to have an app for the sole purpose of managing tables that multiple apps need. Are there any other approaches to this? Is there one that is preferred or established practice?

[irowebbn]

I've continued to dig around examples and documentation, but still haven't found a satisfactory answer.

[avan989]

I don’t have an “best practice” but just to throw an idea out there, why not use the software bus to control these parameters. Essentially all the applications subscribe to the same message that when received would update these parameter. That way no one application needs to own anything and it doesn’t matter if the ground system updates these parameter or any single app updates these parameter, everything would be kept in sync as long as they subscribe to this message.

[irowebbn]

Thanks for the suggestions. I'm not sure if this totally solves the problem though. The initial values still have to come from somewhere, and now you run the risk of apps having multiple different values for parameters if one app misses the message (due to the message queue being full, for example). And if the ground station isn't sending these commands, then one of the apps will still need to be responsible for managing the values, which doesn't always make sense if there isn't a clear primary/secondary hierarchy between the apps sharing the values.

ROS used to have something like this called Parameter server http://wiki.ros.org/Parameter%20Server, nowadays with ROS2 they just recommend having a dedicated node to manage shared parameters. I think that is where I am leaning towards -- one app that loads tables with config values shared between multiple apps, using the software bus (like you suggest) to communicate updates to consumer apps.

[irowebbn]

Our current workaround is to have each app load its own table, with entries that may duplicate that of other apps' tables. But we generate the tables ahead of time using our build tools so that the values always stay in sync. If, for some reason, we needed to swap tables during a mission, we would need to issue the same command to each app using a copy of the table.

[avan989]

That node server idea seems like a good approach. Another idea if you're worried about the individual app's not being in "sync" is maybe to implement a redundancy system where the app itself periodically sends a "request for parameter" to other apps, and the "parameters received" need to be in sync with "3???" other apps. How you would handle an out-of-sync case is up to the mission (maybe notify the ground command to resend the "updated parameter"...etc).

More upfront work but less managing all the different tables.