The problem with this idea is the "identical" aspect of each redundancy. If it's identical, then it will likely suffer from the same failure mode at the same time as the others. In the case of the AoA freezing, that's exactly what happened.

A more robust idea is to have three redundant subsystems, each different.

Yeah, but I get the feeling that it's more of a way to ensure that you probably get at least two components that will 'burn in' well and hopefully not fail too early:

https://en.wikipedia.org/wiki/Bathtub_curve

Like, you don't expect them to last forever, but you do expect at least 2/3 to meet their lifetime estimates.

I once had a discussion with a scifi author about how to design a starship to last a long time. I suggested that it being repairable would be of paramount importance. To that end, the various systems should use interchangeable parts. Starting with the obvious like nuts&bolts should be standardized, extend that to things like computer boards and components, motors, etc.

For example, if you had a linux machine running the fusion drive, and a mac machine running the entertainment arcade, and the linux machine shorted out, it would sure suck if you couldn't cannibalize the entertainment arcade computer to fix it.

It goes back to Apollo 13, where the CO2 scrubbers on the command module were a different design than the ones on the lunar module, which inhibited them being able to refresh the ones on the lem, and nearly caused loss of the crew.

It's the same for software. Software that's supposed to be used "forever" should be written such that parts of it can be easily replaced. Highly flexible designs often lose against simpler designs because it's easier to rewrite the latter and very hard to change something when you bump against the limits of flexibility in the former.

I had a similar discussion once, and the result was very biology cells inspired. Any subsystem must be able to repair itself, and must state its defunct state on repair needed state. If that times out the subsystem must destroy itself "deactivation". Dependant on importance other subsystems must pick up the load and create a replacement under strain over time.

In a plane, the aoa could be replaced by sensor fusion of gyroscopic sensors and air density sensors distributed over the hull.

Selfrepairing could be a achieved via a reservoir of peeble like standardized spare parts traveling through a conduit and applied via vibration and standardized interfaces. Final fallback, a simulation of expected circumstances, suggesting a half way accurate fallback model.

The difference with a plane, however, is it isn't necessary to fix it. It's just necessary to get it on the ground safely.

I don't think it's so much about the lifetime of the component, or whether it eventually fails due to faulty manufacturing or gradual wear and tear. (What the bathtub curve gets at.)

It's that if you do make parts that are identical, and you expose them to identical unanticipated circumstances, they're likely to behave identically, and fail identically.

I've seen this w/ distributed databases. I overloaded a Cassandra instance once, causing it to OOM. That node failed, but it's distributed, so another node automatically took over, ran the same query, and OOMed, and then the last guy took the query, and very quickly I had 3 dead nodes.

This is especially true with software. Having identical software in the backup means it'll seg fault too.

That's science fiction, not science. Clarke used three to push your brain past our sense of left/right symmetry not because of some idea related to redundancy.