Flight Computers Role in Engine-Out Capability, Lessons from Starship Flight 12
- May 31, 2026
- CAVU Aerospace UK
When discussing engine-out capability, the focus is often placed on propulsion hardware. A launch vehicle loses an engine, the remaining engines continue firing, and the mission survives. While this description is technically correct, it overlooks the most important component of modern fault-tolerant flight systems: software.
The true enabler of engine-out capability is not the presence of extra engines but the ability of the vehicle’s avionics and guidance software to detect failures, evaluate their consequences, and continuously generate a new flight solution while the vehicle is moving at thousands of kilometers per hour.
Starship Flight 12 provided an excellent demonstration of this principle. After the loss of one Raptor engine during ascent, ship maintained stability and continued toward its planned trajectory. The event highlighted how modern launch vehicles increasingly rely on real-time computation and autonomous decision-making rather than purely mechanical redundancy.
The same philosophy could eventually transform satellite propulsion systems, enabling spacecraft to survive propulsion failures through software-driven reconfiguration rather than hardware replacement.
Sequence of an Engine Fail
A rocket follows a carefully planned trajectory generated before launch. Guidance algorithms continuously compare the actual vehicle state against this reference trajectory.
At every instant, the flight computer knows position, velocity, acceleration, attitude, angular rates, remaining propellant & engine performance. When all engines operate normally, the guidance system predicts where the vehicle should be seconds or minutes into the future and generates steering commands accordingly.
An engine failure immediately changes the physics of the vehicle. Suddenly total thrust decreases, vehicle acceleration changes, thrust becomes asymmetric, predicted future position changes, fuel consumption profile changes & arrival conditions at orbit insertion change. Without correction, the vehicle would gradually diverge from its intended trajectory. The challenge therefore is not simply replacing lost thrust. The challenge is recalculating the mission while it is already in progress.
Starship Flight 12: A Real-Time Re-planning Case
During Flight 12, one of Starship’s six Raptor engines shut down during ascent. From a software perspective, this transformed the mission into a real-time optimization problem. The avionics system had to answer several questions simultaneously:
- How much thrust has been lost?
- How does the loss affect future velocity?
- Can the mission still achieve its target conditions?
- How should the remaining engines be steered?
- How long should they continue burning?
- What changes are required to the guidance profile?
These calculations occur continuously and automatically. Rather than following a rigid pre-programmed sequence, modern flight computers operate as closed-loop control systems. They constantly measure the actual state of the vehicle and generate updated commands. As a result, the rocket is not merely executing a script. It is continuously solving a navigation and control problem.
The Role of Guidance Software
Guidance software determines where the vehicle should go. Navigation software determines where the vehicle actually is. Control software determines how to move the vehicle toward the desired state. Together, these systems form the Guidance, Navigation, and Control (GNC) architecture. When an engine failure occurs, navigation algorithms first identify that measured acceleration no longer matches expected acceleration. The guidance system then predicts the impact on future trajectory. A new trajectory solution is generated using the remaining propulsion capability. Finally, the control system computes the steering commands needed to achieve this updated solution. This process can occur many times per second. The result is a vehicle capable of adapting to changing conditions without human intervention.
Engine gimbaling is often cited as the reason Starship can tolerate engine failures. However, gimbaling is only an actuator. An actuator cannot decide how to solve a problem. The flight computer must first determine desired attitude, desired angular rates, desired acceleration, & desired trajectory corrections. Only then are gimbal commands generated.
In this sense, the engines are analogous to muscles, while the avionics and software function as the nervous system. Without the software layer, the remaining engines would have no way of knowing how to compensate for the failed engine. The remarkable achievement is therefore not the physical movement of the nozzles but the computation occurring behind the scenes.
Traditional satellites often treat propulsion failures as major mission risks because each thruster has a specific assigned function. Future spacecraft may adopt a more flexible architecture. Imagine a satellite equipped with twenty-four micro-thrusters, multiple electric propulsion units, distributed propellant feeds & high-performance flight computers.
If one thruster fails, the onboard software would detect the anomaly and automatically calculate a new control allocation strategy. Instead of commanding: Thruster A + Thruster B, the spacecraft might command: Thruster C + Thruster D + Thruster E to generate the same net force and torque. The spacecraft continues operating despite the hardware loss. This approach mirrors the philosophy demonstrated by Starship Flight 12.
Software-Defined Propulsion
The aerospace industry increasingly views propulsion systems as networks of controllable actuators rather than fixed-function hardware. In such systems Hardware provides available force, Software decides how force is used, guidance algorithms determine mission objectives & control allocation algorithms distribute commands among healthy actuators.
As onboard computing power continues to increase, future spacecraft may become capable of autonomous fault recovery, trajectory redesign, and propulsion reconfiguration without ground intervention. In this vision, propulsion resilience becomes primarily a software capability.
