How I Simulated cFS with NOS3

What NOS3 actually is

NOS3 is an open-source, Docker-based test bed that wraps cFS with:

-a 42 dynamics engine (orbit/attitude propagation)

-simulated hardware components (sensors, radios, etc.)

-ground software (COSMOS / YAMCS) for commanding and telemetry

It's built so you can develop and test flight software against a virtual spacecraft before any hardware exists.

Prerequisites

• Linux host (or a VM) with Docker installed
• Git

That's the whole list — NOS3 ships a prebuilt Docker image (ivvitc/nos3-64) with the cFS build toolchain, simulator libraries, and ground software dependencies already baked in, so there's no manual cFS environment setup.

Install

git clone https://github.com/nasa/nos3
cd nos3
git submodule update --init --recursive

Then let NOS3 prep itself — this pulls the Docker container and builds the 42 dynamics engine:

make prep

This creates a user directory at ~/.nos3 and can optionally launch the Igniter GUI, which lets you pick which components/apps go into your spacecraft config instead of hand-editing XML.

First launch

make launch

If it comes up clean you should get a handful of terminal windows: the cFS flight software console (sc_1), the simulator processes, and a ground system (COSMOS or YAMCS depending on your config) ready to connect.

From the ground system, sending a NOOP command to a sample app and watching CMD_COUNT tick up is the "hello world" of cFS — it doesn't do anything visible, it just proves the app is alive and listening on the software bus.

[drop your terminal screenshot / packet viewer screenshot here]

What I learned

1. NOS3 front-loads all the pain into make prep — once that succeeds, make launch is genuinely one command.
2. A NOOP command with no visible effect is expected — cFS apps use it purely as a liveness check.
3. Igniter is worth using early instead of hand-editing the mission/spacecraft XML configs.

Next note: sending a real command to a simulated component and watching telemetry change in the packet viewer.