PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Rumours & News (https://www.pprune.org/rumours-news-13/)
-   -   C-FWGH 738 slow take off BFS : AAIB (https://www.pprune.org/rumours-news/599844-c-fwgh-738-slow-take-off-bfs-aaib.html)

Nantucket Sleighride 22nd Sep 2017 11:00

C-FWGH 738 slow take off BFS : AAIB
 
https://www.gov.uk/government/news/a...737-86j-c-fwgh

sounds like it could have been a lot worse

bob eric 22nd Sep 2017 15:15

Yet another example of a Pilot/Automation interface failure...

That's 'ok'...

However... what we continue to 'miss' is the back to basics of being a 'Pilot' of an aircraft.

What should be happening in this situation is clear... A 'thinks bubble'... 'Hey... why are we accelerating so slowly? Why is the runway end coming up? Mmmm, something is not right...

Reaction... before, or certainly past V1, we are now going flying. Lets apply full-power, manually (Firewall the trust levers) and get this aircraft into the air and climbing away. Sort out/discuss the cause later.

30+ years of check and training experience says one thing to me. This is a training issue... even probably a 'pilot selection' issue. And fundamentally, a regulator issue.

It starts with more than 'I have £100k, please make me a pilot' and should absolutely ensure that at 'ab-initio' and 'basic' flying training, commonsense and 'natural' pilot aptitude is followed up right through a pilots career/training.

Yes, we need more pilots and the demand for pilots is ever increasing. But this incident is a hairs breath away from yet another totally avoidable hull loss...

History is littered with similar incidents/accidents. The time will come where we reach tipping point on 'dumming' down selection and training versus front page 'newspaper' reports of yet another accident.

Do we have to wait for this? The 'threat' is clear. Lets do something about it now. There are more and more threat signals every year. That response must also include by-passing commercial pressures and e.g.: share and stakeholder budget cutting 2% YOY, in training and regulation. The industry at large, will be much better off as a result.

Airbubba 22nd Sep 2017 16:00

Another Friday night incident like the Air Canada 759 taxiway approach at SFO where the feds were unable to get the CVR (and FDR in this case) due to reporting delays and lack of weekend office hours.

From the AAIB Special Bulletin Introduction:


The event was not reported to the AAIB by the aircraft commander, aircraft operator or the tour operator on behalf of which the flight was being undertaken, although it was reported to the Transportation Safety Board in Canada by the aircraft operator.

At 2053 hrs on 21 July 2017, ATC personnel at the airport filed a Mandatory Occurrence Report (MOR) and sent a signal using NATS’s Aeronautical Fixed Telecommunications Network (AFTN), and the AAIB was one of the addressees on the signal. This system is only monitored by the AAIB during office hours and the message was not read until 0713 hrs on 24 July 2017 at which time an investigation was begun.

The delay introduced by these circumstances meant that Flight Data Recorder (FDR), Cockpit Voice Recorder (CVR) and other recorded data sources were unavailable to the investigation.

lomapaseo 22nd Sep 2017 16:42

Were any laws or regulations violated?

What were the corrective actions? were they airworthiness related or presumed crew or operator error?

DaveReidUK 22nd Sep 2017 17:31

The report (which can be read on the link in post #1) strongly suggests that the primary cause was the crew entering the wrong (TOC) OAT into the FMS, rather than the airfield OAT.

The error was compounded by the fact that the aircraft didn't have the latest FMS software version, which would have trapped that particular error.

G-CPTN 22nd Sep 2017 17:50

a. The expected top-of-climb outside air temperature (OAT) was entered into the OAT field on the n1 limit page instead of the OAT at the airport (a figure of - 52°C as opposed to +16°C); and
b. The correct assumed temperature of 48°C was entered into the FMC.

No other combination of data entries was found which would achieve the same result.

parkfell 22nd Sep 2017 19:51

81.5% N1 ~ should danger bells not have rung on stand, given 179 passengers (189 max) & the sector length (Corfu). A reasonably heavy ac, on a not exactly long runway for a -800
Had it been a short hop to say the Glasgow, & virtually empty, then a much lower N1 would have been generated by the FMC.
No point talking below about EPR values. The NG doesn't deal in that currency.

Simply a lack of airmanship & empathy. Clearly a training issue as well??

BOB ERIC is getting close to the truth......

And the penny is finally dropping with EMIRATES training dept as well according to pprune postings. No doubt pressure from above ?

SymbolA310 22nd Sep 2017 21:11

In my company we use derate and assumed thrust method. The other day we took of with 22k and mid 30 degrees
on the assumed temp. Result was 81% N1 and flaps 1. It is possible and you have to follow your SOP's very closely not to screw up. There have been lots of accidents and incidents entering data from the EFB into the FMC.
But I never heard someone entering the TOC temperature on the N1 limit page as OAT.
Training standards and SMS system should be reviewed in this company.

pilot9249 23rd Sep 2017 00:03

I would also gently question the certification of automation that doesn't even try to validate key inputs.

We've had thermocouples since about 1820.

paperHanger 23rd Sep 2017 01:31

Back to basics
 
If only they had built the aircraft with some sort of forward facing glass panel so the pilots could look forwards and take note of what was going on ..

I seem to be flying a lot of odd weight freight these days, and the "70% of V1 by 50% of the runway" rule works well for us. We aborted one last month that seemed a bit slow ... nailed it faster and harder the second time around and got the numbers up.

If you are just "flying the numbers" that the FMS says are right, then you are not a pilot, you are a passenger.

Capn Bloggs 23rd Sep 2017 02:11

Not mentioned was any cross-check of the N1 in the "documentation" (93.3) verses the N1 the FMS calculated (81.5). I assume we will read about the company procedures in the final report.

I don't fly the 737 but wouldn't the EFB also produce an N1, which would be crosschecked with the FMS?

Centaurus 23rd Sep 2017 02:48


What should be happening in this situation is clear... A 'thinks bubble'... 'Hey... why are we accelerating so slowly? Why is the runway end coming up? Mmmm, something is not right...

Reaction... before, or certainly past V1, we are now going flying. Lets apply full-power, manually (Firewall the trust levers) and get this aircraft into the air and climbing away. Sort out/discuss the cause later.
By coincidence an accurate description of what happened to me one night take off. . Actual event at night. A Pacific atoll runway 5600 ft long with the ocean at end of runway. B737-200. Planned 2.18 EPR with associated 101% N1. I was dead heading in the jump seat.

F/O was PM and captain set thrust levers to 2.18 EPR. Cockpit lighting dim due night. The difference between 101%N1 and 90% N1 on the needles was about 3mm and easily missed especially as both pilots were concentrating on the take off run and no visible horizon. All other engine instruments were parallel and in the needle positions where expected.

It was not possible to gauge exact rate of acceleration at night by seat of pants feeling. With about five runway lights to go, it became evident we were not going to get airborne by the end of the runway. The captain immediately took control, simultaneously fire-walled both engines and hauled back on the control column at what was then V1 minus 15 knots.

It was then an immediate kick in the back increase in thrust was felt. The FDR later showed we maintained 20 feet over the water for half a mile and before climbing even though the body angle was 15 degrees up. The high body angle caused the engines to blow ground debris back over the runway. . On fire-walling the engines the EPR shot up to 2.25 an unheard of figure in the JT8D-17 engines.

On setting 1.98 EPR eventually after flap retract, the rate of climb was significantly less than scheduled. Comparison between 1.98 EPR and expected N1 showed the N1 was down by 10%. The decision was made by the captain to return to land. Investigation revealed that both PT2 probes were blocked thus giving an erroneous EPR reading to the crew. In fact at 2.18 indicated EPR we actually got about 90%N1 instead of the planned 101% N1.

The point being made that it is difficult to accurately predict the rate of acceleration in airspeed between 101% N1 and 90%N1 until it may be too late with the end of the runway coming up fast - especially with lack of cues at night.

dixi188 23rd Sep 2017 05:50

N1 as a measure of thrust is more reliable than EPR as the Centaurus incident shows.

The amount of thrust is not directly proportional to % rpm though. I seem to recall that on the CF6-50 (approx 52000lbs thrust) the difference between 100% N1 and 95% N1 was about 10000lbs of thrust, ie. 20% of power. This on an A300.

As all big fan engines work the same way and most of the thrust is developed at the top end of the rpm range, I doubt they had anything more than about 50% of available thrust with an N1 of 81%.

Very lucky on that day!

Flap 80 23rd Sep 2017 05:54


Originally Posted by Nantucket Sleighride (Post 9900325)
https://www.gov.uk/government/news/a...737-86j-c-fwgh

sounds like it could have been a lot worse

Lower than expected N1 values as a result of erroneous EPR indication we're a contributory cause of the Air Florida B732 crash many years ago.
It is easier to cross check EPR with expected N1 at the commencement of the roll than judge acceleration rate.

RAT 5 23rd Sep 2017 07:17

Lower than expected N1 values as a result of erroneous EPR indication we're a contributory cause of the Air Florida B732 crash many years ago.
It is easier to cross check EPR with expected N1 at the commencement of the roll than judge acceleration rate.


indeed, and that became an SOP in my B732 outfit. Both numbers were written on the bug card.

Back to the topic incident. As Bob E says there is a lack of knowledge of the a/c today and application of gross error checks etc. It is a training issue, no doubt. Today's concept is learn how to use the EFB, learn how to program the FMC, learn the SOP's, learn to follow the FD & let the automatics do everything for you. "It's safer the way." Duh.
There is no feeling for what should be correct and if it ain't then something is wrong, so check it.

Increasing thrust during takeoff roll due to lacklustre acceleration is a good idea & reactive: checking the thrust setting after the calculation seems low is a good idea & is proactive. Which is better? But the latter can only happen if you've paid attention previously and not been a trained monkey.

Savannah Jet 23rd Sep 2017 08:17

Although not directly related to the OAT error which caused this incident, is anyone else reading this thread and the AAIB report wondering why it took the pushback crew to notice the nose gear tyres were so badly worn they both needed replacing before the airplane actually departed ? Surely an item that should have been spotted on the crews pre-flight inspection of the airplane. Did they miss it, or if they notice it, did they still deem the airplane airworthy ? Who would the pushback crew inform after they noticed this, apart from the crew ? And who would make the actual call to have them changed ? The crew or operator ? To me that points to lack of attention to detail and preparation. Maybe the FMC programming suffered the same way. Just a thought.

slowjet 23rd Sep 2017 09:06

BOBERIC; First post and excellent. Many others have repeatedly made similar comments. Selection is vital. Let anyone in with a fat wallet and error numero uno rears it's ugly head. Minimal initial and advanced training compounds the problem. Airline selection almost non-existent. Airline, minimal button pushing training ( even to CBT and "at your own pace" modules) and we have a woeful mix. SOP's that then discourage manual flying (because the new breed couldn't cope with the unexpected) and you are now heading for incident after incident culminating in a prang .


But the low cost operators and bean counters who insist on all this from the risk-free comfort of air-conditioned armchairs still have their way. And like the CEO of one messed up major carrier just stated; " Once trained, the pilot's job is easy" ! Couple of hull losses and a few near misses resulting in zero confidence by the customers might shake up that argument, a bit. But, I doubt it.

Mac the Knife 23rd Sep 2017 11:04

"a. The expected top-of-climb outside air temperature (OAT) was entered into the OAT field on the n1 limit page instead of the OAT at the airport (a figure of - 52°C as opposed to +16°C); and
b. The correct assumed temperature of 48°C was entered into the FMC."

When I write software (mostly medical) I take great care to "sanitise" operator input, i.e., make sure that it is likely or even possible. For example, in calculating fluid resuscitation there are cross-checks between the "date-of-birth", "age" and "weight" fields.

Entering a 48kg for a 1-year-old will generate an explanatory error - "Do you really have a 1-year-old who weighs 48kg. Input refused."

The OAT at Belfast may have been -52degC during the last Ice Age but it is way out of the normal in 2017.

Making sure that all inputs are sane is a chore and can make up as much as 50% of the code, but everyone can make mistrakes and one must check of them.

RAT 5 23rd Sep 2017 11:56

a. The expected top-of-climb outside air temperature (OAT) was entered into the OAT field on the n1 limit page instead of the OAT at the airport (a figure of - 52°C as opposed to +16°C); and
b. The correct assumed temperature of 48°C was entered into the FMC."


There also seems to be a lack of X-checking by both plots of data entered into their electronic toys. How does it work in most airlines? Do both pilots make takeoff performance calculations independently on their own i-pads as a X-check, or is it just one who does it? And even then, is the data entered read out by the other or is it just a one man band calculation? If the latter then there really is a chance of an unmonitored screw up.

DaveReidUK 23rd Sep 2017 16:43


Originally Posted by Mac the Knife (Post 9901431)
Making sure that all inputs are sane is a chore and can make up as much as 50% of the code, but everyone can make mistakes and one must check of them.

As the AAIB report makes clear, a sanity-check on the entered OAT is a feature of later releases of the FMS software on the 737NG, hence the Safety Recommendation that the FAA mandate use of those subsequent revisions.


All times are GMT. The time now is 04:24.


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