Twenty-nine crates of Rust for flight dynamics, guidance, avionics buses, hypersonic CFD, structural coverage and a partitioned RTOS. No Designated Engineering Representative has reviewed it. No authority has approved it. Every DAL-A label in the workspace is self-assessed against a threshold the project defined itself. The status section names the files.
That is the loop most flight-control programmes are in. The model is in a language you licence, the artefact is generated C you did not write, and the qualification argument covers the generator rather than the code.
| Stack | Scope | Language | Source you can read | On the embedded target |
|---|---|---|---|---|
| MATLAB / Simulink + Embedded Coder | Model plus generated code | MATLAB, generated C | Generated output only | Through the generated C |
| JSBSim | Flight dynamics only | C++ | Open | Host |
| FlightGear / X-Plane plugins | Simulator plus plugin | C++ | Partly | Host |
| Bespoke C++ or Ada stack | Whatever you wrote | C++, Ada | Yours | Yes |
| OxiAero | Dynamics, GNC, avionics, CFD, coverage, RTOS | Rust | Licensed source | ARM Cortex-R, PowerPC, RISC-V targeted — see status |
The last cell links to the status section on purpose. oxiaero-rtos is written for ARM Cortex-R, PowerPC and RISC-V as a VxWorks or LynxOS replacement, and the partition-switch cache-flush sequence that backs spatial isolation currently executes real instructions on x86_64 only. That is stated in the repository README as well as here.
Everything in this section has a file behind it that you can open during an evaluation. The section after it is the other list.
Every aerospace supplier ships a certification story you cannot check. This is ours, and it is the same list that appears in the repository README, by file, so that you find it here rather than in week three of an evaluation.
Read the two GPU rows together. The wgpu compute shaders backing the sparse CG and BiCGSTAB linear solvers are real and tested. The distributed GPU and MPI layer for the Lattice-Boltzmann solver is sizing and configuration types with no kernel execution. Anyone writing "GPU-accelerated CFD" without splitting those two is describing something that does not exist.
The ARM backend is a nop. We are telling you before you find it.
The other products in this ecosystem close this page with a stack tree — a numerics floor we rebuilt over nine years before we built on it. OxiAero does not have one. It does not use SciRS2. The two ecosystem numerics crates named in its manifest are not in its lock file. The linear algebra, the atmosphere models, the CFD solvers, the orbital propagators and the bus stacks were all written in this workspace, from the standards and from the literature.
What it has instead is a different kind of provenance, and for this buyer it is the more useful kind. Every aerospace tool you can purchase arrives with a certification narrative you are not in a position to verify. This one arrives with its gaps written into the README by file and by line: which MC/DC path reads real DWARF and which is a probe model, which cache-flush backend issues instructions and which issues a nop, which hypersonic constant is transcribed from NASA RP-1232 and which is an approximation still waiting for a source. A supplier who volunteers that is telling you the truth about the rest of it. That is the claim, and it is the only one we are making.
The same discipline explains the two optional features. gpu links CUDA. gazebo-harmonic links C++. Both are off, and nothing in the core, avionics, FDIR, flight-control or RTOS crates can enable them. We could have taken those dependencies quietly, the way the rest of the industry does. Gating them means the default build — the one you would qualify — has no foreign toolchain in it at all, and turning one on is a decision that appears in your Cargo.toml where a reviewer will see it.
Most of the ecosystem is public on GitHub under Apache-2.0. The aerospace workspace, and the evidence it generates, is the part we licence.
The useful opening message is not a requirements list. It is the one thing on the status section above that would stop your programme — the nop on ARM, the LLVM probe model, the absent DER. Tell us which, and you will get a straight answer about whether it is on the roadmap, how long it takes, and what it costs, within one business day. If the answer is that you should buy a certified stack, we will say that.