[salawat]

>As a computer scientist, I'm not accustomed to thinking about functional equivalence in the presence of hardware failure...

How are you not?

I mean, I get it 90% of the time we screw up the programming somehow, but as a computer scientist, I never ignore the possibility of hardware failure. Memory goes bad. Devices fail. Networks die. Semiconductors transiently in strange ways if you don't take the right precautions...

It's the entire impetus behind GIGO. If you shove garbage into a perfectly working software system; (corrupt data from a malfunctioning input source), you still get out garbage.

It's why life and safety critical automation is so fundamentally different from lower stakes programming tasks where "reboot the damn thing" is a viable option.

If your sensor goes bad, and you're in the air, you can't do squat to fix it. You have to detect the error, and fail the system gracefully by taking it out of the loop, informing the operator of the system failure, and most importantly, never allow that system to do anything that could jeopardize the ability of the operator to continue operating.

This is or at least I thought it was basic Control Systems 101...

[Athas]

> How are you not?

I research compilers and type systems. If the RAM dies while the compiler is running, you rerun the compiler on a new machine. A lot of computer science abstracts away the notion of hardware failure, because otherwise it becomes enormously cumbersome to talk about anything. This is fine as long as you don't actually build real high-reliability systems with the same approach.

[acqq]

>> How are you not?

> I research compilers and type systems.

I hope it's obvious that the software you work on is not supposed to be run during the flight.

The critical software is supposed to do as little as possible, and everything is expected to be in already compiled (and thoroughly verified) state.

And even for the product of yours, as soon as it is not used only for the research but as a production compiler which produces a firmware for the plane, it would have to be proven much more than what is expected from it while it is just an artifact of a research.

In short, even if you are lucky to just do the research, you should be aware (and thankful) that the critical software has other expectations. Including how it responds to failed sensors: different response to the external inputs is a fundamentally different software, even if you never thought about it before.

[gknoy]

I think his main point was that for most of us, hardware failure is considered an adequate excuse for why something works -- most of us are not expected to have software that _continues working_ when things break.

[acqq]

The "failures" of the sensors are simply the "less common" inputs. The proper control software should simply be written for all possible inputs, which include inputs from faulty sensors, and the result of the processing should not have some catastrophic consequences.

Compare to the web app that awaits the username, but when the username is not the "most common" (e.g. contains some new unicode symbols, or is of zero lengh) it allows catastrophic security failure and intrusion.