PPRuNe Forums - View Single Post - Computers in the cockpit and the safety of aviation
Old 3rd Jul 2011, 13:58
  #172 (permalink)  
alf5071h
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,257
Likes: 0
Received 1 Like on 1 Post
TM, there’s no thread drift if you consider the effects of technology; this becomes a good example of potential problems of ‘computers in the cockpit’.

I would be very surprised if Boeing recommended (officially) a ground speed (GS) check during take-off. Where does GS come from, how accurate, update rate, etc, etc, and what time is available for a crew member to look and crosscheck? You mention some of the problems.
The ‘availability’ of GS is an artefact of technology – “let’s use it because it’s there”, without thought to the added complexity and potential for confusion.

Why do we check/crosscheck ASIs?
With old steam driven systems, as you say, - a gross error check.
However, with modern technology, many ADC driven instruments have a comparator alerting system, either ‘Speed’ or for the total system, ‘ADC’.
So the take-off SOP could be simplified by deleting the speed check and relying on the comparator; but is that warning one of those inhibited during take off? If so, would that imply that the malfunction (amber level) does not pose significant risk, certainly not sufficient for rejecting at high speed?

Operators may still call 80kts or similar as an indication of the takeoff progress, or because it could reduce the PF task of glancing into the flight deck.
Or is the call an acceleration check? If so, how would such a system be used, what action might ensue (speed requires a function of time for acceleration, humans are poor time keepers). Speed trend is a form of acceleration (check exact computation and smoothing), but do the crew know what specific value is required for each take-off? Perhaps they are only familiar with a range of values (approximations) gained from experience.
Most aircraft have a designated engine thrust parameter, if that value is set and maintained then the take-off thrust is assured (providing the value has been calculated correctly). A reduction in the thrust parameter should be part of the engine failure process; If engine failed, Then …
Keep SOPs simple, practical, meaningful.

Most of the above is just my view of what you posted, but skewed by technology (automation, computers in the cockpit).
With increasing use of technology there is opportunity for operators to mis-judge the effects of ‘change’, to carry on using the same old procedures (complacency), or unwittingly add unnecessary complexity – ‘because it seems like a good idea’ – “it improves safety”.
Is - 'use it because it's there', a failed application of CRM - see adjacent thread.

Unfortunately many of the technology inspired changes, particularly in SOPs involve weak or inaccurate risk assessment which may not improve safety. Technology is not the cause of this, it’s human judgement; and judgement is part of ‘airmanship’, except in this instance it should be exercised by management and regulators, who have to apply professionalism.
alf5071h is offline