Flap handle. Should be kept for backup only and a new logic incorporated in speed modes allowing flaps extension for slowing down. EGPWS will yell at you TOO LOOW GEAR/FLAPS but no piece of automation here...still manually have to lower the gear. Even 3 radio altimeters not sufficent to tell that we can safely raise the gear automatically. We have auto slats but no auto flaps.
You have raised some very interesting points. The one I have quoted above is another instance of the Automation vs Control debate. Not everything can be developed from the pilots’ use-case. Redundancy, reversion and BITE data-validity checking may be going on of which you are not aware. What level of abstraction is reasonable ? At what level would you want to interrupt the automation workflow if a fault develops (assuming it is safe to do so) ?
The important thing is to avoid latent failures. It is very difficult to establish the impact of
partial loss of inputs to a complex system, in order to allow continued operation. Which functionality of the equipment is still OK ? It is safer to declare the unit non-functional and switch to an alternative. So I agree a “partially failed” indication as mentioned elsewhere in your post is not very helpful !
It is very complicated for a pilot to write down a robust spec to an engineer.
It is very easy for the engineer to implement the IF ...CONDITION then ACTION from the spec, but it is awfully complicated to write a ELSE if nothing is given in the spec.
Most of the problems are coming for this missing statement (unspecified). And it is getting worse because of commercial pressure( shorter coding, testing, integration, robustness test time), more and more combination of conditions are remaining untested or deliberately put into the class "unlikely to occur".
It is not possible to cover testing of all combinations of input scenarios, but the classification DO-178B (Airborne Software Considerations) identifies categories of software an applicable levels and type of testing required. A hazard-analysis bottom-up (what-if ?) and a Fault Tree top-down (what-could-cause-this-top-level-event ?) should cover hazardous events and identify mitigation to reduce to risk of the outcome.
Getting users, even highly trained and intelligent-ones like pilots (!) to express their requirements is difficult and is often based on “I want it like this - but better”. It needs to be related to a specific aspect of an existing system of an available prototype to demonstrate the concept.
I would be interested to know your views of data-fusion, and integration of equipmnet displays and data sources.
hugel