Multi mission repo recommendations

[jechiasson]

Hi John and team,

We plan to use NOS3 across several missions and hardware configurations. Are there any recommendations for a repo configuration that combines NOS3 with custom mission FSW apps (and potentially GSW configs)? Ideally we will keep the NOS3 repo unchanged so that update pulls don't require merges. Each mission could potentially use different FSW / GSW.

Thanks,
John

[jlucas9]

Hi @jechiasson,
In the past we've tried to manage multiple missions in a single repository from NOS3. This was back in 2019 or so. About halfway through that experience we decided we needed to split into various repos due to the large amount of different components and configurations between them. This has driven a lot of the change seen in the past couple years to include everything you need together in a single component submodule (FSW, GSW, Support, and Sim) as well as enable spacecraft configuration XML files.

If I were to do it again today with the improvements mentioned above - assuming these missions are a true baseline that builds over time or is consistent between them - I'd go with a single repo and make individual components for each payload to be supported and different spacecraft configurations for each. This will still look a little sloppy in git if you're doing changes on different spacecraft at the same time, but will enable an immediate difference check between them which I'd say is worth it.

Note that for either setup you'll want to create a fork of NOS3 and of any submodules you may want to change into your own space and update the submodule URLs to that new location. As you go through this process and have any other questions or recommendations to improve the repository layout, workflow, etc. please let us know and we'll see what we can knock out for you!

Thanks and have a great day,
John

[jechiasson]

Hi @jlucas9 ,

Very helpful, thanks. Appreciate the historical view of the decisions leading to the current architecture and your advice on a path forward.
Now the current decision debate is cFS vs. Fprime. Any feedback there from your perspective? I have noted that CCSDS support is still in development, and at this stage in mission development we still don't have any SDK's from ground station providers to narrow down the packet formats.

Best,
John

[jlucas9]

That seems to just be a personal preference of the team. I've used cFS a lot so I lean that way as it's familiar. NOS3 will hopefully enable you to try both out. Also note that F' does have fantastic standalone tutorials as well. My experience with F' is very limited, but some members of the NOS3 development team have certainly been trying it out (@zlynch2 / @rjbrown2 / @kevincbruce).

We're doing an initial set of scenarios using cFS and COSMOS that should demonstrate use cases for that configuration at least and hope to expand that to various other configurations over time as well. Let us know if you have any further questions and have a great day!

[zlynch2]

Yes, Fprime is fairly new to NOS3 and is actively being developed. Currently, NOS3 has integrated the basic functionality of most of our generic components. We are still actively developing our fprime side of fsw for a more robust simulation environment with fprime. However, Fprime is fairly well documented with examples and is very active in their discussion boards.

There is a unique FPP language they developed to help with the backend in fprime building/generation but the fprime teams goal was to provide a fsw framework that handles most of the work in fsw for you. there are many modules that can assist you already created out of the box with fprime with you fprime development, like schedulers, packet framing, etc. However some modification may be needed for your application. You are correct though CCSDS compliance looks to be in the works with Fprime.

The "components" in fprime world are written in cpp which is similar to cFS. You'll notice how we are integrating fprime is taking some of our c/cpp fidelity from our NOS3 components and essentially reusing it with fprime. For now this is our proof of concept.

From a nos3 perspective, I think fprime is great to get up and running quickly, Fprime even comes with its own Fprime GDS that allows you to test the fsw quick as you develop. But again they handle a lot of the integration of your fsw for you with auto-generated code when building.

cFS on the other hand, we definitely have more experience with and our nos3 environment is more robust because of this. I hope this blurb helps provide some insight with our initial experience with fprime.

[jechiasson]

Thanks for all the great feedback! Due to schedule pressures, we're looking at cFS and Cosmos currently. I've managed to fork the repo to our gitlab server, and we have a deployment server set up with our flatsat. There will be multiple users operating the sim for testing, so that leads to a question of workflow. How to best set up user accounts for operation and test? Our developer accounts are tied to an Active Directory Azure instance and will not be available for anyone but the account holder. Would it be best practice to set up a "nos3-user" local only account on the Ubuntu 22.04 server? Any implications for deploying changes and/or debugging?

[Isgaroth-the-Green]

Are you going to be running NOS3 on the cloud or locally? If locally, that sounds very similar to how we run - locally, on a VM with a local user. If on the cloud (or remotely otherwise), how do you expect to connect?

[jechiasson]

Locally. Some of the developers are remote and connect via vpn. I looked into the vagrants vm setup, and see the jstar user setup. I'll give that a try on our server. I have a few thoughts about multiple sets of the docker containers running and port conflicts. Any ideas there? Aside from everyone developing in a vm that is.

[kevincbruce]

Everything container-wise is generally done with hostnames and dynamic allocation to avoid ip conflicts in the docker network, if I recall correctly. I know we have done multiple spacecraft on one server/VM before. Just not sure if we've had multiple GSW interfaces and completely separately controlled craft on one server

[Isgaroth-the-Green]

Because Docker uses DNS names instead of IP addresses, I think it should be fairly workable to have multiple sets of containers; they will need differing names, but that should be fairly doable in the launch scripts (sc_1_ could be replaced with sc_2_ or such). We have had some trouble in the past trying to get multiple different spacecraft to communicate with each other, but if you are intending everyone to develop on the same server but will not need the different spacecraft to communicate with each other, I think that should be achievable with only some changes to the launch scripts. I believe we have had multiple GSW interfaces on one server, though that was not recent.

[jechiasson]

Great. That makes sense and should be an easy change.

…

On Fri, Apr 25, 2025 at 9:20 AM Isgaroth-the-Green ***@***.***> wrote: Because Docker uses DNS names instead of IP addresses, I think it should be fairly workable to have multiple sets of containers; they will need differing names, but that should be fairly doable in the launch scripts (sc_1_ could be replaced with sc_2_ or such). We have had the most trouble in the past trying to get the different spacecraft to communicate with each other, but if you are intending everyone to develop on the same server but will not need the different spacecraft to communicate with each other, I think that should be achievable with only some changes to the launch scripts. — Reply to this email directly, view it on GitHub <#648 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHR3E4WJTZY7RIG3PYUJIP323JAELAVCNFSM6AAAAAB3LJAJ72VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJUHAYDQOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>