01Executive summary
Three milestones in which software became the thing keeping a machine stable, and one standard written because that made software a structural safety concern.
The Airbus A320 entered service in 1988 with digital flight control and envelope protection, placing computation permanently between the pilot’s input and the control surfaces. IEC 61508 was published in 1998, giving a quantified framework for safety-related programmable systems. An orbital-class booster landed vertically under its own power in 2015, and a recovered booster was reflown in 2017. All three are aspects of the same shift: accepting an unstable or unmanageable plant because a controller can stabilise it.
02Fly-by-wire: what the computer is actually for
The obvious reading is that fly-by-wire replaces cables and pushrods with wires, saving weight. That is true and is the least interesting part. The significant change is that the pilot’s input stops being a direct command to a surface and becomes a request for a flight condition, which the control law then achieves.
Analogue fly-by-wire preceded this — Concorde flew with it, and military aircraft used it earlier. The 1988 milestone is the first civil airliner with digital flight control including full envelope protection, where the control law will not permit the aircraft to exceed defined limits regardless of what the pilot demands.
Relaxed static stability
A naturally stable aircraft resists departure from trim, which costs trim drag and control authority. A less stable design is more efficient and more responsive, and is flyable only because a controller corrects continuously.
Envelope protection
The control law bounds attitude, load factor and speed. Protection against stall and overstress becomes structural rather than dependent on pilot recognition under stress.
Software is now load-bearing
A control law defect is a structural failure mode. Development assurance, formal verification and rigorous configuration control move from good practice to certification requirement.
Mode confusion
The same input produces different behaviour depending on the active control law and the validity of sensor data. Several accidents involve crews acting correctly for a mode the aircraft was not in.
Duplicating identical computers protects against random hardware failure and not at all against a design error, because both copies will fail the same way on the same input. Flight control systems therefore use channels with different processors, different software developed by separate teams, and sometimes different requirements interpretations, cross-monitoring each other. Redundancy only helps against failures that are independent, and identical copies of a design have perfectly correlated design faults. This is worth stating explicitly because duplicating identical components and calling the result redundant is an extremely common error.
03Functional safety: making an argument that can be examined
By the 1990s programmable systems were performing safety functions across many industries, each with its own conventions and none with a common way of stating how much confidence was warranted. IEC 61508 provided a general framework, and sector standards for process, machinery, rail, automotive and medical devices derive from it.
- Hazard and risk analysisIdentify what can go wrong, its consequence and how often it might occur without protection.
- Allocate risk reductionDetermine how much reduction is required and what portion each protective layer must deliver.
- Assign integrity levelsExpress the required performance of each safety function as a safety integrity level, with a quantified target failure measure.
- Realise the functionDesign, implement and verify hardware and software to the rigour the assigned level demands.
- Operate and maintainProve-test at defined intervals, manage change, and monitor demand rates against the assumptions.
Components are frequently described as “SIL 3 rated” and specified on that basis. A safety integrity level applies to a safety function, which includes the sensor, the logic solver, the final element, the proof test regime and the operating environment. A device may be suitable for use in a function of a given level; it cannot itself be that level. Assembling certified components does not produce a compliant function, and this misunderstanding produces safety systems that carry a number without carrying the argument behind it.
04Propulsive landing: a control problem before it is a rocket problem
Recovering and reusing launch vehicle stages had been attempted before. The Space Shuttle was partially reusable, with solid boosters recovered from the sea and an orbiter that returned as a glider, though refurbishment cost proved far higher than intended. The 2015 milestone is specifically the vertical propulsive landing of an orbital-class first stage, and the reflight of a recovered booster in 2017.
The controls problem is unusually difficult for reasons that are easy to state.
| Difficulty | Mechanism |
|---|---|
| It cannot hover | Even at minimum throttle, thrust exceeds the weight of a nearly empty stage. The vehicle must arrive at zero velocity exactly at zero altitude; there is no opportunity to stop and correct. |
| It is inherently unstable | Thrust acts below the centre of mass on a slender body, which is the inverted pendulum problem. Without continuous active correction it tips over. |
| The plant changes rapidly | Mass, centre of mass and moment of inertia change quickly as propellant is consumed, so the controller must handle strongly time-varying dynamics. |
| It flies backwards through its own wake | Re-entry occurs base-first through disturbed air, with aerodynamic loads and heating in a regime that is difficult to characterise. |
| Every attempt is a full-scale test | There is no subscale rehearsal of the whole problem, so early attempts were flown as instrumented experiments after the primary mission was complete. |
Landing attempts were made after the paying mission had already been delivered. A failed landing cost the stage — which would have been discarded anyway — and produced data. This converted what would otherwise be a high-risk development programme into a series of free experiments. Finding a way to test a risky capability where failure costs little, rather than deferring the test until it must succeed, is one of the most valuable programme design moves available, and it applies far beyond aerospace.
The economic argument is worth stating carefully. Reuse reduces cost only if refurbishment, recovery operations and the performance sacrificed to reserve landing propellant together cost less than a new stage. The Shuttle demonstrated that reusability does not guarantee this. Whether and by how much the balance now favours reuse depends on flight rate and refurbishment cost, and figures in public circulation vary widely and are not all independent.
05Takeaways for current practice
- Duplicating identical units is not redundancy against design faults. Diversity is required where systematic failure dominates.
- Integrity levels attach to functions, not components. A certified device is suitable for use in a function; it is not itself a level.
- Check the proof test interval against the assumption. Claimed integrity depends on it directly, and it is the most commonly violated premise in a safety case.
- Accepting an unstable plant is a legitimate trade. It buys performance, and it makes the controller safety-critical — both halves must be acknowledged.
- Structure programmes so risky tests are cheap. Attempting the hard thing after the mission is already delivered turns development risk into free data.
Relevant references include IEC 61508 and its sector derivatives IEC 61511, IEC 62061, EN 50128 and ISO 26262, with AS/NZS adoptions where applicable, and DO-178C for airborne software. Cited by number for orientation only — verify currency.