Looking at that not from the pilots perspective but as someone who has to design and implement such computerised control systems it would seem to be a nearly impossible task. Even with today's advances in computing, you have to specify things in black and white, go/nogo, binary type decision trees at the lowest level.
So what criteria could you use to let the automation decide you were on the ground?
I can't find the diagram right now, but has been linked to the thread: the decision of whether or not to allow ground spoilers and wheel breakes is exactly such a binary decision as you describe it. However, it's an
inhibiting decision, if I read the diagram right: wait for all those binary factors to go TRUE before allowing the breaks system. In Warsaw, the missing factor was the 2nd sqat switch, here, it might have been the TLA of more than 22.5° (still no factual data
afaik).
I think the "red button" suggestion was more along the line of "no matter what you (the airplane) think you should do, give me full manual control, i.E. let me manually deploy the spoilers. I understand that wheelbreakes override with the tip breakes.
RA? not accurate enough. Wheel spin up to a certain speed? No good if aquaplaning. MLG compressed? Both or one? That's why AB does the partial spoiler extension to dump lift and get both MLG compressed - but that is itself switched out if one of the TLs is not at idle. Here we go round the loop again.
Yes, and it's what might have happened here. If the logical formula for breaking is somewhere along the lines of
(BREAKES_ARMED AND WHEELS_SPINNING AND SQUAT_SWITCHES_DEPRESSED AND TLA<22.5°) (there were more factors) then one of the input factors being "FALSE" makes the whole expression false and thus does not allow breaking action? How about adding a OR OVERRIDE_BUTTON_PRESSED for the situations where the pilots have no clue what prevents the system from evaluating this expression to true but from their human, analog point of view, they've clearly touched down, want breaking action and have only limited runway left.
Wht I am trying to say is that a lot of thought already seems to have been put in to the area of deciding "on the ground", and it may turn out to be not good enough yet. But i don't see how a new emergency off system would be anything but a) a duplicate of parts of the logic already involved in the decision making process, and b) more complex than that which already exists.
It might - only might - make the pilot a part of those expressions. Specifically logic that inhibits desired behavior until all prerequisites have been met is something that should have an override switch. For several reasons. Everybody who has ever formulated a complex system in binary logic knows how difficult it is to put all allowable states into one, simplified expression and how even more difficult it is to specify all those states a propriori.
Also remember that any hardware component can develop a fault. Both solid state and mechanical devices can wear out/breakdown.
This is all being said by me as a no pro pilot who looks at those logic diagrams shaking his head. There's a certain level of arrogance in constructing such systems on the drawing board and thinking that they will include all possible states they will encounter later. In Warsaw, there was clearly a flaw found in the air-to-ground detection logic (requiring both sqat switches fully depressed before deploying ground spoilers) and in the case at hand, hypothetically, they might at least have left very little room for error.
I have not designed aircraft systems (thankfully, I doubt I could bear the responsibility) but I have worked with complex state machines for internet protocols. I remember that in one protocol (it might have been ppp) there's a state called "SOL" or "seriously out of luck". It is entered when the input just doesn't make any sense for the current state and it's used to reset the state machine to a defined state and continue.
The breaking and lift-dumping state machine of the AB seems to be designed without such a "reset" state. Again, from the diagrams, it sais "do nothing until all requirements are met". After the Warsaw accident, they've added a new state, "partially deploy spoilers". Why? because the inputs the system had back then did not meet the requirements to proceed to the next defined state, however, the physical airplane had long left the logical state the system thought it in and was no longer flying.
And in this case, again under the assumption that the root cause might have been a TLA>22.5° for the #2 engine, all signals were TRUE to go to state "on the ground" and activate breaking but this one. And an ambiguous one it is. The system remained in it's current state. Which would have contributed to the event.
It's been pointed out that out of 55 million landings, only a few ended like this one. Yes, but:
Every single event like this is too much, I don't think we'll have to argue that.
There are errors we will never be able to prevent. You can only have so many mechanical or electronical backup systems, there's always a chance that they all fail. But the logic behind the whole system should not have states where it's sitting like a dead duck, waiting for the next thing to happen, because you don't have a backup logic. The logic might be implemented in three different computer systems of two different brands in two different programming languages, it's still the same logic.
If there's a chance that a TL is malpositioned by human error (or mechanical error or sensor error) then that TL position must not be an
absolute inhibiting factor for a vital system such as deceleration.
That's where the override button might come in handy, even if it might not be a big red "safe me, now!" button but an internal "SOL" state.
pj