FCC-Dynamics-C

Appearance

Plant-Controller-Runner (PCR) Configuration Architecture ​

1. The Core Philosophy: Real-World Mapping ​

In advanced aerospace SIL (Software-in-the-Loop) and HIL (Hardware-in-the-Loop) simulations, a common anti-pattern is coupling the physical properties of the vehicle (the "Plant") with the flight software configuration (the "Controller"). This makes it impossible to run the physics simulation on one machine while deploying the control software onto a real flight computer.

To resolve this, FCC-Dynamics-C adopts a strict "Plant-Controller-Runner" architectural pattern for all configuration files. This perfectly mirrors reality:

  • Hardware Engineers build the rocket, install the engines, and mount the avionics boxes (The Plant).
  • Software Engineers flash compiled code and control parameters into the avionics box (The Controller).
  • Test Conductors decide whether to run a full computer simulation or plug the real avionics box into a hardware testbed (The Runner).

2. Directory Structure ​

The data/input/ directory is strictly partitioned into three distinct domains:

text
data/input/
├── world/                       # Truth: The Environment
│   ├── earth.yaml
│   └── atmosphere.csv
│
├── rocket_v1/                   # Truth: The Physical Asset (Plant)
│   ├── rocket.yaml              # Entry point (Mass, Aero, Devices)
│   ├── devices.yaml             # Engine truths, sensor noise, bus topology
│   ├── aero/                    # Physical wind-tunnel/CFD tables
│   ├── mass/                    # True mass and inertia tables
│   └── engine/                  # True engine thrust and flow rate tables
│
├── fcc_v1/                      # Flight Software: The Controller
│   ├── fcc.yaml                 # Entry point (Algorithm switches, rates)
│   ├── control.yaml             # PID gains, filter coefficients
│   ├── guidance.yaml            # Guidance targets
│   ├── program_att/             # Programmed attitude curves
│   └── schedule.yaml            # Flight event sequencing (Staging, Cutoff)
│
└── sim/                         # Execution Context: The Runner
    ├── run_all_in_one.yaml      # Monolithic SIL (Memory Bus)
    ├── run_dyn_only.yaml        # HIL Physics Node (UDP Server)
    └── run_fcc_only.yaml        # HIL Flight Computer Node (UDP Client)

3. Detailed Domain Rules ​

3.1 The Plant (rocket_v1/ and world/) ​

This domain represents the "God's Eye View" of reality.

  • Rule 1: It must only contain objective physical properties.
  • Rule 2: It contains the true hardware specifications. For example, devices.yaml defines the Engine's actual thrust curve (including real-world degradation or manufacturing offsets) and the IMU's actual noise characteristics.
  • Rule 3: It treats the FCC purely as a physical metal box with mass, a mounting location, and a bus socket. It knows nothing about the software running inside it.
  • Assetization: Because the Plant is fully decoupled, you can swap rocket_v1 to rocket_v2 without touching the FCC software. If you reuse the same engine on a second stage, you simply reference the same devices.yaml block.

3.2 The Controller (fcc_v1/) ​

This domain represents the Flight Software (FSW) burned into the computer.

  • Rule 1: It must never include raw physical look-up tables (like aerodynamics). The flight computer does not have the memory or need for a 100MB CFD table.
  • Rule 2: It contains the FCC's "Worldview". If the FCC needs to know the rocket's mass for a feed-forward control loop, it uses a Nominal Mass defined here, not the True Mass from the Plant (which the FCC cannot perfectly know in reality).
  • Rule 3: It contains all Guidance, Navigation, and Control (GNC) parameters: PIDs, programmed pitch curves, and state machine schedules.

3.3 The Runner (sim/) ​

This domain glues the system together based on the deployment target. It leverages the Free Monad Interpreter pattern of the codebase.

  • Monolithic SIL: The runner configuration instructs the main() function to instantiate both the Dynamics RWS pipeline and the FCC Free Monad, wiring them together via a virtual memory bus.
  • Distributed HIL:
    • On the physics machine, the runner loads only world/ and rocket_v1/, spins up a UDP socket, and waits for actuator commands.
    • On the RTOS flight computer, the runner loads only fcc_v1/, listens to the UDP socket for sensor data, and executes the control loop.

4. Alignment with C-Distillation ​

This configuration architecture is a prerequisite for the project's ultimate goal: C-Distillation. When the FCC codebase is distilled to bare-metal MISRA C for production, it will only carry the minimal byte-arrays compiled from fcc_v1/. The massive physics assets in rocket_v1/ will safely remain strictly within the C++ simulation environment.