In my glider club when flying 2 seat gliders, the procedure for handing control of the airplane from one pilot to the other is; PF – “You have the airplane”, PNF – “I have the airplane”, or vis-versa, depending on who initiates the control transfer. In automated systems, control transfer is not always this clear (but should be). In previous posts I’ve quoted Jef Raskin, but now I’ll start quoting Charles Billings (specialist in aeromedical research who has worked for NASA). Here’s an interesting summary article regarding his theories, which he wrote a few years ago discussing human factors in automated systems and aviation.
http://www.ifp.uiuc.edu/nsfhcs/talks/billings.html
He defines a series of principles regarding the human factors in the design of automated systems. Each item listed below is explained a little more clearly in the summary article.
First Principles of Human-Centered Systems
- Premise: Humans are responsible for outcomes in human-machine systems.
- Axiom: Humans must be in command of human-machine systems.
- Corollary: Humans must be actively involved in the processes undertaken by these systems.
- Corollary: Humans must be adequately informed of human-machine system processes.
- Corollary: Humans must be able to monitor the machine components of the system.
- Corollary: The activities of the machines must therefore be predictable.
- Corollary: The machines must also be able to monitor the performance of the humans.
- Corollary: Each intelligent agent in a human-machine system must have knowledge of the intent of the other agents.
My aviation career was in flight simulators long ago, but my more recent experience has been in business, and I've dealt with the automation of business processes for more than 2 decades now. In that time, I've seen a lot of mistakes with automation, and I've come up with my own list of rules for the proper application of automation to processes. I think some are applicable to aviation.
- The automated process design must always remain customer focused (meaning error free outcome focused).
- The smartest computer in the process in the only one that can think outside the limitations of the flow chart (the human computer).
- Do not try to design to accommodate all problems, all variables and all situations, because you can't. At best you can only accommodate the most common problems, the human operator will have to take care of the rest.
- Keep the human operator informed at all times of the state of the process.
- Build in secondary flow paths wherever possible, so the process can continue in a degraded mode, while the primary flow path is unserviceable and under repair.
- If a secondary flow path is not possible, build in buffering so the process can continue for a time until repaired.
- Provide for clear, controlled and easy to understand manual intervention in the process.
- Provide checks for human errors during manual intervention, so mistakes are caught before they become serious.
- Make the delineation between the computer and the human absolutely clear and unambiguous, as to who is running the process.
Curt Graeber, Chief Engineer Human Factors Engineering, of Boeing, made the following comments in a Boeing Aeromagazine article.
Appropriate degree of automation.
Boeing flight decks are designed to provide automation to assist, but not replace, the flight crew member responsible for safe operation of the airplane. Flight crew errors typically occur when the crew does not perceive a problem and fails to correct the error in time to prevent the situation from deteriorating. Consequently, Boeing flight decks incorporate intuitive, easy-to-use systems. These systems support instrument displays with visual and tactile motion cues to minimize potential confusion about what functions are automated. In the fly-by-wire 777, visual and tactile motion cues are provided by backdriven controls. These controls reinforce situational awareness and help keep the flight crew fully aware of changes occurring to the airplane’s status and flight path during all phases of automated and manual flight.
One of the most common mistakes I see in automation is attempts to over automate processes. The result is a process that fails unexpectedly for mysterious reasons and without timely notification of the failure to the process monitors and operators. I think one of the reasons for this is the idea of artificial intelligence where a computer and software can accommodate all variables and all conditions. In reality this is fiction and is not possible. The computer will always be limited by the flow chart and the logic built into the program. It can never do more that the sum of its program logic, and that logic can never accommodate all possible variables and conditions. Because the human mind is more creative and an infinitely better problem solver, it will always be the smartest computer in a process. The computer however can assist the human in its main weakness, which is making mistakes when performing routine repetitive tasks. The strength of each can accommodate the other's weakness, as they are very complimentary.
In the A320, I believe the design philosophy was overly ambitious from the beginning. The A320 was the first of it's kind in FBW airliner design, and l believe later designs have learned from the A320 experience.
In Bernd's post #1837 he said,
As to the workings of the thrust levers: it is really terribly simple, and a confusion very unlikely:
In a normal flight you really only need three positions. This flight was no different:
- FLX/MCT (or possibly TOGA in certain conditions) from takeoff to thrust reduction. This gives flexible (or maximum) take-off power and arms autothrust.
- CL throughout the entire flight from thrust reduction to flare. This activates autothrust, previously armed by setting (flexible or maximum) takeoff power.
- IDLE during flare.
I think it's not really this simple. How wonderful to think an automated system could make the speed control of an airliner this simple, but in reality it cannot. This represents an overly ambitious design effort that cannot accommodate all the variables and conditions one can encounter.
From my Six Sigma training and time spent applying it, I have learned that exceptionally low error rates usually only happen in manufacturing environments where the variables can be limited and controlled. In service oriented processes, the variables are usually much larger in number and many are usually beyond control. The human often has to intervene is these cases. It’s much easier to control the variables when manufacturing an airliner, than it is to control the variables when an airliner is used in service.
The landing of an airliner is not always predictable and the human is subject to making an error when performing a repetitive task during landing. Thus I find it hard to believe that the pilots of the TAM A320 were allowed to get into the situation that killed them. Once they deployed thrust reverse on ENG1 while leaving ENG2 thrust lever in the CLB detent during touchdown, the accident had already happened. Correct me if I’m wrong, but doesn’t the 737 for example prevent such an occurrence (with a lockout), by not allowing the pilot to put an engine in reverse if the other throttle lever is not in idle? This preserves the go-around option which was lost with the TAM A320.
Who has the airplane in regards to speed control? Once the pilot selected reverse thrust for ENG1 in those conditions, who had control over the aircraft’s speed on the ground? Because the airplane allowed the asymmetric reverser deployment (automation or even mechanically not watching over the pilot), the ground spoilers and auto brakes did not respond correctly to these conditions. Yes, these systems responded to their control logic, but that was all they could do, as they could not go beyond their control logic to assist in this particular set of circumstances. Of course there was no override of the ground spoilers available to the pilots (overly ambitious automation design that assumed it would never be needed), which I’m sure they would have used (if available) due to the fact that they cycled the arming of the spoilers to try and stop. They had manual brakes, but no manual spoilers, thus who had control over the speed of the airplane on the ground was ambiguous.
I think the H2F3 software modification is helpful, but less than a satisfactory solution. I think it better to prevent the pilots from entering into this single TR thrust lever coffin corner, than to warn them about it once they’re in it already.
I could go on, but will stop here as I have to go.