By Evan

Guidance, Navigation, and Control (GNC) software has a uniquely unforgiving failure profile. There's no graceful degradation when your state estimator feeds corrupted quaternion data to the control law at 10 kilometers per second. There's no rollback when your thruster firing sequence overflows an integer during terminal descent. The software either works, or you lose the mission.
This isn't hypothetical. The history of spaceflight has no shortage of hundred-million dollar lessons in what happens when flight software hits edge cases no reviewer thought to test.
Ariane 5 Flight 501 — June 4, 1996
Forty seconds after liftoff, the maiden flight of Europe's most powerful rocket ended in a fireball over French Guiana. The root cause: a 64-bit floating-point value representing horizontal velocity was cast to a 16-bit signed integer. The value overflowed. The SRI software had been inherited from Ariane 4, where horizontal velocity never exceeded the 16-bit range. Ariane 5's faster trajectory did. The overflow shut down the active SRI. The backup — running identical software — had already failed 72 milliseconds earlier for the same reason. With both inertial reference units offline, the flight computer fed raw diagnostic data to the nozzle actuators. The rocket veered 90 degrees off course and self-destructed. The cost was approximately $370 million in payload alone.

Ariane 5 Flight 501 self-destructs 40 seconds after liftoff (ESA)
Mars Polar Lander — December 3, 1999
NASA's Mars Polar Lander was designed to touch down near Mars' south pole. During descent, touchdown sensors on the landing legs generated spurious signals when the legs deployed. The software interpreted the vibrations as surface contact and shut down the descent engines at roughly 40 meters altitude. The lander hit Mars at about 50 miles per hour. No software requirement existed to filter false signals, and a wiring error during testing masked the flaw entirely.

Mars Polar Lander (NASA)
Beresheet — April 11, 2019
SpaceIL's Beresheet was attempting to become the first privately funded spacecraft to land on the Moon. During final lunar descent, a software command reset the inertial measurement unit, triggering a chain of errors in the main engine control logic. The engine shut down during braking. Beresheet impacted the lunar surface at over 3,000 km/h. The failure traced back to an unintended interaction between fault handling and engine restart sequences.

Beresheet spacecraft during pre-flight prep (IAI)
Notice what these have in common. None were algorithmic errors. Nobody got the orbital mechanics wrong or designed a flawed control law. They were mechanical software bugs: an unprotected type conversion, a missing input filter, an unhandled state transition. The kind that live in the seams between subsystems, survive code reviews, pass unit tests, and activate at the worst possible moment.
These aren't the bugs your linter catches. They hide in the gap between what the language permits and what the physics demands.
NaN propagation: A single NaN introduced anywhere in a Kalman filter propagates silently through every downstream computation. In C/C++, there's no compile-time guarantee you're checking for NaN at every interface boundary. In practice, you don't. The NaN reaches the control law, produces nonsensical thruster commands, and by the time telemetry reveals the problem (if it does at all) the vehicle is unrecoverable.
Integer overflow and wraparound: Angle computations in GNC code frequently operate near wraparound boundaries (e.g. 0°/360°, ±180°, ±π). A single unchecked integer cast can invert a steering command. This is exactly what destroyed Ariane 5: a value that was perfectly safe on one vehicle exceeded the representable range on another, and the language made it trivially easy to ignore.
Uninitialized or stale state: A sensor driver that misses an update cycle. A mode flag that isn't cleared on transition. In C, reading uninitialized memory is undefined behavior, meaning the compiler is free to generate code that works in testing and fails in flight. This has been directly implicated in mission anomalies.
Data races in concurrent systems: Modern GNC architectures run sensor acquisition, state estimation, control law execution, and health monitoring as concurrent tasks sharing state. A variable written by the estimator and read by the controller without synchronization produces control commands based on a physically impossible vehicle state. In C/C++, this is managed through developer discipline and code review. It's not enforced by the compiler.
Rust's value proposition for GNC isn't syntax preferences. It's about the compiler's default posture toward the exact categories of bugs that end missions.

The point isn't making it harder to write bugs. It's making entire classes of bugs unrepresentable. The compiler rejects programs that contain data races, use-after-free, or uninitialized reads. Not with warnings. With hard errors.
Consider Ariane 5. In Rust, that 64-bit to 16-bit conversion requires an explicit checked conversion the compiler forces you to handle:
let bh_64: f64 = compute_horizontal_bias(velocity);
// Checked conversion — compiler forces you to handle the overflow
let bh_16: i16 = match i16::try_from(bh_64 as i64) {
Ok(v) => v,
Err(_) => {
trigger_safe_mode();
return Err(GncError::SensorOverflow);
}
};
The silent, catastrophic overflow that destroyed a $370M rocket becomes a handled error case.
For concurrency, Rust's ownership model makes data races a compile-time error. Share a mutable reference across threads without synchronization, and the program won't compile. You don't find the race condition during a 3 AM anomaly review. You find it when you build.
A common objection to Rust in safety-critical contexts is performance overhead. GNC software runs on deterministic real-time schedules. For example, a control law that misses its 100 Hz deadline is a failure mode regardless of correctness. Rust's safety guarantees sidestep this entirely because they're enforced at compile time, not runtime. The ownership model, borrow checker, and lifetime system don't exist in the generated binary. The resulting code is as fast as equivalent C, and often identical at the assembly level. There's no garbage collector, no runtime, no hidden allocation. Rust's no_std mode targets bare-metal embedded systems with full safety guarantees and a binary that starts at a few kilobytes.
The other historical barrier has been certification. For GNC software to fly on any certified vehicle, the toolchain matters as much as the code. A compiler that hasn't been qualified under DO-178C, ISO 26262, or IEC 61508 is a non-starter. That barrier is falling fast. Ferrous Systems' Ferrocene compiler achieved TÜV SÜD qualification under ISO 26262 at ASIL D and IEC 61508 in 2023, becoming the first qualified Rust compiler for safety-critical development. By late 2025, Ferrocene achieved IEC 61508 SIL 2 certification for a subset of the Rust core library, and DO-178C aerospace qualification is actively in progress. For NewSpace companies building under launch-specific safety regimes or non-crewed vehicles, Rust is viable today.
The embedded Rust ecosystem has reached an inflection point. N7 Space uses Rust in aerospace software components. Parallel Systems runs it on autonomous rail vehicles. Fusion Engineering uses it for drone flight controllers. Multiple satellite companies such as Gama Space use Rust for flight software.
The policy signal from the U.S. government is equally clear. The NSA, CISA, and the White House have all issued guidance urging a shift to memory-safe languages, with the White House's 2024 report explicitly naming Rust. DARPA went further with its TRACTOR program, funding automated translation of legacy C codebases to Rust across DoD systems. For aerospace and defense firms, this isn't background noise, but a critical procurement signal. Companies building flight software, embedded systems, or safety-critical code for defense programs should expect memory safety to become a contractual expectation, not a technical preference in the near future.
NewSpace companies are already listing Rust as a desired or required skill for GNC and flight software roles. This is a practical response to the reality that the bugs Rust prevents are the bugs that cause launch failures, and that the organizations buying flight software are starting to demand the languages that prevent them.
This is exactly why Stella, Navier's GNC agent, is designed for Rust natively.
Most GNC teams that want to use Rust face a significant 0-to-1 barrier. Standing up a Rust-based GNC development environment from scratch — configuring toolchains, writing boilerplate for state estimation and control architectures, building simulation harnesses, setting up concurrent task structures — can take weeks before anyone writes a single guidance algorithm. Stella removes that barrier entirely. Engineers start with a fully configured simulation environment and have GNC models running in under an hour, not months.
Inside Stella, those models don't stay confined to simulation. Control laws, autonomy behaviors, and maneuver logic developed in Stella's simulated environment compile directly into Rust-based flight software. No model-to-flight translation gap. What's simulated is what flies. The traditional handoff from MATLAB or Simulink to a C reimplementation is completely eliminated. Engineers iterate on guidance algorithms, estimator tuning, and fault management logic inside the simulation environment, and the flight code that comes out the other side inherits Rust's compile-time safety guarantees automatically.
This results in a meaningful change in development velocity. No separate V&V cycle to hunt down memory bugs that a better toolchain would have prevented. No manual reimplementation where context degrades and assumptions drift. GNC teams should be spending their time on the actual hard problems, not hunting bugs that a better language and a better toolchain would have prevented. Stella exists to make that tradeoff unnecessary. Rust eliminates the bugs. Stella eliminates the barrier to using it.
Ready to experience Agent-Driven GNC Engineering with Stella?
Learn more about Navier's Stella platform or contact us to see how we can transform your GNC workflows.