PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Rumours & News (https://www.pprune.org/rumours-news-13/)
-   -   Hanscom G-IV Crash - NTSB probable cause (https://www.pprune.org/rumours-news/567550-hanscom-g-iv-crash-ntsb-probable-cause.html)

b1lanc 11th Sep 2015 22:25

Hanscom G-IV Crash - NTSB probable cause
 
How does a professional crew with a combined 29000+ hours and flying together for 12 years get into a routine of "habitual noncompliance with checklists"?

http://www.ntsb.gov/news/press-relea...R20150909.aspx

B2N2 12th Sep 2015 01:34


flying together for 12 years
You've answered your own question.
Human factors, you get too 'comfortable' with each other.

This is troubling:


However, the investigation revealed that Gulfstream did not ensure that the gust lock system would sufficiently limit the throttle movement on the G-IV airplane, which allowed the pilots of the accident flight to accelerate the airplane to takeoff speed before they discovered that the flight controls were locked

The NTSB said that the Federal Aviation Administration’s certification of the gust lock system was inadequate because it did not require Gulfstream to perform any engineering certification tests or analysis of the G-IV gust lock system to verify that the system had met its regulatory requirements.

Also contributing to the accident were Gulfstream’s failure to ensure that the gust lock system would prevent an attempted takeoff with the gust lock engaged and the FAA’s failure to detect this inadequacy during the G-IV’s certification.

archae86 12th Sep 2015 02:59

Continue when locked?
 
Not a pilot, but a former reliability guy for the major microprocessor manufacturer, and well aware that routine checks can get skipped by human beings who don't think they'll ever catch anything. But I'm genuinely puzzled by this:


About 26 seconds into the takeoff roll, when the airplane had reached a speed of 148 mph (129 kts), the pilot in command indicated that the flight controls were locked, but the crew did not begin to apply the brakes for another 10 seconds and did not reduce engine power until four more seconds had passed.
My guess it that despite the recorded comment, somehow internally there was some combination of disbelief and of "success orientation", but that is a pretty wild guess.

atakacs 12th Sep 2015 06:11

Hanscom G-IV Crash - NTSB probable cause
 
Quick question: is the a way to unlock the flight control from the cockpit? Would that be an option instead of rejecting the take off?

fullforward 12th Sep 2015 06:21

Attack
 
There is: if you read the NTSB report you'd learn that the system incorporates a feature supposed to prevent the throttles to be advanced with flight controls locked. It simply didn't performed as supposed to.

What you suggest would be expensive and/or difficult to certificate.
Furthermore, it's impossible to design an airplane that protect itself from pilots displaying a complete lack of airmanship.

atakacs 12th Sep 2015 06:48

Hanscom G-IV Crash - NTSB probable cause
 
Sorry maybe I did not spell out my question correctly. I understand that the built in safeguard has failed here. My question was more: was there another option to the (late) RTO ? Could they have taken the aircraft into the air after having the flight control unlocked ?

olasek 12th Sep 2015 10:51


. I understand that the built in safeguard has failed here.
Your understanding is wrong. What failed here were pilots who failed to perform basic checklist.

peekay4 12th Sep 2015 10:54


Could they have taken the aircraft into the air after having the flight control unlocked ?
The Gust Lock is operated from the cockpit, via a lever near the flap handle. However, the gust lock cannot be disengaged if the Flight Power hydraulic assist system is already loading on the flight controls.

So normally the gust lock must be released early in the checklist, when the hydraulic system still unpressurized before the engine is started. Otherwise the gust lock will remain engaged until the engines are shut off again and hydraulic pressure is removed.

There is a Flight Power Shut-off Valve (FPSOV) which can be pulled in an emergency in case there is a jam in the hydraulic system. The FPSOV will relieve the hydraulic pressure. It can also be used as an unapproved way to disengage the gust lock once engines have been started (e.g., during taxi).

There's evidence that the crew pulled the FPSOV. But, it is not known if pulling the FPSOV during a take-off run will successfully disengage the gust lock, because now we're dealing with aerodynamic pressures loading on the flight controls, in addition to the hydraulic pressure.


"the pilot in command indicated that the flight controls were locked, but the crew did not begin to apply the brakes for another 10 seconds and did not reduce engine power until four more seconds had passed."

My guess it that despite the recorded comment, somehow internally there was some combination of disbelief and of "success orientation", but that is a pretty wild guess.
Part of the reason is that they did not discover the issue until after v1, when they attempted to rotate. Pilots are trained with the mindset that problems before v1 == rejected take-off, while anything > v1 means continuing the flight.

Another reason is they might have initially thought that they were having a power hydraulics issue and so they tried to solve it by pulling on the FPSOV handle (as above) and tugging on the flight controls.

Car RAMROD 12th Sep 2015 11:00

Pulling the FPSOV also disabled the ability to deploy the spoilers didn't it? That didn't help in the reject attempt.

The biggest issue is the lack of control checks. Whilst there may well indeed have been a fault/flaw with the gust lock mechanism which may have actually engaged as they started rolling down the runway- IF the crew had of been more professional and done a successful FULL control check prior to that takeoff I would expect that at the first sign of lack of control when barrelling down the runway their decisions and actions would have been different. I know mine would... Let's see I just did a successful control check before applying takeoff power, now my elevators are jammed and the lock is on and not releasing. No hope of getting airborne let's abort!

Miles Magister 12th Sep 2015 11:49

Control Checks
 
This poor practice and lack of knowledge is unfortunately not uncommon.

Not too long a go I was flying for a European scheduled airline as a line training and checking captain where I routinely saw the FOs do the control checks then if it was windy put the control locks back in. They would rely on memory to remove them before take off but never considered doing another control check.

The fact that I saw many different FOs do this indicates that it was normal practice in the airline which was also backed up by my questioning of the crews. They also saw nothing wrong with it and considered it to be normal practice. Believe it or not a couple even thought I was being awkward by insisting on a control check every time the locks were removed.

This unfortunately happens when small isolated groups of people do not either have or seek outside input to their operation.

MM

RAT 5 12th Sep 2015 12:05

So normally the gust lock must be released early in the checklist, when the hydraulic system still unpressurized before the engine is started. Otherwise the gust lock will remain engaged until the engines are shut off again and hydraulic pressure is removed.

This strikes as a classic case for having a takeoff configuration warning horn fitted, as per most airliners. This would act as a back up to the other system preventing takeoff power being selected, which didn't work.

Part of the reason is that they did not discover the issue until after v1, when they attempted to rotate. Pilots are trained with the mindset that problems before v1 == rejected take-off, while anything > v1 means continuing the flight.

At the end of the takeoff/RTO brief it usually goes on the "or if the a/c is unsafe to fly." Even if >V1 this scenario seems to fit into this category. How long was the runway? On longer than required runways stopping after V1 is often not a problem; if you react soon enough. There might have been a moment of astonished disbelief frozen in the headlights phobia.

LLuCCiFeR 12th Sep 2015 12:37


Also contributing to the accident were Gulfstream’s failure to ensure that the gust lock system would prevent an attempted takeoff with the gust lock engaged and the FAA’s failure to detect this inadequacy during the G-IV’s certification.

Amazing! := :ugh:

olasek 12th Sep 2015 15:57


Excessively harsh comment and i take offense to it.
I don't, the comment is justified in view of this... , quoting AOPA:

"A review of the flight crew’s previous 175 flights revealed that the pilots had performed complete preflight control checks on only two of them. The flight crew’s habitual noncompliance with checklists was a contributing factor to the accident.”

No Fly Zone 12th Sep 2015 17:22

Easy Answer? No Such Thing
 
As others properly note, they got into this situation for exactly the reasons that the thread opener asks. High-time, long personal association, long experience on type (probably the same specific aircraft) and the like. Habits like these are nearly impossible to break and comments like, "We always do it this way," and "We know this airplane inside and out," are not rare.
One of the genuine hallmarks of the 'real' professional is to assume nothing and conduct the inspections and setups from scratch, Every Single Time. As this situation demonstrates, super-efficiency and perhaps saving a whopping five minutes is never worth the risk.
I do not know how to break that mold, but I hope someone figures out a good way to do so.
I must add that I do NOT understand how/why any pilot would/could release brakes without first performing a full range control surfaces test. If the results dictate a shutdown and further inquiry, so what? Even a C172 student pilot understands that one cannot control an airplane with locked controls - and V1 is darn sure not the place to discover the problem. Ouch!

B2N2 12th Sep 2015 17:55

Screw AOPA, that comment si from the NTSB report.


I don't, the comment is justified in view of this...
In any case, Let him who is without sin cast the first stone comes to mind.
  • The crew failed
  • The airplane failed
  • Gulfstream failed
  • The FAA failed

This is why an accident seldom has a single cause.

http://s3.amazonaws.com/rapgenius/Swiss-Cheese.jpg

RAT 5 12th Sep 2015 19:56

The crew failed
The airplane failed
Gulfstream failed
The FAA failed


And what % of causal blame do you attribute to each? It would seem your list is in reverse order of occurrence, slightly. I'd put FAA at No.2., but still reverse order.

His dudeness 12th Sep 2015 20:06


This unfortunately happens when small isolated groups of people do not either have or seek outside input to their operation.
Has happened to operators with huge fleets and huge numbers of pilots as well. E.G. the takeoff warning CB in DC-9ers or was it the MD s in an american carrier that led to an flap/slatless T/O attempt...

Feathered 12th Sep 2015 21:49

See also my post in the GA Forum thread on the KBED accident (below). Such a shame that the crew realized a problem early on per the NTSB video but by the time they took action to stop, it was too late.

http://www.pprune.org/biz-jets-ag-fl...ml#post9111459

Smilin_Ed 12th Sep 2015 21:50

100%
 

And what % of causal blame do you attribute to each? It would seem your list is in reverse order of occurrence, slightly. I'd put FAA at No.2., but still reverse order.
All four get 100%. Had any one of them done the job correctly, this accident would not have happened. :ugh:

LLuCCiFeR 12th Sep 2015 22:07


This is why an accident seldom has a single cause.
And that's why there will always be pilots on airplane: to ensure that the big corporations, airlines, aircraft manufactures and 'regulators' will walk away with a light slap on the wrist at the most.


All times are GMT. The time now is 16:05.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.